Search results for:

Sorry - this stuff is in flux at the moment. I have created a new branch to resolve the issues, then will push once all the testing is done. This branch updates the tool chain and solves all the issues you are seeing.
I then have the task to merge the two branches into master...

Can you wait a bit longer?

If it is firmware you want to try with Ble compiled, I can provide a link for that.

I've got a plain build with v3 and 4000 vars booting. Please see the github post above.

Next step is to update the build tools so this can be part of master, then look at bring in the Bluetooth

At this stage I still can't get a build running, as it's expecting the psram, and that not available on the standard boards. I need to get the build working with a standard board and v3 before we can move on...

I’ve started an issue page here - it’s probably best to track there.
https://github.com/espruino/Espruino/issues/1387

I have done a pull request on the master branch which updated the compiler. This is done in the provision script.

Will add more answers to your questions today.

@Gordon

I had a chance to try it - the 64 byte buffer works a treat on the esp32. The upload is so fast that if you blink you miss it, and that was pulling in 3 modules!

Your right - the ota stuff was never completed.
My two cents worth... this is a possible plan

1. Make a partition table to use for BLE and non BLE
   
2. Update espurino build tools - add a espv3 branch and get that working
   
3. Add an espv3 branch to espruino and get that building against the build tools branch
   
4. Once this is working, this can be pulled into master
   
5. Look at merging the esp32 branch
   
   

At this stage I'm not sure if the esp32 ble branch builds if the BLE Makefile flags are off?

I believe we should offer a build without BLE, as the increased RAM usage and power requirements might not suit everyone.

Perhaps it can be one firmware with the option to turn BLE on from JavaScript?
Or the other options to offer two firmware - one with BLE and one without?

How does this sound?

@Gordon

Thanks for the hint. I'll give that a try and if it works out ok I'll do a pull request.

@jugglingcats

Thanks for posting.

@jugglingcats

Thanks. I actually added an option on my local CLI, -s --serial-block-size. I can send you a pull request if useful. I found that on the ESP32 128 works well enough.

I would like to look at what is involved with this, as I need to use throttle on send when using the linux espruino build on telnet on the web ide. If throttle on send is off:

New interpreter error: FIFO_FULL

I would like to get an idea about where to increase the buffer size to 128.
When throttle on send is used, it is overly throttled, so would be great to be able to tune this.

Thanks.

Try changing the flash mode from qio to dio.

I need to use dio on the nodemcu board I have.

Read up on how require works and how the save function works.

@mfgea

You might want to look at the Linux compile for espruino. It allows you to run on the same code as the physical boards.

I guess you are on windows? If you are on 64bit windows can you can run the WLS (windows Linux subsystem) to get the environment.

I think you might be using a different version of esptool.py.

4M = 32 mBit so you could try 32m-c1

Have you considered using a puck? You might have enough io pins and it has the coin cell as is already round like a watch?

I see hashlib is still there - does that take much space?

https://github.com/espruino/Espruino/blob/master/boards/ESPRUINOBOARD.py#L38

I suppose people might be using that too!

@Gordon
The esp8266 build only includes the Sha functions - and not the complete library - so that is smaller, so there a possibility that might fit?

It seems that making clearInterval(undefined) throw an exception

Seems like a clean solution.

As you already have
graphics = require("SSD1306").connect(I2C1, initGraphics, { height : 64 });

You can get rid of your oninit() that calls load module.

Does it depend on the specific board -- are some more stable than others.

I think the powersupply has a lot to do with it.

at the command prompt dump().

@Will
I guess you are not using the web IDE then - this pulls in the required modules and uploads with your code on send, so you don't need to explicitly load the module.

I've pulled the ESP32 and attempted a compile. It errors out with:

xtensa-esp32-elf-gcc: error: unrecognized command line option '-mfix-esp32-psram-cache-issue'

