Many different types of EmCan bus nodes implementing various functions accross various applications are possible. EmCan tries to NOT assume too much about the capabilities of a node and what it's purpose might be so as to not limit the possibilities. The more specific the EmCan spec is, the more it may prevent useful but unenvisioned future architectures.
However, a common theme of many nodes on a CAN network is to have outputs that might control things, and inputs that sense or measure conditions. While this is not always the case, it is common enough that it is useful for EmCan to provide some basic low level facilities for managing such inputs and outputs. Application development is simplified and differences between applications minimized in those cases where nodes can be viewed as having a collection of inputs and outputs, since the basic infrastructure will be built into the EmCan layer.
To this end, EmCan provides the abstraction of each node having a collection of "ports". It is up to each application what a port is, but generally it would be a single input or a single output of the bus node. For example, a bus node could have a number of digital inputs and digital outputs. Each such input or output signal could be considered a separate port. Other ports could be analog voltage outputs, temperature sensor inputs, solenoid actuators, something controlling the effective driving voltage of a motor, etc. EmCan does not attempt to define what a port does, but only basic management operations that transcend actual port function.
It may not be convenient or meaningful to view the function of some bus nodes as a collection of individual ports. There is no requirement in EmCan that a node have ports, or more specifically, a node can have zero ports. In that case, whatever function the node provides is accessed thru more application-specific means. A node may also have a mix of EmCan ports and other application-specific functions. The point is not to impose a particular abstract view of a node, but to provide some common infrastructure in those instances where the abstraction of a collection of ports is useful.
Each port is identified per node by a 16 bit unsigned integer ID. Since the number of implemented ports is also described in a 16 bit integer, the logical maximum number of ports a node can have is 65535, with port numbers from 0 to 65534.
Each node implements a specific number of ports. Within that node, only port IDs from 0 up to the number of ports minus 1 are valid. It is strongly encouraged that nodes implement ports contiguously from 0 to the maximum specified port number. Some application controllers may attempt to enumerate various parameters associated with ports, so a sparesely implement port range causes unnecessary bus traffic and may lead to unnecessarily high memory requirements in what could be small resource-limited systems.
For example, a particular bus node may implement 8 analog outputs and 16 digital inputs, for a total of 24 ports. It is preferred if the node reports that it implements 24 ports, which implies port IDs will be in the range of 0 to 23. In that case, for example, the analog outputs could be ports 0-7 and the digital inputs ports 8-23. The node could instead define the analog outputs as ports 0-7 and the digital inputs as 16-31. In that case, it must report 32 ports, although 8-15 are not actually implemented. This is legal in EmCan, but the gap of 8 unimplemented ports is discouraged. A relatively small gap like this may not cause much extra burden, but leaving large gaps is strongly discouraged. For example, the node could assign the analog inputs ports 0-7 and the digital outputs ports 1024-1039, which would then require it to indicate it has 1040 ports. This could add significant overhead to the system as a whole and to the bus controller and other parts of the system, which could be implemented with small resource-limited processors. Again, EmCan makes no rules about how the 16 bit port space is assigned, but thought should be given to minimizing unused ports within the range reported by the node.
All the port-related frames are extended data frames with the first two data bytes being the port number. The host can request a ACK/NACK response to such frames, and the node can not respond, respond with ACK, or respond with NACK. Remote request frames to these opcodes are not supported since they are meaningless without the 2-byte port number data.
Any frame that is not structurally correct or is self-inconsistant is ignored. A frame is not acted upon if any of the following conditions are met:
Ignored frames must not be acted upon. Other than examining them to determine they must be ignored, receiving such a frame must be the same as receiving no frame at all.
A NACK frame is sent in response to a valid port-related frame which requests a ACK/NACK response, and any of the following conditions are met:
Port-related NACK frames only contain the port number data bytes.
A ACK frame is sent by a node in reply to a port-related frame if all of the following conditions are met:
ACK frames contain the data value currently in use by the port after the received frame is processed, whether the data values in that frame were ignored or modified before use or not. ACK frames always report the final result, regardless of what influence, if any, the received frame had on that result.
For example, if the node is not in configuration state, ACK replies to attempts to change non-volatile settings will report the existing value since the setting was not changed. In that case, the data value sent in the request is irrelevant.
ACK frames always report that actual current value. The host can cause a ACK frame to be sent, and thereby receive the current value, by sending a port-related frame with only the port number and no additional data bytes. Such a request is guaranteed not to change the port state, only to request its current value.
A current value request frame must still request a ACK/NACK response to receive one.
A current value request as described here is implicitly valid for all port-related frames unless specifically stated otherwise.
Note that ACK frames have a uniform format and meaning whether they are in response to a action request (contains data beyond the port number) or a current value request (contains only the port number data bytes). In each case, the ACK reports the current value in use by the port at that time.