Search results for:

In my real-life job, when changes are being suggested that might impact folks upstream or downstream we call them "stakeholders" and try and get them involved early and often in things that might impact them. Perhaps if you know of folks who are "important" consumers (and that is an extremely subjective concept) we can make them aware of this work item and see if they would be interested in commenting or getting involved in the decisions? If they say that the impact of changes is not acceptable ... then that's a major consideration. If they say that proposed changes are welcomed ... they may even have important contributions to include.

Maybe drop them a note pointing to this thread and/or the issue?

On the subject of Websockets ... there is an issue already in flight for that ... see #258

https://github.com/espruino/Espruino/issues/258

That might be a great place to capture technical and pertinent notes on Websockets as needed.

I'm thinking that's the good thing about all this pre-amble discussion. If we discuss the proposed specification for the interface up front and iron it all out (as best we can) before we implement and then ship ... that will make sure we are all in agreement.

As I understand it, if we build this new interface ... that will be a new interface that will not have been coded to previously? It will be a generic interface that all existing boards could choose to implement and at that point, a "WiFi" implementation would then be normalized. I could also imagine that we could choose that the existing implementations remain exactly the same so that there would be TWO ways that WiFi could be used ... one would be the way that exists for boards that already exist ... and the other would be a "common" mechanism that new boards would comply against.

I don't personally consider the ESP8266 support "released" so as yet, all ESP8266 board users are still alpha/beta testers and should expect flux.

@tve Good thoughts ... since there are lots of questions and lots of details ... Ive created a Wiki page we can use to categorize our questions and comments. See the following:

https://github.com/espruino/Espruino/wiki/Generic-WiFi-Design

Feel free to update the page with your own comments and thoughts.

@asez73 After studying some of these articles, what I think I am sensing is that this is still a bleeding edge area. There seems to be quite a few different stories ... but at this stage, none of them appear to be overly polished. There doesn't seem to be a recipe (that I have seen yet) that one would just follow to achieve source level debugging that doesn't seem to include "... and start by downloading this GitHub project to a Linux environment and compile it .... ". This is not to short change the efforts that are going on to make all this happen ... it just doesn't appear to be as consumable as I might personally like.

I personally enjoy writing up "how-to" guides ... and would be delighted to write up a recipe in depth ... but that pre-supposes I can learn a recipe to write about :-)

Currently, I seem to have two tracks ... one is QEMU and the other is deeper study of something called Crosstool-NG. Neither of which I know much about yet.

@asez73 Oh Wow!!! This looks GREAT .... MANY thanks for the link ... looks like I have lots of new study to do now.

My thinking has always been that there is a current Espruino architecture in place that @Gordon designed and built to support a number of partner networking devices. I too believe that there may be alternative designs available but my thinking at this stage of the project is to adhere to the current designs in place. The alternative would be to re-architect and re-work existing designs which (opinion) would delay the availability of a good ESP8266 port.

My vote would be to get as much of the ESP8266 port working as possible adhering to the existing designs and then ... when the port has reached a stage that some might call "complete" ... then we can turn our attention (if needed) to suggestions for core Espruino internal re-designs.

Now ... as we go through the ESP8266 porting work, things like you have said are golden and should not be lost but instead, perhaps, captured as new "Issues" for subsequent evaluation and addressing.

It took me a ton of time to get my mind around how the networking subsystems worked ... but once I did that, the actual amount of design and coding needed to "integrate" with the existing design wasn't horrible. That leads me to believe that if future rework was needed at the ESP8266 level because of a change to the way Espruino core was driving it, that wouldn't be radical surgery.

(all opinions)

When working on the source code of Espruino (C) and making changes, I find myself injecting logging statements to see what is going on. This is the case for my tinkering with ESP8266 port. I am wondering if on other boards or in general there is a better debugging strategy?

Is there any kind of source level debugger being used?

Should we consider the ability to include debug statement in the C source code that would be compiled out for release but present for debug builds? At present I am putting in debug statements, testing and then removing the debug statements but I would rather be able to leave them in and simply switch them off.

@MichaelPralow Awesome ... community choices are (to me) the most important guidance. I am still ignorant on Node.JS so it is incumbent on me to go study that. However if y'all are saying that the defacto story is error code first ... then that has to be the right answer.

