Search results for:

@MaBe I have tried all three of them to no change in behavior. See the outputs I posted above, they prove the different SPI Modes.

Can you think of anything else? Is there anything to be learned from the rst cause?

Hi!

I wonder what should I do to fix this. I have got a few d1-mini clones with:

Manufacturer: 20
Device: 4016
Detected flash size: 4MB

Connecting with espruino --no-ble -b 115200 I get gibberish and similarly as http://forum.espruino.com/comments/14147­154/ I cannot connect properly.

Hinted from the linked thread I tried all of the FLASH_MODEs and tried to connect to freshly flashed boards at 75600 bauds only to get the outputs below. Changing flash_freq, unplugging or anything else has no effect from what can I say.

Anybody dealt with this?

Thanks!
Standa

DOUT

$ espruino --no-ble  "-b" "75600"

Espruino Command-line Tool 0.1.31
-----------------------------------

Using first port, {"path":"/dev/tty.wchusbserialfd12240","­usb":[1,7523]}
Connecting to '/dev/tty.wchusbserialfd12240'

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 2408, room 16 
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0 
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0 
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : DOUT
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000

No result found for "process.env" - just got "ÿ"
Unable to retrieve board information.
Connection Error?
Connected

DIO

$ esptool.py --port /dev/tty.wchusbserialfd12240 --baud 115200 write_flash \
		--flash_freq 80m --flash_mode dio --flash_size 4MB-c1 \
		0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin \
		0x3FC000  esp_init_data_default.bin 0x3FE000 blank.bin
esptool.py v2.3.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
...
Leaving...
Hard resetting via RTS pin...

$ espruino "-b" "75600" "--no-ble"

Espruino Command-line Tool 0.1.31
-----------------------------------

