urbiman

Most recent activity

• Bake JavaScript into firmware

  @urbiman started

  • 8 comments
  • 3,876 views

  @Gordon replied
• Bake JavaScript into firmware

  in General • 7 years, 11 months

  

  Thanks @Wilberforce , can you maybe point me to a list or other source where I can find the area where the code is stored?

• Bake JavaScript into firmware

  in General • 7 years, 11 months

  

  @Ducky you are completely right, this is exactly what I would like to achieve. Any hints?

• Bake JavaScript into firmware

  in General • 7 years, 11 months

  

  Is there any way to bake JavaScript into the firmware so it gets flashed with the firmware? I mean a JavaScript that gets executed after startup of the chip just like if I would have transferred it using the IDE?

• I've made some updates to the webSockets lib ws.js

  in JavaScript • 8 years, 7 months

  

  My JavaScript is based on the wsx.js from the first post here which should be widely identical to the current ws.js available from the espruino site so it is compatible to what is in place now. Just give me a few days as I would like to further improve the http handshake as it could still fail under certain circumstances and I would like to add support for larger messages (more than 127 chars).

• I've made some updates to the webSockets lib ws.js

  in JavaScript • 8 years, 7 months

  

  Ok, I fixed it myself. The reason why the code was disconnecting all the time when using cloudflare was the following: The handshake was transmitted in two chunks (each chunk has a wrapped around it here):

  <DATA>HTTP/1.1 101 Switching Protocols
  Date: Sun, 08 May 2016 08:59:10 GMT
  Connection: upgrade
  Set-Cookie: __cfduid=xxx; expires=Mon, 08-May-17 08:59:10 GMT; path=/; domain=.urbiworx.de; HttpOnly
  Upgrade: websocket
  Sec-WebSocket-</DATA>
  <DATA>Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
  Server: cloudflare-nginx
  CF-RAY: 29fbb6cda43e26d2-FRA
  </DATA>
  

  So what happend here was, that during the handshake one data packet was received with an "H" at the beginning (first chunk) that did not contain the "Accept" Header (that is in the second chunk) and so was interpreted as WS message. "H" in hexadecimal is "48" which is the worst that could happen as it means opcode "8" - terminate connection.

  I now changed the code accordingly so that chunks do not get interpreted as message as long as the handshake is not finished.
  It is not yet implemented optimal right now however it works much better than before.

• I've made some updates to the webSockets lib ws.js

  in JavaScript • 8 years, 7 months

  

  I had problems getting WS to work with the latest nodejs ws version (1.1.0) as a server.

  The trick for me was to add a "return" statement in the first if block of the "parseData" method (roughly line 117 of wsx.js) to prevent the other statements to execute and produce unexpected results in some cases. After I did this change the connection was not directly terminated any longer.

  My ultimate goal is to get it running together with cloudflare (as they now support websocket connections in free plans).
  I did some changes that significantly improved the behaviour:

  Added the hostname to the handshake (otherwise reverseproxies can not handle the request)
  Removed the Origin from the handshake (otherwise correct WS servers would decline the connection because of CORS problems, however it is optional for devices like espruino)
  Added XOR encryption for the send method as this is mandatory for clients to do

  Further I also try handle binary data, however this is experimental and has nothing to do with cloudflare.

  Now cloudflare finally accepts the connection and even forwards my first message, however the connection is terminated right after that. When not using cloudflare (and connecting directly) everything works as it should. Does anyone have a clue what could be the problem?

• Light- or Modem Sleep

  in ESP8266 • 8 years, 8 months

  

  I did a pull now to merge the deepSleep and modemSleep stuff (#825).

  Regarding the lightSleep it seems that this is only possible with wifi off if you want to enforce the sleep (which is what is supposed as far as I understand):

  Yes, wifi_station_disconnect(); and wifi_set_opmode_current(NULL_MODE); are needed before calling force sleep function. We will add more description on this in the documentation.
  Source

• Light- or Modem Sleep

  in ESP8266 • 8 years, 8 months

  

  Ok, good to hear :) I will do a pull in the next days first adding deepsleep and modemsleep. However it seems to be possible to implement what you have done for the STM boards by using lightsleep. I found the following code (using light sleep and a timer):

  //sleep over.
  void fpm_wakup_cb_func1(void)
  {
     wifi_fpm_close();   //disable sleep function
     wifi_set_opmode(STATION_MODE);      //set wifi mode to station mode
     wifi_station_connect();         //connect ap
  }
  
  void user_func(...)
  {  
  wifi_station_disconnect();
  wifi_set_opmode(NULL_MODE);      //set wifi mode to null mode.
  wifi_fpm_set_sleep_type(LIGHT_SLEEP_T);      //set force sleep type, clsoe rf&cpu
  wifi_fpm_open();            //enable force sleep fucntion
  wifi_fpm_set_wakeup_cb(fpm_wakup_cb_func1)；   //Set fpm wakeup callback function 
  wifi_fpm_do_sleep(10*1000);         // do sleep
  ...
  }
  

  Source

  I think that would be the next step then...

• Light- or Modem Sleep

  in ESP8266 • 8 years, 8 months

  

  Actually I do not interact with setTimeout. In the case of deepsleep it wouldn't make too much sense either I think, as after deepsleep the chip is resetted and therefor all timers are lost. In case of modemsleep it should be uneccessary as the CPU runs normal.

  I am not sure about lightsleep (I did not implement that) but my current understanding is, that lightsleep needs an external trigger to wakeup:

  Under the light-sleep mode, the CPU will not respond to the signal and interrupt from the peripheral hardware interface under the pause state. Therefore, the ESP8266 need to be waked up via external GPIO, and the wake process is less than 3 ms.
  (Source)

  To me currently it seems that there is no way where the ESP8266 could interact with setTimeout (however I am not completely sure when it comes to lightsleep as RTC is running according to the document above).