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

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

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

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

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

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