GPY/FiPY & Expansion Bd 3 - Multi I2C and SD Card Instances

[Stevo52]

@paulm Thanks for the comments. I hear what you are saying and strangely enough I am doing some parallel development using an M0 board, much as you are. I still have the same I2C issues though but with more pins available it is easier to work around. :-)

All in all the GPY suits my needs for this project, with careful attention to timing/times,memory etc. but I may be pushing the limits soon :-)

I haven't experienced any reliability issues to date and my test mule has been running for nearly 4 weeks now without issues. The error handling module is quite 'involved' but seems to manage all the issues so far - including logging them. It isn't running the full code of course (while I sort out threading & I2C), using 18 out of 22 sensors, but doing everything at a greatly increased frequency and lots of writing of data to disk, so it is as loaded as I can get it.

Thanks again for your advice with SPI earlier, I now have that working really well and am developing code to do file copies, transfers, updates etc. Also adding in some SMS functionality after successfully playing with that a bit yesterday.

[robert-hh]

@stevo52 Therwe was a discussion eralier of connecting two I2C buses. https://forum.pycom.io/topic/4001/some-magnetometer-sensors-are-incompatible-with-the-pytrack-shield/11
The Pycom Firmware only allows to have one I2C initiated at a time. That is a strange limitation. So the post above switches between the physical buses by sequences of init-use-deinit.
You could also consider to multiplex the buses by hardware, e.g. with an analog switch like the CD4052 ic.
Edit: You can use multiple I2C buses, up to three, which operate independent.

[Elizar]

@stevo52 Did you pay some attention to the correct value of the i2c pullup resistors? When it comes to higher speeds there is a need for higher pullup currents (= lower resistor values).
Having a dozen i2c devices on a single bus should not be a problem.

[Stevo52]

@elizar Hi, yes I did a lot of trial and error experimentation using external pull-ups and have a workable solution which lets me use fast mode (1000000) . Having two I2C buses seems to be the way to go for this project - using P21/P22 (3.9K PU's)and P3/P22 (3.3K PU's). Using a common clock doesn't appear to be a problem either - but only limited testing don with that configuration so far.

[robert-hh]

@stevo52 said in GPY/FiPY & Expansion Bd 3 - Multi I2C and SD Card Instances:

Is it feasible to have two I2C instances running at the same time?

Yes. I just tried that. Both instances need separate pins, of which you do not have too many. And any attempt to use two buses at the same time using the same pin for SCL fails. The only thing that works when using two I2C instances who share the SCL line and have separate SDA lines, is to alternatively init and deinit them. But then a single I2C bus too would be sufficient.

Unfortunately there is no API access to the GPIO matrix for an attempt to redefine Pins P13-P18, if that would be possible at all.

[Stevo52]

@robert-hh Thanks for that info Robert. I'm still experimenting and testing but I seem to have two I2C buses (GPY as master for both), using a common clock, working to a fashion. I'll evaluate the stored data today to be sure. I am using an i2C mux on a different project with good success, so I might look at that as a way to get around the limited mappable pins available on the FiPy/Gpy. I'll also try using P8 gor the second i2c SAD/SCL, but that pin is assigned to SDIO - as sdDATA0 so I have avoided that pin so far. I think that I am trying to do too much with the limited physical pin capabilities of the GPY. :-( but otherwise it is doing a great job for this particular project.

The problem with the attached sensors is that one in particular is heavily over-sampled for accuracy and read at a very high frequency, continuously, so getting data basically floods the bus it is on. Might need a dedicated sub processor for it.

I have found there is quite a lot of helpful information on Pycom products available but it isn't always easy to find when you need it :-)

[robert-hh]

@stevo52 I just tried to reassign UART0, RX to e.g. P15, using:

>>> from machine import UART
>>> uart=UART(0, 115200, pins=('P1', 'P15'))

Then P0 can be used as another GPIO pin. I tried that with I2C and it works fine. In my test I used P9,P10 for I2C, bus 0, and P22, P0 for I2C, Bus 1. Attached I2C devices work as expected.

