Most recent activity
-
Assembly is not portable across cores (not future proof): C helps to be core agnostic. Few years back we learnt to optimize the way we code in C so the compiler is generating efficient machine code. I try to use only the NOP instruction for basic S/W delays. Javascript evolves and adopt what is popularly implemented new features in browsers. How about Embedded JavaScript? (no V8 engine to compete with eLua's performance)
-
That's right. Actually, when I looked at Tessel's add-on board animation which gets inserted on the MCU board, it reminded me of the impractical USB custom devices: when plugged in the first time: It's plug and pray because compiled drivers need to be found (on top of being admin)... for the host (win, iOS, Android, Linux...)
Would developers' life be easier if each "shield" comes with an EEPROM which contains the javascript drivers and web pointers (where to get spec, upgrades etc...), so the platform (whatever the MCU) can use it right away, like dynamic added resource? This would justify interpreted language implementation for portability.
By the way, surveying around, got some questions:
- What are the pros and cons of embedded Javascript vs eLua (which could be precompiled)?
- Can Espruino's interpreter get extensions that would allow specific boost of performance for MCU embedded applications? (because maybe supporting type strong C var types to complement the flex var type of Jscript?)
- What are the pros and cons of embedded Javascript vs eLua (which could be precompiled)?
-
Minifying is nice, bumped on github a javascript string compressor http://pieroxy.net/blog/pages/lz-string/demo.html which compress the minified (on a PC the 830 bytes becomes 322 bytes net).
The original code is 1788 bytes compressed to 498 bytes.
Serial links are slow, so the MCU got time to decompress with this kind of option.
More bang for the memory buck, and probably more throughput in serial links?
It also makes the original JS code probably closer to a compiled C code, which would be used for speed? -
How about alternate digikey's NHD-C0216CZ-FSW-FBW-3V3-ND
It's 2x16 char display, transflective (low power reflective or LED backlighted), SPI like sending commands, and avoids memory bloating. Unit price around 11 USD.
The maker also has a 160x160 I2C bus B &W display (limitation: can't read back pixels)
After some thoughts, it's probably the best compromise. A 5-way rock button attached to it should be enough to make simple nav menus, like digital watches or data loggers.Graphical display should be by the mobile phone using serial BT transmission.
-
Espruino's embedded Jscript seems to be a nice concept!
How complex would it be to add Espruino's JScript engine on STM32F437 (more Flash/RAM) using IAR toolchain running on Windows PC? (IAR does not use/import makefile). How easy it is to access the low level C HW drivers from Javascript? Is it also possible to use same or secondary serial bus from MCU to output some global variables/events to the WebIDE either in text value or graphical (gauge, 2D graph, table) form? (by JSON elements?)
Blockly provides input as graphical, if the debug outputs can too be graphical, it may be nice. Thanks for your advice.
Probably sending data has limitation. Could be interesting to check on how long between each transmitted byte to calc the effective speed. While operating the HW from JS give flexibility, it seems that predefined "HW operating scheme" modules (made in C) could improve performance for people going the performance/speed path. If there would be a way to use JavaScript to implement things like this: http://www.wolinlabs.com/blog/stm32f4.adc.dsp.dac.html would be an achievement!