I was talking with someone about developing a multifunction I/O Cape
for the BeagleBone and I wondered how much interest there might be in
this. It would be intended for controlling external equipment and
taking measurements. The I/O would include four differential analog
inputs, four analog outputs, six low level digital inputs (5 volt
tolerant), six 3.3 volt digital outputs, six isolated digital inputs
and six isolated, high current outputs (up to 2.5 amps and 50 volts).
The analog inputs will have a 5 volt input range and be compatible
with thermocouples. This is intended to be used for controlling a
variety of equipment that is not compatible with a basic BeagleBone.
I am looking for software developers who would be interested in
providing an interface to the cape. I am planning to use one of the
serial ports with a simple command structure to read inputs and
control outputs.
As a separate feature there will be an option to include a high speed
parallel processor with 144 small but very high speed processors (700
MIPS each). I don't know if this will be of value to BeagleBone
users. If interested contact me.
I was talking with someone about developing a multifunction I/O Cape
for the BeagleBone and I wondered how much interest there might be in
this. It would be intended for controlling external equipment and
taking measurements. The I/O would include four differential analog
inputs, four analog outputs, six low level digital inputs (5 volt
tolerant), six 3.3 volt digital outputs, six isolated digital inputs
and six isolated, high current outputs (up to 2.5 amps and 50 volts).
The analog inputs will have a 5 volt input range and be compatible
with thermocouples. This is intended to be used for controlling a
variety of equipment that is not compatible with a basic BeagleBone.
I am looking for software developers who would be interested in
providing an interface to the cape. I am planning to use one of the
serial ports with a simple command structure to read inputs and
control outputs
I would have thought using either SPI or I2C would be a much better
option. With I2C you already have the option of multple devices on
the one link with well defined addressing rules, and plenty of existing
chips that support use it. I2C is already supported in linux, and
readlily accessible from user programs - so there is no software to
support and provided the relevant I2C channel is enabled almost no
pinmuxing to enforce in the EEPROM.
On Friday 02 Mar 2012, rickman wrote:> I was talking with someone about developing a multifunction I/O Cape
> for the BeagleBone and I wondered how much interest there might be in
> this. It would be intended for controlling external equipment and
> taking measurements. The I/O would include four differential analog
> inputs, four analog outputs, six low level digital inputs (5 volt
> tolerant), six 3.3 volt digital outputs, six isolated digital inputs
> and six isolated, high current outputs (up to 2.5 amps and 50 volts).
> The analog inputs will have a 5 volt input range and be compatible
> with thermocouples. This is intended to be used for controlling a
> variety of equipment that is not compatible with a basic BeagleBone.
> I am looking for software developers who would be interested in
> providing an interface to the cape. I am planning to use one of the
> serial ports with a simple command structure to read inputs and
> control outputs
I would have thought using either SPI or I2C would be a much better
option. With I2C you already have the option of multple devices on
the one link with well defined addressing rules, and plenty of existing
chips that support use it. I2C is already supported in linux, and
readlily accessible from user programs - so there is no software to
support and provided the relevant I2C channel is enabled almost no
pinmuxing to enforce in the EEPROM.
David
Yes, I meant "serial" port in the literal sense, all of these are
serial ports. Your point about I2C being sharable is a good one. Are
there any other capes using the I2C interface for interboard comms?
It would be most compatible if I used the same mechanism, but I expect
we would need to have a way to set the address. I don't know how
practical it would be share the boot eeprom I2C.
I've built two different expansion boards, one for the Beagleboard/Beagleboard-XM and one for the Beaglebone. Both have Microchip PIC microcontrollers on them communicating with the host Beagle via SPI. The Beagleboard expansion has a dsPIC6014A and the Beaglebone expansion has a PIC32MX150F128D. By just setting up spidev in the board files and some minor muxing changes, both are working fine. All the code is C and both Beagle's are the masters and the PICs are slaves. So, yes this concept works and works well. You will need to be a bit creative with your higher level communications protocol, but the underling infrastructure is in place and works well.
> On Friday 02 Mar 2012, rickman wrote:> I was talking with someone about
> developing a multifunction I/O Cape
>
> > for the BeagleBone and I wondered how much interest there might be in
> > this. It would be intended for controlling external equipment and
> > taking measurements. The I/O would include four differential analog
> > inputs, four analog outputs, six low level digital inputs (5 volt
> > tolerant), six 3.3 volt digital outputs, six isolated digital inputs
> > and six isolated, high current outputs (up to 2.5 amps and 50 volts).
> > The analog inputs will have a 5 volt input range and be compatible
> > with thermocouples. This is intended to be used for controlling a
> > variety of equipment that is not compatible with a basic BeagleBone.
> >
> > I am looking for software developers who would be interested in
> > providing an interface to the cape. I am planning to use one of the
> > serial ports with a simple command structure to read inputs and
> > control outputs
>
> I would have thought using either SPI or I2C would be a much better
> option. With I2C you already have the option of multple devices on
> the one link with well defined addressing rules, and plenty of existing
> chips that support use it. I2C is already supported in linux, and
> readlily accessible from user programs - so there is no software to
> support and provided the relevant I2C channel is enabled almost no
> pinmuxing to enforce in the EEPROM.
>
> David
Yes, I meant "serial" port in the literal sense, all of these are
serial ports. Your point about I2C being sharable is a good one. Are
there any other capes using the I2C interface for interboard comms?
It would be most compatible if I used the same mechanism, but I expect
we would need to have a way to set the address. I don't know how
practical it would be share the boot eeprom I2C.
There are two I2C busses in pinmux group 0, so there is at least one
not shared with the config eeprom. And even if you do share that bus
all you have to do is avoid the eeprom address.
I was thinking about this, too, but had a hard time getting past the size of a cape and the relative difficulty of adding a large number of pins for this purpose. What I finally decided was add a reasonably hardened SPI port with a data out, data in, clock, and latch signal; then be able to add “expansion I/O” in the form of very simple boards with a 74HC595 or equivalent… that way all that’s required externally are shift registers, and you can add as much medium-speed I/O as you want, and worry about interfacing/isolation externally.
I am working out the details of an XBee cape now, for home automation. My plan was to add an I/O SPI connector as described above for interfacing with my home security (wired sensors on all doors, windows, some motion detectors, etc.)
The analog inputs will have a 5 volt input range and be compatible
with thermocouples.
There are some nice integrated components for dealing with thermocouples - built in ADC and amplifiers and digital output (SPI or I2C) … might want to consider that too.
Yes, the CPU I want to use is the GA144 from GreenArrays with144 of
the F18A processor on chip. This device has a lot of shortcomings if
you try to make it do what the TI ARM chip on the BB does, but it is
very capable as a piece of hardware doing similar things to what an
FPGA does. Just as they add DSP ALUs to FPGAs now, the GA144 is
similar to having 144 of them complete with instruction decode, etc
and running at up to 700 MIPS.
My original idea was to build an eval board for the GA144, but I
couldn't figure out what direction to orient it to. I was going to
add a Silicon Blue FPGA to provide some flexibility on the I/O
voltages since the GA144 can only do 1.8 volts. Then someone had an
idea of making an isolated I/O cape board for a particular application
and I thought this might be a good combo, two birds with one stone so
to speak.
While researching the isolated I/O I came to the conclusion that this
is not the best type of cape board because of the limited space.
Isolated I/O boards need lots of space or even multiple, separate
small boards for isolated I/O in a modular fashion. The original app
seems to have fallen in so now I am thinking of the same "smart" I/O
board, but with more lines of non-isolated I/O.
The GA144 has five analog input and output. This can be used to
provide additional analog I/O to the ADC inputs on the BB, all of
which would be buffered. Then some 20+ buffered digital I/O can be
done. The SiBlue chip can provide up to 8 mA on 3.3 volt inputs so
I'm thinking some number of pins would be direct since they can be
configured as input or output. Then some number would be buffered for
higher drive capability, either with buffers or maybe just open
collector configured transistors.
With all I/O going through the SiBlue FPGA it can act as a switch to
allow I/O to be controlled by either the BB or the GA144 chip. In
fact this cape will be capable of operating stand alone if anyone
wants to use the GA144 as the main controller.
I still need to look hard at the I/O signals between the BB and the
cape and see what is best to use. The original app was going to use a
simple serial port, either async or maybe I2C or SPI. But I want to
be able to support a mode where the GA144 has a high bandwidth to the
BB CPU. I'm told there is a DMA enabled memory bus to the cape which
would be ideal for off loading high speed computations to the GA144 if
needed.