Most recent activity
-
Thanks! I've actually done a bunch of this myself already - so please hold off until I say I've pushed my changes as we might end up duplicating work.
I vaguely remember this coming up, but IDF 5 has changed a lot of the network handling stuff, so even though I seem to have got a lot of stuff building, there's going to be a big chunk of work there getting that through.
-
if you just do a
BOARD=BANGLEJS RELEASE=1 makethat's enough to build bootloader+app+softdevice in one, so you just upload the final fileTo install JS, you have to do that from the app loader - just "install default apps". On BJS1 there's not enough flash to store a 'factory reset' image like we do on BJS2
-
Ok, great! Thanks for your work on the repo! I believe you can change your username just by clicking
Edit Profilein top right?Before I saw this post, I just did a diff between your code and Espruino 2v16 and got the diff attached, which seems pretty nice - as you say if you can use ifdefs like that to handle the different boards it'll be great.
It would be really handy for us if you could try and apply your work on top of the existing Espruino Github repo though - and then it's very easy for us to pull changes upstream. When you start by just copying some of the files in it gets a lot more difficult to both see and transfer any changes -as well as for you to pull in any changes from new versions of Espruino.
If you can get the original repo built with your
CMakeLists.txtthen I'm very happy to try and modify the espruino Makefile such that it will auto-generate aCMakeLists.txtthat basically matches, and we could have a working solution quite quick.If we're going to change everything around, I'd really like to move to IDF 5.2.1 and not just 4.4.7 though. I'm interested in the C2 (ESP8684), and that wouldn't be supported by IDF 4.
-
I just did a very quick hack at https://github.com/espruino/Espruino/compare/master...gfwilliams:Espruino:esp32_idf_5?expand=1 shamelessly based off of https://github.com/rgomezwap/EspruinoS3/tree/main for now (eventually we can make the Espruino makefile create the CMakeList)
It doesn't fully build, but it doesn't look completely impossible as most things appear to be minor renamings or changing defines for functions. As you noted @MaBe the mbedtls version is different and we could look at updating Espruino, but just to get the build working for now we can disable TLS I think.
I guess we should probably look at that repo and try and figure out what changes were made to the other source files (we'll have to try and figure out which commit it was based on and then manually diff it). It may be quite a bit of the work has already been done there.
-
There is already https://banglejs.com/apps/?id=powermanager which actually does a very similar thing (just using JS) - it's got various warnings you can enable - I'm not sure if one is for high power usage over a long time but I guess it could be added.
-
One thing I notice from that is that the values in
cvary by +/- 200ishHowever the values for min/max are anywhere from 1000 to 1600 apart, so basically however you calibrated it, it must have been near a much bigger magnetic field somehow so the min/max values (and hence the center) are way out.
If you do
vmin = vmax = new Vec3(Puck.mag());when the Puck is on the paper as you had it, and then rotate it slowly by 360 degrees I'd expect that then vmin/vmax will end up around 400 apart, and at that point you'll get a much better reading.Getting the compass calibrated is a right pain - it's why even on phones where they've got sometimes billions in R&D budget the phone still occasionally asks you to rotate it in circles to recalibrate.
If you know the field strength where you are (looks like ~160ish for you?), you can effectively just keep track of the center point (rather than min/max) and then if the reading is ever more than 160 away from the center point you just update the center point.
-
Just looking again at https://docs.espressif.com/projects/esp-idf/en/stable/esp32/get-started/linux-macos-setup.html#configure-your-project they really seem to want you to use the
idf.py, and it seems fighting against that might be an uphill battle, making it hard for us to upgrade to later versions.I'd be interested to know how you got 4.4.7 working but it feels a lot like we can modify the ESP32 makefile for Espruino to auto-generate a
CMakeLists.txtfor each target like https://github.com/rgomezwap/EspruinoS3/blob/main/make/esp32idf4/main/CMakeLists.txt and then just call theidf.pyto build everything.So you still call
BOARD=ESP32C3 makeif you want to build it, and that'll generate all the files ingenfor Espruino, and will then call intoidf.pyto finally build everything - but honestly that feels like it'll tidy up the ESP32 build system a lot anyway. -
That sounds great! I know IDF 5 will be different, but hopefully some of what you did for 4.4.7 will still apply. I think if we're going to all this effort we should really try and target IDF 5 as it provides the widest support.
Did you manage to get it building within the existing Makefile framework?
I know someone put a lot of work into https://github.com/rgomezwap/EspruinoS3, but because it throws out the whole old build system it's not something I could pull back in to the main project - and I'm not willing to completely re-architect Espruino for it as it's got to support a bunch of different hardware alongside ESP32.
I know at the moment we have this system where we precompile the IDF which we then download and include in the build. Computers have got a bit more powerful since that went in, and I imagine if that's making it difficult we could ignore that and just build it each time without it being a total nightmare.
Ok, so I've just pushed my changes to
master. You may have to addtarget_compile_options(${COMPONENT_TARGET} PUBLIC -DESP_IDF_VERSION_MAJOR=4)but it's possible it is set by default.... but if you:
boards/ESP32.pyBOARD=ESP32 make(to generate the contents ofgenmake/esp32idf4andidf.py buildI think you should be almost there. Because you're not building in BLE stuff yet (I daren't check that!) you'll get errors about
enableBLE/etc in jswrapper.c - but I just edited jswrapper.c and changed the relevant function names with any old function in the list nearby, and it builds!Not had a chance to try yet - but if you include the relevant BLE stuff and can get that building then we should be almost there - it's just a matter of porting Espruino to use the new mbedtls I think