ELLSI. EtherCAN Low Level Socket Interface. Software Manual. to Product C.2050.xx and C.2051.xx

Transcription

1 ELLSI Software Manual to Product C.2050.xx and C.2051.xx Software Manual Rev. 1.5 Page 1 of 26 esd electronic system design gmbh Vahrenwalder Str Hannover Germany Fax: 0511/ Phone: 0511/ International:

2 N O T E The information in this document has been carefully checked and is believed to be entirely reliable. esd makes no warranty of any kind with regard to the material in this document, and assumes no responsibility for any errors that may appear in this document. esd reserves the right to make changes without notice to this, or any of its products, to improve reliability, performance or design. esd assumes no responsibility for the use of any circuitry other than circuitry which is part of a product of esd gmbh. esd does not convey to the purchaser of the product described herein any license under the patent rights of esd gmbh nor the rights of others. esd electronic system design gmbh Vahrenwalder Str Hannover Germany Phone: Fax: info@esd.eu Internet: USA / Canada: esd electronics Inc. 525 Bernardston Road Suite 1 Greenfield, MA USA Phone: Fax: us-sales@esd-electronics.com Internet: All trademarks, product names, company names or company logos used in this manual are reserved by their respective owners. Page 2 of 26 Software Manual Rev. 1.5

3 Document file: I:\Texte\Doku\MANUALS\PROGRAM\CAN\ELLSI\Ellsi_Manual_en_15.wpd Date of print: ELLSI version: Changes in the chapters The changes in the document listed below affect changes in the firmware as well as changes in the description of facts only. Chapter Changes versus previous version 2.2 New chapter 2.2 Port inserted. Technical details are subject to change without further notice. Software Manual Rev. 1.5 Page 3 of 26

4 This page is intentionally left blank. Page 4 of 26 Software Manual Rev. 1.5

5 Contents 1. Introduction Intention Functional Principle ELLSI vs. esd NTCAN API Restrictions ELLSI API Number of Client Connections TCP/IP vs. UDP/IP CAN Interaction Some Thoughts about Performance The ELLSI-Protocol Data Layout Byte Order Header Sequence Numbering Commands Numerical Values of Commands Numerical Values of Sub-Commands ELLSI_CMD_NOP laststate for ELLSI_CMD_NOP ELLSI_CMD_REGISTER laststate for ELLSI_CMD_REGISTER ELLSI_CMD_REGISTERX ellsiextregistration laststate for ELLSI_CMD_REGISTERX ELLSI_CMD_CAN_TELEGRAM ellsicmsg_t laststate for ELLSI_CMD_CAN_TELEGRAM ELLSI_SUBCMD_TXDONE ELLSI_CMD_HEARTBEAT laststate for ELLSI_CMD_HEARTBEAT ELLSI_CMD_CTRL ELLSI_IOCTL_CAN_ID_ADD/DELETE ellsicanidrange laststate for ELLSI_IOCTL_CAN_ID_ADD/DELETE ELLSI_IOCTL_CAN_SET_BAUDRATE Baud Rate Values laststate for ELLSI_IOCTL_CAN_SET_BAUDRATE ELLSI_IOCTL_CAN_GET_BAUDRATE laststate for ELLSI_IOCTL_CAN_GET_BAUDRATE ELLSI_IOCTL_SET_SJA1000_ACMR Mapping of ACR / AMR to CAN ID in a 29-Bit Frame laststate for ELLSI_IOCTL_SET_SJA1000_ACMR ELLSI_IOCTL_GET_LAST_STATE ellsilaststate ELLSI_SUBCMD_AUTOACK Software Manual Rev. 1.5 Page 5 of 26

6 This page is intentionally left blank. Page 6 of 26 Software Manual Rev. 1.5

