monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

RPi + many-Pico I2C controller/responder AND peer-to-peer

Sun Jun 06, 2021 11:03 am

Thanks to Raspberry Pi foundation/trading we have $5 full-OS and $4 micros (~$1 w/o board)!! Obviously target rich environment for distributed processing. Missing is medium speed low cost network datalink-layer to connect many real-time pico nodes passing peer to peer messages in soft real time while also linking a web-connected rpi to loosely coordinate when necessary when it is powered-up.

i am a huge fan of CANBUS for this mission but it's differential line driver requirements make it prohibitive for the "low cost" need for hobby, light commercial apps (and neither rpi or pico have native CANBUS peripherals). On the other hand i2c is free for the cost of two pullup resistors.

Of course there are issues.

The 'main' i2c of a rpi is supposedly for a "single-master" scenario where it is intended to control all activity and is not amenable to a multi-master scenario needed for peer to peer comms.

The i2c peripherals (2) of the pico seem to be well suited for a multi-master lashup that handles two nodes starting their transmissions at the exact same time. A process of arbitration sorts out the contention nicely, one wins, one backs off, message not destroyed. And the "backer-offer" knows her message was not transmitted, so waits a bit and re-transmits (handled in software, the most elegant CANBUS handles this situation in hardware). However, the i2c of the pico docs specifically state that the peripheral can be a 'master' or a 'slave' (sorry) not both. Configuring as both has advantages.

(cuttng to the chase)

yesterday, i finally proved to myself empirically (tired of reading incomplete docs) that a rpi3 can be connected to a pico configured as both controller AND responder successfully. The pins of pico's i2c0 and i2c1 tied together so that one is config'd controller, other config'd responder. (At the combo-pico SDA and SCK have external pullups to 3.3). Bitrate is 100kbps. Also on this "piNet-i2c" is a couple of picos configured as either controller or responder, with controller sending a periodic General Call Address (GCA) message. The rpi is periodically sending a time sync message as a GCA. The rpi seems to work fine when the cli utilities i2cdetect interrogates the net to find picos configured as responders.

BTW... the time GCA-message from the rpi is hoped to be basis for something like Time-Triggered-Ethernet to sort out the situation that rpi doesn't do multi-master.

So... i am now confident that for medium-robustness, non-safety critical apps, networks of single raspberry pi plus MANY picos can be accommodated by clever application of i2c.

obviously, using BOTH i2c peripherals of the pico is a major constraint. IMHO this is where the pio of the pico can really become a market differentiator! supposedly, it can become a i2c controller to connect to all your sensors and such. i have not proven this to myself yet but i have high hopes (hope is the last to die).

please feel free to throw rocks at my concept)) Also suggestions as to how to describe this concept appreciated.

User avatar
Gavinmc42
Posts: 6062
Joined: Wed Aug 28, 2013 3:31 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Mon Jun 07, 2021 2:30 am

Have a look at the HDMI stuff, that's fast comms.
Could it do Transputer type micro to micro comms?
Those PIO things have some smarts that might help.

I2C is pretty slow, SPI is faster.
The Pi4 has more of both.
Uarts too, fastest speeds that they can go?

2 wire Ethernet for Automotive is interesting, driver chips for those?
Does it goes up to 100Mbs or only 10Mbs?

Fiberoptics, cheap 1mm plastic can do 50Mbs.

This would be more a software issue, any off the shelf solution?
https://en.wikipedia.org/wiki/Distributed_computing

A useful purpose would be a Wall of Pico's, like the old Wall of Pi's.
https://www.youtube.com/watch?v=K4QwODpgm9k
Picos can do VGA and HDMI displays, can they do video?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Wed Jun 09, 2021 12:09 pm

@gavinmc42 thanks for input. I think maybe i need to refine what i'm after. Not looking for bus to move tons of data fast. Looking more for multi-drop minimal wire peer-to-peer control bus (that's pretty much how CANBUS could be described) and (since i am pensioner on strict budget) cheap is a primary concern.

From lack of response I'm guessing that this is not a big desire in the community. It seems to me that for robotics this sort of network would be a natural requirement. My background is complex avionics where this concept was commonplace (Mil 1553 was the tool back when i got a paycheck).

Anyway, the big point of my empirical work with i2c as peer to peer is mostly getting "it-is-what-it-is" characterized (finding quirks) and making do with what i have to make many node robots for cheap.

So, i'll go back to my characterization quest (now that i KNOW the concept works) and work toward a reasonable robotic demonstration of what can be accomplished for cheap.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Thu Jul 01, 2021 1:35 pm

periodic sitrep

continuing empirical testing of a general purpose i2c network still showing great promise to scratch my personal itch ( cheap control and peer-to-peer network consisting of rpi3 (4?? zero??) ) and bunches of picos primarily for robotic applications.

i've now got bench top network with the following;
1 rpi3 that accesses the network using C calls to i2c in the file plus ioctl methods AND bash utilities i2cdetect and friends.
2-3 picos configured as master + slave (using both i2c0 and i2c1 paralleled)
2-3 picos configured as slave only but that can listen for addressed packets OR GCA (general call address)
1 pico that is acting as i2c bus sniffer
(and a bitscope-dso to verify the numbers)

(pullups are on ONE of the picos, rpi configured to use 100kbps)

results are very good so far for running continuously without breaking. The rpi is sending a time hack as a GCA at the top of every second. The master+slave picos are using the time hack as basis of avoiding collision with rpi as they send periodic GCA of their own of no more than 16bytes (so as not to worry about buffer overflow on other pico). (see time triggered ethernet for source of stolen idea) The master-slaves experience a very low probability hang that i've been able to handle with a watchdog timer. The rpi3 never seems to hang.

better report will be made in future with more complete data.

A QUESTION: the "ACTIVITY" bit in the i2c raw status register never seems to get set. Anyone have any real experience in using that bit please give me a hint what it is supposed to do, the description in rp2040 datasheet could use a few more words))

btw.. necessity is a mutha. I decided i needed a i2c bus sniffer. after successfully using a pico to detect i2c-start and i2c-stop events and looking at timing requirements, i have high hopes of making pico a fully functioning bus sniffer.

amenjet
Posts: 3
Joined: Thu Jul 22, 2021 9:30 pm

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Thu Jul 22, 2021 9:36 pm

Hi,
I thought You'd be interested in the work I have done porting a transputer emulator to the Pico. I've also implemented the transputer links using the PIOs and some extra code, and hooked them in to the transputer emulator.
There's a set of videos here.

https://youtu.be/MV_q7ltG8gY

The links run at 10MHz and the aim is to run Occam code on the emulator, thereby having a hardwar ebased transputer replacement with modern hardware. Of course, it doesn't run too fast, I've not benchmarked it against a real transputer yet. Of course, you can program the Pico in C and talk to the PIO links, or even use a ross compiler and use Occam compiled to ARM (this compiler does apparentlt exist, I may have a look at that). The 10MHz speed is chosen so the links are compatible with the IMSC011 link adapter, they could probably run much faster, the PIOs are able to.

Andrew

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Sun Jul 25, 2021 1:15 pm

@amenjet, thanks for reply and links (no pun intended). Although "transputer" rang a memory bell i don't believe i ever looked at the architecture. quite interesting but probably beyond any use case that i might hope to attack. However, i'll drill down a bit into the link protocol as i have some academic software friends that might could use a pico-transputer approach to their lofty problems but are rather o-scope challenged (where i am comfortable). i am extremely interested in your use of pio to achieve the link. using pio to implement comm protocols is fascinating approach but i fear it will be beyond my debugging expertise/patience. However, i'm really looking forward to USING working pio code that that becomes available.

For my level of parallel processing (for robots) a 100kbps 'bus' between many picos is totally sufficient. implementing it with i2c scratches my budget itch of $0.00 per node and i do like the synchonous-mostly nature of i2c.

My progress on more i2c evaluation stalled after writing a bare-bones i2c-sniffer for pico. my sniffer was sufficient for measuring length of i2c transactions but i ran into buffering issues on really loaded bus. Now i see that @joan has a i2c-sniffer in C (i believe) that runs on rpi, so eval'ing that code is next step.

User avatar
Gavinmc42
Posts: 6062
Joined: Wed Aug 28, 2013 3:31 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Mon Jul 26, 2021 5:59 am

My Transputer memory Bell rang loudly when I saw this :D
https://shop.pimoroni.com/products/pga2040

A bit expensive to make a 4 x 4 2040 PGA layout, but cheaper than the original ;)
Even a PCB with 16 RP2040s would not be very big.
Make a TransPico Hat for a Pi

