-
(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? -
There is a gitter stream being used for more general chit chat ....
https://gitter.im/aplikatika/Espruino-on-ESP8266That's where the news on a constant feed goes right now.
-
-
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.
-
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.
-
I'm working on support for an as un-yet supported board and am making progress. During my unit testing, I am finding that something odd is happening with numbers. For example, I ran the following function:
var x=1; setInterval(function() {x=x+1;}, 1000);
Expecting to find that the function would be called every second. Instead, I seem to find it being called very, very fast. When I run dump(), I find the following:
setInterval(function () {x=x+1;}, 8.855);
which as you can see, the last parameter has been changed. Digging further, I found the function called:
JsVar *_jswrap_interface_setTimeoutOrInterval(JsVar *func, JsVarFloat interval, JsVar *args, bool isTimeout)
and added a logging statement to print the value of "interval" when it is called. What is logged is:
8.85454559326
I'm not sure where to go next. Apparently something is wrong in my setup. My processor is the xtensa lx106 (ESP8266) which I believe is a 32bit device. I sense I may be mixing 64bit processing and 32bit processing ... but haven't seen where yet.
Neil
-
Howdy folks,
I'm studying jsdevices.c which, if I understand correctly, is a device independent handler of certain I/O operations for boards. As I look into it, I find jshTransmit() which appears to want to transmit a character through the UART (or other transmission vehicle). If I read it correctly, there is a section of code where we check that the buffer for output characters has nearly filled (the headNext == tail) and then we execute a loop. The loop is:while(txHeadNext==txTail) { }
I understand the logic ... but this seems to tell me that txTail will change outside of the primary flow of this loop and, since my target device is a single core processor, can only happen as the result of an interrupt being handled. What if UART doesn't generate interrupts on character consumption or otherwise needs processing logic? We might get into a deadlock here.
Also, on my target device (the ESP8266), the WiFi subsystem needs to be "fed" regularly. We have a "yield()" type function and I'm wondering if this needs to be exposed as a jshardware.c exposed logical capability with an invocation within this tight loop?
Still studying ... but I am hoping that there might be others in the community that have walked the insides of Espruino for board addition.
Neil
-
-
-
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
-
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.
-
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.
-
@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
-
@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. -
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?
-
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 ...
-
-
Great news. I got it 100% cleanly built AND linked on Windows. Since the original project was built on a Mac and I don't have one of those, I had tried to take the code and build it on Windows. I have an ESP8266 tool chain and used my own Makefile templates to build ... the code compiled cleanly by the linker failed with the error reported previously.
I decided to start again ... this time I still used my ESP8266 tool chain but this time used the Makefile that was provided with the project and this time not only did the code compile cleanly but the linker completed resulting in a firmware image that I can now upload.
And then it was bed time ... so I haven't tested the pay-off yet :-)
A question for the community ... do we want to continue to use this one forum thread for this project discussion ... that is fine by me, but the thread may get VERY big. Just checking if there is a better desire?
Neil
-
I made my first pass at seeing what aplikatika has built. Looking at his git project, I see he is building on a Mac where I have windows. Ok ... not an issue. I built an Eclipse environment with the C Development Tools and the ESP (Xtensa) tool chain. The good news is that every last source file compiled cleanly!! YEAH!! ... However, when it came to linking the parts together, we failed with a "xtensa-lx106-elf/bin/ld.exe: build/myApp.out section '.irom0.text' will not fit in region `irom0_0_seg'" error. The ESP8266 has about 40k RAM and 512K of Flash. Two thoughts immediately strike me:
- How big is the compiled Espruino program? Will it fit in 512K of Flash?
- In ESP8266 programming, when one compiles a C source file, for each function one can specify which "section" it will be loaded from. Loading it from RAM causes the code to be loaded into RAM and run there ... while loading it from Flash causes the CPU to read the code slower from Flash. However, since Flash is much larger than RAM, we normally flag the code as running from Flash and take the performance hit. We normally flag this on a function by function basis. Since the Espruino code doesn't have these ESP8266 per-function attributes, I think everything is being flagged as to be loaded from RAM and that of course won't fit.
Since aplikatika has solved this with his Mac makefile but that isn't working in my Windows makefile ... I am thinking there is something in that area.
- How big is the compiled Espruino program? Will it fit in 512K of Flash?
-
Thanks Gordon, I'm sure we'll need your support for this. The good news is that I feel very comfortable in the WiFi areas on the ESP. I'll start studying the internals docs and reading the code. Ive emailed the author of the ESP project but haven't heard back yet.
Let us assume that his sandbox project "got it working" ... what I hope we can do it identify the differences in his fork from your master and try and merge the two together. I'm hoping that we can have one source of truth on the Esprunio code base and that would be your master. Depending on the nature of the changes that might have been made, would you (in principle) be willing to accept pull requests against your code to bring together common changes?
Neil
-
I've emailed the owner of the Github project to see if he can join in the story again. Looking at the owners other contributions, he too seems to be very knowledgable on the ESP8266 technology. Since we may be staffed with ESP8266 resources, I think the missing ingredient is probably going to be someone who claims competency on the Espruino internal architecture.
Do we have any architecture and design docs on the Espruino? Anything that talks about its core architecture and what pre-reqs it may have with respect to its operating environments?
Neil
-
I'm not yet sure what the specs are on Espruino. The ESP8266 has 80MHz or 160MHz processor and 64k of RAM of which 40K is typically free while running as a network device. The flash starts at 512KBytes and can go up to 16Mbytes max. I think the first things that would have to happen is for the folks who care to get involved "get together" (on the Internet). At a minimum, we would need someone who speaks ESP8266 well (I can volunteer for that) and someone who fully understand the code base of Espruino. Without at least those two participants, we have nothing to start with.
Am starting to examine and debug now ... I ran a trace ... and the following is interesting as it appears to clearly show the puzzle. Now going to start looking at jsnative.c: