Espruino on ESP8266

To be honest I'm not sure I'd be able to check it often enough for it to be useful... I've been resisting IRC for the same kind of reasons I'm afraid.

Not a problem ... if everyone is ok with it ... then we can just use this thread and let it get as big as we like. If no-one objects, I'll just keep posting small and short status reports here. My thinking is that as it moves along, I want the ESP8266 support to be as open and transparent as possible so the more conversation on it, the better. In one of your last posts, you asked about the serial input ... you are 100% right ... at this point I deliberately disabled serial input. Part of the architecture of the ESP8266 is that it has TWO UARTs. One is used to flash the device and the other is (by default) TX only used for debugging. Because of the nature of what an ESP8266 actually is ... my plan is to add a "telnet" interface to it so that once it is running, you telnet into it by its IP address can then enter JavaScript commands through that mechanism.

However ... my next challenge is to deeper understand just what we have here and understand the API used to "submit" fragments of JavaScript for execution ...

So which UART is the one you'd generally use if you had the AT firmware on the ESP8266?

I'd strongly suggest you enable the command prompt on that one at least initially, as it'll make it a million times easier to test and debug the wifi networking capability, as well as to use Espruino with the Web IDE.

When that's done you can just run this to get your telnet shell:

    require("net").createServer(function (connection) {
       connection.pipe(LoopbackA);
       LoopbackA.pipe(connection);
       LoopbackB.setConsole();
    }).listen(23);

Obviously that could be built-in, but it's a good start.

Hi guys!

First, thank you Kolban for waking me up and pointing me to this thread and Gordon with all respect for everything you have done for Espruino. I really love this project!

The project Espruino-on-ESP8266 was planed to prove that Espruino can be ported for Xtensia compiler and can run on ESP devices. It turned out successful last March as it was able to run basic JS program with some timer callbacks. At that time I was planning to merge the code to Espruino and complete my task.

For some good reason, there was my friend Sameh (whom I also thank for support from the beginning) very enthusiastic and said this was not yet done and I need to implement some more functionalities of the device. I couldn't agree more but also couldn't complete everything by myself, so I wished some help...

I had put on hold this project because of summer time which I didn't want to spend my leisure in the office, but because winter is coming I will be then at home and code, I'll be back in october.

I still would like to merge the code very soon, ASAP, because the more code will be implemented under this free-style project of mine the harder it will merge into strict rules of Espruino.

I will be thrilled if anyone would help us with the merge!

Blaž

I don't know why I am user57360, but I should be aplikatika@gmail.com.

Gordon, require("net").createServer() will not work because most of functionality was commented out just to be able to compile... Currently it fully supports just javascript and few functions unknown to you, related to ESP wifi, but anyway, what is explained in readme, works perfectly :)

I'm looking through Blaz's code here .... (worth a quick scan) ...

https://github.com/aplikatika/Espruino-on-ESP8266/blob/master/user/user_main.c

which seems to be the interface into the API of Espruino. However, I can't yet seem to find any docs on the functions used ... for example "jsInit" or "jsKill" or "jsEvaluateVar". I am thinking that these are the internal APIs of the Espruino project and are not meant for JavaScript authors ... but instead for folks like me who want to get the Espruino runtime running on the ESP8266. My next step is to go through the Github source ... but I'm wondering if there is already a "document" that describes the Espruino architecture and key methods and orders that they should be driven?

Just as a comment, as much as I am a big fan of the interactive console on Espruino, basically making me using screen instead of the Web IDE very often, I could imagine living without it for this application/implementation if that's needed to make the whole idea work on the ESP.

I could imagine the chip getting more memory in the future anyway, as other projects might have similar demands.

Great project, that I wondered if it might be possible, when playing with the ESP and hating at the serial comms between pico and Espruino. After all, those three letters also being the first three of Espruino can't just be a coincidence...

BTW, would there be anything gained from using something like MOD-WIFI-ESP8266-DEV ?

For those that like such things ... there is now a gitter stream for the project ... see

https://gitter.im/aplikatika/Espruino-on-ESP8266?utm_source=share-link&utm_medium=link&utm_campaign=share-link

Feel free to drop by and chat, say hi, watch questions, answers and progress.

@Stev
Fortunately, we have no issues with knowledge and skills on the ESP8266. There are many boards and modules out there and all of them are "about" equal ... there are also communities and even free books on the ESP8266 which cover the majority of the area. So it doesn't really matter "which" ESP8266 one gets ... whether it is the ESP-1 dirt cheap or the more expensive nodeMCU at the high end ... all of them should work fine.

@Kolban
I am not sure if I understand your "knowledge and skills" comment. It's probably true that there are an increasing amount of people knowing the ESP8266, as it's even got support by the Arduino IDE and more IO-oriented boards with it coming out every day (with relays or other components already onboard). Still, having Espruino running on it is a totally different quality.

I just saw Olimex' new board with SPI flash added and wondered, especially after a comment you made about the memory partitioning of the board, if more flash might be helpful or not. After all it does not seem to make that much of a difference in price.

@Stev
Sorry ... I wasn't at all clear. Let me try again... when you said "BTW, would there be anything gained from using something like MOD-WIFI-ESP8266-DEV ?" .... I probably mis-understood what you meant by "anything gained". I had assumed that it was in the context of furthering the project of getting Espruino running well on the ESP8266 ... and my answer related to that concept was "no" ... it doesn't matter which boards we use for development or testing ...