7 Introduction 1. Introduction 1.1 Intention ELLSI offers the possibility to use an esd EtherCAN on all platforms not (yet) supported by esd NTCAN drivers (e.g. Mac OS, PLCs with Ethernet capability, etc.). The standard NTCAN over Ethernet functionality is still usable in parallel to ELLSI. However, for all platforms with an existing NTCAN driver, we suggest to use NTCAN instead of ELLSI for communication with the esd EtherCAN. 1.2 Functional Principle We tried to develop ELLSI as simple as possible. We don't provide an API to use ELLSI, but there is some sample code, which should help you to build such an API yourself. Using ELLSI is "simply" assembling UDP-datagrams plus transmitting them to the ELLSI-server on the esd EtherCAN and analysing UDP-datagrams obtained from the ELLSI-server on the esd EtherCAN hardware. At first the ELLSI-client has to register itself at the ELLSI-server. After this, both sides have to send heartbeat-messages at regular intervals if there is no data exchange. If the client has not received any data or heartbeat from the server within a given time interval, the client will assume that the server has disappeared. Maybe the network connection is broken, somebody did a reset on the EtherCAN, etc. In consequence of this, the client has to try to register at the server again. If the server has not seen any data or heartbeat from the client within a given time interval, it assumes the client has disappeared. The server no longer transfers any data and heartbeat to the client then. After the client has registered itself, it must set a baud rate and enable all CAN IDs it wants to receive data for. Now the client is ready for transmission and reception of CAN telegrams. To be sure CAN telegrams are sent / received in correct order, there is a sequence number. 1.3 ELLSI vs. esd NTCAN API esd carefully tried to develop ELLSI as compatible as possible with the standard esd NTCAN API. We would therefore recommend to read the esd NTCAN API documentation in parallel to this document. The esd NTCAN API documentation far often delivers more detailed information about the esd NTCAN philosophy then this document. Software Manual Rev. 1.5 Page 7 of 26

8 Introduction 1.4 Restrictions ELLSI API esd electronics does not support and maintain an official API for ELLSI, but you can use the provided examples, in particular ellsicommon.c, ellsicommon.h in combination with ellsiclnt.c and ellsiclnt.h as a base for your personal ELLSI API. For all platforms with an existing NTCAN driver, we suggest to use NTCAN instead of ELLSI for communication with the esd EtherCAN Number of Client Connections The number of client connections to the ELLSI server is currently limited to 5, to not overstrain the EtherCAN hardware TCP/IP vs. UDP/IP At the moment the ELLSI-server only supports UDP. For future versions it is planned to also support TCP-connections CAN Interaction The standard esd NTCAN drivers maintain a feature called interaction. This feature allows CAN messages transmitted on a certain CAN ID on a certain CAN bus also to be received by other processes reading CAN messages on the same physical CAN bus (CAN card). ELLSI does not support this feature in the current release. But for future releases it is planned to allow the user to reactivate interaction (as optional parameter for the ELLSI_CMD_REGISTER command). 1.5 Some Thoughts about Performance Here are some proposals to maximize ELLSI performance on an esd EtherCAN: Try to send as many CAN TX messages as possible in one ELLSI telegram. Furthermore, the ELLSI server automatically tries to pack multiple CAN RX messages into a single ELLSI telegram to improve the performance. Only enable those CAN IDs for reception you're really interested in Minimize the number of clients connected to the ELLSI server Make use of the auto-acknowledge (ELLSI_SUBCMD_AUTOACK) feature wherever it is possible If your application allows for this, avoid sending CAN TX telegrams using the TX-DONE feature Page 8 of 26 Software Manual Rev. 1.5

9 2. The ELLSI-Protocol 2.1 Data Layout The data always consists of a header plus trailing payload data. The payload data itself consists of the data according to a single command or to n-can-telegrams. Header Command data or n * ellsicmsg_t Thus it is possible to send or receive multiple CAN telegrams at the "same" time. Using this feature you can greatly improve the performance of the esd EtherCAN. 2.2 Port The default port for the ELLSI UDP server is Byte Order Attention! All ELLSI-telegram data has to be given (or is given) in network byte order (most significant byte first). E.g. Intel x86 processors host byte order is least significant byte first. So always be aware of your host byte order before assembling ELLSI-telegrams! Software Manual Rev. 1.5 Page 9 of 26

