Espruino on ESP8266

Cool stuff :)

ooh I am so glad that you guys finally started supporting this project =) I will be following your updates and will be happy to test with you guys.

I am sure Blaz is proud now :P

Blaz is awesome ... don't let my appearance on the scene distract. Blaz is as key to this project as ever. The project is fully open source, so if anyone has time and effort to contribute, all are welcome. We have a loose plan to try and submit it to Gordon for formal Espruino inclusion in November. However, the source code is on Git and anyone can download and build and we hope to have test drivers available later ... hopefully no later than October.

Ooooh!!! And now we have full serial port functions ... here is an example using the Espruino Chrome app. Again, the runtime is running ON and ESP8266!!

(See attached).

1 Attachment

Wow, looking good!

WOW,
thanks and gratulation to Blaz, Kolban and last not least to Gordon.
Sometimes I still cannot believe how Javascript can run on these chips.
Not only that, all of these magic words like I2C, SPI, ADC.... are supported.
Guys having more knowledge than I will ever have spend their time.
And at the end people like me will benefit from that, unbelievable.
Can't wait to get first binary, to replace my solution based on nodemcu.

Is it a dream or reality? Boys, you are really big stars!!! :-)
Is it all located in the only e.g. ESP-01 with 512KB? Some limitations?
What are your next steps in developmnet? ... digital inputs/outputs, what all functions?
BRAVO, incredible... waiting impatiently for next news... and binary to flash :-)

There is a gitter stream being used for more general chit chat ....
https://gitter.im/aplikatika/Espruino-on-ESP8266

That's where the news on a constant feed goes right now.

(I am not that skilled on using Git and Github and am looking for community assistance ... beneath are notes on my current thinking as well as the questions I have ... )

Let us review the Github environment used to build this project. There are a number of players in this story. The first, and arguably most important is espruino/Espruino. This is the home project of Espruino itself. The ultimate goal of the ESP8266 project is to create changes and new code and have that published in espruino/Espruino. At that time, there would be no further need for any other projects.

However, during this development period, we need a second project that will be used to host the ESP8266 work that is in flight. Currently, this is a stand-alone Github project called esp8266-espruino/esp8266-espurino. By stand alone, we mean that this is a file by file copy of the espruino/Espruino project with changes made for the ESP8266.
Unfortunately, this does not feel right either.
What we need to understand is the following.

Let us assume that we can fork the espruino/Espruino project under the "esp8266-espruino" organization.

(See the attachment)

We will now end up with a project called "esp8266-espruino/Espruino" that is modifiable but will not contaminate "espruino/Espruino". When ready, a pull request can be submitted to "espruino/Espruino" where the owner can then merge in the changes made to "esp8266-espruino/Espruino".

Question:
Is this an all or nothing story? If many changes are made to the "esp8266-espruino/Espruino" project and only a "few" files are to be incrementally submitted into "espruino/Espruino" ... can this be done?

Question:
Can changes made to "espruino/Espruino" after the fork be pushed (pulled?) into the "esp8266-espruino/Espruino" project?

1 Attachment

we can fork the espruino/Espruino project under the "esp8266-espruino"

Yes, this is the best way to do it - then you keep all the original commit history. I think this is how Blaz did it...

Is this an all or nothing story?

Not at all - you can 'cherry-pick' the specific commits that you want when merging back. However realistically what will happen is you'll do all the development work and create a separate branch that you 'tidy up' ready for a pull request. You can git diff mybranch original-espruino to see exactly what's changed so you can make sure it's all good.

Then, when you do the pull request it'll come in, and while all the history will be there, if you've made files and deleted them between times they won't end up showing up in the proper espruino project unless someone specifically goes back to those commits.

Only thing I'd avoid doing is changing big swathes of existing code (like tweaking indents or something) as that can cause issues when merging.

Can changes made to "espruino/Espruino" after the fork be pushed (pulled?) into the "esp8266-espruino/Espruino" project?

Absolutely - this is why Git is so popular :)

Git's amazingly powerful, but a bit hard to get your head around at first.

You should probably read through some kind of git introduction... Maybe someone can recommend one - a quick google found this one that might help.

Howdy Gordon, I think Ive followed the instructions and forked the "espruino/Espruino" repository into "esp8266-espruino/Espruino". No issues with that.

I then extracted "esp8266-espruino/Espruino" to my workstation and have an editable local copy on my file system. Still all good.

I edited one local file "jsnative.c" to reflect the changes needed for adding the XTENSA architecture. I am using this is a "take it slow" test. No problems with the local change.

I then comitted my local clone back to "esp8266-espruino/Espruino". Again ... all looks great.

Here is where I start to get fuzzy. I have now issued a "pull request" on "esp8266-espruino/Espruino" which I believe indicates to you ("espruino/Espruino") that a merge request has been made and that the action is now on you to examine my submissions and then approve or reject them. If approved, I believe that the changes I made (i.e. the one file ...) will be updated in the master repository ("espruino/Espruino") and we will have effected a "merge" of our projects (to this one file level).

Does this sound/feel right? Is this how we should be working? (Again, apologies for the questions up front ... I just want to make sure that this subproject plays correctly by the rules and we can integrate as painlessly as possible and that you are happy with the workflow).

Neil

Yes, that's all worked great. Got the pull request and I'll merge it in.

Especially for small changes that can go in and don't affect the building of everything else, that's the best way to handle them. You want any pull request you send to be self-contained (in that it isn't part of a 'work in progress' though).

So for bigger changes you might want to do a bit of work, with maybe several commits, and then only issue a pull request when it's done.

As I understand it, with Git if you issue a pull request from a branch (eg. master) then any changes you push to GitHub after you've made the PR will update the PR. That may not be what you want, if you're working on stuff continually, so for bigger changes you may well want to create a branch locally, work on that, and then submit a pull request for just that branch.

Just wanted to check though, I notice in your diff you change:

[#if](https://forum.espruino.com/search/?q=%23if) __WORDSIZE == 64

to

[#if](https://forum.espruino.com/search/?q=%23if) defined(__WORDSIZE) &&__WORDSIZE == 64

I don't think that actually does anything apart from complicate the code though - or did it actually cause you compile problems? If __WORDSIZE isn't defined, then it's not equal to 64 so the statement still works as expected?

Howdy Gordon ....
I got a compiler error with

if  WORDSIZE==64

if WORDSIZE was not defined and had to guard it with an existence test. My compiler reports that it is based on GCC version 5.1.0 and gnu99 as the language standard.

That's odd. I just tested and I get no problem here on 4.6 or 4.8 with:

if __WORDSIZE==64

sigh. I can't put a hash in because of the forum.

The hash matters though - if you don't have that then it won't get kicked out by the preprocessor.

I had hashes and underscores .... but the forum ate them ... :-) However ... here is exactly the error I get without guarding:

xtensa-lx106-elf-gcc -Wall -Wextra -Wconversion -Werror=implicit-function-declaration -std=gnu99 -fno-builtin -Wno-maybe-uninitialized -Wno-old-style-declaration -Wno-conversion -Wno-unused-variable -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-discarded-qualifiers -Wno-float-conversion -Wno-parentheses -fno-strict-aliasing -Wno-type-limits -Wno-unused-function -Wno-unused-value -Wno-implicit-function-declaration -Wpointer-arith -Wundef -Werror -Wl,EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ETS__ -DICACHE_FLASH -Os -c -DUSE_MATH -DEMBEDDED -DXTENSA -IC:/Git/esp8266-espurino/espruino -IC:/Git/esp8266-espurino/espruino/targets -IC:/Git/esp8266-espurino/espruino/src -IC:/Git/esp8266-espurino/espruino/gen -IC:/Git/esp8266-espurino/espruino/libs/math -IC:/Users/IBM_ADMIN/Documents/RaspberryPi/ESP8266/libs/esp_iot_sdk_v1.3.0_15_08_08/esp_iot_sdk_v1.3.0/include -IC:/Git/esp8266-espurino/espruino/targets/esp8266 -IC:/Git/esp8266-espurino/espruino/libs/network/ESP8266WiFi -DUSE_MATH -DEMBEDDED -DXTENSA src/jsnative.c -o src/jsnative.o
src/jsnative.c: In function 'jsnCallFunction':
src/jsnative.c:93:5: error: "__WORDSIZE" is not defined [-Werror=undef]
 [#if](https://forum.espruino.com/search/?q=%23if) __WORDSIZE == 64
     ^
cc1.exe: all warnings being treated as errors
Makefile:1348: recipe for target 'src/jsnative.o' failed
mingw32-make: *** [src/jsnative.o] Error 1

Note that the forum is "eating" the "#if"

I also just noticed ... that we can probably choose how "undef" conditions are handled ... so the question probably becomes not one of "which is correct" rather "what levels of compliance to the language" do we wish to have the compiler compile to.

See also:
http://stackoverflow.com/questions/25379300/preventing-undefined-macro

Well, I'm happy to have the #if defined(...), but to me it feels like new behaviour. Maybe it's a GCC 5 thing? I guess I ought to watch out for that, there are probably other places I'm doing the same thing.

We have the first of the potential ESP8266 functions running ... see the beginnings of the Espruino on the ESP8266 user guide that has a holding Wiki place of here:

https://github.com/esp8266-espruino/esp8266-espurino/wiki/05-User-Guide

This project on the ESP-09 would make for an awesome tiny WiFI enabled device, and if you make it an option to turn on the WiFi portion than it could be low power too. Perhaps logging data into memory then uploading in bursts, I wounder how long something like that could last on a battery?

This is the ESP-09 variant, only 1cm * 1cm
https://imgur.com/XSunTU8,b45rpjB,YBwx2vn,k0DNE9t,TOfxQIF

Someone used this with a 3.3v regulator strapped onto the back to control some WS2812b LED's (even though there's no antenna attached the author claims it still has a 4-10m range) : here

I was googling around and found this:

https://www.cesanta.com/smartjs

It appears to be an open source project called "smart.js" which claims to be an alternative JavaScript engine that appears to already be working on the ESP8266. Has anyone investigated this project and have a comparison to Espruino? This project appears to have 9 current contributors. I'd like to work on the completion of the Espruino to ESP8266 port but only if there is interest. If JavaScript on ESP8266 coalesces elsewhere, then that's where I'd turn attention.

Never heard of it. I think espruino is a better platform, since it supports so many more boards, not just the esp8266

I'm super excited about espruino on esp8266 - but that's because it will work the same as the espruino platform that I know and have written runs of code for. Some other esp-only javascript platform is of a lot less interest to me - might as well be the lua one or code in C.

Nice find, I'd like to check it out to see how well it works. Personally though, I think there is a lot of value in having Espruino on the ESP8266 rather than just javascript.

A large part of the work Gordon has done is making it suitable for running on small devices. Even if you somehow got all of node.js onto an ESP8266, you'd struggle to do what you wanted with the hardware limitations. You'd have to do what Gordon has done, create modules for everything, that are suitable for the hardware.

Also, looks like smartjs doesn't have a module system working yet, there'll probably be other key things missing too.

I've seen smartjs before. Looking at their website, they seem more interested in using it as a way to do consultancy work.

To be honest, it's not difficult to get a JavaScript interpreter and shove it on a microcontroller that's got a bunch of memory. It's been done before several times already - including with TinyJS and mbed, even before I released Espruino.

The V7 interpreter that they use for smartjs is probably technically better than Espruino, however the interpreter itself is a tiny proportion of what you need for a properly working system. You also need a decent hardware API that handles SPI/I2C/OneWire/Serial/etc the same across many devices, modules, documentation, IDE, support, etc. I'm pretty sure smartjs doesn't have much of that at all.

There are always 3 sides to the coin... the third one be the rim... and defines the completeness and balancedness - what a term - of a whole system.

@Gordon, what would you consider technically better in V7 vs Espruino? May be, you just call it just E8... to challange V8 :)... - because - last but not least - it all depends. I'm very happy with what I have with E8... Even with the best libraries - not even Arduino - can hold the candle to the setup of Espruin: general purpose, tailorable, wit strong support for hardware details on multi-platorms... but again: it all depends.

Even with the best libraries - not even Arduino - can hold the candle to the setup of Espruino

FWIW: I agree.

Thanks!

V7 has something neat called 'NaN packing' - they use a 64 bit floating point value for everything, but then it turns out there are thousands of 'invalid' floating point 'not a number' numbers, and they use those to encode other data. It's quite an efficient way of storing data.

It does however rely pretty heavily on malloc, interprets via bytecode, and uses a mark/sweep garbage collector as far as I can tell - so I'd imagine that overall performance would be faster, but not as dependable... It might just block everything to do a GC pass in the middle of execution of something time critical - something Espruino is good at avoiding.

There's also the question of how you encode all the built-in functions. I'm not sure about this, but it seems that V7 might use RAM for each function - something that fills up RAM very quickly. Espruino's got a bit of a cludgy (at the moment) way of handling built-in functions, but it does mean that no RAM gets used at all.

It'd be interesting to do a proper comparison - but my take is that on low RAM parts, Espruino comes into its own - as you add more RAM, V7 will probably become more sensible. On ESP8266 there's not much RAM available and I think Espruino may well be a better choice.

But as you say, I hope that the whole system - the board, firmware, IDE, modules, and support - makes Espruino a much better choice :)