Most recent activity
-
was checking this atom Atom X5-Z8350 vs Pi4 and found this
https://openbenchmarking.org/vs/Processor/ARMv7%20Cortex-A72,Intel%20Atom%20x5-Z8350
this is 1.5Ghz cortex-A72 vs 1.9Ghz Atom (Pi4 can be easily overclocked to 1.9GHz too, possibly even more)
I am surprised that cortex-A72 (=Pi 4) is not that bad compared with Atom Z8350, in average and in most benchmarks it is faster even on 1.5Ghz clock! -
so it is like @Gordon says, you have intel binaries - x86-64, so you should get aarch64 ones instead - they are avaliable
-
Wonder if my idea to use raspberry for compiling is doable.
for ARM definitely doable, for ESP maybe there won't be prebuilt gcc toolchain for xtensa?
exec format error is probably wrong binary type
try to run
file /home/nodejs/efeu/tools/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gccor
ldd /home/nodejs/efeu/tools/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -
Others suggested you could actually just use the Pi's own GCC (since it's ARM anyway) but I'm not sure if it's quite good enough for embedded.
debian on pi has gcc-arm-none-eabi which on latest buster version is this
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)so is reasonably fresh (?), then provision says
pi@raspberrypi:~/Espruino $ scripts/provision.sh MDBT42Q Provision BOARDNAME = MDBT42Q Provision FAMILY = NRF52 ===== NRF52 ===== ARM arm-none-eabi-gcc installedhowever when I just checked out Espruino and tried to build for MDBT42Q it breaks on
JSON PARSE FAILED for { "type" : "event", "class" : "E", "name" : "touch", "params" : [ ["x","int","X coordinate in display coordinates"], ["y","int","Y coordinate in display coordinates"], ["b","int","Touch count - 0 for released, 1 for pressed"], ] } - No JSON object could be decoded make: *** [Makefile:744: gen/jswrapper.c] Error 1 make: *** Waiting for unfinished jobs....it always builds few files and then gives this but next time it is building another couple of sources and still gives this same error
now tried building for PICO_R1_3 = stm32 and having same json parsing error, so is the tree broken now or do I perhaps miss some json related package?
-
When thinking about it more, on one side it would be nice to e.g. add your own button or LED to e.g. MDBT42Q and do
LED1 = new LED(D16,{inverted:true})currently those are only hardcoded.
On the other hand the easiest method with just exposing inverted flag I can still have BTN1 and D27 to be same object and when I disconnect the jumper on that E104 board to use the pin directly I could flip the inverted flag to use pin as ordinary pin in sane way - e.g. as CS pin and pull it low by setting it to 0.
-
This was added because beginners complained a lot about 'why does the LED go off when I do LED.set()' and so on... and you're the first person to complain the other way so far...
No, not complaining about this. This I would keep, but only this - inverting value. Not pull up/down. If you know what pin.setMode("input_pullup") means you can manage inverted flag and set it as pulldown yourself. beginners won't touch this, they will have their leds,buttons,motors already working. BTW are you inverting PWM duty cycle too?
It was quite a surprise to me that in board file I must set pull the other way than it is for real, e.g. here https://github.com/espruino/Espruino/blob/master/boards/NRF52832DK.py#L70 it is in fact set as pullup! here I would really expect to set it like it really is.
It's not that easy if we want to allow people do use digitalPulse/analogWrite/etc on a LED or screen backlight - which are all pretty common things to want to do.
Well , I don't know how hard it is to implement it. As for behavior - when using BTN1, LED1 object it should do the magic (with everything that makes sense for that type of object - digitalPulse/analogWrite), when using underlying pin directly it should not do this. That would be least surprising to me. E.g. I have one board (E104-BT5032A-TB) where buttons and leds are enabled by jumpers and are inverted, if I disable the jumper and use the pin on the header directly as is and refer it by pin number, I would expect the pin to be not inverted.
However we could negate anyway, and it makes sense to expose the fact the pin is negated via pin.getInfo
yes
-
Do you have other suggestions? If there's a better way of doing it I'd be interested.
Few ideas
- ifdef code and enable only if some pins are really negated in board file - you already mentioned it
- move this to common code if possible (?) so it is not in each port separately
- I am actually not sure what it should do and why and on what level this should be, is this mainly just for buttons and leds? So that in javascript code you can treat button/led in normal way - reading,writing, watching change? Will it work if the pull up/down are left alone and instead the negated flag would be visible flag on the Pin object (so you could even toggle it from js yourself on any pin?) because with such flag I'd left figuring out correct pulls on the user code too. So only value would be negated, not pull up/down, that is lot of complicated code. Also if only the BTN1 or LED1 would be negated but the underlying pin D13 not, it could also make the code handling 'normal' pins clear from this if Led and Button would be special object inherited from Pin. Then also the debouncing magic in setWatch in case of buttons would be more clear - watch on Button object would do it, watch on (same) Pin would not. Then maybe port specific code could drop it altogether and Pin and Led with this pin negation feature could be in common code.
So to sum it up I think making negated flag on pins completely invisible/transparent including pull up/down is too heavy and too much magic. Letting user know about it and possibly handle it could be better. An also maybe this should not be feature of the pin at all but something more high level - button, led.
- ifdef code and enable only if some pins are really negated in board file - you already mentioned it
-
Just an update about the WeAct board and negated pins - looks like stm32 port does not have support for negated pins. At least not in same way as nrf5x port.
For nrf5x there is runtime check forpinInfo[pin].port & JSH_PIN_NEGATEDand value and possible pull ups/downs are negated. I am not sure if this is actually good solution in NRF code but anyway there is nothing like that in stm32 code.
So I have extended the patch http://microco.sm/out/78xji to handle negated pins in get/set value but in NRF code there is more (pull ups, downs in get/set pin state)Anyway here is updated binary https://filebin.ca/5hFTUCKr4JA5/espruino_2v08.5_weactf411.bin where button and led works as expected - button skips startup code if held, LED is off at startup.
The question about how to handle negated pins remains, should the (extra) nrf5x code be copied to stm32 port? To see more start here https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L966 and search for JSH_PIN_NEGATED. Similar stm32 code is here https://github.com/espruino/Espruino/blob/master/targets/stm32/jshardware.c#L1036 - check methods
jshPinSetValue,jshPinGetValuealso visible on board file changes https://gist.github.com/fanoush/7553104fa7c8c596fe91f276d3f297fd/revisions is that there was other
invertedflag used for pin configuration (got it from other stm32 board files) but it did not work as expected (or at all) so I removed it and added the nrf5x style NEGATED flag insteadEDIT: fixed few more bugs and updated to latest
https://filebin.ca/5hG1r5OvrY9N/espruino_2v08.82_weactf411.bin -
Just a heads up that DK08 is $9.50 today (11.11. sale) https://www.aliexpress.com/item/4001224081207.html
There is also GPS Time app that can sync time from GPS on request.