10 2.4 Header The header mentioned above looks like this (see ellsicommon.h): typedef struct { uint32_t magic; uint32_t sequence; uint32_t command; uint32_t payloadlen; uint32_t subcommand; union { int32_t i[8]; int8_t c[32]; } reserved; } ellsiheader; Member Size Description magic unsigned 32-bit Magic number: ELLSI_MAGIC= 0x454c5349 It's mandatory to have this value (switched to network byte order!) in every ELLSI telegram. ELLSI clients should first check this value before doing anything else with a received ELLSI telegram. sequence unsigned 32-bit Sequence number or zero command unsigned 32-bit ELLSI_CMD_* (see ellsicommon.h) payloadlen unsigned 32-bit Length of payload data (in bytes) subcommand unsigned 32-bit ELLSI_SUBCMD_* or ELLSI_IOCTL_* (see ellsicommon.h) reserved 32 bytes For future protocol extensions Sequence Numbering UDP does not guarantee to receive the datagrams in the same order they were transmitted. In local Ethernets without routing, you normally don't have to bother about this. To avoid sending CAN telegrams in wrong order to the CAN bus, the ELLSI-client can make use of the sequence-element. If sequence equals zero, the ELLSI- server does not take care of the sequence number and unconditionally will send CAN telegrams to the CAN-bus. If non-zero, the ELLSI-server discards CAN TX telegrams if the sequence number is less or equal to the sequence number of the last CAN TX telegram. For the other direction, the ELLSI-server will increment the sequence-element for every telegram send to the ELLSI-client (regardless if CAN RX data, a response to a previous command or a heartbeat). Page 10 of 26 Software Manual Rev. 1.5

11 2.4.2 Commands Numerical Values of Commands You can find the following defines in ellsicommon.h: ELLSI_CMD_NOP 0 ELLSI_CMD_CAN_TELEGRAM 1 ELLSI_CMD_HEARTBEAT 2 ELLSI_CMD_CTRL 3 ELLSI_CMD_REGISTER 4 ELLSI_CMD_REGISTERX Numerical Values of Sub-Commands You can find the following defines in ellsicommon.h: ELLSI_IOCTL_NOP 0 ELLSI_SUBCMD_NONE 0 ELLSI_IOCTL_CAN_ID_ADD 1 ELLSI_IOCTL_CAN_ID_DELETE 2 ELLSI_IOCTL_CAN_SET_BAUDRATE 3 ELLSI_IOCTL_CAN_GET_BAUDRATE 4 ELLSI_IOCTL_GET_LAST_STATE 5 ELLSI_IOCTL_SET_SJA1000_ACMR 6 ELLSI_SUBCMD_TXDONE 128 ELLSI_SUBCMD_AUTOACK ELLSI_CMD_NOP A type of no-operation command. magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_NOP payloadlen 0 subcommand 0 reserved 0 Software Manual Rev. 1.5 Page 11 of 26

12 laststate for ELLSI_CMD_NOP ELLSI_CMD_NOP always will set laststate to ELLSI_CMD_REGISTER As the first operation the ELLSI-client has to register itself at the ELLSI-server. Therefore a telegram like this must be set up: magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_REGISTER payloadlen 0 subcommand 0 or ELLSI_SUBCMD_AUTOACK reserved laststate for ELLSI_CMD_REGISTER 0 for successful registration. All values unequal to 0 stand for a failed registration. Page 12 of 26 Software Manual Rev. 1.5

13 ELLSI_CMD_REGISTERX Starting with ELLSI Version (March 2006) there is an extended registration operation, allowing the user to have influence on some ELLSI-server parameters. Therefor you need to setup a telegram like this: magic ELLSI_MAGIC sequence 0 Header Payload command ELLSI_CMD_REGISTERX payloadlen sizeof(ellsiextregistration) subcommand 0 or ELLSI_SUBCMD_AUTOACK reserved 0 ellsiextregistration ellsiextregistration The ellsiextregistration structure mentioned above looks like this: typedef struct { uint32_t heartbeatintervall; uint32_t clientdeadmultiplier; uint32_t cantxqueuesize; uint32_t canrxqueuesize; uint32_t socketsendmaxntelegrams; uint32_t socketsendintervall; uint32_t reserved[8]; } ellsiextregistration; Software Manual Rev. 1.5 Page 13 of 26

