Search results for:

Thanks - yes I did that. I might need to get it down to a simpler case. The code is using 3 local modules. I'll also take a closer look at the console log.

Looks great!

Is line 28 correct? It's assigning the var to itself?

On the esp8266 there is way of setting the hostname, so then you can use for example http://espruino.local - is there a way of doing this on this board - then you don't need to worry about the IP address..

I have an early build - it has the storage module, so must be quite recent.
All is ok with this build.

However with a fetch/pull of 1.96.22 and connecting on telnet 2323, when sending to via the ide, it does not complete. Disconnecting the ide does not release the telnet session.

The is on Linux on windows subsystem, which has worked fine in the past.

ah - so you have turned on flashfs - this will use the flash memory as a filesystem, and disable the code that uses the sd card. I guess you have not tested the sd card yet? You might need to reduce the number of variables as the flashes support creates a 4K buffer for the sectors in the flash memory.

With regards to suppressing the boot messages- I'm not sure there is an easy way. On the esp32 you can hold a pin low to suppress the messages. Do some googling!

Hi,

Thanks for posting. Interesting to see that you are loading the module dynamically:
https://github.com/wga22/esp8266/blob/master/espurino/ESP32_drawforecast.js#L64

Why are you doing that?

A line or two between the text rows might be a bit more readable!

I'm not sure what is so secret about your code that you don't want to post it?

You can * out the passwords.

You have code that is using wifi.connect - however you are using wifi.save as well....
The wifi.save saves the current connection and on next restart -automatically connects. This is useful for telnet to the device..

So you don't need wifi.save in your main code.
The way it it working at the moment is

• restart device
  
• it auto connects to the wifi
  
• then you connect to wifi when the connection is already done.
  Perhaps this is why the wifi.disconnect case works.
  
  

Use the 4mb build and see here:

https://github.com/espruino/Espruino/blob/9ffc5162047e93200e1356c3334b05f5ab67db53/boards/ESP8266_4MB.py#L25

Comment out and uncomment - and do a make clean

I thînk you are creating a firmware to large to fit on the board.

Which modules get applied is controlled in the .py board file. Since you are have a 4mb module, you should use the esp8266_4mb firmware which also needs to be flashed a certain way.

See here- the flash size parameter

http://www.espruino.com/EspruinoESP8266

Also - should the time zone and time get set for the save on send option? The next time the board resets and loads the code the time will be in the past - set to the time when the code was uploaded?

Without seeing what code you are uploading and what you are trying to do it would all be guess work.

What you are seeing is a core dump - something is causing the board to panic.

Have a look in the console log of the ide...

I'm seeing some stangeness too:

Save on send transformed code to: E.setBootCode("setTime(1521267139.472);E.setTimeZone(-780)\nModules.addCached

The set TimeZone looks odd!

Which version firmware are you using?

This is from the readme...

espruino --board PUCKJS --minify mycode.js -o output.js

Then you could use nc or similar to send output.js to the telnet port...

Not sure about the serial console, @JumJum wrote this code. I don't know if all boards have flow control enabled.

Your other option is to use the telnet port 23 to send code up to the esp32, bypassing serial. In the web ide you can cannot via ip - not sure if the command line tools are set up for this.

This is bit odd as you would expect the interpreter code to be the same across the devices.

As far as raising issues @Gordon 's call - it is sometimes useful to discuss here and then raise an issue if requied

In the esp32 case you mentioned allocating memory in a certain way to use for Dma. Is there any downside to this, as the arraybuffer class in the esp32 case could allocate this type of continuous block, and then you would not need to the memcpy at all as the source would already be of the correct type.

Rather than remove - what about changing the default to be on if greater the v90, so that people still have the option of turning off?

Perhaps it should be relabeled or a sub note saying that this means modules go to flash?

Another option is to build a custom firmware that compiles in the SSD1306 and graphical_menu as js sources, then these modules will be in flash instead of ram...

The other option you have is to have a bootstrap script that you run first, that saves the large btoa image as an array into with Storage.write. This can be run once to save the data, and then the main script just pulls a reference to this in flash and won’t consume any valuable ram.

For the esp32 case it looks like this flag should be set:

https://esp-idf.readthedocs.io/en/v2.0/api/peripherals/spi_master.html

SPI_USE_TXDATA
It says:
Sometimes, the amount of data is very small making it less than optimal allocating a separate buffer for it. If the data to be transferred is 32 bits or less, it can be stored in the transaction struct itself. For transmitted data, use the tx_data member for this and set the SPI_USE_TXDATA flag on the transmission. For received data, use rx_data and set SPI_USE_RXDATA. In both cases, do not touch the tx_buffer or rx_buffer members, because they use the same memory locations as tx_data and rx_data.

I'm wondering if once the speed is set, it stays the same. Perhaps try setting to 400000 after a fresh boot?

The Bitrate should be getting set:

https://github.com/espruino/Espruino/blob/master/targets/esp32/jshardwareSpi.c#L120

https://esp-idf.readthedocs.io/en/v2.0/api/peripherals/spi_master.html

disconnect and reconnect then it may work

This tends to happen straight after flashing. If you connect with putty(windows) or minicom(Linux) after flashing, and then disconnect, you can then connect with the ide.

I think it is related to the state of the com/tty port after flashing...

If it the puck output getting displayed on your android phone, you can host the web page on github.io, and use web Bluetooth to communicate with the puck. You can then display information and send setting to the puck via the web page talking over web Bluetooth. Then you would not need to use the pi as a broker in between.

Didn't you update to use hardware flow control on the espruinoWifi? Doesn't that mean there would need to have the rts and cts pins wired too?