You are reading a single comment by @k6bsd and its replies. Click here to read the full conversation.
  • With SPIFFS - perhaps we could look at some kind of abstraction given we now have Linux, FATFS, FATFS over Flash, and maybe SPIFFS - it'd make things a lot tidier. Had you considered using the FlashEEPROM module?

    I took a quick glance at FlashEEPROM, and it has many of the same problems as FAT... no wear levelling, no use of the ability to change any '1' bit to a '0' bit etc. Granted, the W25Q128BV has a lot of erase cycles for an SPI flash part, but since the idea is for other people to write whatever they like, I don't really like having them beat on the same sector until it dies.

    As for an abstraction layer, I suspect that the limitations of special use things like SPIFFS would either make the abstraction too limited, or make everything in it "optional" or "emulated" thereby making it almost useless. I think that using a common API when possible is likely more useful than an abstraction layer.

    With the IDE - you could try running the 'IDE server' - espruinowebide on NPM. That'll run a Node.js app and then serve up the IDE over HTTP. Might be a good way to sidestep any chrome issues?

    I'll give the espruinowebide a shot, though Node.js support on FreeBSD tends to be worse than Chromium support... for example, node-serialport has this beauty:

    var linux = process.platform !== 'win32' && process.platform !== 'darwin';
    
About

Avatar for k6bsd @k6bsd started