i2c prop to prop

micronewb · 2010-07-07 02:38

Hey everybody,

Has anybody managed to use an I2C bus in a multi master setup to communicate between propellers. So far I am starting, stopping, and writing correctly, but when I read on the slave propeller I am having clock syncing issues and it is missing pulses. I am working on a project where I need multiple propellers to communicate in both directions. Any ideas, i'm also open to other ways of accomplishing this (the faster the coms the better)? Thanks for the help.

Leon · 2010-07-07 04:56

Why I2C? It's very slow. It can save pins, though, compared to other solutions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

max72 · 2010-07-07 06:32

check the obex.

For instance:

obex.parallax.com/objects/546/

Massimo

micronewb · 2010-07-07 12:49

I was trying I2C because there will most likely be four or five props involved and I can't spare more than two I/O pins for coms on some of them (so SPI is out). I am now thinking I will either try and rewrite some of the inter-propeller object to act just like an I2C bus or change the setup to a main controller and sub controllers that communicate with one wire serial. Only bad thing is everything would have to go through the main controller but it could be worse. I was just curious if anyone had pull this off [noparse]:)[/noparse] i love how people don't assume anything is impossible with the prop...what a great chip!

BigFoot · 2010-07-07 13:41

It might be allot easier to just use a high speed serial bus between the processors. Then
you wouldn't have to worry about formatting packets and all the overhead. We have seen
well over 500 Kbsec with the Propeller running at 100 MHz.

Russ

BigFoot · 2010-07-07 13:59

If you could spare 4 I/O pins per Propeller you could implement a ring bus. Any
propeller could talk to any other and you wouldn't need a master.

You would have to write a simple OS to control the bus, check parity and detect
collisions.

Russ

jazzed · 2010-07-07 14:41

Only one COG could be used for I2C or other BUS communications.

Point to point serial connections > 19.2Kb/s require a COG per connection.
No problem if you only need one connection or two like BigFoot's ring idea.

Unfortunately, the Propeller I2C device code I've seen is quite slow.
http://forums.parallax.com/showthread.php?p=721563

An 8-bit bus protocol with pseudo-dma would allow up to 255 devices
and 5 MB/s data transfer rates in one COG per device (I did this in single
master mode only). Here is a link to my parallel bus effort:
http://forums.parallax.com/showthread.php?p=839672

With a transport layer done, then you have to focus on a fit IPC method
which can be simple or a big can of worms depending on the application [noparse]:)[/noparse]

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Timmoore · 2010-07-07 16:16

None of the i2c objects I have looked at support multi-master. I think its doable but you probably need to start with the i2c slave object since you need to monitor the bus all the time for arbitration, etc. so it will take a cog.

The other option is to use a serial ring, tx· goes to the next prop, rx goes to the previous prop. You will need some work to do addressing, remove stuff from the ring etc.

Both need 2 pins and a cog but the serial ring is propably easier since the serial driver will do the low level work.

JonnyMac · 2010-07-07 16:18