However, any ESP8266 module with more "stuff" is going to be better than one with less "stuff" from an absolute perspective. I.e. 4M of flash is quantitatively better than a device with 512K of flash. Is that what we are discussing?

Neil

Based on my poor knowledge, I cannot help directly.
If you want somebody for testing, please let me know.
Right now, I'm working with nodemcu(lua) on ESP8266 with ESP01/07/devkit
Actual project is a data logger on Espruino, using ESP8266 with nodemcu as web server.
Switching to Javascript(Espruino) would make life much nicer.
BTW, is flashing done with this https://github.com/nodemcu/nodemcu-flasher ?

@user57360/aplikatika thanks for posting up! That's great - it'd be really good to get a nice 'polished' ESP8266 version of Espruino.

@Kolban yes, those are internal functions used to set everything up - check what's in targets/*/main.c to see how it generally works. There's usually a bit of documentation in the header file about each function too. @user57360 has already sorted out all that stuff for you though. It'd be worth scouring the forum a bit - I've spent hours writing detailed responses to people's questions about the source on here.

I seem to be having trouble mapping the app into the address space for the ESP8266. No great panics yet ... but working methodically, here is a spreadsheet of the file object files and their sections so I can see what needs to go where. I have generated data for ALL the sections but some won't be mapped such as the debugging. See attached.

1 Attachment

• SectionData.ods

I have it running!! I can now telnet into the ESP8266 and run Espurino!!! It builds cleanly on Windows under Eclipse. This includes full WiFi support ... now when I boot up the ESP8266, it becomes a WiFi station, connects to my local WiFi access point from which I can telnet into the device and run JavaScript!!!!

Now that I have this "sandbox" running, I can start learning the Espurino properly and start bootstrapping the full function ... including the Serial support.

Ive been studying the Espruino source trying to understand its general architecture ... one of the things I seem to find is that it is a "busy poller". What I mean by this, is that it seems we have to regularly call "jsiLoop" when otherwise doing nothing else. This seems to call "jsiIdle" which appears to be where timer processing is being performed. One of the core things I was hoping to find was that there would be nothing going on while no events need processed. The ESP8266 is an extremely passive MCU meaning that one sets up event handlers and then gives control back to it as a supervisor. When something interesting happens such as a Serial character arriving, a timer firing, network traffic arriving, GPIO changing state ... that is when control is given back to us and we handle it from there. This is in contrast to what might be termed "busy polling" where we continually ask the environment "anything I need to do in this area?". By being passive and registering callbacks, the ESP8266 minimizes its power consumption ... effectively consuming as little as it can get away with and leveraging as much of the hardware as possible to detect events needing processed.

This "seems" to be in contrast to the Espruino architecture which appears to be more like the Arduino setup()/loop() structure of busy processing.

.... to be considered further.

Neil

Excellent progress. Can't wait to try it out.

Wish I could help, but I have just enough knowledge of both to be dangerous.

@Kolban, I woid not exactly compare the loops Espruino has with the typical 'application visible' and infinite - inevitable - loop of Arduino.

For me Espruino feels like two workers that cooperate with one another. Simplified:

The first one is very fast completely hardware event - pin, timer, communicaiton subsystem - driven and creates the software events and puts them into a work queue for the javascript coworker. The javascript coworker works around this queue until it is empty and then goes to sleep. It has to be this way, because the first, very fast worker has to make sure no events gets lost. The second one is slower and continuously works through the event list and executes the event related application code. If no application code has defined interrupts on pins and timers and communication sub systems, then I expect only internal timer events happen to keep up the (Espruino getTime()) time. Even when on-data communication events are defined and happen, the related data entity - nibble, byte, string/line/buffer - 'filling' has to complete before a javascript event is put into the queue for handling by the application queue.

Every on-"something" and setTimeout() and setInterval() of the application code registers and configures an event handling in the first, fast worker and defines what this worker has to put when into the queue for the javascript worker.

When the very first hardware or timing event happens and has been processed, the processer changes hats and puts on the javascript worker hat and looks into the javascript event queue to handle the event that it just has placed there. If a new hardware or timing event happens while handling the javascript event, the processor quickly and briefely changes hats and handles the event and then returns to resume the javascript processing. On finishing the javascript event handling of a particular javascript event, the processor checks for more javascript events and processes them until the javascript event queue is empty, and then goes to sleep... until it gets waken up by the next hardware event.

Just throwing this out there..... is this possible on the nrf24l01+??

Not sure what you're asking. I don't think the NRF24 is programmable at all...

Espruino does have a main loop - as would any RTOS. The confusion is probably that the ESP8266 has its own RTOS which you then expect to call Espruino.

When Espruino isn't doing anything for a set time period it calls jshSleep, which should go to sleep for the amount of time requested, but should return early if an event happens. You should be able to hook onto that, or if you need something that returns you could modify jsiIdle to instead return the amount of time it wants to sleep for.

Wasn't sure just curious, little over my head at this point

The ESP8266 port now has a new Github project found here ... https://github.com/esp8266-espruino/esp8266-espurino. It is being carefully changed to ensure that it will merge as cleanly as possible with the master Espruino project when the time comes. We will be having firmware builds for tests relatively shortly.