k6bsd

Most recent activity

• Espruino on a handheld radio

  @k6bsd started

  • 10 comments
  • 3,339 views

  @Gordon replied
• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  Hrm, yes... Could not find a compatible version of nw.js to download for your platform.

• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  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';
  

• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  Yeah, it's a great fit for what we're doing... easy to hack around with the pins and prototype stuff, and fairly straight-forward to move to a "production" script once everything is good.

  I hadn't noticed jspEvaluate(), but I think I'm happy with what we came up with despite the 64KB restriction on each module and the clear abuse of the PRECOMPILED_OBJS make variable. (Just noticed I have the jsvUnLock() calls commented out - whoops!)

  Having it compile into the flash image is great, and having it not pollute the global namespace is very handy. We'll likely be adding some of the minified modules in a similar way if you don't beat us to it. When you have a lot of spare flash space, having a selection of the modules baked in and require()able without using much RAM or needing the IDE will be quite nice.

  I had to do horrible things to the IDE to get it to work on FreeBSD since chrome.serial.getDevices() doesn't work (basically, I hard-coded a list of serial ports into EspruinoTools/core/serial_chrome.js) it would be nice if there was a way to connect to a serial port by name without having to go through a picker, but it seems to be working though a test using require("Font8x16").add(LCD) seems to hang Espruino... haven't looked to see why yet.

  Great fun, and once we get the radio working, I'll post an update.

• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  The STM32F405VGT6 itself has 1MB of flash, the SPI flash part is a W25Q128BV with 128Mb (16MB) of storage. Of that 16MB, the first 1MB we're going to try to keep untouched since the stock firmware makes use of it, and some of the info in there is likely going to be useful to us.

  FAT would be both overkill and underkill for the application... overkill because we just need a way for 3rd-party add-ons to coordinate storage, not directories and attributes, and underkill because it's not flash friendly in that it doesn't do sector/block erase, wear leveling, etc. SPI flash parts don't have the nice abstraction layer that SD cards do, so SPIFFS is more appropriate.

  We plan to try and make it as compatible with the fs API as possible though.

• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  Looks like I can use E.memoryArea with Modules.addCached() whee!

• Espruino on a handheld radio

  in Projects • 7 years, 6 months

  

  We've done initial bringup of Espruino on a UHF radio. The excellent reverse engineering work done by the folks at md380tools laid the groundwork, so it was relatively easy to write a keypad and LCD library and whip up a board file. The single-thread model of Espruino really makes dealing with shared pins trivial.

  We still have a long way to go... there's a 16MB SPI flash we intend to write an SPIFFS library for, and there's the interface to the radio itself (along with all the required reverse engineering). Much of can be done in JS though thanks to the excellent Espruino package.

  Figuring out if it's possible to allow modules to run from the SM32F4's built-in (memory mapped) flash rather than needing to be require()ed into RAM is likely the last Espruino internal thing we need to deal with. Having a standard JS library that doesn't eat into the RAM budget would be great. There seems to be support for built-in modules, but that may only be referring to the jswrap_* stuff.