Search results for:

In an attempt to provide more information, I created a 70 second you tube video ... see here:

https://www.youtube.com/watch?v=z8TJu-3PxqA

The Script I am using is as follows:

E.setClock(80);
var i = 0;
var esp8266 = require("ESP8266");
console.log(esp8266.getState());
pinMode(D4, "output");
function colorLeds(red, green, blue) {
  var data = [];
  for (var i=0; i<20; i++) {
    data.push(green);
    data.push(red);
    data.push(blue);
  }
  esp8266.neopixelWrite(NodeMCU.D4, data);
}

setInterval(function() {
  console.log("Changing ...!");
  i++;
  if ((i % 3) === 0) {
      colorLeds(255,0,0);
  } else if ((i%3) === 1) {
      colorLeds(0,255,0);
  } else {
      colorLeds(0,0, 255);
  }
}, 1000);

which alternates a string of 20 pixels between red, green and blue once a second. The Espruino build is the downloadable binaries for 1v87. The ESP8266 is a NodeMCU DevKit module.

When I started capturing the video, all was working as expected. At about the 20 second mark, we can start to see the weirdness creep in ... this goes on until about 1:00 and then we seem to "resynch". There doesn't appear to be any patterns ... it can start generating ambiguity immediately or can be "correct" immediately ... the duration between weirdness and correctness also appears to be non deterministic. I have tried a variety of different pixels, power sources, pixel strings and pixel types.

I'm very much open to the notion that I am doing something wrong in my setup ... but I'm hoping to hear experiences from other NeoPixel users ... how "stable" are your outputs? What are your configurations? etc etc.

I still can't get the latest builds to run my ws2812b Neopixels ... so I got out my signal viewer which is super high resolution and started looking at the signals. In my tests, I have just one Neopixel connected (again ... just for testing) and every second, change its color from red to green. This should be the byte sequence 0xff 0x00 0x00 (red) and then a second later 0x00 0xff 0x00 (green). The way that bits are sent to a Neopixel is that a "1" bit is high for longer than a "0" bit. This page gives a good reference ...

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

The summary is that a "1" bit should be high for >= 625ns and a "0" bit should be high for less than 563ns.

My logic trace shows that we are all over the place. See the attached diagrams:

What I am seeing is that the "relative" durations of highs vs lows is working but the absolute values are out of whack.

@JumJum ... I'm really interested to hear what you have and have not got working. What kind of NeoPixels are you using? Do you known if they are WS2812s or WS2812b's or something else?

I wonder what is meant by 512/512 in the message area on line 11? I also believe that the latest Espruino is 1v87 ... something might have improved in a later release?

With the help of @tve ... it seems that the latest download of the esp-open-sdk brings in the ESP8266 SDK 1.5 release (note that 2.0 is now available). As such, when I tried to build Espruino, it used the ESP8266 SDK 1.5 release. Now, SDK 1.5 supplies a tool called "gen_appbin.py" which is used by the Espruino Make system. Unfortunately, SDK 1.5 added an extra required parameter to that command which, so far, we have been unable to find any documentation upon. The up-shot of this is that attempting to build Espruino against an ESP8266 SDK 1.5 (or later) results in the errors reported at the start of this thread.

As a community, we need to decide what we want to do next. My votes would be to attempt to get Espruino working with SDK 2.0 and skip SDK 1.5. This would then mean the following tasks:

1. Install and build the esp-open-sdk package
   
2. Upgrade it to use SDK 2.0
   
3. Correct/fix/change the Espruino Makefile to add the required parameters to gen_appbin
   
4. Correct/fix/change the Espruino Makefile to use the "boot" file supplied by SDK 2.0.
   
5. Possibly other steps ...
   
   

Does this sound about right to the community?

... Later ...
I downloaded a virgin/fresh ESP8266 directly from the Espruino Github ... and this time I found the missing/extra parameter. Yet another case of me bungling something I'm afraid. I still find problems building against 1.5 SDK ... namely I had to change the reference of lwip_536 to lwip and change the boot file from boot_v1.4(b1) to boot_v1.5. But other than it ... it compiled cleanly.

... Later still ...
It seems like @Wilberforce and @tve have already provided separate pull requests to update to SDK 1.5 and SDK 2.0 ... this looks promising.

@Wilberforce
Many thanks for the assistance ... I checked my settings and they were almost identical to yours. I tried a make clean and then a rebuild but same error. If we look at the current master Makefile which is here:

https://github.com/espruino/Espruino/blob/master/Makefile

and we look at lines 1968 and 1982 ... we see two mv statements that use the fiile eagle.app.flash.bin as the source but I am at a loss to see where this file may come from in the first place. It isn't in the Git repository and I don't see where it is "generated". Can I ask you to look in your Makefile and see what is on or around the same sections of instructions?

.... later

I found the commit that made these changes ... it is this one:

https://github.com/espruino/Espruino/commit/8323a8a832ceb538e832b954bc7dbfbf3c47685c

as I dug deeper ... the file that is missing (eagle.app.flash.bin) appears to be generated by a program called gen_appbin.py which is named in the variable APPGEN_TOOL.

However, what I find odd is line 1966 of the Makefile which reads:

$(Q)COMPILE=gcc python $(APPGEN_TOOL) $(USER1_ELF) 2 $(ESP_FLASH_MODE) $(ESP_FLASH_FREQ_DIV) $(ESP_FLASH_SIZE) 0 >/dev/null

and this is where my Makefile skills may be leaving me. What does that line do/mean? As far as I can tell it assigns to a variable called COMPILE ... but I'm guessing that must be wrong.

I am trying to compile Espurino but it seems to fail right at the end. The last lines in my make are:

  4 -rwxrwxr-x 1 kolban kolban   2108 Sep 16 11:18 eagle.app.v6.data.bin
384 -rwxrwxr-x 1 kolban kolban 389124 Sep 16 11:18 eagle.app.v6.irom0text.bin
 24 -rwxrwxr-x 1 kolban kolban  21588 Sep 16 11:18 eagle.app.v6.rodata.bin
 32 -rwxrwxr-x 1 kolban kolban  29692 Sep 16 11:18 eagle.app.v6.text.bin
mv: cannot stat 'eagle.app.flash.bin': No such file or directory
Makefile:1642: recipe for target 'espruino_esp8266_user1.bin' failed
make: *** [espruino_esp8266_user1.bin] Error 1

The source is a fresh download of 1v87. I am compiling on Ubuntu Linux using the Xtensa toolchain built from https://github.com/pfalcon/esp-open-sdk. It appears that this has pulled in ESP8266 SDK 1.5.

The initial debugging I have done is to look through the Makefile to see where "eagle.app.flash.bin" is mentioned. It appears at:

L1649 - The source of a move statement
L1679 - The source of a move statement

I don't yet know if I am missing an instruction or failed to perform a step (both are possible) or whether there is something "up" with the build recipe. If anyone has any knowledge here, most appreciated.

Has anyone gotten the NeoPixels function working recently. When I try and run it, the first neopixelWrite() works but ones after that seem to be ignored. This is the sample I am using:

var esp8266 = require("ESP8266");
pinMode(D2, "output");
function colorLeds(red, green, blue) {
  var data = [];
  for (var i=0; i<2; i++) {
    data.push(green);
    data.push(red);
    data.push(blue);
  }
  esp8266.neopixelWrite(NodeMCU.D2, data);
}

setInterval(function() {
  console.log("Changing ...");
  colorLeds(Math.floor(Math.random() * 256), Math.floor(Math.random() * 256), Math.floor(Math.random() * 256));
}, 1000);

Congrats on the 1v87 release. Is it safe to assume that the builds (for me the one I care about is the ESP8266 build) comes from the source tree found here:

https://github.com/espruino/Espruino

If I wanted to build the latest and greatest 1v87 build for myself so that if I wanted to make changes for potential submissions for pull requests, I want to be sure I start from the right place.

The first link on this page titled "reference section" seems to be broken.

http://www.espruino.com/ESP8266_Flashing

When the ESP32 starts to ship, I for one will happily volunteer to port to ESP32. I am still waiting on details but believe that the ESP32 will be core based on RTOS ... that will take a bit of effort. But after the work done last year on getting Espruino running on the ESP8266, it shouldn't be too awful. And with the upping from 96KBytes to 512KBytes of RAM ... we should be in GREAT shape for larger apps.

@d0773d ... for FreeRTOS, see this existing Github Espruino issue .. https://github.com/espruino/Espruino/issues/699

The ESP32 which ... as we understand it ... will be an ESP8266 with a lot more RAM and CPU power ... will very likely use RTOS as its base. The ESP8266 today has an Espressif RTOS base that ... strangely ... appears that it may already need LESS RAM than the non-OS-SDK today. Not only that, it provides a blocking sockets based TCP/IP API. One of the side effects of that is that the networking portion of the Espruino port to EPS8266 could be replaced with the standard sockets networking code base today.

