-
Real time, normally, means with a known delay between this instant of the event and the start of the routine in charge of handling the event.
In the particular case of the Espruino interpreter, things are handled by pushing a time stamp and the handler gets it with the pertinent data somehow later.
So, in such a very different context, I would call "realtime" anything that would end up by consumming events fast enough so as not to overflow the event fifo....
I guess this is how Espruino was designed.
Of course, in my particular gps goals, I need to end up all of the computations within a second since the gps gives its data every second, or 1/10 of a second if properly setup.
At this point, your own requirments are the rule.
Do forget that writing to aflash memory takes literally ages per comparison since they are blocking apis.
Even worst, the so called non blocking apis are never so:
Either you use a multi core / processor, which is not Espruino's case and you could delegate blocking tasks to one of them.
Or you have to buffer and delay blocking actions to the risk of not handling whatever happens at that instant.... So i would say that buffering is, per itself, a problem! That's why, I would that consider only buffering summaries, that can wait in a buffer for a very long time (seconds to hours). While i'd prefer to handle the full data stream in "realtime".
There is no universal answer to this!
It will, forever, be a matter of priorities: should I kill my batteries by over discharging them, or let my drone fall on someone's else head? A boat or a car could just safely stop in place and not destroy anything or anyone.
You are reading a single comment by @asez73 and its replies.
Click here to read the full conversation.
asez73
@asez73, where do you draw the line 'real time'? Batching to simplify in the internal processing does not mean it is not real time for the user. Batching was also meant for just collecting all the received bytes until they make a reasonable gps sentence. This process should not be visible to the application. When look at @Gordon's implementation of the GPS moudle, it has a continuous buffering of received data. When something is ready to put into the buffer it is just appended, and when a sentence is found, it removes that part from the buffer and calls the callback. In other words, the filling of the buffer happens in chunks not necessarily aligned with the calling of the callback. If the buffering happens in pieces smaller than a complete sentence callback is not called on recption/buffering event. If more than one sentence is received, then the code loops around invocation of the callback until no complete sentence is found anymore in the buffer.