You could actually do serial on one pin using half-duplex, open-source connections. FullDuplexSerial allows for this configuration (I use it in a product to "talk" to a BASIC Stamp"). You simply need to come up with a protocol.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

micronewb · 2010-07-07 19:54

Thanks for the suggestions everyone. @timmoore I hadn't seen anything with multi mastering already done either I just wanted to make sure I wasn't missing something so thanks for confirming that (no since redoing somebodies hard work). I have seen a couple people mention a ring bus. I am familiar with the connection pattern but have never done the protocol. Do you have to go through each prop in the ring until you reach the one you want to communication with? I am also assuming you can only "talk" one way around the ring, correct? More on the I2C side, I think I am getting close on the multi master protocol, but want to make sure this is correct: is waitpeq sufficient to wait for a start bit and sync the clocks? I am getting varying results when receiving the same byte and it makes me suspect clock issues. Any inputs on transmission rates for i2c versus ring bus? 400 kbs : i2c ? : ring bus

jazzed · 2010-07-08 04:38

A good ring example to study is Token Ring

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

pjv · 2010-07-08 15:05

@jazzed

Steve I expect one could get a single cog to run three or four simultaneous half duplex ASCII channels at 115,200, reading from and dumping to hubram.

Cheers,

Peter (pjv)

jazzed · 2010-07-08 16:33

@pjv,

Hi Peter, yes it is possible using your scheduler.

A little Spin packaging would make your method more accessible to the average user.

Maybe use a startup interface something like this:

{{
============================================
addTask - adds a PASM task to the scheduler
taskcode - address of the PASM task code to load
parms - address of parameters that task will use
}}
pub addTask(taskcode, parms)

It might be worth starting a topic dedicated to using the scheduler.
We could all help each other develop scheduler interface routines there.
A good first example would be how to add serial interfaces.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Bill Henning · 2010-07-08 18:20

Can I put in a request?

I'd love to see a one cog driver that combined keyboard, mouse, and one or two serial ports!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

lonesock · 2010-07-08 19:15

I personally like the CAN-bus design: en.wikipedia.org/wiki/Controller_area_network. I think the collision detection/avoidance algorithm is particularly elegant. (Of course I have not written any prop code for it, so this doesn't help you directly, sorry.)

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")

pjv · 2010-07-08 20:06

@Bill;

That sounds like a good idea, and I can contribute to that, but perhaps not for a bit yet.

Actually I'm working on a scheme just now where the tiny drivers I use are stored in HubRam, and get pulled into CogRam as required. The scheduler of course lets me do this in the background. So as the mainline executes, it will cause the necessary tinies to be loaded, used and discarded as required, and genreally runs at full speed. This way CogRam appears to much larger than it is, because it gets reused. I think one could effectively get rather large programs to run in this manner in a single Cog because only that which is required stays resident, the rest gets swapped out.

Perhaps this is how your LMM works.... I have not yet looked at that since I'm having too much fun trying these concepts.

Cheers,

Peter (pjv)

micronewb · 2010-07-08 20:13

@lonesock

i'm cool with ideas of things people haven't tried but think would work. I am going to have to write something new either way I would rather start with the best overall method first and write one rather than several to find the best if possible. i'll check into the CAN bus.... thanks

Bill Henning · 2010-07-08 22:31

Hi Peter,

Not quite how it works (well, unless you use FCACHE), but very close.

Actually I am considering brushing off an old idea - writing a multi-threaded LMM kernel. I think I mentioned that possibility in my original LMM thread. It would be pretty easy to make one that was quite deterministic for four threads, giving four 1MIPS threads. Or nine 0.5MIPS threads.

Hmm... I should do that. It would make writing the combo driver I really want (kb/mouse/2 serial) fairly trivial!

I think I will call it TLMM for Threaded Large Memory Model

Bill

pjv said...
@Bill;

That sounds like a good idea, and I can contribute to that, but perhaps not for a bit yet.

Actually I'm working on a scheme just now where the tiny drivers I use are stored in HubRam, and get pulled into CogRam as required. The scheduler of course lets me do this in the background. So as the mainline executes, it will cause the necessary tinies to be loaded, used and discarded as required, and genreally runs at full speed. This way CogRam appears to much larger than it is, because it gets reused. I think one could effectively get rather large programs to run in this manner in a single Cog because only that which is required stays resident, the rest gets swapped out.

Perhaps this is how your LMM works.... I have not yet looked at that since I'm having too much fun trying these concepts.

Cheers,

Peter (pjv)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

BigFoot · 2010-07-09 13:10

You could probably implement a half duplex ring bus with only 2 I/O pins per
Propeller (Data in & Data out). The data would have to travel through four of
the five processor maximum.

I made a typo in one of the posts above, we think we can get over 400 Kbaud
with the propeller running at 100 MHz. Even our 80 MHz terminals run reliably
at 115 Kbaud.

Russ

Beau Schwabe · 2010-07-09 15:36

Something to consider with open-source (aka open-collector) connections such as 1 wire serial or CAN-bus, is that speed may become an issue if the pull-up is weak resulting in a slow rise time.

One way to solve this would be to implement a token ring or star configuration where in the token ring only one master was allowed to talk at a time in a round-robin fashion. The same goes with a star configuration, only one master allowed to talk at a time, but with the star configuration each master has an ID and is only allowed to 'talk' if given permission from the previous master (<-- could be in any order).

Having a single master at any given time allows the signal to be driven high rather than pulled high.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

micronewb · 2010-07-09 15:47

Thanks Beau, I have the basic ring driver done and working on the collision aspect and was doing thinking about something similar. My thought (and please give your thoughts) was to send a first byte that would bring the entire ring high and identify who the receiver is, send the byte, send the line low releasing to the next inline for transmitting. Anyone have a suggestion for queuing the masters or somehow ranking importance? For example, if I am needing to send a stop command to a motor that is more important than receiving an encoder reading.

i2c prop to prop

Comments