I have a Raspberry Pi 2 at my disposal and I'm going to start an investigation on the state of play of JavaScript programming with electronics integration on a standard Raspbian Linux base. I'll be writing that up for the broad community but as a side effect, we'll maybe get a sense on whether or not Espruino offers something that would warrant any form of port to native hardware. For example, we'll see if SPI, I2C, PWM and all the other items where we need exact timing come across without issue.

Ive also got a thought in my mind at the notion of an Espruino "shim" layer for existing JavaScript engines. For example ... if one took Nashorn as a JavaScript engine (for example) and then implemented the Espruino specific JavaScript APIs (relatively simple) ... would one then be able to harvest the large set of component integration libraries already available for Espruino on a non-Espruino JavaScript engine running on Pi Zero linux?

@DrAzzy ... I'm still thinking the notion through. The announcement this week of the Pi Zero has changed the landscape. I had been anticipating C.H.I.P. ($8) and Onion Omega ($19) to have been game changers and didn't see a $5 Pi coming.

Let us take a step back. Up until now, we had low end processors such as the Arduino and ESP8266 and also the dedicated (but pricier) dedicated Espruino boards. I am now going to take the Arduino out of the story since it doesn't have the ooomh to run Espruino.

Now if we take the Pico as the gold standard for a platform for running Espruino ... we end up with a device that runs at 84MHz with 96KByte of RAM. It has no video and no USB output and retails at about $25. If we see value in that device ... what more value would we have in an equivalent device which has 1GHz processor speed, 512MB of RAM and GBytes of SD storage ... for a base price of $5.

If we choose to use the Pi Zero as is, then the question becomes one of "What value is Espruino?". My thinking goes as follows ...

I want to write applications. When I write applications, I have a choice of programming languages each suited to different purposes. If my purpose leads me to JavaScript ... the question becomes "which" JavaScript run-time environment should I choose?

As far as I can see my choices are:

• node.js
  
• Nashorn
  
• pijs.io
  
• others?
  
  

Over the last month, I've been eagerly awaiting my Onion Omega but @tve has been cautioning me that because it runs Linux, I may not be happy with what I find. I have no experience running Linux on small embedded systems so I took his cautions as very worthy of consideration. I have a Pi 2 Model B ... but since that is a quad core monster and also comes in at $35, I put that aside as "not applicable" to our comparisons.

Without having had any experience nor read any empirical evidence, my "gut" (and it is only my gut) says that running an existing JavaScript runtime on the Pi Zero will be more than satisfactory for my personal needs. However, if the "cost" of running Linux interferes with what I or others may want to do ... then we eliminate Linux ... and run Espurino on the metal.... and that brings us to this post and the thought experiment.

I see a flow chart here ...

#1 run JavaScript as-is on Pi Zero on Linux and all is well - stop
#2 run Espruino (JavaScript) on Pi Zero with no Linux and all is well - stop

The question in front of us is one that hobbyists in combined electronics/computing like myself will see revealed over the next 6-12 months.... and that is where do we focus our tinkering? Historically it was Arduino because it was so easy and so cheap. Then came the Pi ... but that was really a computer and for some reason the price north of $20 caused us to pause ... we got all excited again about the ESP8266 ... not necessarily because it just had WiFi ... but because it gave us 80MHz processor and 40K of usable RAM for about $5. Now we have another turn of the crank and we have 1GHz processor with 512MB for $5. GULP!! Orders of magnitude improvement.

I can imagine and understand folks saying ... ahhh ... but what about power consumption ... and other dimensions ... and those are all valid ... no question. But in some dimensions ... those that relate to CPU cycles and available RAM and price ... it seems we have just witnessed a dramatic leap forward that will take quite a while to beat.

The reason I waffle down this path ... which appears unrelated to our Espruino discussions ... is that if (just IFF) my suppositions hold any merit, then all eyes will transition to Pi Zero ... likely away from Arduino and likely away from ESP8266/ESP32 ... for the hobbyist community (which is where I play). And if eyes transition to Pi Zero ... then maybe (just maybe) a first class ridiculously efficient JavaScript engine running natively on the Pi Zero might have some value ... and again ... that assumes the Node.js with all ITS eco-system doesn't already fill that niche on the Pi Zero on Linux today.

