Hello Gene
I always forget some context...
In my use of the RPi and SPI and stacking connectors ( there, that's the
context )
I have SPI devices connected thru the 40pin stacking header
so my paths are very short and solid.
Theres topological problems with the stacking connectors
but SPI routes are very short.
( some one list referred to the 'sandwich' problem of these
microcontrollers )
I have the RPi3B and two protoboards with MCP23s17's stacked,
then short jumpers to the PICnc stepgen.
I use the 'extender' style 40pin headers, gold plated.
I dont know how tall the stack can grow before signals degrade.
re: the topology
I tried to invert the 40 pin connector
that is, to move it to bottom of RPi
so the heatsinks and fan on top side didnt bother the stacking
It was a mess, too hard to remove it :-(
I considered a board to just breakout just the spi pins.
But for the RPi's , a generic SPI driver is needed ( talks _to_ many/any
devices).
And for the LinuxCNC community, a generic SPI driver that talks _from_
many hosts is needed.
Thats another problem, can a comp have its own modules?
Like, can a generic SPI host comp have specific client sub-comps?
How to talk to different devices with same protocol?
I cant right now, I'm attempting python calls to use the MCP23s17 i/o,
its slow and non-realtime if I cant swing it, but for buttons, relays
and lights, thats ok.
BTW: Theres 2 spi buses on the rpi3b
one SPI0 has 2 chip selects the other has 3 SPI1.
tomp
On 03/28/2019 02:49 AM, Gene Heskett wrote:
On Wednesday 27 March 2019 14:03:33 Nicklas Karlsson wrote:
On Wed, 27 Mar 2019 19:12:48 +0700
TJoseph Powderly <tjt...@gmail.com> wrote:
( list apology, I seem to have replied to posters rather than to the
list, and several times :-(
re SPI comms Linuxcnc SBC microcontrollers ...
it has been said on this mail list,
that SPI is a good candidate for a bus technology to work _with_
realtime.
Maybe not as a bus but chip select between devices over a short
distance work. Isolation is possible but delay may cause problem at
high speed. If drivers are kept close together and there are not to
many of them which likely to be the case it is a good candidate.
CANopen is available for ordinary CAN networks and over Ethercat. SDO
protovol may be a very good candidate for configuration to get a more
or less standard format, *.eds files may be used as a standard
dictionary format, expedited transfer of up to 32 bit at a time is
relatively simple to implement, to add a sequence number might be a
good idea so that severel messages could be on the the they thru the
system but for configuration to wait a short while is OK since there
usually only is a need for a few numbers. I have som code is somenone
need it. PDOs are simple if harcoded, mapping and communication
parameters are harder but may not be needed for a working system.
SPI is very common on Micro controllers, cheap and fast but only over
very short distances, there certainly are limitations.
Qualify very short distance to include up to 8" long although it wasn't
as bulletproof at a lower speed as I was using 8" pin to pin jumpers and
no termintors. Now my cable is a legit ribbon and about an inch. And
Jon E's little terminator board adds a little under an inch to that. At
that distance, its bulletproof.
heres some work in that vein (maybe overlooked)
yeltrow's work:
a generic spi hal module so you can use other SPI devices ( rpi,
arduino, mcp23s17, ENC28J60, theres a lot of spi stuff to hang onto
such a bus )
https://www.forum.linuxcnc.org/24-hal-components/28851-spi-bus-gener
ic-driver-and-st-l6480
the files are on the forum for members
linuxcnc-upload-2015-12-03.tar
erste's work:
for ethernet circumventing usb ( via spi
interesting as spi and ethernet seem to be future avenues
http://erste.de/ethraw/README
theres other efforts but less coupled to the spi grail
tomp
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Cheers, Gene Heskett
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
