[Mike Copioli]

Originally Posted by Radical Pi

Request messages would still be blocking, right? Having some sort of asynchronous request system would be IMO an annoyance for programming and would just confuse people trying to use CAN in their code.

Requests do not have to be blocking. The gateway device could simply dump the result of the request, say current from JAG 1, 2, 3, 4... into a buffer over TCP/IP/UDP or serial. A buffer would have to exist on the application side that holds the data. A ring buffer(fifo) would work fine for this task. Basically the application requests current from the Jags, then proceeds to the next task, when the data is available a flag is set notifying the application that new data is available. The application then pops the data from the FIFO. This is probably not even necessary though. The blocking time would not be very long for even a dozen requests, sub mS. The whole process could be run on it's own thread anyway. The point is to let the CAN BUSS do all the dirty work.

Imagine this scenario:

-CAN GYRO
-CAN ADC
-CAN QUAD ENCODER
-CAN SPEED CONTROLLER

-CAN gyro node performs all of the integration math for calculating angular position.

-CAN ADC performs all of the ADC sampling and averaging and could provide position, velocity or raw analog value.

-CAN quad encoder node decodes all quadrature encoder data and provides position and velocity.

The CAN nodes will now have the functionality of sending traffic to and from each other instead of back and forth to/from the application. I want to servo speed controller 1 to the position returned by the ADC or Quadrature module. You get the idea.