SENT Interfaces¶
The AutobusGW C24S6 provides 6 J2717 TM SENT ports on the front panel. The SENT interfaces are implemented in FPGA and therefore provide jitter-free operation. The supported mode of operation in firmware version 1.x is slave mode, used to emulate sensors on a SENT bus.
Operating the SENT interfaces requires first configuring the interface and then successively updating the payload data with the required data. These two steps are described in the following sections. Payload update is possible using REST API and TCP at the same time.
The SENT interface supports all fast channel modes defined in the SENT standard document revision April 2016. Slow channel is also supported in all modes: off, short, enhanced with config bit = 0, enhanced with config bit = 1. The SPC enhancement (short PWM code) is also supported, which allows the SENT slave to only respond to master trigger pulses which have a specified duration.
Configuring SENT Interfaces¶
The configuration of SENT ports is achieved using the array of sentconfig struct sent_channel_config located under /sent/config, reachable via HTTP GET and PUT requests.
Every array element of sent_channel_config contains the configuration of a single SENT channel and has the following paramters:
- enabled (bool)
- The port is enabled if this is set to true.
- ut_in_us (uint32)
- The desired SENT UT (Clock Tick Time) in microseconds. According to the standard, values between 3 microseconds and 90 microseconds. Legal values are more relaxed between 1 microsecond and 100 microseconds.
- fast_channel_mode (uint32)
This defines the operation mode of the fast channel. See table below for the meaning of all valid values:
Value Operation Mode Description 0 H.1 Two 12-bit fast channels (6 data nibbles) 1 H.2 One 12-bit fast channel (3 data nibbles) 2 H.3 High-speed with one 12-bit fast channel (4 data nibbles, where only values 0-7 are used) 3 H.4 Secure sensor with 12-bit fast channel 1 and secure sensor information on fast channel 2 (6 data nibbles) 4 H.5 Single sensor with 12-bit fast channel 1 and zero value on fast channel 2 (6 data nibbles) 5 H.6 Two fast channels with 14-bit fast channel 1 and 10-bit fast channel 2 (6 data nibbles) 6 H.7 Two fast channels with 16-bit fast channel 1 and 8-bit fast channel 2 (6 data nibbles) - slow_channel_mode (uint32)
This defines the operation mode of the slow channel. See table below for the meaning of all valid values:
Value Operation Mode Description 0 OFF No slow channel data. 1 SHORT Short slow channel mode. The 4-bit message ID, 8-bit payload, and 4-bit CRC are sent on bit 2 of the status nibble. 2 ENHANCED_C0 12-bit Data and 8-bit message ID. Configuration bit = 0. 3 ENHANCED_C1 16-bit Data and 4-bit message ID. Configuration bit = 1. - pause_enabled (bool)
- Setting this to true will enable the pause pulse. The pause pulse allows all frames to have equal length (set in pause_frame_target_in_ut) regardless of data content. Since the SENT protocol encodes data in pulse lengths, the length of every frame is dependent on the data content of the frame.
- pause_frame_target_in_ut (uint32)
- if pause_enabled is set to true, a target frame duration in UT (clock ticks) must be defined here. Valid values are [0 -> 1000]. If the target frame duration is shorter than the actual frame duration, no pause is generated.
- spc_mode_enabled (bool)
- If enabled, enables SPC (short PWM code) mode. In this mode, the SENT slave only responds to a master trigger pulse if the master trigger pulse is between spc_mode_mtrig_min_ut and spc_mode_mtrig_max_ut.
- spc_mode_mtrig_min_ut (uint32)
- If spc_mode_enabled is true, sets the minimum duration of the master trigger pulse in UT’s.
- spc_mode_mtrig_max_ut (uint32)
- If spc_mode_enabled is true, sets the maximum duration of the master trigger pulse in UT’s.
Updating the /sent/config array will cause all SENT ports to be reloaded. Alternatively, starting v2.3.6, it is possible to access a single port’s configuration using /sent/config/<int:ch>. The channel numbering matches the front panel numbering and is a zero-based index. To get the config struct of channel 0 the URL /sent/config/0 must be accessed.
Updating Payload with REST API¶
Updating the payload of SENT interfaces is achieved the sent_data struct sent_data located under /sent/data/<int:ch>. HTTP GET and PUT requests are supported to get and set new values, respectively. The channel numbering matches the front panel numbering and is a zero-based index. To get the payload struct of channel 0 the URL /sent/data/0 must be accessed.
Every payload struct has the following members:
- payload_status (uint32)
- This field encodes the data to be transmitted in the STATUS nibble. Higher order bits of the supplied integer are ignored.
- payload_fast_ch1 (uint32).
- This field encodes the data to be transmitted in via fast channel 1. Depending on the fast channel mode, different number of least significant bits will map to payload data. Higher order bits of the supplied integer are ignored. Possible nibble swapping is handled by the hardware and should not be done by the user.
- payload_fast_ch2 (uint32).
- This field encodes the data to be transmitted in via fast channel 2 (if fast channel 2 is active). Depending on the fast channel mode, different number of least significant bits will map to payload data. Higher order bits of the supplied integer are ignored. Possible nibble swapping is handled by the hardware and should not be done by the user.
- payload_slowchannel_id (uint32).
- This field encodes the data to be transmitted in the slow channel ID field (if slow channel is active). Higher order bits of the supplied integer are ignored.
- payload_slowchannel_data (uint32).
- This field encodes the data to be transmitted in the slow channel DATA field (if slow channel is active). Higher order bits of the supplied integer are ignored.
Since updating payload is asynchronous to SENT frame transmission, it is possible to update the payload during a SENT frame transmission. This can safely be done since the hardware implementation always makes sure that a consistent message gets transmitted before latching in the new values into the internal snapshot registers.
SENT TCP Interface Configuration¶
In case frequent updates to the SENT Payloads is desired, it is possible to send the desired Payload Data using a binary TCP interface. Updates to all SENT ports are handled using a single TCP port. Up to 30 concurrent client connections are allowed to the SENT TCP server.
In order to enable the SENT TCP interface, it is requied to write the property tcp_port inside the node /sent/tcp_config usign an HTTP PUT. After this, it should be possible to connect to the SENT TCP port.
Writing updates using the REST API will directly update the hardware and will not go to the software cache. It is however possible to read back the currently active payload data using the REST API, regardless of how it was initially set (REST API or TCP API).
SENT TCP Interface Operation¶
The SENT TCP interface is implemented similarly to the CAN TCP interface. A single TCP client may update payload for any SENT port.
The required TCP Frame format is shown below:
struct sent_frame_tcpformat {
uint32_t update_hw_bitmask; /*one bit per SENT port. Examples: 1: port0, 2: port1. 3: port0 + port1*/
uint8_t port0; /*zero based port number. Example range for 6 ports: [0:5]*/
uint8_t reserved_bytes[3];
uint32_t payload_status;
uint32_t payload_fast_ch1;
uint32_t payload_fast_ch2;
uint32_t payload_slowchannel_id;
uint32_t payload_slowchannel_data;
};
The SENT TCP server has an internal cache of payload data. Writing to a particular port will only update the internal cache, if the proper update_hw_bitmask field is not set. The update_hw_bitmask field serves to order the software to transfer payload cache of the selected ports into the hardware, allowing synchronized payload update of multiple ports. The payload data in a TCP Frame is first written into the cache before processing the update_hw_bitmask field.
The cache allows for synchronous update of SENT channels. The user could for example update port0 without setting any bits in update_hw_bitmask (value of 0) and then send another frame which updates port1 payload while setting update_hw_bitmask = 3. This will signal the update of SENT ports 0 and 1 synchronously after the payload cache of port1 has been updated.