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

[Stevo52]

I am hoping some of the more learned/experienced people in the forum can help me with a couple of issues regarding use of GPY/FiPY on the Expansion Board 3.

After a few years away, I am currently getting some hands on experience in coding - this time with Micropython, for a couple of projects I have been tasked with. I have some questions that I need some clarification on - a bit long winded but I have tried to explain the purpose and reasons for them

The more complex project currently uses a GPY on the Exp Bd 3 and requires:
1. Using Two x SD Cards.

• Using the Exp. Bd, SD for internal storage of sensor data and connection via WLAN, LTE, FTP and Web Server functionality to record constant sensor data, send it to remote servers and allow it to be viewed and/or accessed from remote log ins eith on WLAN or WAN.
• The other SD card I would like to use as an externally accessible mechanism to allow manual operations on site to (i) retrieve data , (ii) apply code updates and revisions (licenses etc for various sensor functions) and (iii) allow changes to configuration settings.
• At the moment I an using the on-board SDIO for the internal SD Card and after quite a bit of trial and error I now have a workable SPI interface for the 'external' SD card. There are limited pin mapping options and I am using:
• SDIO seems to use PINS P4 (SD CMD), P8 (SD DAT0) and P23 (SD CLK)
• SPI is currently on PINS P9 (SPI CS), P10 SPI CLK), P11 (MOSI) and P14 (MISO)

Other PIN assignments are:

• P19, P20 - CLK Crystal (accurate clocking and timing required )
• P21 for I2C SDA and P22 for I2C SCLK

The above seems to work OK, but is a work in progress as I refine the associated capabilities of the two SD cards, file handling and also the current I2C sensors - but also see the following item 2.

2. Using Two x I2C Interfaces
Through the prototype development I have found that I need one sensor to operated continuously, recording and analysing data at a fairly high rate and oversampling to provide increased accuracy. I don't believe the type of sensor and what it is recording to be relevant to the issue I am asking about. At present the lower rate/lower accuracy sensors work fine and record ambient environmental conditions quite happily to the internal SD card. However, when I add the high sample rate/high accuracy sensor to the I2C bus I seem to get a range of errors which I believe is due to 'interference' or timing issues between the devices on the I2C bus - OS Errors and data errors. If I run either the high speed/accuracy device or the low speed items separately there are no such errors so I think the two sections of code are fine on their own. But run together, even in separate threads, the issues occur.

So my questions about I2C are these:
a. is it feasible to have two I2C instances running at the same time? If so, this would permit me to treat the two I2C interfaces separately in code I think, and reduce or remove the errors.

b. If two I2C instances is achievable, the shortage of mappable pins in the GPY/Exp Bd combo makes this a bit difficult to implement.

• My current thinking is to leave the existing I2C instance ('i2c_B') on Pins P21 (SDA) and P22 (SCLK) and have the second instance ('i2c_A') on Pin P3 for the second SDA and share the Pin 22 (SCLK) across both instances?
  I will try this but I am wondering if anyone can comment on whether this might work or am I wasting my time. I don't see too many issues using the same clock speed for the two instances, I have tried both separately and it seems fine at 1000000 for them both. Of course the sensor devices and the micro-controller/expansion board combo use the same power rails, so that shouldn't be an issue.

I am hoping there are people in this forum who might be able to help - the issues are more a result of GPY/FiPy/Exp Bd mapping limitations than code, but maybe I am headed in the wrong direction? Any comments or suggestions would be most welcome. Getting SDIO and SPI working was quite an effort, and dual I2C instances might be unworkable but I haven't been able to find much in the way of documentation to help me so far either way. Maybe I am asking too much?

My other option of course is to use two micro-controllers but that brings the complications of interfacing of the two together, so as to use common communications and data cards, plus increased power requirements etc. etc. (as you all would appreciate).

Thanks for reading this and thanks in advance for any responses offered. My apologies also for any typos in the above.. :-)

Steve W

[PaulM]

Step 1. Buy an actual non-Python MCU board (e.g. Adafruit ItsyBitsy M0) and program a test written in C/Arduino to see if you get the I2C interference problems with two sensors thereon. If you don't, it's another Pycom software problem.

Step 2. Consider using an external MCU written in C/Arduino as your main MCU, and powering on the Pycom as needed through a MOSFET for the communications piece. That is how I am using Pycom products. I love the Pycom hardware. But I absolutely detest Python and the crappy software environment on these boards. It feels like running a teachings-kids-how-to-program programming language being run on totally competent hardware that should be programmed in C/Arduino. I note that it is very possible to program Pycom boards on Arduino. As it stands, I cannot trust it for 24/7 operations. Pycom really made a bad decision tying themselves to such a stupid, inefficient, high-level programming language for kids, not professionals. I know Python people will read this and say "well you just don't know how to write proper code with try/except error handling, yada yada". I'm sorry, but for any industrial application that needs 24/7 reliability, you can't risk the fickle variability of this giant interpreted language. You need to be able to do raw pointer/memory math - totally impossible with this Micropython stuff - and if you screw something up, your code continues instead of dies in the field with an unhandled exception. I know, watchdog timer, try/except, 'faster development than C', I've heard it all. I hate Python. But the Pycom GPy has been relatively excellent used as a 4G modem externally switched on/off, and has way more potential if used as a raw ESP32 board in Arduino. I would recommend you try out my design of low power Cortex M0 master controller taking sensor data dynamically switching on/off Pycom GPy for LTE/etc communications. You'll also save a ton of power as the Pycom boards are insanely, prohibitively power consumptive even with WiFi off, since they do not offer a way for you to change the clock speed. Maybe some expert will come in here and prove me wrong with code that puts my GPy to 2MHz in Python.

Hope this helps.

[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.