all leds cycling

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
smhodge
Posts: 86
Joined: Tue Jan 22, 2019 2:16 am
Location: Kirkland, WA, USA

Re: all leds cycling

Post by smhodge » Wed Mar 04, 2020 4:27 pm

Thanks for your continuing suggestions. I'm working on them. An initial test seems to indicate that the machine implementation of I2C may help. Standby, I'll update when I have something more definitive to say.

smhodge
Posts: 86
Joined: Tue Jan 22, 2019 2:16 am
Location: Kirkland, WA, USA

Re: all leds cycling

Post by smhodge » Mon Mar 09, 2020 4:25 pm

Time to finish off this thread with what I found. The machine implementation of I2C definitely fixed the I2C issue. I'm not sure I mentioned exactly what that was. At startup it initally could do a scan() and get all the devices but later on during startup, w/o doing anything with I2C, it "lost" that and scan() reported no devices. After re-initializing it found them ok and was good to go from then on. Switching to the machine implementation eliminated that (weird) issue.

The REPL/leds-cycling issue is still there, occurring roughly half the time, but now it typically only takes one reset to get it going ok again, instead of upwards of 10 attempts. So maybe the machine implementation of I2C helped but did not eliminate this issue???. That said, I have found a guaranteed way to avoid it and that is to send Ctrl-C over the USB connection to shut down my code on the pyboard before I attempt to load new/modified code onto the pyboard with rsync.

I tried the machine implementation of SPI but could never, even with just a simple REPL session, get read & write to work with the same devices I have no trouble using with the pyb implementation. The methods also seem to be more cumbersome to use, so, since I'm having no problems with the pyb implementation of SPI, I'm sticking with that.

Post Reply