A github work item (#589) has been created to track the low level design and implementation.

https://github.com/espruino/Espruino/issues/589

@Gordon This is perfect ... exactly what I hope for from an architect. We can now start designing an implementation for this and see what gets uncovered as that progresses.

@allObjects Your thoughts are vital ... this is community stuff. I think I also lean towards and object with properties over parameters ... however ... I also am keen that if an object is passed in that is missing some required "property" that the implementation makes that known rather than breaks or quietly does nothing.

I am also of an opinion that callback functions that are passed an "error" indication ... that the error parameter be the last parameter in the callback function's formal parameter list. So instead of:

function(err, ap)

we would have

function(ap, err)

Of course if there is some existing standard or convention in Espruino, I would follow that and then if I felt strongly, I'd raise a work item request that we address the standard or convention as a whole.

@Gordon I think we need a whole new thread that I would suggest titling:

"Architecture: WiFi generic object interface"

What that thread would cover would be the "spec" for the generic WiFi object that would be exposed to JS and then board implementations such as ESP8266 would then implement that spec.

In my mind, the "WiFi" spec would NOT own any API networking ... it would specifically own WiFi access ... functions that it might expose would be:

• Scan and list the available access points
  
• Connect to an access point as a station
  
• Disconnect from an access point
  
• Become an access point
  
• List the the stations connected to me when I am access point
  
• Drop a station connected to me when I am an access point
  
• Configure DHCP, static IP addresses, default TTL, mDNS, gateway interfaces ... etc etc
  
  

All of these are "WiFi" related and are present to initialize the network arena but aren't network programming so I would keep separate from socketserver functions.

(opinions were rife in this post :-)

@Gordon ... If you or someone can own the "Travis CI" skills, I'll certainly be willing to own the compilation process of the ESP8266. I'm very keen on the community having folks who are specialists in areas ... for example ... ive never used Travis and don't want to learn it when someone else in the community might already have those skills. So this is where we can partner together.

I can certainly provide either a Linux or Windows set of compilers but there will also need to be libraries and tools. Where does "Travis" run? What kind of environment control might we have over it?

I agree with both of ya ... however ... what we all need to do now is put our heads together and ask what the "abstract" WiFi API should be?

Assuming that we had a 'require("WiFi")' that returned an object with methods, what then should the method names, signatures and semantics be? If you don't have a basis at this time, I'll go ahead and make one up.

@the1laz ... Would you be interested in community project job? How about you spend an hour or so and make up a spec for the "virtual" WiFi interface and we can implement it against ESP8266 and the other network WiFi boards to come?

The merging of the ESP8266 port and ESP8266 specific code to the master Espruino code base has now been completed. The Espruino github repository is now the exclusive place for the past work performed for an ESP8266 port and will be the exclusive place where future changes are made.

@Gordon has been an awesome owner and steward of the project and without his assistance and support, we would have been sunk. He is also extremely responsive and the merges were approved VERY quickly.

@Gordon ... awesome ... youve created a Gitter area for your account (Espruino) but haven't yet created a room for the Espuino project. What you have to do is click the "Create a Room" button at the bottom left of the Gitter tool and select the Espruino repository from within the Espruino account.

Ok ... I'm sold ... TODAY is merge day. I have a full 8 hours to devote to this.

@Gordon I'm going to do the merge ... and then lock down the separate repository. What is your availability today to work with me on this task?

@tve If you are available today too ... let me know.

The chatter will be on the gitter stream ... see:

https://gitter.im/aplikatika/Espruino-on-ESP8266

@Gordon ... can you create a new Gitter stream for Espruino? Once the merge takes place and the separate project is locked down, I'd like to move everyone interested in Espruino chit chat (including ESP8266 support) onto that formal chat stream and since a chat stream associated with a Github project has to be created by the Github owner, that would be you.

As of today, the ESP8266 networking support is a static class called "ESP8266WiFi". I was about to rework to be a library that would then be accessed (as I understand it) with the format:

var esp8266 = require("<some name>");

I was going to choose "ESP8266" for the name of the networking library but then realized that "ESP8266" is already chosen for use with the ESP8266 piggybacked support. I'm now thinking through what the resolution options may be.

The HTTP client (at least GET) has now been tested and is included in the 2015-09-26 binaries.

I've studied and plan to study more ... but if anyone can help me out by explaining some architecture it would be appreciated. I am at the point where in the ESP8266 support I can load JavaScript into the ESP8266 for execution ... but now am puzzled on what techniques should come into play should I want to "harden" or "save" the application such that when the ESP8266 boots and loads Espruino ... my app will start and come to life without me having to load it again through UART.

Neil

I find that when I write a JavaScript which includes a "built in" module ... I get an IDE popup warning saying that the module was not found. For example:

var http = require("http");

Could this be because the IDE is looking to find the module from an external repository but the module is actually not going to be found since it is built in?

Neil

He he he .... so "SAVE_ON_FLASH" is all about "save on the usage of flash memory" as opposed to "saving data to flash memory" .... LOL ... British vs American language structure strikes again :-)

Howdy @Gordon, we actually haven't tested the HTTP client stuff yet ... this is incremental bits and we want to be as methodical as we can be. I thought you might like to see this ... it is based on the design pattern you gave us over the last week ... it is the state diagram of a socket at the ESP8266 level ... (see attachments).

Which begs a new question ... where within the source tree of the Espruino project should we put document files (images) like this?

Just in case it helps ... there is a whole ESP8266 community of support staff at your disposal ... see:
http://www.esp8266.com/

The forums are active and friendly and there is a ton of historic information about all things ESP8266. Flashing the ESP8266 is a story that has to be done all the time for those who like to play with ESP8266 by itself so you will likely find a ton of useful posts, tips and tools present there.

@Gordon ... he he he .... Am I sensing the asynchronous story of ESP8266 is biting us again for the partner board story? As you know, a request to do something on the ESP8266 does not mean it is done until the ESP8266 later tells it is :-)

I'm starting to study how to integrate Flash interaction with the ESP8266 port. I have stumbled over a macro definition called "SAVE_ON_FLASH". I grepped the whole code based and searched the forum looking for a description of what it means but couldn't find one.

Does anyone know what the meaning of this definition might be?