Most recent activity
-
Hi Gordon! Thanks for the reply.
That's a really good point ─ I should've just made the
returninside the app file instead of forcing the Espruino to copy the whole code into RAM to concat a string on the end of it! Also your point on defining vars in functions instead of in the module-wide scope is a good one to take on board too.The changes shouldn't be too hard to implement ─ after all, my IDE also does a lot of work to ensure safety when encountering
whileandforloops so that an infinite loop doesn't happen (otherwise, an error is thrown/displayed). The same has been applied to the simulator, seeing that web JS is also single-threaded! I think that building the string on the IDE side is easy to do but really effective at freeing RAM as you say.I've heard that some people have connected an SD card reader to their Espruino. I think that's a great idea providing it fits into my little 3D-printed unit! I'm sure it'd make it easier to copy over app code from devices that don't support Bluetooth, too.
As for the idea of a Pixl.js V2, that would be awesome! I love the idea of that extra flash and memory space... It'll be cool to see what others in the Espruino community do (and I'm sure I could implement a few extra features into my OS 😉)!
Having bought 3 Pixl.js boards in total (one for me, two for some friends of mine), I may have to wait a bit before I consider buying the upcoming Pixl.js V2 so that I can give my wallet a rest, but it's certainly something worth purchasing!
Thanks for the help so far,
-James. -
Sounds like a good idea! I originally read this thinking probably not, but when scouring the internet, it could be possible...
LVGL has the following system requirements that could be a make-or-break deal:
- Flash minimum 64 KiB, recommended 180 KiB
- Memory minimum 2 KiB, recommended 4 KiB
With the Pixl.js (which would be ideal given that it has a display), it's probably not possible: iirc you're given around 40 KiB to play with when the Espruino firmware/interpreter is installed. With some of the non-Bluetooth boards, I believe that they have a much higher spec, so it probably could fit on a few of the other Espruino products.
As you say, you'd have to port the code over to Espruino, which would require quite a lot of effort since it's probably a top-down rewrite of over roughly 383,002 source lines of code (according to a Chrome extension I installed for GitHub), so pretty big task. By no means impossible though ─ LVGL would only make up around 14% of the Espruino source code if both codebases were merged!
I admit that I'm not an expert at writing C myself (more of a JS guy ─ I've only written a bunch of small C programs!), but it sounds like an interesting project for those who have more experience at C. Defo a pl that I want to learn since it's so interesting, anyway!
One thing that would work is just using Espruino's own UI library ─ I mean, you can't go wrong there! I haven't used it myself (I implemented my own basic UI library for a project I've been working on), but it seems to be somewhat powerful given the limitations of the Espruino hardware. It works on the Espruinos with screens, and that includes the Pixl.js if you have one, as well as some of the other boards.
Hope this helps!
-James. - Flash minimum 64 KiB, recommended 180 KiB
-
Hello! I'm back (after continuing to not break my Pixl.js)...
After about a month of development, I've been creating a project with my Pixl.js board which I'm pretty proud about, though there's a small (but currently not-a-big) problem in that the file size in my
buildfolder (bearing in mind that it's all minified using terser) is about 26.7 KB, so it's getting close to the 40 KB limit! I don't expect there to be much more to write any time soon (my project's pretty complete, as far as the Espruino code goes), but it's something to consider.A bit of background: So yeah, my project is basically an educational OS/environment where people can write their own 'apps' with our IDE, using our API, in JavaScript. The code's minified (again, using Terser) before upload, which is a big bonus considering that one may have a few apps installed and minification definitely reduces the file size. The only problem that remains is if you want to write a more complex app, you run into the high chance of crashing the device the bigger your code gets. A ~1 kb minified app with around 5 numeric vars, 1 bool var, and a couple of ~30 char strings (in some test code/minigame I made) has previously caused the device to crash (not good!).
If you must, the code's here: https://github.com/NanoPlay/os (The photo in the readme will give you a good idea as to how my project operates.)
The problem: My problem is about RAM. How can I optimise using
evalto 'open' these apps? The current architecture makes a call toevalonce it has read from an app file stored in flash, and then retrieves functions that were instantiated in thatevalfor processing later. This pseudocode will explain it a bit better:class AppLoaderScreen extends Screen { // A component of my UI library which enables multi-screen/page navigation constructor(appCode) { // When the app is opened this.appFunctions = []; // Contains start function, followed by loop function this.appFunctions = eval(appCode + `; return [start, loop];`); } onFirstRender() { // When my internal UI library starts rendering the app screen this.appFunctions[0](); // Make call to start function } onTickRender() { // When my internal UI library renders the app screen from setInterval this.appFunctions[1](); // Make call to loop function } }The actual implementation of my app loader/runtime functionality is here. Specifically, the
evalis on line 145.Enough of my code now! Are there any general optimisations that I can do to improve the memory so that there's plenty of free space for users who wish to write their own relatively large apps? Bearing in mind that my project's use case is kids/beginner programmers, so I don't expect there to be too many colossal projects (otherwise, they should move onto getting a Pixl.js/Arduino/removing my OS altogether if they want the free space!).
Also, one thing that is probably a no, but with regards to the hardware (and specifically the nRF SoC), would there be any way to 'upgrade' the RAM and storage as a simple task of directly replacing/desoldering the nRF52832 and putting in a higher-spec chip (if any)? Then, I would think it's just a case of flashing the Espruino firmware onto the new chip, right? The nRF52833 would easily double the RAM (and the nRF52840 could double the flash and quadruple the RAM!), and I assume it'd just be a case of rerouting some of the PCB traces and then fabricating a PCB that accommodates the pin locations on the aforementioned chips. I'm also wildly guessing the Espruino firmware has some way of detecting the RAM size, and that the chip architecture is very similar across SoCs...
I do admit that I am by no means an expert when it comes to hardware, though! I'm probably quite naïve with respect to the hardware architecture of the Pixl.js board.
Any help with optimisation would be greatly appreciated (I've already tried to implement some of the optimisations on the Performance Notes), but if not, it's not the end of the world! There's a lot to unpick (including my bonkers idea/question at the end there), so sorry in advance if this is quite a long-winded post (probably a book at this point...)!
Thanks,
-James. -
Hi Gordon,
I was using the Chrome Extension, as well as the build from my PR on GitHub. I don't know how long ago the Chrome Extension was updated, but I changed the code upload mode through the settings dialog.
I think the issue was to do with the board running out of flash storage? I had a lot of code on the board at the time, and I only had around 2-3 KB left. I've since made the code much more efficient and ran a
require("Storage").eraseAll();! I discovered the board went into this state when it runs out of RAM or flash (can't tell exactly) whilst uploading a big (> 8 KB) file. I believe that the SELF TEST mode now works correctly now that I've freed the memory!-James.
-
- 6 comments
- 1,804 views
-
Update... I managed to reflash a new copy of v2.08 back onto my Pixl.js through the DFU mode of the nRF Toolbox app, and I've managed to get going again! I eventually got to the point where the progress bar actually moves on the app and shows a status percentage, instead of it just saying 'Uploading...'.
Upon auto-resetting after the update, the board doesn't execute my reset-run code, and so I can now fix my dodgy code once again 😅 The terminal then shows
-> Bluetoothto tell me that my endeavours were successful.Note to self: Never set the IDE to the 'Direct to Flash (execute code at boot, even after 'reset()') - USE WITH CARE' mode! I find it weird that there's this option, when the similarly-named perfectly normal 'Direct to flash (execute code at boot)' option works just like that one in that the code still runs after reset. Less dangerous though, from what I can see.
Also top tip, just keep trying to do a firmware update via the DFU, because you could get lucky and the transmission might not actually fail for once.
Still very confused as to why it didn't want to go into hard reset mode... Probably is a bug or something.
Thanks to everybody on this thread who helped!
/me pats self on the back
-James. -
Seems to always advertise in my Bluetooth unpaired device list as 'DfuTarg'... Even when I've powered off both my phone, laptop and Pixl.js and turned them all on without holding down BTN1 to go into the bootloader
Though on my laptop (which is a Chromebook) shows 'No compatible devices found' when the Bluetooth pairing dialog shows up in the IDE
I can't actually connect to it though; using an app on my phone to flash a new firmware copy never works since it hangs when trying to connectNevermind, it seems to be copying now! Must be a one-in-a-million chance...If anybody knows how to fix this, please let me know.
-
Also, firmware version v2.08 if that helps!
Yeah, it's certainly a lot! Though as you say, the code may be quite modular, and so probably only the code that talks to the hardware would need to be changed a bit.
There's certainly a lot of files in their codebase, and I'm taking a guess that some of them are related to driving/controlling the hardware peripherals, and then other parts are just code that interface with the hardware-controlling code ─ much like a Hardware Abstraction Layer, or HAL, found in modern operating systems.
Like you, I don't know about the internals of LVGL, but just making an educated guess here! After all, LVGL is designed for a large range of devices ─ after all, their demos page on their website runs all of the code on the browser and that's a much more different architecture than embedded, so I'm sure that they've made their code so that it works practically anywhere. Seeing that both Espruino and LVGL are written in C, it should be possible to somehow merge the code, and then on the Espruino side of things, expose some of the LVGL API to the JavaScript engine for use in your JS program.
-James.