• That function would iterate over the buffer again and write it to SPI.

    That's the issue here. I notice your code effectively does this:

     for (var i=0; i<arrayBuffer.length; i++) this.spi.write(arrayBuffer[i]);

    but the send/write functions can take arrays, so you can do this:


    All the iteration is then done in native code, so it's very fast. If you're generating the data byte by byte it's less of an issue, but let's say you got it from Waveform, or it came in via serial/USB - you actually have no need to access the individual bytes from JS, you can just pass the string or arraybuffer around which is much faster.

    I intended an API that let users:

    • Read a chunk of data from anywhere - ideally there'd be a way of just streaming data out as well. From that POV flash.read(bytes, address) makes more sense as Address could then be undefined when streaming data out.
    • Find the sizes and addresses of blocks of memory that can only be erased in one go - sectors in this case - maybe the choice of name getPagewas confusing.
    • Write a chunk of data absolutely anywhere - the function would handle pages, so the user would not have to care about when to call finish. That could probably have bytes/address arguments swapped as well, to allow streaming more easily.

    As I understand it, nothing actually stops you writing the same page twice without erasing - just as long as you don't write 0s over bytes that were already 0?

    A nicer approach would be smarter code which - when data within a page needs to be overwritten - copies the page to a free page

    Yes, I've been planning on a simple 'fake EEPROM' module that does something like that. Ideally it would sit on top of the Flash module, using an API that was the same for all different flash devices - hence having functions like erase16Pages aren't a huge help, as the STM32's flash definitely doesn't have the 16 page limitation.


Avatar for Gordon @Gordon started