Using first port, {"path":"/dev/tty.wchusbserialfd12240","­usb":[1,7523]}
Connecting to '/dev/tty.wchusbserialfd12240'
cònglo'ãì
             [#xds](http://forum.espruino.com/search/­?q=%23xds)${$xóoà
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 2408, room 16 
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0 
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0 
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : DIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000

No result found for "process.env" - just got "ÿ"
Unable to retrieve board information.
Connection Error?

QIO

$ esptool.py --port /dev/tty.wchusbserialfd12240 --baud 115200 write_flash \
		--flash_freq 80m --flash_mode qio --flash_size 4MB-c1 \
		0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin \
		0x3FC000  esp_init_data_default.bin 0x3FE000 blank.bin

$ espruino --no-ble -b 115200 "-b" "75600" "--no-ble"

Espruino Command-line Tool 0.1.31
-----------------------------------

Using first port, {"path":"/dev/tty.wchusbserialfd12240","­usb":[1,7523]}
Connecting to '/dev/tty.wchusbserialfd12240'

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 2408, room 16 
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0 
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0 
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000

You mean, move it from firmware to javascript?

Well, sure it's possible ...

With the aim to completely unify board Wifi support I think it would be worth doing as well as perhaps also making it compatible with the http://www.espruino.com/Reference#t_Ethe­rnet interface e.g. the getIP() to be usable with a callback. @Gordon what do you think?

I agree on the memory issues to be fairly pressing but I'd move the related discussion to another forum topic.

For the sake of making the firmware simpler/smaller I wonder if the wifi.save() could simple store wifi config script instead of the the JSON it does now?

This could still be constructing and saving a string and perhaps it would be more bytes written to the .wificfg in the end but I think the benefit of not having to translate the JSON to other setup could make it simpler (the following two functions would not need to exist):

libs/network/esp32/jswrap_esp32_network.­c:1359:void jswrap_wifi_restore(void) {
libs/network/esp8266/jswrap_esp8266_netw­ork.c:902:void jswrap_wifi_restore(void) {

I mean like making wifi.save() save something like this to .wificfg:

(function(w) {
    w.stopAP()
    w.setHostname(...)
    w.connect(..)
})(require('Wifi'))

Or perhaps we don't need any wifi.save at all with the .bootX automatic loading?

Just to confirm. I confirmed the above mentioned IR sending is working as described without any issue on the Original Espruino board v1.3.

@MaBe I too seem to have some issues here on my d1-mini. I am trying to do IR transmit based on the instructions at the bottom of https://www.espruino.com/pronto.

I get Uncaught InternalError: Timeout on Utility Timer message.

It seems that the analogWrite() with 38kHz gives just too much work to do for some reason to the ESP8266. As once I turn the analogWrite() on the previously installed watch for reading the IR (on another pin) starts to be very unreliable. As soon as I did digitalRead() on the same pin the receiver became properly responsive again.

Perhaps a combination of analogWrite()/SPI and digitalPulse() don't play well together?

>process.env
={ 
  VERSION: "2v04", 
  GIT_COMMIT: "3956264e", 
  BOARD: "ESP8266_4MB", 
...
>function codeToPFTimes(code) {
:    let times = [];
:
:    function pushBit(c) {
:         times.push(0.16);
:         times.push(c === '0' ? 0.262 : 0.552);
:    };
:
:    times.push(0.16);
:    times.push(1.18); // START
:    code.split('').forEach(pushBit);
:    times.push(0.16);
:    times.push(1.18); // STOP
:    return times;
:}
=function (code) { ... }
>codeToPFTimes('1000000110011111') 
=[ 0.16, 1.18, 0.16, 0.552, 0.16,  ... 0.552, 0.16, 0.552, 0.16, 1.18 ]
>analogWrite(No,0.95,{freq:38000});          

>analogWrite(NodeMCU.D1,0.95,{freq:38000­}); 
=undefined
>digitalPulse(NodeMCU.D2, 1, codeToPFTimes('1000000110011111')); digitalPulse(NodeMCU.D2, 1, 0); 
Uncaught InternalError: Timeout on Utility Timer
 at line 1 col 94
...gitalPulse(NodeMCU.D2, 1, 0);

Moved my comment to a more appropriate place hopefully (sorry for the confusion): http://forum.espruino.com/comments/15142­355/

@Gordon One thing I think about is the size of the font used.

The app selector contains 3 lines of apps where the icons are decent size but the text is quite small. The Settings app has got like 10 lines and I find that to be the reason it is not too convenient to use.

I would say using a font that would read nicely in 4-5 lines on full screen would be of great benefit to the overall usability of the whole Bangle.js platform.

Menu cycle navigation would be nice. BTN1 when on top could move to the last item in the current menu.

Thank you @MaBe for all the info!

I'll try the dout as the last thing...

Then I guess I give up as I am starting to think that the USB serial is strange. Appears to be loosing characters during ./espruino --no-ble ./index.js. Sometimes it gives syntax errors during that on that one particular board.

I just tried another one marked 'AI Thinker' and that seems to work ok.

>require('ESP8266').getState()    
={ 
  sdkVersion: "2.2.1(6ab97e9)", 
  cpuFrequency: 160, freeHeap: 11144, maxCon: 10, 
  flashMap: "4MB:1024/1024", 
  flashKB: 4096, 
  flashChip: "0xe0 0x4016"
 }

This is a 'doit esp8266' board which is giving me trouble (tried 2v00, 2v04 and now running the master build). Same results - resets on connection (when flashed with dio, doesn't connect when flashed with qio):

>require('ESP8266').getState()
={ 
  sdkVersion: "2.2.1(6ab97e9)", 
  cpuFrequency: 160, freeHeap: 13296, maxCon: 10, 
  flashMap: "4MB:1024/1024", 
  flashKB: 4096, 
  flashChip: "0xc8 0x4016"
 }
>process.env
={ 
  VERSION: "2v04", 
  GIT_COMMIT: "1c3547a", 
  BOARD: "ESP8266_4MB", 
  FLASH: 0, RAM: 81920, 
  SERIAL: "5ccf7fb8-e75e", 
  CONSOLE: "Serial1", 
  MODULES: "Flash,Storage,hea" ... "r,crypto,neopixel", 
  EXPTR: 1073643636 }

Hey @MaBe!

Maybe switch from qio to dio when flashing.

Using qio I wasn't able to connect and it was looking like this:

$ espruino -b 115200 --no-ble 
Espruino Command-line Tool 0.1.20
-----------------------------------

Using first port, {"path":"/dev/cu.wchusbserialfa1340","us­b":[6790,29987]}
Connecting to '/dev/cu.wchusbserialfa1340'
No result found for "process.env" - just got ""
Unable to retrieve board information.
Connection Error?
Connected

Using dio I am now able to connect but looks like it is reseting the board on every connect.

Any idea?

@nistvan.86 There is a different philosophy behind the new module. It has been created so that I could separate the JS mangling stuff like module resolution, optimizations and minification from the actual code upload to the boards. We exchanged ideas on this with @Gordon earlier here.

So the workflow it has been designed in mind with is:

• use the rollup-plugin-espruino-modules to create the final .js bundle
  
• use the EspruinoTools (espruino npm module) to send the bundle to the board
  
  

Or you could use the EspruinoTools (there a config/job variable for that) to run rollup for you with predefined config suitable for using with Espruino. I admit that this needs to get documented better... but you can have a look here.

@allObjects @Konkery Unfortunately I did not test it in Espruino before so sorry for pronouncing it a problem.

I can confirm now that for the RELEASE_1V96 this doesn't work as shown in the comments above and works appropriately in master.

An Arrow function is different from a normal one in that its context is not bound and is taken from the scope lexically above it. Here is an article explaining the differences.

The code looks as correct ES6 wrt to context use and it should work (I had to fix class inheritance and undeclared variable use in order to run it in Chrome). It looks like an Espruino bug.

@tve The approach you are using is basically what I do as well.

@MaBe

Tested with tinyMQTT and a strip down of SSD1306 for I2C only (SSD1306_I2C).

Using Rollup https://github.com/espruino/EspruinoTool­s/blob/f8a5ed8bd565070d33154d9196ad9e51f­8aa3c33/plugins/minify.js#L52-L65 you'll be able to create bundles that only contain the module exports that were actually used in the application.

My CLI preferred approach is to use the https://github.com/opichals/rollup-plugi­n-espruino-modules to do all the JS magic and use the espruino cli to only 'upload' the resulting bundle to the board just as @tve mentioned.

I use an HTTPS gateway in the cloud which provides a tunnel which is established from within my LAN using secure WebSocket. On LAN I run the MQTT server for the pub/sub IoT stuff and also other HTTP-based services.

@dave_irvine I run the whole application on my local machine. I mock any HW stuff and so the application graphics rendering is done as usual but uses some fake data to render.

It should be capable of working on boards but I have actually only ran it on my OSX laptop.

I guess the bandwidth and the lack of WS binary support might be a little problematic memory-wise as it is getting 8kB (screen buffer for 128x64 1bpp) over to the browser on every flip() call.

@dave_irvine from http://forum.espruino.com/comments/14535­405/

I have played with the idea of having an easy way to debug graphics locally and made the following module https://gist.github.com/opichals/8f74cc4­94a3e2d7cf122c6013e8935cf

It wraps the Graphics.createArrayBuffer by calling require('./webGraphics').add(Graphics) and exposes http://localhost:8000 endpoint with canvas renderer for Espruino.

I used it to debug the morphing clock. With some mocking it is possible to debug graphics related stuff nicely before you put the code to the board.

@Mrbbp As the same code runs in Chrome I believe this is an Espruino parser bug. Please submit an issue at https://github.com/espruino/Espruino/iss­ues.

add serial and Bluetooth support to Espruino itself on each of those platforms, and use Espruino as the Native application.

Thinking about this a bit more this sounds like it would make the rest of the project benefit as well. I might require fixing the stack to actually use select for networking and so not consuming 100% cpu all the time and I am sure there are more things to think about.

@Gordon As I suggested in the Rollup.js PR in my head all this communication interface should go into a single-purpose tool which is then called from other parts of the ecosystem (directly as a binary /think UNIX architecture/ or as a library).

that what would be perfect is a very small standalone (eg. not Node.js,
Python, Java, etc) Native Application for each platform (Windows/Mac/Linux)

I totally agree here, access to hw is complicated otherwise.

As for the language of choice I would suggest golang as I hear (I didn't do anything substantial using it yet) it should have the required support in standard/external libraries. Quite complicated apps compile into a very small statically linked binaries which would be IMO just perfect for this purpose. There is ready-to-make docker to build all the required target architecture binaries. As an example project I'd suggest looking at is https://github.com/github/hub.

IMO it would be worth to replace Esprima minification with the recently merged Terser minifier (see https://github.com/espruino/EspruinoTool­s/pull/80).

@Gordon Another reason to deprecate Esprima (it has all kinds of issues with ES6 code).

@Frida Thanks! Will try that once I convince myself to dig into the lamp guts again :)