14 Member Size Description heartbeatintervall clientdeadmultiplier cantxqueuesize canrxqueuesize socketsendmaxntelegrams socketsendintervall reserved[8] unsigned 32-bit unsigned 32-bit unsigned 32-bit unsigned 32-bit unsigned 32-bit unsigned 32-bit 8x unsigned 32-bit ELLSI server heartbeat interval in ms. Use 0 for default value (default is 2500 ms). The valid range is 250 <= x <= After clientdeadmultiplier / 10 * heartbeattime [ms] we assume a client as "dead". Use zero for default value. Default is 30 (which is equivalent to a multiplier of 30/10 = 3.0). The valid range is 10 <= x <= 100. Size of message queue used for CAN TX telegrams for each(!) of the clients. Use 0 for default (default is 128). The valid range is 1 <= x <= Size of queue used for CAN RX telegrams for each(!) of the clients. Use 0 for default (default is 512). The valid range is 1 <= x <= Maximum numbers of CAN RX telegrams to store in a UDP telegram. Use 0 for default. (default is CAN_READ_MAXLEN= 50) The valid range is 1 <= x <= CAN_READ_MAXLEN. Try to collect CAN RX data for up to socketsendintervall ms before sending an UDP telegram to the client. Use 0 for default (default is 0 ms). Not yet implemented!!! Reserved for future use!!! To be set to zero!!! laststate for ELLSI_CMD_REGISTERX 0 for successful registration. All values unequal to 0 stand for a failed registration. Page 14 of 26 Software Manual Rev. 1.5

15 ELLSI_CMD_CAN_TELEGRAM ELLSI telegram layout for received CAN telegrams and CAN telegrams to be send: magic ELLSI_MAGIC sequence Sequence # [or 0] Header Payload command ELLSI_CMD_CAN_TELEGRAM payloadlen n * sizeof(ellsicmsg_t) subcommand 0 [or ELLSI_SUBCMD_TXDONE] reserved 0 @ ellsicmsg_t #n Software Manual Rev. 1.5 Page 15 of 26

16 ellsicmsg_t The ellsicmsg_t data structure of CAN messages mentioned above looks like this: typedef struct { uint32_t id; uint8_t len; uint8_t msg_lost; uint8_t reserved[2]; uint8_t data[8]; ellsican_timestamp timestamp; } ellsicmsg_t; Member Size Description id len msg_lost reserved[2] data[8] timestamp unsigned 32-bit unsigned 8-bit unsigned 8-bit 2x unsigned 8-bit 8x unsigned 8-bit 64-bit 11- or 29-bit CAN ID data was received on or data should be transmitted on Bit 0-3 : Number of CAN data bytes [0..8] Bit 4 : RTR Bit 5 : TXDONE (see ELLSI_SUBCMD_TXDONE) Bit 6-7 : Reserved Counter for lost CAN RX messages. Allows the user to detect data overrun: msg_lost = 0 : no lost messages 0 < msg_lost < 255 : # of lost frames = value of msg-lost msg_lost = 255 : # of lost frames > 255 Only meaningful together with ELLSI_SUBCMD_TXDONE. In this case used to allow association of TX-DONE messages with previously sent CAN TX messages (see ELLSI_SUBCMD_TXDONE) CAN data bytes Time stamp for CAN RX messages. This time stamp is meaningless for CAN TX messages Not yet supported!!! To ease porting applications between ELLSI and NTCAN, this structure is compatible to the CMSG_T-structure in the esd NTCAN API (see ntcan.h). Page 16 of 26 Software Manual Rev. 1.5

