K
Kevin C.
- Jan 1, 1970
- 0
Working on a basic dual drive autonomous bot.
The Motor Controller has it's own MCU generating the
PWM and reading the odometry sensors. It makes adjustments
to stay on the course if it detects wheel slip and such and sends
status messages to the main controller. Currently, the two
controllers pass messages back and forth over the USART.
I'm starting to think about the next phase, and am
toying with the idea of adding another MCU to the mix
to handle the sensors.
This of course brings up the question of how to have the
main controller talk to both the motor controller and the
sensor board.
Since USART is point to point (not a bus configuration, no
addressing),
the master could be configured in a star configuration and implement a
software USART to each of the sub-processors. It would be relatively
easy and inexpensive but wasteful of I/O pins and would (probably)
only practically
scale to 4 or 5 sub-processors.
It seems I have three choices. SPI, I2C (TWI) or CAN.
My knowledge of any of them is limited, but my research indicates the
following.
SPI - Ideal for single slave, single master configuration. Each
additional
slave device requires an additional i/o pin to set the "slave select"
(beyond
three devices, I suppose one could put in an octal or hex decoder to
get
around that). It's a full duplex communication stream and supports
fairly
high speeds. It's hardware interface is more than I2C/TWI, but needs
less software support (I think). Further, many processors have
hardware
support.
Some info is here: http://www.embedded.com/story/OEG20020124S0116
I2C - Definitely a bus architecture, but seems designed to have one
main
Master talk to a variety of slave devices. Several times I've seen
mentioned
the fact that there can be several "Masters" who contend for the bus,
but
haven't seen a lot of detail on how that's accomplished. It has light
hardware
requirements and certain processors are able to handle the interface
in hardware.
The communication channel is half duplex up to about 400 Kbps
Some info is here: http://www.embedded.com/story/OEG20010718S0073
CAN - This seems to be the big guy on the block. Basically, an
Ethernet type
interface for a MCU up to 1 Mbps.
It appears that an interface chip is required for each MCU to access
the bus
or the CAN controller is an MCU feature since the protocol software is
fairly
heavy duty and would overload the processor. Fully capable of just
about
anything you want to do, but seems to be the most expensive and
elaborate
solution. Of course, it is also the most feature rich and future
proofed. The
upper level protocol definitions such as CANopen make this more
appealing
for a small project like this.
Some info is here: http://www.mjschofield.com
http://www.esacademy.com/faq/docs/canopen/
So, the question is what wisdom can the group offer on the different
alternatives?
Thanks,
Kevin
The Motor Controller has it's own MCU generating the
PWM and reading the odometry sensors. It makes adjustments
to stay on the course if it detects wheel slip and such and sends
status messages to the main controller. Currently, the two
controllers pass messages back and forth over the USART.
I'm starting to think about the next phase, and am
toying with the idea of adding another MCU to the mix
to handle the sensors.
This of course brings up the question of how to have the
main controller talk to both the motor controller and the
sensor board.
Since USART is point to point (not a bus configuration, no
addressing),
the master could be configured in a star configuration and implement a
software USART to each of the sub-processors. It would be relatively
easy and inexpensive but wasteful of I/O pins and would (probably)
only practically
scale to 4 or 5 sub-processors.
It seems I have three choices. SPI, I2C (TWI) or CAN.
My knowledge of any of them is limited, but my research indicates the
following.
SPI - Ideal for single slave, single master configuration. Each
additional
slave device requires an additional i/o pin to set the "slave select"
(beyond
three devices, I suppose one could put in an octal or hex decoder to
get
around that). It's a full duplex communication stream and supports
fairly
high speeds. It's hardware interface is more than I2C/TWI, but needs
less software support (I think). Further, many processors have
hardware
support.
Some info is here: http://www.embedded.com/story/OEG20020124S0116
I2C - Definitely a bus architecture, but seems designed to have one
main
Master talk to a variety of slave devices. Several times I've seen
mentioned
the fact that there can be several "Masters" who contend for the bus,
but
haven't seen a lot of detail on how that's accomplished. It has light
hardware
requirements and certain processors are able to handle the interface
in hardware.
The communication channel is half duplex up to about 400 Kbps
Some info is here: http://www.embedded.com/story/OEG20010718S0073
CAN - This seems to be the big guy on the block. Basically, an
Ethernet type
interface for a MCU up to 1 Mbps.
It appears that an interface chip is required for each MCU to access
the bus
or the CAN controller is an MCU feature since the protocol software is
fairly
heavy duty and would overload the processor. Fully capable of just
about
anything you want to do, but seems to be the most expensive and
elaborate
solution. Of course, it is also the most feature rich and future
proofed. The
upper level protocol definitions such as CANopen make this more
appealing
for a small project like this.
Some info is here: http://www.mjschofield.com
http://www.esacademy.com/faq/docs/canopen/
So, the question is what wisdom can the group offer on the different
alternatives?
Thanks,
Kevin