Search results for:

Gordon,
I am ready to start checking in some of the new work for the ESP8266 runtime port. This means that I will be creating some new artifacts and have made choices for the namings. What process would you like me to follow to check these in with respect to namings. For example, under libs/network we already have an entry called "esp8266" which is for the ESP8266 used as a network module for existing boards. For Espruino running ON the ESP8266, we also need a name under "network". What should we call this entry? I am leaning towards "esp8266board". Do you have any preferences or suggestions?

Neil

Thank you sir ... that looks straight forward enough.

I'm hoping to make a big push this month to make some good progress. Hopefully this will involve some well tested "Pull requests" from my clone of the "espruino/Espruino" project. However, I'm still somewhat new to GitHub and want to make sure I don't make a mistake. Here is what I have done so far.

1. I went to Github: espruino/Espruino and executed a "Fork" which created nkolban/Espruino.
   
2. I made small changes to this fork and issued a "Pull request" which was accepted.
   
   

Now ... weeks have passed and I want to make sure that the "nkolban/Espruino" is still in synch with the "espruino/Espruino". Is there a mechanism/recipe/technique I should use to make sure that my fork is up-todate with "espruino/Espruino"?

Awesome ... thanks Gordon .. I'll be testing now.

Howdy Gordon, is there any basic write-up or other docs for network access as opposed to serial access for the IDE?

Thanks Gordon, I'll shoot for a Linux compile for testing. Did you have any thoughts on the content of the original question? Is this expected behavior that when we form a connect and then issue an end() that it doesn't actually end the TCP connection at that time?

Howdy Gordon. Thanks for the response. Am still catching up on a couple of weeks missed goodies. I had a look at how the ESP8266 library that already exists works. If I am understanding it correctly, the library is sending Serial AT commands and parsing their responses. This means that the ESP8266 as an external network device is "piggy-backed" onto the Espruino boards. The blocking connect works in this case because the library is sending a Serial request and can then happily block waiting for a serial response. Unfortunately, when we run on the ESP8266 itself, we can never afford to block. When C code running on the ESP8266 executes its equivalent of a sockets "connect" call, what really happens is that the a request to perform a connect is placed on a processing queue any is not executed until control is given back to the ESP8266. A callback function is registered that is invoked with the outcome of the connect. Would it be possible for us to chit chat on this story in more detail? I am a cross roads on which path ESP8266 board implementation should take and I'd love it to be as as seamless as possible with what already exists but some of that may need compromises and changes. I want to figure out a strategy with you that meets your desires while at the same time hoping to follow the ESP8266 architecture practices where ever they don't conflict.

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.

As I dig deeper, it is getting worse. It seems that the Espruino architecture assumes that the net, socket and HTTP libraries make TCP calls that are blocking until they have completed their tasks. However, the ESP8266 architecture is such that we make network requests and the results happen asynchronously some time later ... however, between the time that we make the request and get the result, we must give control back to the ESP8266 kernel ... which means that I can't just "busy wait" for the callback to happen.

Actually, the good news is that I had that working before I had serial working. The ESP8266 is great at being a network device and telnet client support was plain easy. What I'm hoping is that as part of the telnet support we can look into adding that as a supported mechanism for the IDE so Telnet would become just another "connection option".

@DrAzzy,
Many thanks for the offer .... and I WILL take you up on it. Starting Sunday morning, I have to put my toys away for 2 solid weeks while I attend to other stuff, but from the end of September, onwards I'll be back on the project at full strength. At that time, I'll post detailed instructions to test. I may also splurge and buy an Espruino board just for testing ....

Am working on the port of Espruino to an ESP8266 and have found something I am not understanding. If I form a TCP socket connection to a partner and the invoke the "end()" method on the socket I am finding that the request to disconnect doesn't actually happen until after I try and transmit something further. For example:

var n = require("net");
var s = n.connect({
      host: "192.168.4.2",
      port: 25867
}, function(req) {
      print("Connected!: " + JSON.stringify(req));
      req.end();
});