I will be following your progress with interest, while I acquire some more Picos and lots of RP2040 chips ;)
I was wondering if Occam would port.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

llooman
Posts: 5
Joined: Sun Aug 01, 2021 11:56 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Sun Aug 01, 2021 12:35 pm

Idea: "lets try to have a pi pico running in i2c salve mode and switch to i2c master mode when needed. Once succesfully send return back to i2c slave mode"

I am using a i2c multimaster iot network between several arduino avr boards at home for many years. Solved the wire length limit by adding active terminators at the end of the network.

This way the iot home server can send commands to client nodes and client nodes can upload values from sensors when new values become available. When the server wants to know a perticular value from a client node it sends a refresh command and the client will then upload the current value as an i2c master. All communicatoin is done async. No need for a master to wait for a client response.

With the Arduino wire library you can act as a i2c slave by setting a service routine to handle request from i2c masters. At same time you can fire a master request to any client. So both can be active in your program. Ofcourse only one can be active at the same time. Thats how i2c works.

I don't see this option in the pi pico C++ SDK so it look like you have to choose how the pico i2c behaves in your program a master or a slave.
On the internet i saw someone succesful using both pico i2c ports to create an i2c pear to pear network.

My idea now is to try switching between slave and master mode when needed. Default the pico will be a i2c slave. When your program needs to send data it will switch to an i2c master. Once the data is send it returns to an i2c slave.
Will let you know what the outcome will be.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Tue Aug 03, 2021 11:24 am

Thanks for suggestion @llooman. I had looked at that possibility (using only one i2c channel and reprogram on the fly to be master) by using direct programming of the i2c hardware registers or using the library calls. Seems doable either way and that would free up one i2c channel for other sensors. I'm sure my concept of ganging BOTH i2c channels together to obtain peer-to-peer AND responder(slave) behavior would not be popular. I will test your concept soon.

Currently, i am bogged down on my attempt to write a full i2c transaction sniffer. The i2c hardware on pico doesn't have a promiscuous mode, it's either controller(master) or responder(slave) and for slave operation it will grab data only for packets addressed to it. Listening for ALL activity so far is eluding my abilities. I could really use some help on this. anyone? anyone? I'm using i2c1 hardware to detect the start and stop conditions (appears to work fine) then using i2c0's pins (commoned with i2c1's pins) to detect edges of SCK to time sampling of SDA. The data sampling does NOT work so far. I am doing the data sampling in an ISR that is rising edge triggered by SCK. anyone?

llooman
Posts: 5
Joined: Sun Aug 01, 2021 11:56 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Wed Aug 04, 2021 5:28 am

@monkeyfork,

A i2c sniffer sound cool. Did you consider the new PIO option? To me this PIO option sounds good for lowlevel work.

Before starting with Pico development i am waiting on the platformio "earlephilhower/arduino-pico". At the moment platformio does support the Pico out of the box but not jet with the full c++ SDK. With this earlephilhower it will have the full Pico SDK

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Wed Aug 04, 2021 1:04 pm

@llooman, yup, i have considered using PIO for making i2c master+slave peripheral (mentioned in original post). For now i'm sticking to C on a single core using rpi's most excellent SDK. The PIO would be the optimum/elegant end game but right now it is in the "too-hard-pile" for me. Fairly involved assembly coding (making a promiscuous mode i2c i believe, would be quite difficult) is just beyond my patience and skill level. However, testing/verifying same would be right up my alley in case anyone wants go that path and is looking for an annoyingly critical tester))

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Mon Aug 09, 2021 1:33 pm

Shifting into a higher gear as i prove to myself once again that necessity-is-a-muther. i stalled on getting i2c sniffer working it was apparent that my interrupt driven method of sampling data within a i2c transaction was missing a lot of interrupts for unknown reasons. seemed obvious to me that i will have to delve MUCH deeper into timing issues like interrupt latency and interrupt nesting maybe (nasty, nasty stuff in my opinion). so, decided if i'm going to be confused a lot might as well give the pio-i2c example a try and get on with learning pio. The pio-i2c-scan example didn't work for me at first due to confusion about how to get output via printf on usb but finally sorted that out with forum help. As i already had wiring using gpio 12,13 i chg'd example to conform with my wiring (eg uses 2=sda, 3=sck). that change didn't seem to work, going back to gpio2,3 worked. So now i have basis of i2c master/controller as a pio peripheral that hopefully will be helpful in sorting out my i2c sniffer code (by separating 'start', 'stop', data segments of i2c transaction).

