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

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

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