-
As mentioned some days ago, I've created a simple dictionary for Espruino Extensions in github.
Some extension are there, mainly for testing. They are left over from some hacking months/years ago.
An interface to this is added in actual version of firmware tool.In a next step I would like to do something similiar for modules.
Options comin to my mind are- upload from local computer, that would support self written modules. This is an easy part and is already implemented in a not fully tested version
- use modules list from https://github.com/espruino/EspruinoDocs/tree/master/modules. This is a short list without minified files but with md files
- use modules from https://www.espruino.com/modules/ Thats a very long list with minified files but without md files. Would have to scan this list with regex, which is not my favourite tool. Anyway, would be my problem
Is there an better option ?
- upload from local computer, that would support self written modules. This is an easy part and is already implemented in a not fully tested version
-
-
-
Hmm, your feedback to userdefined C code sounds like "there is no market"
People with knowledge to do that will already have their own development.
Thats a good point.So lets go back one step. The idea of predefined C code sounds good to me.
I can imagine some reasons why you did not get lots of contributions- lack of knowledge how to built
- bottleneck for additional functions due to actual restrictions in size
- functions are not helpful for majority of users, for example who needs a Schmitt Trigger. On the other hand I would like to have lowpass, highpass, pid control, etc. etc.
- restriction to "must run on all boards", for example I've a full color P3 driver, which works on ESP32 only. some guys could be interested
- no "how to proceed" for plugins
Summary, I would like to start a first version of a registry. About 3 years ago I've created a github with my extensions https://github.com/jumjum123/EspruinoExtensions c files.
And never worked on that again :-( Lets give it a try.
I will create an interface to that into my firmware build tool, and remove upload for C files - lack of knowledge how to built
-
As mentioned in another chat, I'm just restarting a project to create specific firmware for Espruino.
It's in early state and will take some time.
Create specific firmware means- you only need a browser, no development tools on your computer
- select board
- set/unset definitions like USE_BLUETOOTH or USE_GRAPHICS
- remove functions, you don't need. Like eval to give an example
- add JS modules to firmware, Gordon already does this for some boards
- add your own source files (c-filesand h-files)
@Gordon already mentioned, that support of c-files opens a door for security issues.
AFAIK, these are mainly security issues for the server. One example is the use of
#include "/usr/passwd" in C-source
Ideas to bypass this problems are- build my own scanner to recognize
- search the internet for scanners
- load sources only from "secure github sites"
- remove the option for adding c sources, in my eyes the worst option
Please give comments/feedback/experience
Hopefully somebody has some knowledge around this. - you only need a browser, no development tools on your computer
-
-
@Gordon, just found the entry in forum. Usually I visit forum randomly, and watch specific part only. So this went through without being noticed by me.
And after searching by date, I also found the mail. It was sorted in "wrong" folder by google.
I'm sorry about that. Anyway, it would have been too late for me that day. Is there a restriction to send it that shortly ? Getting a mail in the morning for a meeting late afternoon is sometimes challenging.@Gordon, could you please explain your security concerns a bit deeper ? I've an upload which checks extension of files on client and stores everything in temporary folder. I will add check of extensions on server. Its an Ubuntu server, and I've to check permissions, so they are read/write by nodejs only. One of the next steps is to create something like a lifetime for temporary folder.
@wilberforce, as you assumed, I use provision to
- install compiler etc, one time only
- set variables like path or ESP-IDF to create a specific compile/make script
Install was done manually, so I'm not sure, do I still have correct/actual version ? For example, you are working on 3.1.3. I would like to recognize that and do an automatic reload. Any suggestion from your side ?
BTW, i checked 3.2 pre shortly, size of binary is grown one more time, and does not fit in partition anymore. Lets wait and see for release of V3.2 - install compiler etc, one time only
-
some short feedback.
- I've been waiting for connect info for last video chat. Got nothing (or didn't recognize ?) May be others had same problem.
- something like a list of topics from your side would be helpful. Usually, people are interested to listen and maybe ask questions about that.
- with other words, please present something first. You are leader of the gang. ;-)
BTW, I started again to get a firmware build tool online. Big changes to first one are
- use existing files instead of creating additional ones
- support more targets, wilberforce did a lot around travis, that I can use now
- support js source files
- better implementation of .....
Any idea how to get feedback/testing for that ?
- I've been waiting for connect info for last video chat. Got nothing (or didn't recognize ?) May be others had same problem.
-
-
@SergeP took a closer look to NEOpixel and created a new version.
Please see attached file.
And this is explanation from @SergePAfter FIFO maximizing everything works in my case. I've found that, as I wrote, there are two classes of high-priority delays (it may be other interrupts) which delay neopixel_handleInterrupt() call. One class is about 1 original buffer, so about 1,25us*64bit=80us, another one is about 4..5 times longer - 300...400 us.
Now I use full RMT buffer and it's enough to neopixel code work. But it is impossible to use pulses on pins at the same time. This was not possible before my changes, too. But it was possibility to fix that, while my code makes it principially impossible. -
Only a few pins are available for setWatch. Its checked with jshCanWatch in targets/ESP32/jshardware.c
Just checked with D12 and that works.bool jshCanWatch( Pin pin //!< The pin that we are asking whether or not we can watch it. ) { return pin == 0 || ( pin >= 12 && pin <= 19 ) || pin == 21 || pin == 22 || ( pin >= 25 && pin <= 27 ) || ( pin >= 34 && pin <= 39 ); }
-
ESP32 uses some firmware already on chip (ROM) and some precompiled libs for BT
I'm pretty sure, 22 limit is hidden there
In latest ESP-IDF- versions, some functions from ROM are moved to flash. This is one reason why size of binaries increased that much.
Not helpful for you (sorry), but at least you know why we have these, and other, limits -
You could try ESP32 WROVER board, which has additional PSRAM.
Right now it supports 320kb, and could be expanded.
See espruinoTask(void *data) in https://github.com/espruino/Espruino/blob/master/targets/esp32/main.c
Each jsVar takes 16 bytes, so 20000 jsVars are 320kb
To put water into the wine, I would still expect firebase is way too large for these small chips. -
ESP-IDF itself creates different tasks for wifi, bluetooth etc.
Espruino port for ESP32 uses 2 tasks, one for Espruino itself and 2nd for uart console, see targets/esp32/main.c
There has been a first question/idea from @Wilberforce to move some of those tasks to 2nd core.
Don't know if somebody has experience with that.Splitting Espruino itself into several tasks would be (IMHO/AFAIK) a complex rebuild.
Running 2 Espruino tasks, one on each core, hmm, memory is too small for that.
One could think about supporting SPI, I2C seperately, but again, this would be a complex rebuild.Some months ago, I asked in ESP32 forum for experience using both cores.
At the end, feedback was more or less a theoretical description, how powerful it would be for example for graphics. No feedback about experiences in own projects.
Looks like 2 cores are not (yet?) used in real applications. -
The idea behind speedy is slightly different.
forEach is running with one callbackFn only.
Idea is to combine different functions with a default function.
Thats close to your changes to shiftOut.
in this example we combine a simple console.log with pin.set/resetfunction fill(){ arr = []; arr.push({callback:en.reset.bind(en)}); arr.push({callback:console.log.bind(console,"qwertz\n")}); arr.push({callback:en.set.bind(en)}); arr.push({callback:console.log.bind(console,"asdf\n")}); arr.push([1,3,5]); arr.push("abc"); } x = console.log.bind(console,"z:"); function speed(n){ fill(); if(!n) n = 100; var t = getTime(); for(var i = 0; i < n; i++) E.speedy(x,arr); console.log(getTime() -t); }
I would not say, this is standard Javascript ;-), it could be helpful, but is it worth it ?
-
-
@Gordon I've checked with
shiftOut.bind(null,[R2,G2,B2,undefined,R1,G1,B1],{clk:Clock}); .... Graphics.createArrayBuffer(64,32,4,{interleavex:true});
setPixel, drawLine work fine,
but fillRect, drawRect, clear, drawCircle, fillCircle don't. Some pixel are at wrong places,
Data in buffer is wrong, easy test isgr = Graphics.createArrayBuffer(64,32,4,{interleavex:true}); gr.setBgColor(1) ; gr.clear(); console.log(new Uint8Array(gr.buffer,64,64));
Rotating of Ellipse, hmm no idea, I've to check. But Christmas is coming, and family is coming, ....
-
-
-
@Gordon please see attached zip file.
I've combined Graphics.ellipseDraw/Fill, panel driver and example in JS.
File changes.txt in zip file gives some information about changes -
-
I've checked your version and it takes about 0.16s on ESP32.
I agree, ESP32 its not the fastest on earth.
Anyway, this results in a black led-panel for a remarkable time, before new data is available.To get a better idea what a setPixel driver in C could be, I created a version for testing. All together it is about 25 lines including initialization. Switching to this driver is done by adding panel:true to config of createArrayBuffer.
Wow, now a clear() takes less than 2msec. And I was able to create some kind of simple animation using graphics class.
I wonder, how we could add this to Espruino. It is specific for these kind of boards (P2.5,P3,P4,P5). It is not as specific as Neopixel, where we need implementation for each board. So it would be available for all boards.My ideas behind using this panels are things like:
- replacement of open/close panels (used in shops)
- display simple processdata
- all kinds of special boards, you can see in shops
- art, just created a simple algorithm to create Mondrian like images ;-))
- replacement of open/close panels (used in shops)
-
During my test with a driver for LED panel, @Gordon added a very nice speed up function.
This looks very good, and I gave it a chance to become a seperate function. In first test, it even speeds up bit.
@Gordon, usually you have some good ideas. Could this be a starting point for a kind of prebind, not saying precompile ?void jswrap_espruino_speedy_callback(int val, void *data){ JsVar *fnc = (JsVar*)data; JsVar *value = jsvNewFromInteger(val); if(jsvIsFunction(fnc)) jspExecuteFunction(fnc,0,1,&value); jsvUnLock(value); } void jswrap_espruino_speedy(JsVar *arrayFunction, JsVar *arr){ jsvIterateCallback(arr,jswrap_espruino_speedy_callback, arrayFunction); }
-
During my test for this LED board, I tested a driver using setPixel in javascript.
At the end it turns out, that this is faster than a converting step (see above)
And it does not waste more memory.
Even being faster than expected, I would like to add setPixel for LED Panels in C. These would be only a few lines, but I've no idea, where and how to add.me.setPixel = function(x,y,col){ var adr = ((y & 0xf) << 6) + x; if(y>15) ledBuf[adr] = (ledBuf[adr] & 0xf8) + col; else ledBuf[adr] = (ledBuf[adr] & 0xc7) + (col<<3); };
quickly checked and the result is:
For now I would start with master/devices and create a *.min.js on the fly
If no doc is available, we could show source instead.
Update:Sorry, misunderstanding from my side
Looks like I've to combine both github directorys to get most correct list