doesn't cause the socket connection issued from the ESP8266 to be disconnected until I try the following:

var n = require("net");
var s = n.connect({
      host: "192.168.4.2",
      port: 25867
}, function(req) {
      print("Connected!: " + JSON.stringify(req));
      req.end();
      req.write("We should be already disconnected");
});

Unfortunately, I don't have a real Espruino board to test against so I can't tell if this is how it works on the real Espruino or whether I have broken something in the ESP8266 implementation.

In the architecture of the "net.connect()" function we can supply a callback function that will be invoked when a connection has been established. The parameter to the callback function is the Socket data structure that represents the connection. This is all sound.

However, studying the socketserver.c source (lines 700-712), I find that a socket creation request is sent to the board driver and then IMMEDIATELY, the connected callback is invoked. This is a problem for some board implementations (such as the ESP8266) which have their own callbacks to indicate when the connection has been established.

What this means is that today ... if I call "net.connect()", the connected callback is invoked before we have actually established a real connection through the board interface. What it seems we need is some form of integration with the board's concept of when a connection is ready.

I have been studying the networking layer of the Espruino and it seems to be dawning on me that there is support for TCP connections but not for UDP datagrams. Am I correct in that assumption?

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/esp8­266-espurino/wiki/05-User-Guide

Bits are starting to come together. We can create a new object instance using jspNewObject() and add properties to the object using jsvObjectSetChild(). I think one of the things that has been confusing me is the notion of "children" which I believe are what I consider to be "properties" in JavaScript. I also found a thread which talks about jsvLock() as a mechanism to prevent the garbage collector from cleaning up references. This means that deep testing will be required to ensure that objects created by the code are not left locked or we will run out of memory.

Howdy folks,
Am studying the use of the JsVar suite within C code. My first question is ... is there an architecture or programmers guide on using JsVars? There seems to be a ton of functions including concepts such as "locking" and "references" and I'm looking for a primer on such. If nothing like that exists, if anyone wishes to post their theory or experiences, it will be most welcome.

The next set of questions will all be on "usage patterns". For example, how to create a Java Script object, what does typing "mean", how to populate an object's fields, how to invoke a variable that represents a function etc etc.

Anything and everything is welcomed here ... and I suspect this thread may grow along this area.

Neil

Howdy @Gordon,
Completely with you. What I am going to do is study all the APIs ... and see if I can't get close to what the community wants. I'm a huge fan of written stuff and plan to document the hell out of the work I do ... Open Source if fantastic ... but no-one wants to write stuff up. This post was to see if anyone wanted to "help" do some of the research and say "this is the API you should use" ...

As for the Telnet, I agree 100%. When I started the project, I couldn't get the serial stuff working but because the ESP8266 is a WiFi device, I could telnet into it and drive the JavaScript exactly that way. Now that I am starting to get something working, I am thinking that I can see that ESP8266 support can supply a Telnet story via JS level ... and hence NOTHING is likely to be needed at the board/code level.

Neil

@profra
Good post. I am not familiar with Lua which I think is the language that I think is used in this binding. NodeMCU has two stories ... one is an ESP8266 board (which should be able to run the Espruino port) and the other is their IDE/Lua language. The APIs that you listed match almost exactly the "C" language bindings supplied by the ESP8266 SDK. (The ESP8266 is made by a company called Espressif ... this is the raw IC that IS the ESP8266 which board makers then include in their boards. Espressif provides a C language set of libraries that can be linked with a C application to achieve WiFi, network, GPIO, timers etc etc ... it is this SDK API that is being leveraged by the Espruino support for the board specific capabilities).

