C
Chris Carlen
Greetings:
I have two system designs in the works that will need some sort of
communication link between boards. In both cases, there will likely be
a microprocessor board (MB) in the chassis which will facilitate
communications with perhaps a PC, and several other slave boards which
should receive configuration parameters from the MB. I am pretty
certain at this points that the slave boards will only ever have to
receive data, not send. Though acknowledgement might be nice. The
number of slave boards may vary in both applications, so a
communications method that doesn't depend on a hardwired number of
slaves would be required. Data throughput will be low, just a few dozen
bytes or so every once in a while.
This all sounds like the realm of I2C.
The first case is a research lab fuel injector driver system which
should support 1-4 injector power driver modules. Each module should
accept configuration data from the MB consisting of the inject durations
and pause lengths for multiple injection sequences initiated by a single
trigger pulse (which goes directly to the power module, not through the
data comm link). The MB in this case will have the typical keypad and
character LCD user interface. It will also provide a PC interface for
remote setting of these parameters.
The second case is an abstract laser light-show projection system which
will employ 4-6 DDS function generators based on AVR microcontrollers.
Each DDS has its own user interface and display capability for setting
frequency and phase of its dual outputs, but I'd like to also be able to
command them remotely for computer sequencing of the displayed patterns.
Thus to implement a remote interface, I plan to have a MB that will
string I2C to all the DDS modules.
It would seem that in terms of hardware configuration of the
communication system, in the case of multiple identical "slave" units,
that they would need something like DIP switches to set unique
addresses. But from what I have read about I2C (just a brief intro this
evening) there is a hardware call command which can allow the master to
figure out how many folks it's talking to. So this would mean I don't
have to provide any user configuration facilities within the MBs to tell
them how many slaves they are talking to.
I have also taken some initial looks at CAN bus, which seems a bit more
involved and also capable than I2C, as well as being suitable for longer
distance communication. But it seems that I2C might be a more
approachable first step for me into the realm of communication hardware
layers, which also looks likely to serve my needs for the immediate
projects.
That leads to my main question:
Does it seem like I am on the right track in considering I2C for these
applications? To be sure, the I2C busses in each case would be
contained within only a single chassis, but I am planning to route the
bus between several boards (either via a backplane or just a daisy
chained cable), rather than just between several chips on a single board.
Any other approaches I should consider?
Thanks for input.
I have two system designs in the works that will need some sort of
communication link between boards. In both cases, there will likely be
a microprocessor board (MB) in the chassis which will facilitate
communications with perhaps a PC, and several other slave boards which
should receive configuration parameters from the MB. I am pretty
certain at this points that the slave boards will only ever have to
receive data, not send. Though acknowledgement might be nice. The
number of slave boards may vary in both applications, so a
communications method that doesn't depend on a hardwired number of
slaves would be required. Data throughput will be low, just a few dozen
bytes or so every once in a while.
This all sounds like the realm of I2C.
The first case is a research lab fuel injector driver system which
should support 1-4 injector power driver modules. Each module should
accept configuration data from the MB consisting of the inject durations
and pause lengths for multiple injection sequences initiated by a single
trigger pulse (which goes directly to the power module, not through the
data comm link). The MB in this case will have the typical keypad and
character LCD user interface. It will also provide a PC interface for
remote setting of these parameters.
The second case is an abstract laser light-show projection system which
will employ 4-6 DDS function generators based on AVR microcontrollers.
Each DDS has its own user interface and display capability for setting
frequency and phase of its dual outputs, but I'd like to also be able to
command them remotely for computer sequencing of the displayed patterns.
Thus to implement a remote interface, I plan to have a MB that will
string I2C to all the DDS modules.
It would seem that in terms of hardware configuration of the
communication system, in the case of multiple identical "slave" units,
that they would need something like DIP switches to set unique
addresses. But from what I have read about I2C (just a brief intro this
evening) there is a hardware call command which can allow the master to
figure out how many folks it's talking to. So this would mean I don't
have to provide any user configuration facilities within the MBs to tell
them how many slaves they are talking to.
I have also taken some initial looks at CAN bus, which seems a bit more
involved and also capable than I2C, as well as being suitable for longer
distance communication. But it seems that I2C might be a more
approachable first step for me into the realm of communication hardware
layers, which also looks likely to serve my needs for the immediate
projects.
That leads to my main question:
Does it seem like I am on the right track in considering I2C for these
applications? To be sure, the I2C busses in each case would be
contained within only a single chassis, but I am planning to route the
bus between several boards (either via a backplane or just a daisy
chained cable), rather than just between several chips on a single board.
Any other approaches I should consider?
Thanks for input.
