• 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 asez73 @asez73 started