New firmware release for Pytrack and Pysense version 0.0.8
We have released a new firmware for Pytrack and Pysense that finally allows to check the wake up reason.
You can get the firmware from here: https://docs.pycom.io/chapter/pytrackpysense/installation/firmware.html
This new firmware includes several stability improvements and bug fixes in the USB stack. The coolest thing with this update is that now the CDC device is able to achieve speeds on the serial port of up to 921600 bps (yeah almost ~1Mbps) without flow control. This also enables the usage of Pytrack/Pysense with the firmware update tool at high speeds. Shortly we will also release a new version of the firmware update tool that uses the PIC microcontroller inside Pysense and Pytrack to put the Pycom module into programming mode automatically. Using a cable jumper and pressing the reset button to deploy a new
firmware is going to be a thing of the past very soon :-)
catalin last edited by
@jcaron Hi, just released new firmware for Pytrack and Pysense v0.0.8, where both your requests were implemented: https://forum.pycom.io/topic/2286/new-firmware-release-for-pytrack-and-pysense-version-0-0-8
Hi @catalin Thanks!
Yes, I only needed INT to wake up the LoPy (and read its value).
Don't remember the details, but isn't GIE set and required for some other features? IIRC without the INTF clearing, as soon as INTE was set the PIC locked up, so GIE probably was set as well.
I'll try to find some time to test the new features in the coming days.
catalin last edited by catalin
Hi @jcaron, sorry for late answer; the firmware changes are done (and python pytrack/pysense libs also), just a little review before release.
Some notes, the INTF flag doesn't need to be necessarily cleared in ISR, to use INT pin as wakeup. Do you want to use INT pin just as wakeup, right?
Only if GIE (global interrupt enable flag) is set, then the MCU goes into ISR, otherwise MCU just wakes up and continues executing the instructions after sleep.
There are actually two different needs, but both are in the Pysense/Pytrack firmware (+ eventually some changes in the matching libraries):
- Handle wake-on-pin
- Keep track of time.
For the first issue, the most important change is to clear
INTFin the ISR. Otherwise when you enable
INTE, when the pin changes, the PIC will just keep running the ISR forever. This can be done with a simple:
BCF 0B, 01
INTCON, bit 1 is
But since that wakes up the module, it would indeed make sense to add the information about that wake-up source to the current 3 possibles values. So:
- when going to sleep:
- clear "woken up by INT" flag
- in ISR:
- if set:
- set flag to remember that the PIC was woken up by INT
- add that flag to the wake-up sources bitmap
For the second issue, yes, being able to read either the time left or the time elapsed when waking up would be useful, either to go back to sleep with the time left, or to get a vague sense of the current time.
catalin last edited by
Hi @jcaron, let me recap what I've understood, so I can see if I can help.
- You managed to connect to the PIC on INT pin a wakeup source.
- If Pytrack/Pysense is in deep sleep, you want to read this wakeup source (INT pin) (additionally to the other 3: Accelerometer pin, reset button and end of deep-sleep)
- even more, when PIC woke up, you want to read how much is left from the deep-sleep period
@daniel while you have your hands in there, would it be possible to add the following:
in the ISR, check
INTF, make a note of its state somewhere (possibly used to add a bit in the wake-up cause bitmap), and then clear it? This is required for wake-on-pin during deep sleep (at least the clear
INTFpart). Details here https://forum.pycom.io/topic/1673/pysense-pinout-wake-on-pin/16
if at all possible, some way to get the elapsed or remaining time on the deep sleep timer? This could allow restoring an at least approximate time after deep sleep.
As the code for the firmware is not on GitHub there’s no issue tracker to submit those, let me know if there’s a better place.
@crumble thanks. I have just fixed the note about the version number. I recommend that you update, it should probably fix your re-connection problems if those were caused by the board and not the Atom plug-in.
@daniel, the version number mention on the linked paged is still 0.0.4.
I don't like to screw up my pytrack case that often ;) Will this fix some reconnect problems under Win7 with Atom as well? Or can we wait until your convenient firmware updater is ready ;)