17 laststate for ELLSI_CMD_CAN_TELEGRAM laststate, after issuing a CAN TX message using ELLSI_CMD_CAN_TELEGRAM, contains the return value given by the cansend()-function of the esd NTCAN API. Concrete, 0 stands for successful completion of cansend() and the respective ELLSI_CMD_CAN_TELEGRAM-command. All non-zero values will indicate an error condition. Seeing laststate as zero indicates successful completion of the ELLSI-server internal cansend()-command, but does not necessarily indicate a successful transmission of the corresponding CAN telegram(s) on the CAN bus, because cansend() is a non-blocking function! Therefore, if you are interested in knowing, if the appropriate CAN telegram has been successfully send on the CAN bus, laststate will not help you. See ELLSI_SUBCMD_TXDONE instead ELLSI_SUBCMD_TXDONE As mentioned above, requesting the last state of an ELLSI_CMD_CAN_TELEGRAM command does not necessarily indicate a successful transmission of a CAN telegram to the CAN bus. If you've the need to know if your CAN telegram was successfully transmitted, don't query laststate. Instead, while assembling a CAN TX message using ELLSI_CMD_CAN_TELEGRAM, set the headers subcommand element to ELLSI_SUBCMD_TXDONE. The ELLSI-server then will send you a transfer-done message (TX-DONE message) after successful transmission on the CAN bus. This TX-DONE message is assembled very similar to a "normal" CAN RX telegram. To distinguish a normal CAN telegram from a TX-DONE telegram, the length element in the corresponding ellsicmsg_t is logically ORed with ELLSI_CMSGT_LEN_TXDONE (0x20). Additionally, the two reserved bytes in ellsicmsg_t are echoed back! If you e.g. set this two reserved bytes to the two last significant bytes of the sequence number, you will easily be allowed to associate a received TX-DONE to a previously sent CAN telegram. If additionally to ELLSI_CMSGT_LEN_TXDONE, ELLSI_CMSGT_LEN_TXERROR is set in the length element, this will indicate an error while sending the telegram to the CAN bus. An corresponding error code can be found in the id element of ellsicmsg_t. Software Manual Rev. 1.5 Page 17 of 26

18 ELLSI_CMD_HEARTBEAT Both sides (ELLSI-client and ELLSI-server) have to send heartbeat-messages at regular intervals if there is no data exchange. At the moment this interval is fix 2500 ms. Future releases will add the possibility to change the interval(s) used by the ELLSI-server. If the client has not seen any data or heartbeat from the server within a given time interval, the client will assume that the server has disappeared. Maybe the network connection is broken, somebody did a reset on the EtherCAN, etc. In consequence of this, the client has to try to register at the server again. If the server has not seen any data or heartbeat from the client within a given time interval, it assumes the client as disappeared. The ELLSI-server no longer will transfer any data and heartbeat to the client then. Telegram layout for a heartbeat message: magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_HEARTBEAT payloadlen 0 subcommand 0 reserved laststate for ELLSI_CMD_HEARTBEAT ELLSI_CMD_HEARTBEAT will (contrary to the very similar looking ELLSI_CMD_NOP command) not set laststate! Page 18 of 26 Software Manual Rev. 1.5

19 ELLSI_CMD_CTRL Setting the headers command element to ELLSI_CMD_CTRL, the client can send special commands to the ELLSI-server. This special commands are specified by setting the headers subcommand element. Currently the following subcommand controls exist: ELLSI_IOCTL_CAN_ID_ADD/DELETE By means of ELLSI_IOCTL_CAN_ID_ADD the client can enable CAN IDs for reception. Using ELLSI_IOCTL_CAN_ID_DELETE the client can disable (previously enabled) IDs, to no longer receive data on this CAN IDs. The IDs to be enabled or disabled are given in the efficient form of an array of ellsicanidrange structures. Telegram layout for enabling / disabling CAN IDs: magic ELLSI_MAGIC sequence 0 Header command payloadlen subcommand ELLSI_CMD_CTRL n * sizeof(ellsicanidrange) ELLSI_IOCTL_CAN_ID_ADD or ELLSI_IOCTL_CAN_ID_DELETE reserved 0 Payload @ ellsicanidrange #n Software Manual Rev. 1.5 Page 19 of 26