i would really like to hear that someone is working on a pio i2c slave/responder code or even comments about feasibility of such a code.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Wed Aug 11, 2021 3:28 pm

morphing my madness...

the code pico-examples/pio/i2c i2c_bus_scan.c i2c.pio pio_i2c.c pio_i2c.h have been a huge help in understanding both pio and i2c. i've now got a pico transmitting a GCA (general call address 'packet') which contains a timestamp for synchronization (ala time triggered ethernet) via hacked version of i2c_bus_scan.c. Very helpful was the low level c routines in pio_i2c.c which can separate parts of a i2c transaction like sending a start condition, sending a stop condition via the pio state machine. i'm inching toward understand pio and remain pretty much amazed at the possibilities.

being able to transmit and receive GCA (ie to broadcast address 0x00) is key to my scheme of making a publish and subscribe mechanism for general purpose zero-controller network of picos (which are benignly and optionally administered by a rpi)

it appears now that understanding the i2c.pio code is not necessary for my purposes (and is too much for my pea-brain).
However, i would like to understand the C interface to the PIO prog. If anyone has insight into pio_i2c.c i am really
baffled by this line.

Code: Select all

pio_i2c_put16(pio, sm, (addr << 2) | 1u);
Commenting that line in future releases would help all (IMHO). leaving explanation here would accrue massive karma.

llooman
Posts: 5
Joined: Sun Aug 01, 2021 11:56 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Thu Aug 19, 2021 12:47 pm

Made progress testing using 1 pico i2c-port. Default in slave mode. Switch to master mode before writing.
In test it is now working in my pear to pear network together with other arduino avr nodes.
The arduino avr i2c don't need this switching.

On start i just do the normal init as a slave:

Code: Select all

    i2c_init( i2c_default, 100 * 1000); 
    i2c_set_slave_mode(i2c_default, true, slave_address);
....

When need to send bytes to an other node:

Code: Select all

i2c_set_slave_mode(i2c_default, false, slave_address);
int bytesWriten = i2c_write_timeout_us (i2c_default, toAddress, rxData->raw, twSendSize,  false, 1000  ); 
i2c_set_slave_mode(i2c_default,  true , slave_address);
Reading input from other nodes in the loop, there i check the i2c_get_read_available( i2c_default ).
When input is available i wait for 1 millisecond, then read the whole buffer.

Code: Select all

