-
-
-
-
-
-
-
Christmas time is comin soon.
That's a good time to report actual status of Espruino on ESP32.- ESP32 tree in Espruino on github
- standard Espruino compiled and got it running (@nkolban)
- WIFI handling added (@nkolban)
- SPI compiled with Arduino Sources (@nkolban)
- interrupt handling for gpios, to support setWatch (@jumjum123)
- switch polling of console to interrupt driven handling (@jumjum123)
- one wire implemented and tested with DS18B20 (@wilberforce)
- I2C compiled with Arduino Sources and tested (@wilberforce)
- ADC and DAC running with new driver for specified pins (@jumjum123)
No drivers are available for I2C and SPI in esp-idf yet.
Therefore we have to live with Arduino sources right now.
Esp-idf is under heavy construction.
Sometimes even a simple call of a function changes its parameter sequence.Actual status of Espruino for ESP32 is
- available mainly for developer, it is extremly simple to build
- first docs are available on github under targets/esp32/doc
- needs testing, testing, testing
- waiting for driver for I2C, SPI, BLE, etc. etc. in esp-idf to replace Arduino sources
- PWM needs to be implemented
- expect surprises, like not linear ADC
- ESP32 tree in Espruino on github
-
Right now we have pins named D0 ..... D39
Is there an option in boards file or somewhere else, to have pins named like:
ADC1 pointing to D36, would be readAnalog(ADC1)
...
ADC4 pointing to D32
...
DAC1 pointing to D25
...
For ESP8266 there is something like that in jswrap_nodemcu.c
Following this idea in general we could have a class called pins, where pins.ADC1 = D36
Any other suggestion ? -
-
@Wilberforce, 0x100000 is start of save area, which is 16 pages, each 4096 bytes.
So startadresse is end of flash area (0x110000) minus size of your empty file. -
-
for first testing you can download from here Its latest version from my "playing with the chip". Source is available on github, pull request to Espruino is created and open for discussion. Stability(?), at least it starts and runs commands, http, pin, .... but its more or less a proof of concept.
I would recommend to build your own development area. Neil Kolban added some helpful docu under targets/ESP32/docu
flashing:
bootloader.bin to 0x1000
partitions_singleapp.bin to 0x4000
espruino_ESP32.bin to 0x10000 -
For a small project I'm searching a sensor to read a color pixel matrix.
Pixel map somewhere between 16x16 and 64x64 would be fine, color 2 bit each color is sufficient.
Speed is not a big problem, reading the matrix once a second would be the target.
Last not least, an interface for Espruino (I2C, SPI, serial) would be fine.
Just seen ASDN 5050 mentioned by Gordon, is there something like the ASDN 5050 with color info ? -
Reading the comments, there is a discussion starting "do we need 2 Espruino tasks" From my point of view this would be one option only to use multiple tasks. Mention the 2-core Espruino option in was accidently begin of a wrong question.
Writing this, I'm absolutely sure, if we can do 2 tasks running Espruino, there will be some guys using that, if we like it or not.Looking back to history, there was a time where so called mini-computers (mini not micro) have been as powerful as ESP32 is today. Several OS have been on the market and all of them supported multitasking. And there was a good reason for that.
Today we have this chip supporting multitasking, lets discuss how Espruino could support multitasking.
One big question is sharing data between tasks, queues and semaphores are a way to do this. Another question is task handling, and some more will come up.
Thats what I wanted to discuss, not "do we need 2 Espruino tasks". As I can see, my first post was misleading, sorry for that. -
Some days ago I got an ESP32 Dev Board. Based on Neil Kolbans work it was easy to get a first version of Espruino running. It lacks a lot of things, since Espressif is still working on SPI/I2C/BLE, ...
Anyway we have a new world for Espruino and this world supports tasks, queues and other nice functions.
First version of queue handling is already running- a seperate task polls data from somewhere and writes it to a queue
- in Espruino a function polls this queue for new data
Task handling is not that easy, there are some restrictions which hopefully will disappear with next versions. May be that time, we will be able to have 2 Espruino tasks running, one on each CPU talking to each other using queues.
Target is to have JS-commands like:
- queue.list()
- var q = new queue()
- q.assign(queue_name)
- q.newDataAvailable()
- q.readData()
- q.writeData(.....)
- ......
- task.list()
- var t = new task()
- t.assign(task_name)
- t.suspend()
- t.resume()
- ........
We would need a list of queues and tasks like {name,handle} for that. This could be an internal jsi-type function which would be called from other tasks. Or we could add function calls in jshardware.c returning pointer to global arrays.
This would be the first time, Espruino meets something like RTOS, therefore I would like to get some other thoughts before spending too much time walking into wrong direction.
- a seperate task polls data from somewhere and writes it to a queue
-
Take a look at this
It's a very very simple kind of handling files in flash.
Bad part of the story, its tested on first MB in flash only.
This is because memory mapping of flash to 0x4020000 is used. -
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. -
Thanks for hints,
downloaded sdk 2.0 as shown in travis.yml
After compiling there are some warnings like this one:libs/network/esp8266/ota.c:93:3: warning: format '%lX' expects argument of type 'long unsigned int', but argument 3 has type 'uint32_t' [-Wformat=]
Is there anything, I can get rid of those ?
-
-
See line 883ff in makefile, ESP8266 does not use GCC's lib
Some time ago we found out, lmirom from RTOS-librarys works with SDK1.4 and saves some memory.
On a long term this is a hack, may be SDK2.0 now has its own lmirom ?
@tve, is there a place to get SDK2.0, same way I got SDK1.4 from your server ? -
use RAM when it's needed only, good point.
Quick first test with changes:
typedef void(*JshEventCallbackCallback)(bool state,int exti); //changed by jumjum jshEventCallbacks[channel-EV_EXTI0](state,channel); //changed by jumjum
It works prefect, tested with SetWatch and Gesture itself(very early version).
Just got some angry eyes from family, so its better to stop this now and take care on infrastructure for vacations like Laptop, CamCorder, Radio, GPS, cellphone, several charger, SD-cards, Camera, .........
How could we live without any of this in previous millennium ;-) -
Hmm, understand.
Passing EXTI into a function, would this be adding (channel-EV_EXTI0) to calling callback in jshPushIOWatchEvent (jsdevives.c) ?Thinking loud:
I could add the list of parents to Gesture source, so that only guys using this have to pay the price (in bytes) ?
Or an array of internal parameters and replace internal structure with an entry in this array, which would make setVar and getFromVar needless ?Hmm, anyway, next weeks are reserved for family and vacations.
-
-
@gordon, thanks for the feedback. In my knowledge, this would be a first step solution and would solve my needs.
On a longer term, there are some questions, like what happens on something like clearwatch ?
Would it be a better option to change definition of jshEventCallbacks in jsdevices to a struct, having a JshEventCallbackCallback and a JsVar for parent (or something else, I cannot even imagine right now) ?
As far as I can see, there are only 5 locations, where JshEventCallbacks is used.
Adding something like set jshSetEventJsVar to set and an if-statement in jshPushIOWatchEvent which would add this to callback ?
I'm pretty sure, it is doable, but would it be helpful ?
Lat not least it would slow down, would this be acceptable ?
Is it possible to restrict a GPIO in board.py to support input (or output) only ?
Some of ESP32 GPIO's support only one direction.
Optional we could check this in jshardware.c.