Briefly, CAN frames can be either standard or extended, and either data or remote request. All four combinations are possible. Standard frames have a 11 bit ID, and extended frames a 29 bit ID. Data frames can have 0 to 8 data bytes, whereas remote request frames can not have any data bytes. Remote request frames are intended for requesting data of their particular ID, but their actual usage is up to how the nodes on the bus implement the protocol.
EmCan logically allows for up to 127 data nodes on the bus and exactly one controller. In practise, a CAN bus is limited to less than 128 nodes electrically in most cases. All frames defined by EmCan are either to or from the bus master. The application protocol layered on EmCan may allow for data nodes to transmit frames to each other, but there are no such frames used by the EmCan layer.
Each data node is assigned a unique 7 bit bus address by the bus master. Until that is assigned, data nodes can only act upon broadcast messages from the bus master, and can only send requests for a address. Valid node addresses are 1 to 127. The special value of 0 is not a valid node address.
In the frame descriptions below, the mnemonic frame name is shown, followed by a colon, followed by the value of the opcode field in the frame ID, followed by a description of any data bytes. Unless otherwise stated, data values are unsigned, integer, and 8 bits, with multi-byte fields transmitted in most to least significant byte order. Unless specifically stated, remote requests for a particular opcode are not supported.
Standard frames have 11 bit IDs. For the purpose of this protocol, the low 7 bits are considered the node address and the high 4 bits the opcode. The special node address value of 0 indicates a broadcast frame. The opcodes for broadcast frames are different than those with valid (1-127) node addresses. There are therefore two separate opcode namespaces, for broadcast frames and for node-specific frames.
All standard frame broadcast frames are reserved by EmCan. The broadcast frames are:
This causes all nodes to reset their CAN bus state to the power up state. This means all bus addresses are unassigned and any application level functions beyond the basic EmCan protocol are disabled.
Sent by the bus master to assign a bus address to a data node.
Vblockid is a 24 bit integer value containing two fields. The high 20 bits is the vendor block number. These are unique numbers assigned by a central assigning authority to organizations that produce EmCan-compatible devices. The low 4 bits of vblockid are the ID of the device within that vendor block. Organizations can therefore produce up to 16 different devices with the same assigned vendor block number. The assignee of a vendor block number is responsible for determining the device IDs within that block. Organizations that produce more than 16 EmCan devices can be assigned multiple vendor block numbers.
Serial is a 32 bit serial number. Every instance of a particular device (any one vblockid) must have a different serial number. It is the responsibility of the vendor block assignee to guarantee all devices with the same vblockid have a different serial number.
Together, vblockid and serial form a 7-byte globally unique value, thereby guaranteeing that every instance of every device on a EmCan bus can be individually identified.
Adr is the 7 bit address being assigned to the node identified by vblockid and serial. Adr is a whole byte, but valid addresses are 1-127. The special address of 0 specifically unassigns the currently assigned bus address, if any, in the targeted device. Adr values of 128-255 are reserved and should not be sent. Devices must unassign their bus addresses (same as receiving address 0) for adr values of 128-255.
Each node must unassign its bus address at power up, after a RESET frame, when specifically unassigned, when it sees its address being assigned to another node, when a ADRELEASE frame is received with its address, when it can be determined that the bus connection to the bus master has been lost, and after a specific lifetime has expired. This lifetime of a assigned bus address is 3 minutes. Generally a data node will send a bus address request a few seconds before its current address expires.
Causes all nodes with virtual byte streams open from the node to the master to send a sync frame at the next opportunity. Sync frames indicate a break between whole responses in the byte stream. The next byte after a sync frame is always a response opcode.
Sync frames are STRIN frames with 0 data bytes. A sync frame will be sent at the next known break between whole responses. This could be up to one output buffer full of bytes.
Sent by a node to deliberately release its assigned bus address. Adr is a single byte containing the 1-127 address currently assigned to the sending node. The sending node must consider its bus address unassigned immediately after sending this frame.
When a node knows it will no longer be participating on the bus (power going down, reset by user, etc), it should send a ADRELEASE frame if it is capable of doing so. If no such frame is sent, the node's address will eventually time out and be unassigned by the master. This frame provides a mechanism to let the master know deliberately when the capability to do so exists.
All bus nodes must examine any received ADRELEASE frames. If a node receives a ADRELEASE frame with adr set to its own address, it must unassign its own address. This should never occur, since the sending node should have a different address, and nodes may only send ADRELEASE frames with their own addresses. If such a frame is received, some error has previouly occurred. Unassigning the address is the safest action to attempt to recover from the error.
Sent by a data node to renew its bus address assignment. Nodes may only use ADRREQ (as apposed to ADRREQRES) to request a address assignment if they already have a valid address assigned. Re-assigning the same address before it expires causes no change in operating state. Nodes must wait at least 2 seconds between sending any ADRREQ and ADRREQRES frames.
The data parameters are the same as the first two data parameters to the ADRASSIGN frame, described above.
Nodes with bus addresses that are about to expire should send address renewal requests. This should be done shortly before the address expires, but with enough time for 2 retries. Since a address request can only be sent every 2 seconds, it is suggested to send the first request when the current address has about 6½ seconds of life left. When a node requests a bus address that has a currently assigned valid bus address, the bus master must assign it that same address if this information is known.
Like ADRREQ except this also indicates that the node currently does not have a assigned address and is therefore in reset state. This is the only frame a node is allowed to send when it does not have a valid assigned bus address.
Nodes that have no assigned bus address should periodically request one. To avoid flooding the bus, such request must be sent no more often than every 2 seconds. Note that the bus master has no indication of the existance of a node until it requests a bus address.
ADRREQRES allows the bus master to reset state it may have saved or assumed about the node. For example, the bus master may have established the output byte stream to the node and sent it some data using STROUT frames. If the node gets independently reset without the bus master's knowledge (power got interrupted, user pressed a button, etc), then the STROUT stream could be out of sync. The node does not have the stream open and will only accept open requests with sequence number 0 . The bus master will be expecting to send data without restarting the stream and the sequence number it will send only has one chance in 16 of being 0 as the node expects. This will result in deadlock until the bus master re-opens the stream. Whenever the bus master receives a ADRREQRES frame it marks the STROUT stream as closed, along with resetting other state about the node.
Nodes that do not currently have a assigned address must use ADRREQRES, not ADRREQ, to request a address assignment. Otherwise, the same rules apply to ADRREQRES as to ADRREQ, including the minimum retry interval.
Node-addressed frames contain the 1-127 address of the specific node that is sending or receiving the frame. Nodes ignore all standard frames that either don't have their assigned node address in the low 7 bits of the ID, or don't have 0 there. Therefore node-addressed frames are always to a specific node, or from a specific node to the bus master.
Nodes don't "watch" node-addressed frames with other than their own addresses. These frames are discarded in the EmCan layer and not passed to the application in the EmCan reference implementation.
Other than the restrictions above, the use of node-addressed standard frames is up to the application. Note that there is a namespace of 16 possible standard frame IDs per node that will be visible to the application level.
Extended frames have 29 bit IDs. Various separate fields are encoded into these 29 bits. Each of these fields is described below. Bit 0 is the least significant bit, and bit 28 the most significant. Unless otherwise stated, single bits are described such that their value is 1 when the description is true and 0 when false. The bits in the extended frame ID are:
Identifies the particular frame.
Should be set to 0 by transmitters and ignored by receivers for now.
Should be set to 0 by transmitters and ignored by receivers for now.
This frame is not a ACK reply to a previous frame. This can be thought of as the not-ACK bit. This bit together with bit 14 is used to provide for a ACK request, ACK, and NACK mechanism. See the bit 14 description for details.
The frame is not part of the normal deliberate request and response sequence between the bus master and the data node. This can happen, for example, when the frame is triggered by a external event detected by the node, or when the node sends data at regular intervals triggered by a timer.
When NEW DATA (bit 16) is 1: The receiver of this frame must reply with a ACK or NACK frame. The transmitter may resend this frame if no ACK or NACK is received within 2 seconds.
Unless otherwise explicitly stated, ACK frames contain no data bytes and the same frame ID as the frame they are ACKing, except the NEW DATA bit (16) must be 0 and the ACK REQUESTED bit (14) must be 0. A NACK frame is the same with this bit (ACK REQUESTED) set to 1.
When NEW DATA (bit 16) is 0: This bit indicates the ACK or NACK status of a ACK reply frame. This frame is a response to a frame that specifically requested a ACK. In that case, this bit is used to indicate a positive versus negative acknowlegement. Both types of acknowledgement (ACK or NACK) indicate that the orignal frame was received, and the sender must therefore not resend it. The exact meaning of ACK or NACK may differ depending on the frame, but generally ACK means "yes", "desired action taken", etc. NACK generally means "no", "unable to perform requested action", "feature not implemented", etc. Both ACK or NACK specifically say "request received".
To clarify, the 4 possible combinations of bit 16 and bit 14 have the following meanings:
| Bit 16 | Bit 14 | Meaning |
|---|---|---|
| Normal frame, no reply requested | ||
| Normal frame, ACK reply requested | ||
| ACK reply, positive response (ACK) | ||
| ACK reply, negative response (NACK) |
Note that it is not possible to request a ACK response to a ACK response frame.
This frame is a continuation of a previously started sequence of frames. A sequence of multiple frames is used when more than 8 data bytes need to be transferred. The first frame of a sequence must have this bit set to 0. All single-frame sequences have this bit set to 0. This bit can also be thought of as the not-first bit.
Frames may only be sent in a sequence when this is specifically stated in their descriptions.
At least one more frame in this sequence of frames will follow. This can also be thought of as the not-last bit. All single-frame sequences have this bit set to 0.
Identifies this frame's position within a sequence of frames. The first frame in a multi-frame sequence always has the sequence number 0. The sequence number is incremented by 1 modulo 16 with each successive frame. In other words, the sequence number is incremented by 1 each new frame, but wraps back to 0 after 15.
The sequence number mechanism allows distinguishing between a resend due to a lost ACK and the next sequential frame, for example.
Since there is no purpose to a sequence number in single frame sequences (bits 13 and 12 set to zero), this field may contain other information specific to the frame. However, unless explicitly stated to the contrary, this field must be 0 in single frame sequences.
Should be set to 0 by transmitters and ignored by receivers for now.
Frames with a valid node address (1-127) must be ignored by any node that is not assigned that node address. Such frames are only to that node, or from that node to the bus master.
Frames with the special node address of 0 are broadcasts. All extended broadcast frames are reseved for application use and are not defined by EmCan.
Some of the node-addressed extended frames are reserved for EmCan or for other than general application use. The last 32 frames (992-1023) are reserved for EmCan, and the previous 32 frames before that (960-991) for device test modes.
The device test frames 960-991 are undefined in EmCan, but are not available for application use. These are intended to allow for special interactions with the device during manufacturing, field installation, diagnosys, etc. Applications must never issue these frames. The normal operation of a device is not guaranteed after it receives one of these frames.
In general, devices are encouraged to not respond to test frames in normal operation to the extent this is reasonable and possible. For example, each device may be programmed intially with a fixed serial number like, FFFFFFFFh. One of the test frames could be used to assign the final serial number. This frame and other test frames could be ignored if the serial number is not the original programmed value. Other possibilities include requiring a special external input signal, a board jumper to be installed, etc. None of this is required, but thought should be given to avoiding undesirable behaviour should test frames accidentally be emitted during normal operation or even initial debugging and development of a system.
The frames 992-1023 are reserved exlusively for EmCan. Any frames in this range not listed here are reserved for future use. Nodes should ignore any unrecognized frames. The fact that existing nodes will ignore newly defined frames in the EmCan range will be considered in their definition.
The extended node-specific EmCan frames are:
Sent by the bus master to set the port port to the value specified by data. Port is the 16 bit number of the port. The size of data is the minimum number of bytes required to hold the number of bits specified by the bits parameter in the PORTYPE frame.
Since CAN frames are limited to 8 data bytes and the port parameter uses two of them, data can be at most 6 bytes, which is 48 bits. The sequence number in the frame ID is used to allow for more data bits than the 48 that can fit in any one frame. The sequence number indicates which chunk of 6 bytes of the data for this port is being set. Since multi-byte values are always sent in most to least significant order, sequence 0 indicates the high 6 bytes are being set, sequence 1 the next lower 6 bytes, etc. For example, if the port is specified to have 128 data bits, then it requires 16 bytes to be sent to set a new value. Numbering these bytes 15 to 0 in most significant to least significant order, it would take 3 consecutive frames to set the port to a new value. The first frame would have sequence number 0 and set bytes 15-10, the second sequence 1 with byte 9-4, and the last sequence 2 with bytes 3-0. The node does not make the new value take effect until it receives the last frame of the sequence, meaning the not-last bit (12) in the frame ID is 0.
Note that while the mechanism for transferring more than 48 bits to a port is somewhat complicated, it is simple when the port requires 48 bits or less as most ports are expected to. In that case, the node only checks the frame ID no differently than for most other frames. It simply ignores the frame if it is a ACK or NACK, is not first, not last, and the sequence number is not 0.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Indicates the latest value of a readable port. Port is the 16 bit port number, and data the port data. The format of data and how more than 48 bits of data are handled is the same as for the PORTWR frame, above.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Since all the data in this frame is read-only, the only valid frames from the bus master are current value requests.
This frame may be sent by a node without a deliberate request from the bus master. In that case, the asynchronous bit (bit 15) in the frame ID must be set. When/if to send PORTRD data asynchronously is dependent on the specific node and the application. There is no requirement in EmCan that PORTRD is ever sent asynchronously.
Sent by a node to report its firmware version. All parameters are 16 bits.
Type is intended to identify the firmware type or branch in case different firmware can be loaded onto the same hardware. Majver and minver are the major and minor versions of the firmware, and sequence is a build sequence number. It is intended that every build of firmware have a unique combination of these parameters, with the sequence number being automatically incremented each build by the build system.
Later parameters are only relevant within the scope of previous parameters. For example, each major version has a new minor version namespace. Likewise, sequence numbers are only meaningful relative to each other for the same combination of type, major version, and minor version.
Otherwise the exact meaning of each of these fields is up to the firmware implementation. If a particular field is not used, it should be set to zero. For example, if build sequence numbers are not used, then sequence should be zero.
This frame is only sent by a node in response to a remote request to this opcode.
This frame reports the application the node is intended to work with, and the role of this particular node within the application.
Appid is a 32 bit value. The low 31 bits contain the unique ID of the application this node is intended to work within. Application IDs are assigned by a central assigning authority to guarantee uniqueness. Each separate application that is structured on the EmCan framework is intended to have its own unique ID. This is the mechanism that allows any EmCan compliant device to be connected to any EmCan bus (with matching bit rate) without harm. The bus master can determine basic information about each node and whether it is compatible with the application it is implementing.
The high bit of appid indicates whether the application-unique interactions of this node are enabled. 0 means disabled and 1 enabled. Application features are always disabled when the node has no assigned address, and are disabled any time a different address is assigned to a node than it previously had.
Role is a 32 bit value indicating the role this specific unit is intended to perform within the application. For example, a large machine may have several identical bus nodes that each operate a valve. Each node is just another instance of the same general purpose valve controller product that differ only in their serial number. The serial numbers make them unique so different bus addresses can be assigned, but give no direct indication which unit controls which valve. This is what the role ID is intended for. Such units would have some non-volatile memory and a means to configure the role ID in that memory.
Role IDs are assigned as part of the design of the application. The assignee of the application ID is responsible for allocating role IDs for that application. For example, role ID 1 may be the cold water intake valve, role ID 2 the hot water intake valve, etc. Using role IDs to indicate how nodes are installed in a system eliminates the need to record serial numbers and then configure the host application to map those serial numbers to specific roles. Of course the serial number to role scheme is still possible. This is a choice that can be made as part of the design of the application. Applications can simply ignore role if they wish.
This frame is sent in response to one of the following events:
Appid has the same format as when sent by a node (see above), but in this case the bus master is setting the values. The high bit enables or disables the application-specific actions of the node. The low 31 bits are the ID of the application the bus master is expecting the node to work within.
The bus master may send a different application ID than that reported by the node. If the node can operate within the specifications of that application, then the node should enable its application-specific actions (assuming the high bit of appid is 1), but must then report that application ID when sending any subsequent APPROLE frames. If the node can not implement the application identified by the bus master, then the node must disable it's application-specific actions and report the ID of one application it can implement in subsequent APPROLE frames it sends.
This mechanism allows bus masters that are only equipped to implement a single application to blindly enable all nodes with the ID of that application. Those that are capable of implementing the protocol for that application do so and enable their application-specific actions. Those that can't continue to stay disabled.
This mechanism also allows for nodes to be implemented capable of working within multiple applications. If the bus master enables a node for one of the applications it is equipped to handle, the node simply switches to that application.
If the ACK REQUESTED bit in the ID is set, then the node will respond with a full APPROLE frame with data bytes, not just the ID as usual. However, the NEW DATA bit in the ID of the reply frame will be set to 0 to indicate it is in response to a ACK request.
This frame is used to upload new firmware or other data to a bus node. Various interactions are defined using the single FWUPLD frame opcode.
Data is sent in sequences, using the Continuation (bit 13), To be Continued (bit 12), and Sequence Number (bits 11-8) fields in the frame ID.
The first frame of each sequence (Continuation = 0, sequence = 0) has a common format. The first byte is a opcode byte, indicating the meaning of that sequence. The high bit of this byte is 0 for sequences from the host to the node, and 1 from the node to the host. Opcodes 0-127 are therefore from the host to the node and 128-255 from the node to the host. Up to 7 additional bytes can follow the opcode in the first frame of a sequence. The number and meaning of these bytes is defined separately for each opcode.
Once a sequence is started, no other FWUPLD frames other than part of that sequence are allowed until the end of the sequence (To be Continued = 0). If a new start of FWUPLD sequence is received (Continuation = 0), then any existing sequence in progress is aborted. Results of aborted sequences are not defined. Sequences may be ended by setting To be Continued to 0 in the last frame with data, or by sending a empty frame with To be Continued 0. Receivers must support both methods and react to them equivalently. Empty frames with To be Continued 1 are not allowed unless explicitly stated to the contrary, below, for a particular sequence.
All FWUPLD frames are ACKed. The sender must set the New Data and ACK Requested bits in the frame, and the receiver must reply with ACK after the received frame has been processed. Senders may only send the next frame in the sequence after receiving the ACK for the previous frame. Senders must wait at least 1 second before re-sending a frame for which ACK was not received.
For the purpose of uploading firmware and other data to a node, a node is viewed as having one or more 32-bit address spaces. There is one byte (8 bits) of data at each address. Nodes that have physical memory with a word size other than 8 bits must map such memory into a byte-addressed space for the purpose of the FWUPLD mechanism. The exact mapping is implementation-dependent.
Address space 0 is always for the main operational firmware. It must be possible for a generic uploader program to transfer a bunch of bytes at specific addresses in address space 0 to a node to update its firmware.
Other address spaces are optional and have no pre-defined meaning.
In the opcode descriptions below, the mnemonic name of the opcode is shown, followed by a colon, followed by the opcode byte value, followed by the description of any additional data bytes in the frame. Unless otherwise stated, all parameters are unsigned, integer, 8 bits, and multi-byte values are sent in most to least significant byte order.
Upload data to the node. Adrspace is the 0-255 address space that the data is to be written to. Adr32 is the 32 bit starting address of the data within the address space.
Subsequent frames in this sequence contain only data bytes. These data bytes are for sequential addresses, starting with adr32 and incremented by one after each byte.
The host may send data for any address within the 0-FFFFFFFFh address range of the address space adrspace. The node must silently ignore data for any addresses it does not implement.
This sequence only causes the new data to be stored. It does not force the node to use the new data.
Causes the node to attempt to use all new uploaded data. ACK is sent after the node determines the new data is usable, but before this new data is deliberately put into use. If the new data is determined to be inconsistant or otherwise unusable (failed a checksum test, for example), then NACK must be sent and the new data not deliberately put into use.
It is permissible for nodes to not respond on the bus for some time after sending the ACK response. If so, nodes should actively release their assigned node addresses before becoming unresponsive, then request a new address after enabling bus interactions again. It is permissible for a node to lose volatile state during this process. If any volatile state is lost, then a node must also invalidate its node address assignment.
Other situations can also cause a node to attempt to use the latest uploaded data. For example, nodes could always attempt this at power up, or after a user reset. The host can not rely on new data only being put into use after a RUN sequence.
Requests the node to send a ADRANGE sequence, which indicates the implemented address ranges within the adrspace address space.
This sequence only contains one frame.
Requests the node to send a ASPLST sequence, which provides the list of address spaces implemented by the node.
This sequence only contains one frame.
This sequence is used to indicate what address ranges of the address space adrspace is implemented by the node.
Subsequent frames each contain two 32-bit addresses. The first is the starting address of a implemented region, and the second is the last address of the implemented region.
After the end of sequence is received, the host can assume all addresses not explicitly indicated as implemented are unimplemented. For example, it is a valid optimization for a uploader program to first inquire the implemented addresses, then send only data for those addresses, even if data for other addresses is provided, such as in a firmware HEX file.
This sequence enumerates the address spaces implemented by the node. The first frame of the sequence contains only the opcode byte. Subsequent frames contain address space ID bytes. The list of address spaces must be exhaustive. It is a valid optimization for a host to get this list of address spaces, then skip sending any data to the node that is not in one of the listed address spaces.
This frame is used to set or clear configuration state (see the Non-volatile Settings section of this specification for more information on configuration state) or to inform of conditions related to configuration state.
Changes to non-volatile settings are only allowed when in configuration state. A device is always not in configuration state when it has no assigned address. Configuration state is always cleared (device put in NOT configuration state) when the assigned address is changed. Configuration state can only be entered when so enabled by a CONFIG frame. However, devices may have additional requirements to enter configuration state. In other words, receiving a CONFIG frame to enter configuration state is a necessary but possibly not sufficient condition for entering configuration state.
Flags is a byte containing several fields:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| REQCFG | SETID | CLRID | ID | SETCFG | CLRCFG | CONFIG | ALLOW |
REQCFG is set by the node to indicate that it has received a attempt from the bus master to enter configuration state, but that actually entering configuration state is pending some action local to the device. There is nothing more the bus master can do to enter configuration state. The bus master can cancel the request at any time by setting CLRCFG.
SETID is set by the bus master to request that the device activate a user-identifyable signal. There may be a number of identical copies of the same device on a EmCan bus, differing only in their serial number. Due to the unique serial number, each device will be assigned a different bus address and can therefore be communicated with separately by the bus master. However, the serial numbers may not be known to users. SETID provides a mechanism for identifying individual devices from the host to aid in configuration and the like. Devices are not required to provide a mechanism for a user to identify them, but possibilities include lighting a LED, beeping, etc. This bit is always 0 when sent by a node.
CLRID is set by the bus master to request that the user-identifiable signal be de-activated. This bit is always 0 when sent by a node.
ID indicates the current state of the user-identifiable signal. 1 means it is asserted, and 0 not. This signal could be asserted locally, such as when a user presses a button for that purpose. When the state of the signal changes independently of being set by the bus master, the device should send this frame asynchronously. In any case ID always reflects the current state of the user-identifiable signal, regardless of why it was set or cleared. This bit is only sent by the node and is always 0 when sent by the bus master.
SETCFG is set by the bus master to attempt to enter configuration state. This bit is always 0 when sent by a node.
CLRCFG is set by the bus master to clear configuration state, meaning the node must not be in configuration state after receiving a frame with this bit set. This bit takes priority over the SETCFG bit in case both are set, although bus masters should only set one of the SETCFG and CLRCFG bits in a frame. This bit is always 0 when the frame is sent by a node. CLRCFG also always cancels any pending request to enter configuration state. REQCFG will therefore be 0 immediately after a frame with CLRCFG is received.
CONFIG is set to 1 by a node when it is in configuration state and 0 when it is not. The bus master always sets this bit to 0.
ALLOW is set by the node to indicate whether it will currently allow configuration state to be entered. This bit is always 0 when the frame is sent by the bus master. When this bit is 1, the node is indicating that it will enter configuration state if so requested. Note that this is not a guarantee that configuration state will be entered if the bus master subsequently sends this frame to enter configuration state because the ALLOW condition may have asynchronously changed in the time between the two frames.
The CONFIG frame can be sent by the bus master at any time. It is sent by a node in these cases:
The mecahnism implemented by this frame allows for several different strategies to enter configuration state. In general, it is desirable for a node to not allow configuration state without some deliberate confirmation from a user or to require some special circumstance. Various sequences to enter configuration state are possible, and it is not the purpose of this specification to limit creativity or to proclude unusual sequences when they make sense in particular instances. However, two "normal" sequences are described here as guidance and to provide more detail on the various bits by example.
User-initiated configuration state entry:
In the above case, there would typically be some way for the user to abort configuration state. In that case, such a user action would cause a asynchronous CONFIG frame to be sent with the CONFIG bit cleared to indicate the device is no longer in configuration state.
Host-initiated configuration state entry:
As before, the user should be able to cancel configuration state at any time by performing some action on the device. This could be as simple as pressing the same button again that allowed entering configuration state in step 4.
Indicates the number of "ports" this node supports. See the Ports section of this specification for a description of ports. Nports is the 16-bit size of the port range this node implements. Valid port numbers of this node are therefore from 0 to nports-1. When nports is 0, then the node supports no EmCan ports at all and even 0 is a invalid port number. This mechanism allows for up to 65535 ports, numbered 0 to 65534.
This data frame is only sent by nodes, and only in response to remote requests for this frame.
Describes the characteristics of one port.
Port is the 16 bit number of the port being described.
Type is the 16 bit ID for the type of port. The two upper bits of type indicate whether the port is readable, writeable, or both. The remaining bits specify a overall type. These indicate, for example, whether it is a boolean setting, integer input value, etc.
Dim is the 16 bit ID of the physical property being set or measured by this port. For example, this could be length, force, voltage, dimensionless, etc.
Bits is the amount of data in bits minus 1 that is transferred when this port is written to or read from. The standard EmCan data interface to ports always transfers a multiple of whole bytes (8 bits). If a port does not implement exactly a multiple of 8 bits of data, then the smallest number of bytes to hold bits+1 bits must be used. For example, if bits is 13, then 14 bits are required to transfer data to or from the port. This would require 2 bytes with 2 unused bits.
When the data bytes are transferred, the actual data bits are justified in the low end of the byte-multiple value. Unused upper bits, if any, should be set to reasonable values when written if this is possible without undue burden, but must always be ignored when received. For example, unused bits could be set to 0 or be the sign-extension of the actual value, to list two possible schemes.
Dform is the data format ID. Examples of data formats are unsigned integer, signed integer, floating point, etc. Each EmCan port must adhere to one of the finite set of data formats provided for. Some data formats may imply a specific number of bits, or a specific set of bit sizes. It is a error if bits is not one of the supported sizes for the particular data format indicated by dform. A node reporting a inconsistent combination of bits and dform is not EmCan compliant.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Since all the data in this frame is read-only, the only valid frames from the bus master are current value requests.
Sent by a node to indicate the scale factor of numeric data relative to the base physical quantity defined by the dim parameter of the PORTYPE frame. This scale factor is only meaningful when the port value is numeric. See the dim parameter description of the PORTYPE frame for details.
Port is the 16 bit port number for which the scale is being reported.
Scale is a 48 bit floating point value.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Since all the data in this frame is read-only, the only valid frames from the bus master are current value requests.
Sent by a node to indicate the zero offset of numeric data relative to the base physical quantity defined by the dim parameter of the PORTYPE frame. This offset is only meaningful when the port value is numeric. See the dim parameter description of the PORTYPE frame for details.
Port is the 16 bit port number for which the scale is being reported.
Offset is a 48 bit floating point value.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Since all the data in this frame is read-only, the only valid frames from the bus master are current value requests.
Sent by a node to indicate the fixed function of this port within the the context of the application.
Port is the 16 bit port number for which the function ID is being reported.
Functionid is a 1 to 6 byte fixed value. Its meaning and what size or size range it must be is defined by each application. 0 bytes (the frame contains only the port parameter) indicates this port has no function ID assigned to it.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
Since all the data in this frame is read-only, the only valid frames from the bus master are current value requests.
Sent by the bus master to set the non-volatile role ID of this node. See the description of the APPROLE frame when sent by a node (above) for a discussion of the role ID. Role is a 32 bit integer.
If the ACK REQUESTED bit in the ID is set, then the node will respond with a full APPROLE frame with data bytes, not just the ID of this frame as usual. However, the NEW DATA bit in the ID of the reply frame will be set to 0 to indicate it is in response to a ACK request.
This frame writes a non-volatile setting. Nodes must be in configuration state to accept new non-volatile settings. There are other issues that should be kept in mind when writing non-volatile values. For details see the Non-volatile Settings section of this specification.
Sets the initial power up or reset value of a writeable port. The format of this frame is the same as for PORTWR. The difference is that PORTWR sets the immediate port value and this frame (PORTINIT) sets the non-volatile startup value.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
This frame writes a non-volatile setting. Nodes must be in configuration state to accept new non-volatile settings. There are other issues that should be kept in mind when writing non-volatile values. For details see the Non-volatile Settings section of this specification.
Sets non-volatile configuration options of a port. Port is the 16 bit port number to set the configuration of. Config is the configuration data for this port to be saved in non-volatile memory. The format of config depends on the port type as indicated by the type parameter in the PORTYPE frame.
Different port types can be configured in different ways, with some ports not being configurable at all. For example, a digital output can be configured for positive or negative logic.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
This frame writes a non-volatile setting. Nodes must be in configuration state to accept new non-volatile settings. There are other issues that should be kept in mind when writing non-volatile values. For details see the Non-volatile Settings section of this specification.
Sets the non-volatile role ID of a port. Port is the 16 bit number of the port and role is a arbitrary 32 bit role ID. Role IDs have no particular meanings to nodes. They are simply stored and reported back as requested. It is up to applications to assign meanings to port role IDs, if they are used at all.
This is a port-related frame as described in the Ports section of this specification. The node may ignore this frame, reply with NACK, or reply with ACK. See Common Responses to Port-related Frames in the Ports section for details.
This frame writes a non-volatile setting. Nodes must be in configuration state to accept new non-volatile settings. There are other issues that should be kept in mind when writing non-volatile values. For details see the Non-volatile Settings section of this specification.
This frame is used to implement a uni-directional stream of bytes from the bus master to the target data node. "Out" in the frame name is from the point of view of the bus master. Handshaking between the bus master and the data node using the ACK, sequence number, and first/last indicators guarantees reliable delivery of the data bytes in their correct order. The concept is similar (although less elaborate) to TCP over IP frames.
This frame is used in a sequence, as described for the sequence number field of the frame ID, above.
All STROUT frames request ACKs, and the ACK must be received by the sender before it may proceed with the next frame in the sequence. To keep implementation logic in possibly resource-limited systems simple, the sender is not allowed to send "ahead", meaning it may not send the next frame before receiving the ACK for the previous frame. If a node does not implement this output stream, it must reply with NACK to all attempts to open this stream.
The stream must be "opened" before data bytes can be passed. This is done by sending a open request, which is just the first frame of the sequence. This means the open request frame has its continuation bit (13) set to 0. Since it is the first frame in the sequence, its sequence number is always 0. If a open request is received when the stream is already considered open, it is silently re-opened by the receiver. This may or may not reset internal stream state, depending on the implementation. Open requests may not be sent more often than every 3 seconds. However, if a NACK is received in response to a open request, no more open requests should be sent until the node is reset. A NACK indicates the open request was received, but that the node does not implement the stream. Additional attempts to open the stream are therefore pointless and would be a waste of bus bandwidth.
Open frames may contain data bytes.
Subsequent frames may contain 0 to 8 data bytes. Frames with 0 data bytes may be used to indicate activity and verify the stream is still considered open, although this is not required by the protocol. If a ACK is not received for a data frame, the frame may be resent. The minimum wait to resend must be at least 2 seconds for the first retry and 50% more each successive retry, except that it is not necessary to wait more than 10 seconds after multiple retries. The minimum wait times per retry are therefore 2, 3, 4.5, 6.75, 10, 10, 10 ... seconds for successive retries. The bus master may try to re-open the stream after excessive retries. It is up to the bus master implementation whether to do this, and if so, after how many un-ACKed frames.
Receivers must examine the sequence number of new received frames. Even if the receiver ACKed a previous frame, the ACK may not have been received by the sender and the previously ACKed frame resent. Such frames are identified by having the same sequence number as last received. These frames must be ACKed by the receiver, but their data bytes discarded since they were already used when the previous copy of the same frame was originally ACKed.
There are therefore two valid cases of received sequence numbers, the same as last received, and that plus one (modulo 16). The first case is a resend, and the frame must be ACKed but otherwise not acted upon. The second is a new frame. It must be ACKed and fully acted upon. The other remaining 14 sequence numbers are invalid, and frames received with any of these sequence numbers must be ignored.
The stream is closed when a frame is received with its continued bit (12) set to 0, since this indicates no more frames of this sequence will follow. This bit is valid in open request frames, although this is not recommended. The stream must be considered closed after a frame with the continued bit set to 0, even if it was a open request frame.
This frame is used to implement a uni-directional stream of bytes from a data node to the bus master. "In" in the frame name is from the point of view of the bus master.
The protocol of the STRIN frame is the same as the STROUT frame (except when there are 0 data bytes, see below), except that the sender and receiver roles are reversed between the node and the bus master. See the STROUT frame description above for details.
A STRIN frame with 0 data bytes has special meaning. It indicates that the first data byte in the next STRIN frame will be a opcode. Upon receiving such a frame, receivers must abort any responses that have been partially read, and reset the processing logic to expect the next byte to be a response opcode.
A frame with 0 bytes is sent by a node in response to a SYNC command received over its stream interface implemented by STROUT frames, or a SYNC CAN standard data frame. EmCan servers will present this synchronization information to their clients by sending a STRINSYN response. Note that this is a different response stream with different opcodes than that from individual nodes implemented with the STRIN frame.
The STROUT and STRIN frames together are used to implement a bi-directional stream of bytes between the bus master and a target device. The content of this byte stream is defined in the Byte Sreams to Nodes section of this specification.