GPY/FiPY & Expansion Bd 3 - Multi I2C and SD Card Instances
-
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
-
@robert-hh OK, I set up some code to try this out, several timers at different periods and several threads including one to start LTE, send an SMS and then deinit. From what I can see, the timers do NOT get interupted by the LTE device. It seems the timer counts are retained and dumped to REPL as soon as possible (buffered apparently). There is some corruption/mixup of REPL lines but all the timer flags are there
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.
-
@robert-hh I'll do that and come back to you. I'll fry timers from main.py and also from a thread.
-
@stevo52 said in GPY/FiPY & Expansion Bd 3 - Multi I2C and SD Card Instances:
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!
-
@stevo52 Can you check whether timer interrupts still work while calling LTE init/deinit?
-
@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 Yep, the DMM and a couple of extended probes works for this situation.
-
@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.
-
@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?
-
@stevo52 Yes. Just pull the jumper and use a wire strap from the USB side of the jumper to P13.
-
@robert-hh Won't pulling the jumper stop comms with Atom/Repl over USB? Maybe I can connect P13 to the appropriate jumper pin..
-
@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.
-
@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.. :-(
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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 :-)
-
@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.
