Hi all
Just to introduce myself: I'm Curt Wuollet and I'm
designing an Open Hardware PLC. The IO part is really
nothing special except that it will use an OTS CPU
like the Beagleboard and the interface to IO will be
the SPI bus. I'd like to use my one allowed RTFM
question after reading the whole ref manual and
pondering the available Linux options without reading
_all_ the source:^). Which SPI port would be the best
to use for this? what drivers exist? and will I have
trouble dedicating 6 or 8 GPIO to use as chip selects?
I know that's three questions, but I'm trying to pick
a CPU without digging to the microcode level. The
muxing and defaults make it kinda confusing.
Thanks
cww
Excerpts from cww's message of Fri Mar 05 15:23:20 -0500 2010:
Hi all
Just to introduce myself: I'm Curt Wuollet and I'm
designing an Open Hardware PLC. The IO part is really
nothing special except that it will use an OTS CPU
like the Beagleboard and the interface to IO will be
the SPI bus. I'd like to use my one allowed RTFM
question after reading the whole ref manual and
pondering the available Linux options without reading
_all_ the source:^).
You're lucky. I'm in the middle of a BeagleBoard-based SPI perhipheral
project myself.
Which SPI port would be the best
to use for this? what drivers exist?
The OMAP has a set of integrated SPI controllers known as McSPI
controllers. These are directly supported by the kernel's spi subsystem.
The OMAP on the BeagleBoard have four McSPI controllers with different
capabilities,
spi1: 4 chip selects
spi2: 2 chip selects
spi3: 2 chip selects
spi4: 1 chip selects
Unfortunately, Beagle on brings out only spi3 and spi4, meaning you only
have 3 actual chip selects to work with. Luckily, this is something that
can be fixed with a demultiplexer and a few GPIO pins. With this sort of
setup, you can get effectively as many chip selects as you want.
trouble dedicating 6 or 8 GPIO to use as chip selects?
I know that's three questions, but I'm trying to pick
a CPU without digging to the microcode level. The
muxing and defaults make it kinda confusing.
The only non-trivial task in getting the McSPI controllers working on
the beagle is modifying the board file to bind the device. If you are
looking for an example, feel free to take a look at my kernel branch[1].
Cheers,
- Ben
[1]
http://goldnerlab.physics.umass.edu/git?p=linux-2.6.git;a=shortlog;h=refs/heads/tracker
Ben Gamari wrote:
Excerpts from cww's message of Fri Mar 05 15:23:20 -0500 2010:
Hi all
Just to introduce myself: I'm Curt Wuollet and I'm
designing an Open Hardware PLC. The IO part is really
nothing special except that it will use an OTS CPU
like the Beagleboard and the interface to IO will be
the SPI bus. I'd like to use my one allowed RTFM
question after reading the whole ref manual and
pondering the available Linux options without reading
_all_ the source:^).
You're lucky. I'm in the middle of a BeagleBoard-based SPI perhipheral
project myself.
Which SPI port would be the best
to use for this? what drivers exist?
The OMAP has a set of integrated SPI controllers known as McSPI
controllers. These are directly supported by the kernel's spi subsystem.
The OMAP on the BeagleBoard have four McSPI controllers with different
capabilities,
spi1: 4 chip selects
spi2: 2 chip selects
spi3: 2 chip selects
spi4: 1 chip selects
Unfortunately, Beagle on brings out only spi3 and spi4, meaning you only
have 3 actual chip selects to work with. Luckily, this is something that
can be fixed with a demultiplexer and a few GPIO pins. With this sort of
setup, you can get effectively as many chip selects as you want.
I'll have to take a look at where to put code to wiggle
the pins at the right time. I could do a 1 of 8 but I
think 8 straight might be easier to explain.
trouble dedicating 6 or 8 GPIO to use as chip selects?
I know that's three questions, but I'm trying to pick
a CPU without digging to the microcode level. The
muxing and defaults make it kinda confusing.
The only non-trivial task in getting the McSPI controllers working on
the beagle is modifying the board file to bind the device. If you are
looking for an example, feel free to take a look at my kernel branch[1].
Cheers,
- Ben
[1]
http://goldnerlab.physics.umass.edu/git?p=linux-2.6.git;a=shortlog;h=refs/heads/tracker
Excellent! Thanks
An example would be most helpful, it's
been a long time since I mucked around
with the low level stuff. I'm particularly
glad not to have to try and write a driver.
Regards
cww
Excerpts from curt wuollet's message of Fri Mar 05 18:33:45 -0500 2010:
I'll have to take a look at where to put code to wiggle
the pins at the right time. I could do a 1 of 8 but I
think 8 straight might be easier to explain.
I would just do it in user space. GPIO pins are exposed through sysfs.
Earlier, I was considering adding support to the McSPI driver for using
any GPIO pin as chip select, but ultimately I decided against it. A
demux is just as effective.
- Ben
Hi Fellows,
Just for another low cost idea: you can have unlimited number of chip
selects with any combination (multi-select) implemented by using a
(chain of) serial-in parallel-out shift registers controlled by just
three GPIO pins (which are available in the BeagleBoard expansion
connector.
As I remember there is even a cascadeable 32 stage shift register
available in the standard CMOS family and it might work with the 1.8 V
logic levels. Have to check - it' been a while since I actually worked
with this idea (1985) to read an unlimited number of switch settings
the other way around... It also still is a viable idea. And it is not
too difficult to combine both these ideas into one to have unlimited
binary I/O using shift registers and a few GPIO lines in their
different modes!
siñ
Yes, and for the purposes of a PLC where the
card slots are sequentially scanned, that would
work. But, I want to hang onto the idea of
random and least time access simply by writing
a function like read_slot(slot,channel) with a
switch that clears a GPIO based on slot then
does the serial thing. and sets the GPIO on exit.
This will work well with the digital IO and much
slower A/D or D/A. Passing a channel of 0-7 will
get readings from a multi channel A/D for example
and outside that range will simply be a register
read from a digital input card. A decoder could
also be done in a single write, I think, I haven't
had time to look at what is available. I'm getting
the boards ready for fab. I want to try the first
pass with SPIdev from userland and see how fast
that is. PLCs are typically pretty slow, so that
may be fast enough. And much easier for other folks
to write to. I'm thinking of a scanner loop that
reads and writes to shm so apps could just attach.
Regards
cww
Seppo Nikkil� wrote: