-
Yes, I have memory shortages in sight and actually, the main problem seems to be in the events handlers Serial4.on and gps.on. cross referencing each other....
That said, it is fairly simple to execute the functions at launch time, wipe out any thing no more usefull, and save() a completely pre-processed gps object.
The thing is that I want to run the GPS at 10Hz during some circumstances, say a car in motion, and back to 1Hz or 1/3 Hz in others conditions, say a car parked during the last few minutes, and finally physically shut-it off by controlling some power regulator from the STM32, changing that dynamically and resetting the gps parameters on the fly at reboot.Which is still more a hope than a fact.
About figures, this is the 12th iteration of code.
So now, there are some basic considerations:- The predefined setup of the NEO-6M sends 10 nmea sentences per second. There is no way to shorten any of those, you just can mute whichever you want. This is chipset dependant.
- not using try { } catch(e) { } and using explicit tests everywhere takes 45 ms per nmea sentence without any control of the checksum. This resulted in a loop too slow to process all sentences. Then I discovered that the NEO-6M would drop transmission right in the middle of a sentence without any warning.
- using try { } catch { } and going in appropriate treatments of exceptions and adding the checksum control of all nmea sentences, reduced to timing to 25 ms per nmea sentence. 50% of this time was spent in the checksum computation alone.
- compiling basic conversion functions and furthermore the computation of checksum, it went done to 12 ms per nmea sentences.
- shutting off unused sentences directly from the NEO-6M reduced the number of sentences from 10 to 3 usefull and increased to time of treatment to 18 ms. However, the previous figure implied to 7 sentences were consumming some time for nothing too. Net result is very positive (3*18<<10*12)
Finally, I used, and adapted, my Chrono prototypes to get the processor charge in % of the time: that is rather than looking at individual timing of a nmea sentence, look at the global timing of the treatment of all of them.
Basically, now the processor charge is around 5.5% to process all 3 usefull sentences, while this was about 12% to process all sentences with some redundant fields.
I still have to simplify the nmea sentences handlers so as to not take in account more than once the fields I need (hhmmss.ss for instances is read and converted 3 times now while it is always the same figure as long as you have it from the first sentence in a given sequence of sentences). - The predefined setup of the NEO-6M sends 10 nmea sentences per second. There is no way to shorten any of those, you just can mute whichever you want. This is chipset dependant.
You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
asez73
@allObjects
I was thinking about preprocessing even before the launch - I assume you refere with launch to connect and what it does: I separate step, the source generation is run, and it's output is used as part of the .js file. The muting of unwanted sentences - or config which sentences - the gps modules has to send, can still happen when connecting. Doning so does not need the pre-config the device seperately. On the other hand, if memory get's tight, this will be a nice option. I have experienced memory shortages quit quickly, and resorted to similar aproaches: have the config info not in well structured objects, but as single string(s) with comma (or space) separation of the individual values. Processing with a *.split(",") uses only temporary memory. My example was the description of a pac-man board/maze, drawing it on a 320x240 ILI#### controled display , and boundary checking for the 'moving parts', etc... In the end I had even to come up with an encodeing to keep the code/data still readable but using up only one byte.
Finding out 'quickly' what to spend processing time on and what to drop is a nice approach. Do you have figures/stats how much - %-wise - is dropped?
Even with the good data, I had to optimize more: a) only changed data I did render and send to the display, and b) building up of the display is parts by parts to stay 'within the loop' of 1 update/second. Using your approach of 'quieting' the module would have been a great help. Enjoyed very much 'listening' to your code and its style - like a good piece of music!