make clean && BOARD=ESP32 RELEASE=1 make
Cleaning targets
Generating platform configs
Generating pin info
Generating JS wrappers
WRAPPERSOURCES = src/jswrap_array.c src/jswrap_arraybuffer.c src/jswrap_dataview.c src/jswrap_date.c src/jswrap_error.c src/jswrap_espruino.c src/jswrap_flash.c src/jswrap_functions.c src/jswrap_interactive.c src/jswrap_io.c src/jswrap_json.c src/jswrap_modules.c src/jswrap_pin.c src/jswrap_number.c src/jswrap_object.c src/jswrap_onewire.c src/jswrap_pipe.c src/jswrap_process.c src/jswrap_promise.c src/jswrap_regexp.c src/jswrap_serial.c src/jswrap_storage.c src/jswrap_spi_i2c.c src/jswrap_stream.c src/jswrap_string.c src/jswrap_waveform.c libs/filesystem/jswrap_fs.c libs/filesystem/jswrap_file.c libs/math/jswrap_math.c libs/graphics/jswrap_graphics.c libs/network/jswrap_net.c libs/network/http/jswrap_http.c libs/network/js/jswrap_jsnetwork.c libs/network/jswrap_wifi.c libs/network/esp32/jswrap_esp32_network.c targets/esp32/jswrap_esp32.c libs/network/telnet/jswrap_telnet.c libs/crypto/jswrap_crypto.c libs/neopixel/jswrap_neopixel.c
DEFINES = -DGIT_COMMIT=46d6a12 -DNO_ASSERT -DRELEASE -DBUILDNUMBER="40" -DESP_PLATFORM -DESP32=1 -DUSE_DEBUGGER -DUSE_TAB_COMPLETE -DUSE_HEATSHRINK -DUSE_FILESYSTEM -DUSE_FLASHFS -DUSE_MATH -DUSE_GRAPHICS -DUSE_NET -DUSE_ESP32 -DUSE_TELNET -DUSE_CRYPTO -DUSE_TLS -DUSE_AES -DUSE_NEOPIXEL -DESP32 -DEMBEDDED
CC libs/compression/heatshrink/heatshrink_encoder.o
xtensa-esp32-elf-gcc: error: unrecognized command line option '-mfix-esp32-psram-cache-issue'
make: *** [libs/compression/heatshrink/heatshrink_encoder.o] Error 1

So it looks like a new tool chain is required.

@jumjum Are you using ESP-IDF Pre-release 3.0-rc1 ?
https://github.com/espressif/esp-idf/releases

Shall I start an issue on git hub so we can continue this conversation there?

It doesn't look like Travis has run against the build - I think that happens when a pull request occurs. I think it will break because the dependencies will need to be updated in the build tools. Might need to do an esp32-ble branch there to check against.

@jumjum - I see the sdk config changes - is this for ESP-idf 2.1 still?

Firstly, well done @JumJum, I know that is has been a mammoth task to get this far!

At the moment there are dependencies that would also need to be added to the espruino build tools... for example there is a new partition.bin, however I think we can make one partition that could be used for both, as it just makes the firmware partition bigger, and we could get rid of the ota partition as that is not implemented (it's a good idea in principle but not sure about the practicality- that is a different issue). The ble libs might also need to be added, I have not yet tried to build this. If I get a chance over Easter I might be able to do a pull and see what happens.

I'm not too keen on dropping the number of vars in the esp32 normal build. In a conversation I had on gitter with @jumjum I don't think it has yet been tested with the Bluetooth turned off in the Makefile.
However, @jumjum I understand has made this work using Malloc for the jsvars, so perhaps it can detect which build and allocate for:
Wifi only
Wifi and ble
Wifi and ble and psram.

For example at the moment there are changes to main.c that could have conditional includes and some of the intialisation code could be in conditional includes.

I'm not sure how much more memory the ble stack uses, and if it only uses the memory when it is turned on. If that was the case we could have a run time switch to turn in on just one build.

Gordon, what is the best way to handle this - have two board files - one with wifi and one with wifi and ble? Is there another board that handles things like this that way? I know for the esp8266 there are two builds, one for the 4mb flash, the other for 512.

If you want to use the arduino ide - your are in the wrong forum.

This is for espruino JavaScript, rather than compiled c.