Edit: If the SD card is the only device on that bus. you can also try to pull CS to GND permanently, releasing P9, which is used for CS.

[Stevo52]

@robert-hh A couple of good suggestions there, that I will trial. One of them should solve my pin mapping issues. I hadn't tried using P0, never even occurred to me.. :-) That P0 to P15 (or 16/17/18?) reassignment, would need to go in boot.py I guess?

While my 2 I2C buses worked, using the common SCL, I don't think that is the best solution long term - but the tests proved that the two bus method removed the (timing?) errors I had been seeing in the sensor read process.

[robert-hh]

@stevo52 said in GPY/FiPY & Expansion Bd 3 - Multi I2C and SD Card Instances:

That P0 to P15 (or 16/17/18?) reassignment, would need to go in boot.py I guess?

Yes, or early in main.py. You still have telnet in case of trouble.
About sharing SCL: I tried that, but it only worked when deinit'ing the not used bus. Otherwise I had bus errors.

[Stevo52]

@robert-hh Thanks Robert, your suggestion to move UART 0 to P1/P13 ( I used P13 because I already have 2 ADC inputs (P15/P16) configured to work as option switches) was a really good one - still puzzled why I didn't think of it myself. perhaps I just figured the board was setup to use P1/P0 as per the documentation I have. Two i2c buses now working in separate threads with no risk of SCL conflicts.

[robert-hh]

@stevo52 If you use one of the expansion or sensor boards from Pycom, this move is difficult, because the connection to the USB/UART bridge is hardwired.

[Stevo52]

@robert-hh Oh, I wondered about that.. As per the topic heading, I am using an Expansion board 3. So I'll scratch trying that option.. :-(

[robert-hh]

@stevo52 On an expansion board 3 (and 2) the RX and TX connections run through a jumper. So instead of scratching you can pull the jumper.

[Stevo52]

@robert-hh Won't pulling the jumper stop comms with Atom/Repl over USB? Maybe I can connect P13 to the appropriate jumper pin..

[robert-hh]

@stevo52 Yes. Just pull the jumper and use a wire strap from the USB side of the jumper to P13.

[Stevo52]

@robert-hh Is there a schematic of the Expansion Board 3 available anywhere, so I don't have to pull the GPY/Expansion board out of the enclosure to trace connections all the time?

[robert-hh]

@stevo52 PyCom did not publish the schematics yet. And it is not clear whether they will do it. But at least the jumpers are documented. You can use an Ohm-meter to tell, which side is connected to the GPY/FiPy.

[Stevo52]

.@robert-hh Yep, the DMM and a couple of extended probes works for this situation.

[Stevo52]

@robert-hh Hi Robert, today I tried this mod, pulled the jumper and then patched to UART pin (the pin to outside of the Expansion Board 3) to P13. This arrangement seems to work fine for UART REPL and uploads while working on the code so that's great.

One thing I noted from testing out the pin arrangements between the jumper block and the GPY is that GPY Pin 2 (P0 ) actually connects to the jumper marked TX on the Exp Bd 3 - I was expecting it to be RX? Also the RX pin on the board goes to GPY Pin 3 (P1). These seem to be ass about - incorrect labeling on the board maybe? I will check it again though.

Edit: I pinned these out with a DMM, with GPY removed and got the same result. I'm confused though, because disconnecting P13 doesn't stop the REPL even though the jumper is out - a schematic would be so handy because I'm missing something! Whoops, of course that is how it should be.. LOL :-)

Now I have that done, I can do some testing on the two i2c buses. I think my big problem with these and using separate threads is the LTE init/deinit commands that are part of the data upload routine, which stop the threads for a period of time, causing breaks in the sampling. The non critical sensors aren't a problem, but the over-sampled high speed sensor is badly affected by the thread halting. I need to see what I can do about that. The Expansion Board and GPY are all at the latest revisions so I am not sure what I can do. Might have to just work around that pause or perhaps use a separate micro, with buffering, for that sensor - something I was trying to avoid up until now. :-(

[robert-hh]

@stevo52 Can you check whether timer interrupts still work while calling LTE init/deinit?