20 ellsicanidrange typedef struct { uint32_t rangestart; uint32_t rangeend; } ellsicanidrange; Member Size Description rangestart rangeend unsigned 32-bit unsigned 32-bit Interval start, CAN ID(s) to be enabled for reception / disabled from reception Interval end, CAN ID(s) to be enabled for reception / disabled from reception The complete range, including rangestart and rangeend itself, will be enabled or disabled. If rangeend is less or equal to rangestart, only the CAN ID given by rangestart will be enabled or disabled laststate for ELLSI_IOCTL_CAN_ID_ADD/DELETE 0 for success, non-zero for failure ELLSI_IOCTL_CAN_SET_BAUDRATE By means of this subcommand you can set the baud rate to be used on the CAN bus. magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_CTRL payloadlen 4 subcommand ELLSI_IOCTL_CAN_SET_BAUDRATE reserved 0 Payload baudrate Page 20 of 26 Software Manual Rev. 1.5

21 Baud Rate Values baudrate has to be seen as a 32-bit unsigned integer. The predefined baud rates are: baud rate CAN bit rate [Kbit/s] 0x x x x x x x x x x9 50 0xA xB 20 0xC xD 10 If the LSB (bit 31) of parameter baudrate is set to '1', the value will be evaluated differently. In this case, the register value for the bit-timing registers BTR0 and BTR1 transmitted in modules with CAN controllers 82C200, SJA1000, (and all other controllers with this baud rate structure) is defined directly. For further information on this topic, see our esd NTCAN API documentation laststate for ELLSI_IOCTL_CAN_SET_BAUDRATE laststate represents the return value of NTCAN cansetbaudrate(), so 0 stands for success and non-zero for failure. Software Manual Rev. 1.5 Page 21 of 26

22 ELLSI_IOCTL_CAN_GET_BAUDRATE To read back the currently used CAN bus baud rate, set on the EtherCAN, send the following datagram to the ELLSI-server: magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_CTRL payloadlen 0 subcommand ELLSI_IOCTL_CAN_GET_BAUDRATE reserved 0 As answer you will get a telegram like this: magic sequence ELLSI_MAGIC x Header command ELLSI_CMD_CTRL payloadlen 4 subcommand ELLSI_IOCTL_CAN_GET_BAUDRATE reserved 0 Payload baudrate laststate for ELLSI_IOCTL_CAN_GET_BAUDRATE There should be no reason for anyone to query the laststate after an ELLSI_IOCTL_CAN_GET_BAUDRATE. Nevertheless, if you do it: 0 means NTCAN cangetbaudrate()-function an the ELLSI-server completed successfully, non-zero means failure. Page 22 of 26 Software Manual Rev. 1.5

23 ELLSI_IOCTL_SET_SJA1000_ACMR Some platforms using a SJA1000 CAN controller, like the standard esd EtherCAN (with ELLSI version >= ), allow setting its hardware acceptance filter. Therefore the user can directly access the SJA1000's ACR (Acceptance Code Register) and the AMR (Acceptance Mask Register): magic ELLSI_MAGIC sequence 0 Header Payload command ELLSI_CMD_CTRL payloadlen 8 subcommand ELLSI_IOCTL_SET_SJA1000_ACMR reserved 0 0: ACR SJA1000: ACR0, ARC1, ACR2, ACR3 4: AMR SJA1000: AMR0, AMR1, AMR2, AMR3 The acceptance filter is realized by a logical AND-combination of the Acceptance Code Register followed by a logical OR-combination with the Acceptance Mask Register according to the following figure. The figure above shows that an active bit within the acceptance mask results in a don t care condition for the result of the comparison of received message bit and acceptance code bit. It is possible to limit the filter exactly to one 29-bit CAN identifier or one group of 29-bit CAN identifiers. Software Manual Rev. 1.5 Page 23 of 26