void loop() {
uint available = i2c_get_read_available( i2c_default  );
...
i2c_read_raw_blocking (i2c_default, tw_rxBuffer, available);
....


Pretty confident this will work for me.

FYI:
For now i can do development for the pico from VSCode. Still awaiting the platform-io version of earlephilhower.
I installed the arduino version of earlephilhower. From VSCode do compiling by running a task calling the arduino-cli.
With the arduino version of earlephilhower you can use arduino syntax AND the real pico SDK. The above i2c calls are in the pico SDK !

Code: Select all

    "tasks":[
        {
            "label": "cliCompile",
          
            "type": "shell",
            "command": "arduino-cli compile --build-path ${workspaceFolder}\\build --build-cache-path ${workspaceFolder}\\temp --clean --libraries D:\\Arduino\\VSCode\\libraries --fqbn rp2040:rp2040:rpipico ${workspaceFolder}",
            "problemMatcher": []
        }, 

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Fri Aug 20, 2021 1:34 pm

@llooman that is great news (using 1 pico i2c channel for both master and slave).

i've been concentrating on getting a more stable code base for my 2 channel solution. Now my code randomizes slave addresses and transmit time slot on powerup and that seems to be working fine. Presently, the code periodically sends a GCA as a master while other channel is monitoring for messages on it's slave adr and for GCA transactions. Now that you've determined that nothing awful happens when switching
to master mode and back to slave mode, i'll put in a periodic switch to master on the listener side.

Right now i have 4 picos on same bus doing this behavior. i've got a bunch of picos so in time i'll have upwards to 10 on same bus. I'm not sure how to calculate bus capacitance increase with each additional node so will just try to determine what number of picos breaks the bus. There is also a rpi3 connected to the bus that supplies my GCA-1pps timing signal for all nodes to sync with.

Here's a pix of how i'm making the bus connections. just using DB9-like-pin strips (from supplier MPJA) to make all the parallel connections that can be individually easily broken during operation to induce fails and such. i have seen at least one instance that _somebody_ got confused and SDA and SCK were stuck low. If i can trap that i'll be able to determine who's pulled what low forever.

Image

http://dabeak.com/piNet-i2c_busBar_PXL_ ... 803490.jpg

Thanks for the toggle-mode idea and testimonial @llooman!

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Mon Aug 23, 2021 3:46 pm

@llooman, just a quick note for something to watch for. I have had one instance of a pico i2c channel configured as responder/slave that stops responding to bus transactions from a controller/master. It appears that the other channel (which is paralleled to inop channel) and the processor core are fine. (as evidenced by GCA messages still being sent by the master configured channel). The pico that had the problem was not connected in a SWD debug way so for now i'm just guessing at what may have happened and doing a lot of code inspection. For now, my working theory is that the slave address of that i2c channel was corrupted. The test code i've written has a watchdog timer activated but i don't have any way of detecting arranged to know that the watchdog may have fired (which i'll fix soon). Worst case, the watchdog fired AND the i2c slave is still dead, which would imply a hard power cycle is required to fix the problem (which would be a fatal flaw). (power cycle now does fix the slave)

If anyone sees similiar i2c problems i would certainly like to know about it.

llooman
Posts: 5
Joined: Sun Aug 01, 2021 11:56 am

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Tue Aug 24, 2021 10:16 am

@monkeyfork, Overhere still in testing phase. Also encounter some hang situations.
As the i2c network overhere has long lines and multiple nodetypes it's not easy to find the exact course.
Current network has: 1 pico and serveral arduino nano's, arduino mini-pro's and a arduino mega2560.
The pico is at 3.3v the rest on 5v so there is a level shifter in between. At the end of the long lines there are terminators reducing the electronic echo/slosh.
Because it is my domotic network in the house it needs to become 100% robuust.

Now testing with 2 extra checks:
- after a read or write operation i added 2 milisec pauze (avg 2.5 ) before starting the next write.
- when 7 writes in a row recieve an error then do a re-init the i2c stack:

Code: Select all

i2c_deinit(i2c_default); 
all init done at start. 
Maybe this is not perfect but when it works it is ok for me.

Keep you informed

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Wed Aug 25, 2021 10:40 pm

@llooman, i've just coded your scheme of toggling from responder/slave mode to controller/master to send out a General Call Address broadcast and first indications are that it's working fine. That's very good news. At first it didn't work and the re-init was hanging causing my watchdog timer to reset the processor but i traced it a need for disabling interrupts before doing the mode change. My usual setup for responder/slave behavior is all interrupt driven. I had to do that complication in order to be able to receive GCA messages as well as message intended for responder/slave address. (my goal of publish/subscribe using i2c relies on being able to send and recieve the GCA messages which i have not seen used extensively... gonna try to give GCA the respect it deserves). Max nodes on my bus so far is 6. One rpi3 and 5 picos. I'll be ramping up to about 10 picos over the next weeks. Some of the picos will be using the both-i2c-ganged and some with one-i2c-toggled to see if i see any need to keep any with the dual channel method.

So far, the only use case i can see for my original dual-channel-ganged method is for a local loopback to self-test the responder/slave.

Along the way i decided to use the 2nd core for some extra debug uses. Very nice to have such a easy way to go sandbox a bit of code.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Sat Aug 28, 2021 5:46 pm

a note about testing my "piNet-i2c" which now consists of 1-rpi3 and 6picos. To increase load on network, I was using a combination of my C program (that accesses i2c via some ioctl calls) to send GCA broadcast messages and some bash that calls the i2c utilities i2cset and i2cget to increment registers inside the pico (that is accessed like a ram disk). I was amazed that the C program and the bash seemed to be working in parallel with no problem (since both were somehow sharing the i2c). Over time i observed that the pico would eventually have some sort of unknown problem that would cause a hang and reset (due to my watchdog timer). eventually this was tracked to the C program and the bash program not _really_ sharing the i2c bus. Now, I've brought the bash functionality into the C program so there is no contention for use of the bus and all is well, running for 12hours no problem.

Any i2c transaction initiated by a pico acting as i2c master is strictly controlled so as to not collide with transmissions from the rpi (as i believe the rpi's i2c can NOT sort out i2c collisions). This is accomplished by the rpi transmitting a time hack at the beginning of every second, all other transmissions/transactions are sync'd with this time hack. (something like time-triggered ethernet). i'm still scheming on how best to manage the timeline, so far just making 10ms time slots, evens go to rpi and odds go to the picos. opinions welcome.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Thu Sep 02, 2021 2:08 pm

...so there was much confusion (about real-time nature of many nodes talking) and then some clarity. my bandwidth/collision-avoidance coordination scheme (in spirit of "time-triggered-ethernet") of dividing each second into 10ms slots and allocating even slots to raspberry pi 'coordinator' and odds slots to pico 'workers' is now working fine with no apparent i2c net breakage.

next up is testing a scheme to have two rpis + many-picos on one net. my plan is to closely couple a rpi-zero and one pico for a motor-controller that also has camera (specifically for the task of last-meter navigation to dock a rolling robot to a charging fixture). Also on same robot is a rpi3 that is on a rotating turret for primary navigation and other stuff. That rpi3 will comm with rest of network via i2c thru a slip-ring assembly. I've used this scheme before with canbus which is much more robust than i2c. If this scheme can be cajoled into working with i2c rather than canbus i may have made a tiny contribution, we shall see.

A GDB-MULTICORE QUESTION so far i have not seen how openOCD/GDB is made to do debug on core1, any hints would be appreciated.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Sun Sep 05, 2021 3:14 pm

the 100khz i2c that i'm using for my "piNet-i2c" (peer2peer + publish/subscribe) has passes significant milestone (in my mind). The signals are passing thru a slipring unpreturbed and so far not experiencing any error messages (on an existing rolling robot of my kludgy design). So far not much stress on network. next phase of testing will significantly load the bus with traffic and more nodes. so far so good. The slipring was sourced thru Adafruit quite a while ago and was used to pass canbus signals for a fair amount of run time. The rolling robot that
has the slipring has a turret that continuously rotates and has been exposed to outside Florida humidity for about a year. I think it has about 12 wires (will verify later). I send each of the i2c wires (SDA, SCK) thru TWO of the rings (hoping that imperfections in the rings can be overcome thru redundancy). Ground is made continuous thru the slipring also. This unit will get extensive run time and i'll leave test results here.

edit: the slipring i'm using has 12wires. probably adafruit product id 1195 or 1196. As mentioned, i'm using 2 wire each for signals SDA and SCK. Same for 12v sent to upper turret that is downconverted to 5vdc to power a rpi-w/picam, a pico, a PIXY, 1 MBED and a sonar ranger.

monkeyfork
Posts: 113
Joined: Tue Oct 29, 2013 10:14 am
Location: orlando

Re: RPi + many-Pico I2C controller/responder AND peer-to-peer

Sat Sep 11, 2021 3:45 pm

piNet-i2c update. i now have on my rolling robot (code named yardBot, aka zombotUndead) a rotating turret assembly that contains (at least) a rpi2 and a pico. The main chassis has (at least) a rpi4 and a pico. The pico in the chassis has my code to pwm two motors for differential steering. Between the chassis and the rotating turret is a adafruit slipring assembly. Thru the sliprings transit SDA and SCK.

The code to run the motors was already existing and had a console monitor to control motor pwm-drive and deadman shutdown and such. i managed to keep that code intact and graft on the "piNet-i2c" stack by putting it on core1.

All players now have i2c comm with picos acting as i2c-responder(slave-workers) and alternately as i2c-controller(master-overseer) and one of the rpi acting as overall controller (that is optionally powered up).

here is tiny vid of yardBot spinning it's turret;
https://www.youtube.com/watch?v=eNE0qWZ8C8c

the rpi on the turret has a rpi-cam. i hope to use that as basis for determining location. As it figures location, coordinates will be passed over the piNet-i2c to rpi4 on chassis that will be responsible for guidance/nav based on my driveway, location of charger etc. An additional rpi-zero(with piCam) will be added on chassis for visual docking with charger.

so far the time triggered approach to controlling traffic on i2c bus is working nicely.


Return to “Interfacing (DSI, CSI, I2C, etc.)”