asynycio as_GPS

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
User avatar
pythoncoder
Posts: 4025
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: asynycio as_GPS

Post by pythoncoder » Tue Jan 07, 2020 6:49 pm

I have no experience of Pycom hardware but it seems evident that you are short of RAM. Most of my testing was done on Pyboard 1.x, but I have run on the ESP32 reference board. I would normally suggest using frozen bytecode, but I don't know if this is a practical proposition with Pycom firmware. Do Pycom builds have uasyncio implemented as frozen bytecode?

As for filesystems littlefs is better in that it has wear levelling. It also saves 4KiB of RAM, so it may help you in that respect too. The only drawback of littlefs is that you have to jump through hoops if you want to mount it on your PC using MSC mode. But MSC mode is best avoided anyway, IMO.
Peter Hinch

User avatar
pythoncoder
Posts: 4025
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: asynycio as_GPS

Post by pythoncoder » Tue Jan 07, 2020 6:53 pm

MostlyHarmless wrote:
Tue Jan 07, 2020 6:42 pm
...Just in case it is about shifting...
Alas no. If I dropped it at a walking pace I'd probably break bones. Even pushbikes are out of the question :(
Peter Hinch

User avatar
MostlyHarmless
Posts: 147
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: asynycio as_GPS

Post by MostlyHarmless » Tue Jan 07, 2020 6:53 pm

To get back on topic:

Keep in mind that if you create something to mount on a motorcycle/scooter, it needs to be extremely shock proof.

I was able to destroy a Garmin GPSMAP 60CSx by having it strapped too tight to the handlebars. Granted, the pothole I went through also made the little orange reflectors on my front fork fall off.

Anyhow, the vibrations, that you have on a motorcycle, are several times that of what you can expect on a car's dashboard. So plan on having some sort of cushioning built into your design.


Regards, Jan

Online
User avatar
Roberthh
Posts: 1888
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: asynycio as_GPS

Post by Roberthh » Tue Jan 07, 2020 7:30 pm

Question about Flash:
Filesystem: FatFs or LittleFS
Which version do you think is the best?
I am really looking forward to further help.
Lopy1 has not a lot of RAM for the heap. It is like ~60k Lopy1 vs. 2 MByte Fipy. So the memory error on LoPy1 may result from that. The memory error seems to be flagged during import. Then pre.compiling with mpy-cross can help. I have a copy of mpy-cross here: https://github.com/robert-hh/Shared-Stuff. You might need mpy-cross_pycom_v4.exe.

About the file systems, i can only contribute some personal experience:
LittleFS claims to be more robust and efficient on small devices. I did not use it sufficiently long to confirm.
On Pycom devices I had however more or less immediately two events of corrupted files systems using LittleFS. I cannot say that I never had that with FAT, but long ago.
With the MicroPython.org firmware, LittleFS and FAT run equally stable, only that LittleFS seems to run much slower. The onyl cases of File System corruption i had was with PyBoards until I disabled MSC mode (File system access from the PC). After that everything was smooth.

User avatar
pythoncoder
Posts: 4025
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: litlefs

Post by pythoncoder » Wed Jan 08, 2020 8:04 am

In testing a driver for flash chips I have run a torture test on littlefs, which it has run many times without failure.

The test writes 128 binary files of random length between 1 and 65535 bytes to the device and checks their contents. It then (over many iterations) rewrites a randomly selected subset of the files with new contents and lengths, each time checking all 128 files for contents.

I plan to use littlefs wherever possible.
Peter Hinch

User avatar
romeotango
Posts: 27
Joined: Tue Jun 16, 2015 10:52 am
Location: Germany

Re: asynycio as_GPS

Post by romeotango » Wed Jan 08, 2020 5:10 pm

Thanks for the help.
I tried out several versions today.
Little Filesystem,

Code: Select all

import uasyncio as asyncio
import as_GPS
from machine import UART

uart= UART(1, baudrate=9600, pins=('P20','P21'))
sreader = asyncio.StreamReader(uart)  # Create a StreamReader
gps = as_GPS.AS_GPS(sreader)  # Instantiate GPS

async def test():
    print('waiting for GPS data')
    await gps.data_received(position=True, altitude=True)
    for _ in range(10):
        print(gps.latitude(), gps.longitude(), gps.altitude)
        await asyncio.sleep(1)

loop = asyncio.get_event_loop()
loop.run_until_complete(test())
Eine Fehlermeldung trat auf. Der erneute Start von gpstest2.py war ohne Reboot möglich und erfolgreich.

Code: Select all

(sysname='LoPy', nodename='LoPy', release='1.20.1.r2', version='v1.11-06dfad0 on 2019-11-30', machine='LoPy with ESP32', lorawan='1.0.2', pybytes='1.3.0')
>>> Running gpstest2.py

>>> 
>>> 
waiting for GPS data
Traceback (most recent call last):
  File "<stdin>", line 19, in <module>
  File "/flash/lib/uasyncio/core.py", line 180, in run_until_complete
  File "/flash/lib/uasyncio/core.py", line 154, in run_forever
  File "/flash/lib/uasyncio/core.py", line 109, in run_forever
  File "/flash/lib/as_GPS.py", line 209, in _update
  File "/flash/lib/as_GPS.py", line 89, in _crc_check
IndexError: string index out of range
>
Pycom MicroPython 1.20.1.r2 [v1.11-06dfad0] on 2019-11-30; LoPy with ESP32
Pybytes Version: 1.3.0
Type "help()" for more information.
>>> 
>>> Running gpstest2.py
>>> 
waiting for GPS data
[52.12471, 'N'] [8.638295, 'E'] 104.1
[52.1247, 'N'] [8.638288, 'E'] 103.8
[52.12471, 'N'] [8.638304, 'E'] 103.7
It was not clear to me that the LoPy1 provides so little RAM for the heap.
But that was very irritating.
And it turned out that the PyPi version of uasyncio is the only one that works.
Your fast-io version, Peter, cannot be loaded.
The 3.11 version of uasyncio cannot be loaded.
The brand new version of Damien P. George cannot be loaded.

Now I have no choice but to work through the readme files of Peter.
39 pages! Respect! And thank you very much for your work.

And if all ropes break on the LoPy, I still have the FiPy, or I'll buy a whole new WiPy. I love these little computers.

See you soon in this forum.
PS Jetzt könnt Ihr sogar genau sehen, wo ich wohne... :roll:

User avatar
MostlyHarmless
Posts: 147
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: asynycio as_GPS

Post by MostlyHarmless » Wed Jan 08, 2020 7:16 pm

romeotango wrote:
Wed Jan 08, 2020 5:10 pm
PS Jetzt könnt Ihr sogar genau sehen, wo ich wohne... :roll:
Wo in D-Land? Bis 2001 war ich 'n Hamburger Fishkopp.

So much for that, now about your resource problems. The best way to gain RAM is to freeze the code. I still have to adopt the v1.12 method of providing a proper build manifest. Still throwing the stuff I need into the port's modules directory.

Either way, what happens when you freeze code is that it is converted into Python byte code during the build and added to the firmware. That way MicroPython can run it directly from the Flash, without the need to compile it (very RAM hungry) or keep it in RAM after the compile.

I think if you want to use those small boards, building your own firmware is going to be mandatory. The best way to get started with that is to have a Linux system (a virtual machine will do fine).


Regards, Jan

User avatar
pythoncoder
Posts: 4025
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: asynycio as_GPS

Post by pythoncoder » Thu Jan 09, 2020 9:58 am

romeotango wrote:
Wed Jan 08, 2020 5:10 pm
...
And it turned out that the PyPi version of uasyncio is the only one that works.
Your fast-io version, Peter, cannot be loaded.
The 3.11 version of uasyncio cannot be loaded.
The brand new version of Damien P. George cannot be loaded...
In all these cases was the problem a memory error? If so, as @MostlyHarmless says, you'll have to use frozen bytecode. Currently the official version of uasyncio is version 2.0, installed as per my tutorial. If that does not work (when frozen) then you may need to take this up with Pycom. Unless you specifically need the features of fast_io my recommendation is to use the official version, if only because it's smaller.

It's interesting that the version on PyPi worked as this requires firmware from Paul Sokolovsky's Pycopy fork. This suggests that Pycom base their firmware on his fork.

I should point out that I test my code against official MicroPython only. It's not practicable for me to support forks such as Pycom and Pycopy. In general my code is tested on Pyboards, ESP32 and ESP8266 - in the latter case as frozen bytecode.
Peter Hinch

User avatar
romeotango
Posts: 27
Joined: Tue Jun 16, 2015 10:52 am
Location: Germany

Re: asynycio as_GPS

Post by romeotango » Thu Jan 09, 2020 12:25 pm

It is still difficult for me to distinguish the different versions.
Especially the Pycopy project I have not really understood yet.
But your assumption seems to be correct. This is the header of the uasyncio directory on GitHub:
micropython-lib/uasyncio/
Paul Sokolovsky
@dpgeorge
Paul Sokolovsky and dpgeorge uasyncio: Release 2.0.
With Roberthh's mpy-cross I once converted all different versions.
@ Roberthh: Thank You for that, my version for mac produced import errors sometimes. Surprisingly, only the first import was not successful, the same one immediately afterwards worked. Strange.
(Although I always get confused on the command line with ctr-c on Windows and cmd-c on mac).
With this I could even import the brand new version of DPG’s uasyncio. Really close to the limit though. And far away from stability.

User avatar
romeotango
Posts: 27
Joined: Tue Jun 16, 2015 10:52 am
Location: Germany

Re: asynycio as_GPS

Post by romeotango » Thu Jan 09, 2020 12:28 pm

@MostlyHarmless: Hast Du einen Vorschlag für eine Linux Distribution, die am schnellsten und einfachsten für mich wäre?
Ich wohne in Herford, das ist etwas nördlich von Bielefeld, das es ja bekanntlich nicht gibt! :D

Post Reply