• Hi,
    As a complementary question to those flat strings handling, I wonder if there is an efficient way to store a standard string (coming from usart for instance) to a pre-allocated flat string without using looping technics?.
    This is in order to avoid the allocation time each time my pico receives some complete data packets.

    More explicitely, the pico receives some data from usart.
    These chuncks are concatenated in Serial.on('data',...) event handler.
    So far, these are standard javascript strings.
    Once there is enought data, it is sliced and can then be used in a flat string to create an ArrayBuffer resliced itself and finally accessed internally through a Dataview.

    The thing is an Ublox M8U gps device using their binary protocol: very c structs friendly and only bytes/words/long words properly aligned. You can see this to get a clear idea. Here, the interest is that payloads are almost all of a fixed length (DMA in sight), very compact (less bytes on usart fro more data) and no fancy sexagesimally odd computations on latitudes/longitudes and so on!

    My goal is to preallocate a few different dataviews of predefined length and then copy the incoming data from its string format to the dataview after all checksums and length controls of course.
    The gps data will be accessed through getters using v.getUint32(buffer, true) and others as usual with dataviews.

    A side approach would be to use inline C for setters and getters but what in Espruino (javascript)?

    A dream would be to receive data from serial to an ArrayBuffer (kind of DMA) and only wake up when the serial buffer has enough bytes to analyse: so sleep walking while the interpreter is in deep sleep mode.

  • Mon 2018.11.05

    Hi @asez73,

    'efficient way to store a standard string . . . . to a pre-allocated flat string without using looping technics?.'

    While I hope I understand the gist of your request, after the 'light reading' of that struct ;-)

    To also avoid looping, I had to rely on @Gordon for the class hierarchy for this snippet, could this be what you are after?


    from class

    function ArrayBufferView.set(arr, offset)

    It appears from your code examples, you may be light years away from my skills, but I was able to get FlatStrings, inline.C working with plain JavaScript. Array buffers aligned with FlatStrings accessible both by inline.C and direct array access for comparison. A simple concise summary of other docs and what is at:


    'A side approach would be to use inline C for setters and getters but what in Espruino (javascript)?'

    Yes, what you envision can be done that way. My method was required for fast <50msec (goal) access with large 1000byte strings, your
    requirement might be closer to a sort of DMA

    ref: https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Global_Objects­/DataView

    If I missed the concept using struct <--> DataView and concise memory allocation, others pipe in. . . .

    Although I feel you are of the type that would tinker with code to seek your own solutions, should you desire some basic snippets for your perusal, I'll post them here.


    EDIT - while searching the forum


    It appears you may already have the ammo you need from this example #1 of yours from nine months ago; Javascript usage of data stored-accessed in a Flat String

  • HI @Robin and @Gordon,

    Thanks for your help, it did worked and I globally saved some time AND events stack depth.
    Now I don't have to separate in time, by emiting events, concatenation, slicing and storing from the Serial.on handler: it just happens fast enough without throwing any event to my Gps object.
    In some cases, I could receive enough messages and emit one event per messages, which stopped the program with strange corrupted data in the line received. The result was a buffer way too long (32Kb) and other mysterious unvalid gps data.

    Now, I am more on 2 colateral problems:
    1-one in Javascript (Serial.pipe chunk parameter in order to limit the number of calls to handler of the input data and get at least any message header at once),
    2-one in hardware (Pico powered by 3.7 V battery, deep sleeping as long as possible, using the B0 mosfet with the supplied 3.7 V)

    So I think we are far enough of flat strings and should open 2 other threads to handle those points.

    Thanks again!


Avatar for Robin @Robin started