I had assumed that we had walked this space before and there would have been a prescribed strategy that the ESP8266 support would simply "follow" ... however, I'm starting to get the impression that this may be "relatively" new ground. What I think I'll do is do the deep research and make up a "report" on the different APIs that are being used now for networking in Espruino today as well as the APIs being used by ESP8266. However, I believe I want to stay away from anything that would smell of ESP8266 specific ... the goal should be that the ESP8266 should be "just another board" and even if I arrive at Espruino as a skilled ESP8266 kind of guy ... the story should be that this is an Espruino story. To make progress and allow testing, I'm thinking of continuing design and implementation with a class name that may be "EXPRIMENTAL_ESP8266.". Obviously that will not be the final method name or structure but changing names and parameters will be simple once we figure out the API structure we want while at the same time not blocking anyone who wants to continue with the board support. I don't want to stall through analysis paralysis and as long as the method names have no ambiguity that they have not been finalized, we should be ok and not accidentally make something that would lock us in ...

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/targe­ts -IC:/Git/esp8266-espurino/espruino/src -IC:/Git/esp8266-espurino/espruino/gen -IC:/Git/esp8266-espurino/espruino/libs/­math -IC:/Users/IBM_ADMIN/Documents/Raspberry­Pi/ESP8266/libs/esp_iot_sdk_v1.3.0_15_08­_08/esp_iot_sdk_v1.3.0/include -IC:/Git/esp8266-espurino/espruino/targe­ts/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](http://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/25379­300/preventing-undefined-macro

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.

@DrAzzy,
This is good ... so let's follow this through ... and thanks for the names of wiznet and cc3k, I didn't know where to start. If we look here: http://www.espruino.com/WIZnet

We find a bootstrapping of:

var eth = require("WIZnet").connect();

Now ... for an ESP8266 (or a board with native WiFi), I would not imagine we need to require a module ... I would imagine it would "just be present". So I'm imagining an object called "WIFI" being already present in the JS context.

So where in the example for WIZnet we next do things like "eth.getIP()" we might do things like "WIFI.getIP()".

Looking at the CC3000 this looks close to a WiFi story. See:
http://www.espruino.com/CC3000

there we have

var wlan = require("CC3000").connect();

and I imagine that the ESP8266 WIFI object would be a predefined instance of something like that.

But then we get into interesting notions such as the ESP8266 not only being able to be a station ... but also be able to be an access point that other WiFi stations can connect to.

... and all of a sudden ... we start entering the world of "architecture" and "specifications". What I would like to avoid is the notion that ESP8266 does it one way, CC3000 does it another way and un-named devices yet to come do it other ways. Ideally we define the capabilities of an abstract WiFi device and then define the functions on a representative class such that a concrete implementation can "just be" dropped in... where boards such as the ESP8266 already have concrete implementations already present for use without any require() statements.

And this is where we as a community and project owners need to come together and put our heads together. I think progress on ESP8266 networking will have to be suspended until we can figure this one out as the decisions made here will reverberate down the line. Ive internally tested WiFi and TCP/IP working concurrently on the ESP8266 with Espruino and no issues ... so we are literally at the stage now of deciding how to externalize for consumption.

Neil

This post is primarily in relation to the work on the port to the ESP8266 but I believe it has general relevance.

As boards start to have native capabilities beyond just GPIO and UART (and others ...) we start to find richer functions such as WiFi and TCP/IP stacks. How should support for these capabilities be architected into the project?

For example, the ESP8266 has native WiFi capabilities. What should the API exposed to the JavaScript programmer look like? Do we have an "interface" pre-defined that is the "function set" for WiFi that support for a board containing WiFi should provide? Should this be a "module" that the programmer has to import or should it simply be "just there" as a core set of functions for JS programmers on that board?

From a practical standpoint, I have the knowledge and skills to write the C level APIs to drive an ESP8266 to perform WiFi access point attachments and other WiFi related functions but don't know where to start to think about exposing those to the JavaScript programmer that will actually use them on an Espruino environment running on an ESP8266.

Neil

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

Well ... that was nice. This is what an ounce of expert knowledge does. Based on Gordon's suggestion, I added a new processor flag called XTENSA and changed the preprocessor to behave as he posted in his previous post and it worked first time. I'd NEVER have guessed to do that without his knowledge. Awesome Gordon!!! Thank you sir. .... setInterval() is now working.