24 The following table shows some examples of bit combinations of the acceptance mask and acceptance code and their meaning for the filter (SJA1000 in Single Filter Configuration ): Acceptance Code 0x x any Acceptance Mask 0x x000000FF 0x1FFFFFFF Filter Only 29-bit messages with the CAN identifier 0x100 are stored in the receive FIFO of the handle. All 29-bit CAN messages within the identifier area 0x100-0x1FF are stored in the receive FIFO of the handle. All 29-bit CAN messages are stored in the receive FIFO of the handle (open mask). default value The combination in the last row of the table above shows the default function for the reception of 29-bit CAN messages, if no mask is configured. Attention! The 2 least significant bits of the ACR3 and AMR3 are not used and should be set to 1. Bit #3 in ACR3 and AMR3 corresponds to the RTR-bit of the filtered CAN frame! So, if you don t want to take care of the RTR bit, you simply have to left-shift ACR and AMR by 3 and logical-or 0x7 afterwards. E.g. to set the acceptance code to 0x and the acceptance mask to 0x000000ff (as in the above example), set 0x803 ((0x100 << 3) 0x7) in ACR and 0x7ff ((0xff << 3) 0x7) into AMR. To allow reception of all 29-bit IDs, write 0xffffffff ((0x1fffffff << 3) 0x7) into AMR Mapping of ACR / AMR to CAN ID in a 29-Bit Frame Here you can see, how the two 32-bit registers ACR and AMR are mapped to the according 29 CAN ID bits: MSB LSB ACR0 ACR1 ACR2 ACR3 AMR0 AMR1 AMR2 AMR R T R For additional information, especially when using the above filter mechanism on receiving 11-bit standard CAN frames, also consult the according pages in the SJA1000 data sheet! laststate for ELLSI_IOCTL_SET_SJA1000_ACMR laststate represents the return value of the IOCTLs done on the EtherCAN platform. So 0 stands for success and non-zero for a failure condition. Page 24 of 26 Software Manual Rev. 1.5

25 ELLSI_IOCTL_GET_LAST_STATE ELLSI_IOCTL_GET_LAST_STATE allows to get some information about the last command processed by ELLSI on the EtherCAN module and will most times be used to see, if important commands, like registering the client, setting the baud rate or enabling CAN IDs, etc., reached the ELLSI-server and were successfully processed. To request the "last state" from the ELLSI-server send the following telegram: magic ELLSI_MAGIC sequence 0 Header command ELLSI_CMD_CTRL payloadlen 0 subcommand ELLSI_IOCTL_GET_LAST_STATE reserved 0 The ELLSI-server will respond with the following telegram: magic sequence ELLSI_MAGIC x Header command ELLSI_CMD_CTRL payloadlen sizeof(ellsilaststate) subcommand ELLSI_IOCTL_GET_LAST_STATE reserved 0 Payload ellsilaststate Software Manual Rev. 1.5 Page 25 of 26

26 ellsilaststate typedef struct { uint32_t lastcommand; uint32_t lastsubcommand; int32_t laststate; uint32_t lastrxseq; uint32_t reserved[4]; } ellsilaststate; Member Size Description lastcommand lastsubcommand laststate lastrxseq unsigned 32-bit unsigned 32-bit 32-bit unsigned 32- bit Last command processed by the ELLSI-server: ELLSI_CMD_NOP or ELLSI_CMD_CAN_TELEGRAM or ELLSI_CMD_HEARTBEAT or ELLSI_CMD_CTRL or ELLSI_CMD_REGISTER or ELLSI_CMD_REGISTERX Last sub-command processed by ELLSI-server: ELLSI_IOCTL_NOP or ELLSI_IOCTL_CAN_ID_ADD or ELLSI_IOCTL_CAN_ID_DELETE or ELLSI_IOCTL_CAN_SET_BAUDRATE or ELLSI_IOCTL_CAN_GET_BAUDRATE or ELLSI_IOCTL_GET_LAST_STATE or ELLSI_SUBCMD_TXDONE or ELLSI_SUBCMD_AUTOACK For states returned by the commands and subcommands see the corresponding descriptions of commands and subcommands The last sequence number the ELLSI-client send by the appropriate command to the ELLSI-server reserved 16 bytes For future protocol extensions ELLSI_SUBCMD_AUTOACK To speed up the procedure of sending a command and afterwards using ELLSI_IOCTL_GET_LAST_STATE to request the state of this command, we introduced ELLSI_SUBCMD_AUTOACK. By a disjunction of subcommand with ELLSI_SUBCMD_AUTOACK, the ELLSI-server will automatically generate a telegram analogue to the one generated by using the ELLSI_IOCTL_GET_LAST_STATE described above. Page 26 of 26 Software Manual Rev. 1.5