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

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

[robert-hh]

@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]

@robert-hh I'll do that and come back to you. I'll fry timers from main.py and also from a thread.

[Stevo52]

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