With the release of the Pi Zero (https://www.raspberrypi.org/blog/raspberry-pi-zero/) with a retail price of $5 ... I can't help but feel that we are witnessing a significant change.

How about we port Espruino to Pi Zero?

But wait, you are going to say ... the Pi Zero is a Linux system which already has production quality free JavaScript environments ... it has Node.js and Nashorn ... just to name a few. Why port Espruino to Pi Zero?

The answer is a twist ... my suggestion is not to port Espruino onto Pi Zero on top of Linux ... but instead port Espruino to run on Pi Zero natively. Specifically, Pi Zero would have a firmware image that boots from SD card directly into Espruino .... period. No Linux in sight ... just 1 GHz processor, 512MBytes of RAM, SD card FAT32 file system, GPIOs, UART, I2C, SPI, PWM and ADC ... all "just available". WiFi would be handled in the same way that non-WiFi enabled Espruino boards would be handled today. There would be no Video or USB support (in the first release) ....

However, what it would do is appear to provide the most robust environment for only $5 at a performance level that would appear to be unbeatable in the current time frame.

Does anyone see any merit in this? $5 for a 1GHZ, 512MByte, SD card based Espruino environment?

Assuming what you want to do is invoke a JavaScript function next time around the idle loop AND there is no "this" JavaScript context needed, then I think the solution would be to call:

jsiQueueEvents(NULL, jsCallbackFunction, params, count)

Where jsCallbackFunction is a reference to a JsVar that is a function reference.

@Gordon Can you clarify the last post? Are you saying that for ESP8266 users, the latest build as build by Travis can now be downloaded at the URL provided above. Does this mean that should now be where we point end users to obtain the latest build? If that is the case, then we probably need to shutdown EspruinoBuilds to reduce the sources of confusion.

Perfect ... added to Issue #722 as a task to be done before completion of that issue.

@MaBe From your post, a new issue was created (Issue #722) .. fortunately, it wasn't difficult at all to add and can now be found in the latest builds.

See:

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

Would it be possible to place builds here:

https://github.com/espruino/EspruinoBuilds/tree/master/ESP8266

I'm thinking that as long as a build is consistent with what is in Github, then we should be good.

Later ... build placed at ...

https://github.com/espruino/EspruinoBuilds/tree/master/ESP8266

By any chance do you have any raw NeoPixels to test with? I'm wondering if that circuit is giving us some problems?

Try the following:

var esp = require("ESP8266");
var pin = new Pin(15);        // I've tried all available GPIOs
pinMode(pin, "output");
esp.neopixelWrite(pin, [50, 50, 50]);

It may be that setting the pinMode explicitly to output is required.

@bluebie If you or others have C and TCP/IP coding skills, I'll be delighted to work with y'all getting an environment set up and running tests to see what pans out.

One thing we could look into would be the idea that we could provide a non-strategic solution. From a UDP standpoint, the ESP8266 provides some clean APIs. We could provide an "ESP8266UDP" module that could be implemented in C that would externalize a sendto and recvfrom API pair. This could be implemented very quickly ... however, this would not be strategic to the long term direction of Espruino but could get you and other UDP consumers going sooner than later. I'm not sure what the procedure for approval for introducing such a specific module would be ... but if approved, the turn-around to get something working need only be a couple of hours.

@hygy
When last we exchanged correspondence, you had provided me a sample which, when run for a couple of hours crashed. I was able to run the sample sample and mine too crashed after periods of time. As I dug deep into this, I found that, on occasion, the HTTP call to thingspeak failed in the GET request. That is ok ... that should be a potential occurrence. However, the Espruino port to the ESP8266 was doing something bad. It was ignoring the notification that the HTTP request connection had failed and keeping ESP8266 resources locked up. Since the poor old ESP8266 running Espruino has so little RAM to start with, a couple of such failures and we quickly ended up out of memory.

As part of Issue #595, we added a detection of a failure to form a connection and associated cleanup. What that means is that when an HTTP request to a partner fails, ESP8266 will now detect that occurrence AND release the Espruino/ESP8266 resources.

Any build north of 2015-11-14 should contain the fix.

@Gordon I was thinking about the timer workaround ... imagine that a http.get() request is made to a back-end and fails (silently) because there is no callback to say that the network connect request itself failed ... One suggestion was to have a cancel able JS level timer that if not cancelled, would indicate that we had failed to connect ... Imagine that the timer was in fact called ... in our timer callback code we now know we are here because a connect request has failed ... what should we then do? What remediation is possible at the JavaScript level to clean up the internals of todays Espruino? Experience seems to show that I am looping in calls to transmit (to transmit the request).

I'm not sure if this is a doc error or if I am not understanding something ... if we look at this page as of the date of this posting:

http://www.espruino.com/PWM

The sample says:

eg. analogWrite(A0, 0.2) (Pulse high for 10% of the time)

Does a value of 0.2 not mean 20% of the time as opposed to 10%?