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

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.

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.

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.

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 :-)

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

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.

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.

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. :-(

These seem to be ass about - incorrect labeling on the board maybe?

Same on Expansion board 2. The labeling is wrong. Good to know. Please note, @Paul-Thornton!

I will investigate a bit further and see if I can use this to my advantage. One thread/timer I will need will be at 11uS preferably, so as it is too fast to capture by eye, I'll have to write to a file to a file to evaluate any impact by the LTE device. Biggest constraint might be the actual time to write to disk. A FIFO data buffer is probably a good solution - some work to do there.

The test code was pretty rough and ready so its needs a lot of refinement to be truly useful as a valid test.