Espruino on ESP32

Posted on
of 3
/ 3
Last Next
  • I am lucky enough to have received an ESP32 development kit. The ESP32 is a new model of the ESP8266 type device from Espressif ... see:­re/esp32/overview

    The core differences between it and the ESP8266 are:

    • Dual core vs single core (240 MHz vs 160MHz)
    • 520KB ram vs ~80K ram
    • 16MB flash vs ~4MB flash
    • Hall sensor (magnetometer)
    • 32 GPIO including 3 UART, 3 SPI, 2 I2C, 2 I2S, 12 ADC, 2 DAC, PWM .. more
    • WiFi and BLE

    It is still very early days in the release cycle of this device.

    My question to the community relates to interest, design and execution of a port of Espruino to the ESP32. Ideally, I'd like to think that there would be desire for it. I'd also like to suggest that we make it a community project including design choices, implementation choices, coding tasks and more.

    What I'd like to suggest is that if there is interest, we get permission from @Gordon to create a new board in the master Espruino Github (possibly called ESP32) and start building it out from there and using that as the core hub for our work. The most important thing being that any code changes that might be outside of the ESP32 target do not in any way negatively affect the other boards.

    My hope is that with so much more RAM available to us, the scope of our JavaScript applications could be so much larger and allow us to take advantage of other functions.

    If there is interest, lets see if we can't start communicating with each other to introduce ourselves and start a plan.

    I fully realize that the availability of ESP32s is limited right now but a thought I have is that I can take my ESP32 board, a Linux build environment with networking and make that available as a virtual machine. In principle, you should have access to the serial ports etc etc. I'll also set up some WiFi access points for testing with REST servers and web servers (and more as needed). That way you wouldn't have to wait for an ESP32 for yourself and we would have a consistent "ready to code" build environment at our disposal.

  • There's another thread on this as well, with some of my comments:­292525/#comment13203153

    But yes, I'm happy for whoever wants to to have a go at this. Just start a new ESP32 branch in the Espruino project (not a new repo). I just added a new ESP32 label, and you can tag issues with that (it's easy enough to search for only issues with certain labels).

    Please try to document in your code, or in the repo itself (as .md files) wherever possible though. Last time we had wikis and documentation that was totally separate from the repo, and it very quickly became outdated and had to eventually be removed because we had a few posts from people who'd got confused by it.

  • And yes, as long as it doesn't mess anything up I'm happy having it in master. I think initially the Makefile's likely to start getting even more insane than it currently is, so a branch might be better until it calms down :)

    ... If anyone wants to use this as a reason to split the Makefile out into per-target (STM32/EFM/ESP8266/NRF/etc) files that get executed I'd be super happy :)

  • Having reviewed earlier the specs, I see quite some potential in this 2 core setting. Foremost it gives relieve on the issue of the 3 main tasks on single core:

    1. wifi/communication
    2. Local (sensor) low level hardware/appliances/port event handling,
    3. js execution

    Integration of latter two is already included in Espruino, which makes it just a 2 main tasks operation and a good match for 2 cores.

    Having more resources available - memory and cycles - is convenient for application development but is heading in a different direction as Espruino - at least - for the past was - and still is - going for: smaller and less power demanding at runtime (even though it included some memory increase).

    Wifi always needs significant power, one can say... but the new Espruino Wifi alreadt provides both wifi and low power Espruino in a decoupled way. The new ESP32 device can not go that frugal.

    Giving ESP32 a shot and see where it leads to is for sure worth a try... and should even include a slimming down of the ESP32 infrastructure (OS) to a minimum in favor of 'the Espruino side' of the overall implementation. Latter would at least stay true to the original spirit of Espruino: keep it simple and easy to use, all through JS!

  • I would love to see Espruino running on this bad boy!
    The specs of the ESP32 are epic... and I hear they're gonna be cheap and plentiful once production gets going.

    The dual core looks like a real killer feature here - am I correct in thinking that that will mean that the WiFi will be done on one core, so we'll be free from the watchdog's leash on the other?

    I'd be happy to throw some beer money at Neil Kolban or the other greats of these here parts for making the ESP32 drink javascript. :-D

  • I'll be happy to help where I can. The esp8266 has been a bit frustrating fighting against heap and rom firmware sizes, so having those constraints removed would be great.

    It would be even better if Gordon produced a board with the module, so that it would not be a second class citizen... And be a part of the espruino family.

  • Sounds like an interesting project.
    I would like to help. In the beginning this will mostly be limited to listen to the experts.
    What would be the best starting point, is there any documentation you would recommend ?
    BTW, I've a service running for compiling Espruino Firmware. It has some options to make is easy to use your own changes/extensions. There are already some changes in makefile to allow more customizing, see lines 66 to 78 in makefile.

  • I would suggest the following ... this is going to be a long post ... sorry for that ...

    I'd like the project to be 110% open with no private repositories and complete and open communication between us all. We bring different skills, experiences and interests to the table. Whether one is a kernel C programmer, a JavaScript tinkerer, a hardware designer or just a consumer of the eventual Espruino on ESP32 ... we all get to play. There will be opportunities for folks to write tests, play with builds, write up notes, guides etc etc. So no-one should feel left out. In addition, if one is merely "interested" in an area, we can make time to chat, discuss or write it up. There need be no hidden knowledge and the more we share, the more eyes on the project ... the better.

    The project is a game in two halves. We start with the excellent code and architecture which is Espruino today. This code base has excellent support for alternate platforms (ESP32 is considered a platform here) and allows us to create "code" that is platform specific while the majority of the Espruino iceberg is platform independent and hopefully needs not be touched for an ESP32 port.

    The second half of the story is the new ESP32 platform. As I study this device, I find that the documentation is still being baked. As such, there is going to be much to learn in this area and there are no experts we can lean upon at this early time. Much of what was learned from the ESP8266 port can be leveraged ... but also ... much is new. It is appearing unlikely that Espruino for ESP8266 will "just compile" on ESP32. The underlying framework has changed to a real time operating system (FreeRTOS) and the networking APIs changed to be the "sockets" API.

    The runtime libraries and compilation procedures have also all changed.

    Then there is the elephant in the room ... availability of ESP32s. We don't know how quickly they are being produced nor their prices. They will eventually come down to a few dollars each (guess) but availability and price may not reflect this in the short term. Thankfully, I have an instance and we can "share it" over the network when needed.

    What this says, is that the project can be broken down into a wide variety of factors and tasks. Does anyone have any opinions or recommendations on how we manage and track these? The source code control system will be a branch in Espruino Github. That way the source changes and issues we raise will be recorded in history for the project ... but what should we use for discussions and design plans? Maybe a Wiki page at Espruino Github? Maybe gitter chat? Maybe there is some other distributed project tracking mechanism available to us that one of us might recommend.

    As for desirable skills and reading ... some of the following would be ideal:

    • C language programming - Espruino is written in C
    • ESP32 APIs and architecture - the ESP32 IDF , the ESP32 tech docs.
    • Espruino from a user's perspective
    • Espruino internals (as found on Github)
    • The Espruino build system
    • Using Github
    • Using Doxygen
    • Project guidelines, standards and overall conformance
    • BSD Sockets API
    • FreeRTOS API

    Again, knowing all of the above are not required ... a big project can be broken down into bite sized pieces and learning grows.

  • A community member suggested a gitter stream for ESP32 development/design discussions. This seems like a useful idea. A new gitter stream has been created called:

    This can be used to chat and record discussions on the ESP32 port and can serve as an informal history of chats we have had.

  • Ok, sounds good!

    In that post I linked I mentioned that it might be preferable to aim to target FreeRTOS first, with as little ESP32 specific stuff as possible.

    This means that development can get started even without ESP32s, and will hopefully make it easier to port to other devices as well. Hell, you might even be able to find a board that has a debugger on it :)

    There are also some biggish changes to Espruino that would really help (removing the event queues), and doing that in a less ESP32-specific way would make it less of a hack.

  • For reference, I think this the last time espruino with freertos was attempted:­276160/#comment12578162

  • Status report:
    There has been a goodly amount of technical chatter and status updates in the Espruino/esp32 gitter stream ...

    The good news is that we have a proto-type build of Espruino running just fine on the ESP32 with lots of room to spare. We have been taking a lot of notes as "we have hacked". Now it is time to put the proto-typing and loose testing aside and start again. The plan is to do as Gordon correctly desires and create a new branch for ESP32. In that branch we will build out the support for the "ESP32" as a new board but do so methodically and with documentation in the form of markdown to capture design notes, ESP32 specific environment setup (for building) and other goodies. To get us started, I'd like to solicit assistance from folks who have confidence in Git and Github. I know the theory but because we are working on a live system and as a community, it is always better to engage those who have experience. Discussions on this in the gitter stream.

  • Where are people getting their dev boards?

    Adafruit now has a waiting list, and the lopi (with micro python) shipping to new Zealand is £38 pounds!

  • @Wilberforce There doesn't seem to be any supply at moment. I passed on the $15 Adafruit dev board a week back because of the shipping costs, but sort of wish I hadn't now. I haven't been able to find just the ESP32 (no dev board) anywhere either, and it seems the dev boards are now on preorder.

    Do you have a link for the lopi? I thought they where just fulfilling the kickstarter at the moment.

  • Thanks @Frida, I will check that out.

  • After I found the pin that sets the lopy in boot mode, then Espruino is running.

      "VERSION": "1v87.252",
      "BUILD_DATE": "Oct 19 2016",
      "BUILD_TIME": "22:13:30",
      "GIT_COMMIT": "5a0ccacaa75b3f49621ed8517ee8eedf952bbf3­b",
      "BOARD": "ESP32",
      "CHIP": "ESP32",
      "CHIP_FAMILY": "ESP32",
      "FLASH": 0, "RAM": 524288,
      "SERIAL": "240ac400-8c2c",
      "CONSOLE": "Serial1",
      "EXPORTS": { "jsvLock": 1074608440, "jsvLockAgainSafe": 1074608576, "jsvUnLock": 1074611212, "jsvSkipName": 1074631336,
        "jsvMathsOp": 1074642948, "jsvMathsOpSkipNames": 1074646172, "jsvNewFromFloat": 1074625952, "jsvNewFromInteger": 1074625864, "jsvNewFromString": 1074624360,
        "jsvNewFromBool": 1074625924, "jsvGetFloat": 1074636856, "jsvGetInteger": 1074630136, "jsvGetBool": 1074637548, "jspeiFindInScopes": 1074656752,
        "jspReplaceWith": 1074656500, "jspeFunctionCall": 1074666828, "jspGetNamedVariable": 1074658348, "jspGetNamedField": 1074658736, "jspGetVarNamedField": 1074658844,
        "jsvNewWithFlags": 1074623976 }
    ={ "free": 4976, "usage": 24, "total": 5000, "history": 4 }
  • Hey @Frida. Looking at the link, you have the LoPy which can also be a LoraWan hub? I know there's been some discussion on here about LoraWan modules - is the hardware on the chip compatible with this work?

    There's also a WiPy on the website, which is built on ESP32 too, just $10 cheaper. I was impressed with the range figures they cite. I don't see 1km range advertised as part of ESP32 chipset specs, so would you know if this range assumes it's part of a LoraWan setup, or is it something they've added on the board which means we can expect a wifi access point or station to have this range?

    Great that you've got it running too, and I've no doubt I'll ask you which pin set flash/boot mode at some point :)

  • The hardware are non disclosure, the same with the software.
    The same goes the wipy2.0.
    About the range, I don't know anything.
    It was only javascript I had running, there was no network, or io, so it can be a hard work to figure out, let alone the lora thing.
    I'm new to all this stof, so I am moving slowly forward.
    If you don't want to use micropython, you will be better off with other board's.

  • The SyPi version comes out at the end of the month. This uses the sigfox protocol for very long distant (limited to 12 bytes every ten minutes). This next work is getting rolled out in New Zealand so I'm keep to get one of these boards.

  • The ESP32 dev board is back in stock at adafruit:

    68 or so in stock.

    For me the international postage offered shipping of about $US15 was more reasonable than the UPS. I added a pi zero and bluetooth modules so my order too - so that when the puck is out I'll have a bluetooth USB for one of my pi boards

  • How about the SparkFun ESP32 Thing for $20...

  • @CanyonCasa

    Looks like that is on back order...

    My order for adafruit has shipped - yay!

  • @Wilberforce, thanks, just seen this but looks like they are gone again. I think that's the way to do it though - get some other bits to make the shipping easier to palate..


    ESP32 WiFi-BT-BLE MCU Module / ESP-WROOM-32
    PRODUCT ID: 3320

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Espruino on ESP32

Posted by Avatar for Kolban @Kolban