Search results for:

Ok, great! Thanks for your work on the repo! I believe you can change your username just by clicking Edit Profile in 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.txt then I'm very happy to try and modify the espruino Makefile such that it will auto-generate a CMakeLists.txt that 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/com­pare/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=powermanag­er 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 c vary by +/- 200ish

However 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-ma­cos-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.txt for each target like https://github.com/rgomezwap/EspruinoS3/­blob/main/make/esp32idf4/main/CMakeLists­.txt and then just call the idf.py to build everything.

So you still call BOARD=ESP32C3 make if you want to build it, and that'll generate all the files in gen for Espruino, and will then call into idf.py to 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.

Basically imagine writing all your characters in a line: ABCDEFGHJ... then just rotate it by 90 degrees - and that's your font bitmap, then the font widths buffer contains the width of each character... That's basically all there is to it.

There's this tool to create 7 segment fonts which may/may not be useful - it runs on Espruino and generates the bitmap using a Graphics instance: https://github.com/espruino/EspruinoDocs­/blob/master/modules/sevenseg_font_tools­.js#L119-L120

It's been a common issue that especially on battery powered devices like Puck.js and Bangle.js it's very difficult to know how long your device is going to last on a battery, or if you've got your device into a state where it's draining the battery fast. With Puck.js it is at least possible to attach a current meter to measure power consumption, but with Bangle.js you can't even do that.

I've added a function called E.getPowerUsage() to the latest Cutting Edge that should go a long way towards helping with this (when 2v22 is released it'll be in there too). It's most useful on the Official Bluetooth Espruino devices.

When called, it returns an object with a field called total which is the total estimated power usage in microamps. There's also an object called device which lists all devices Espruino thinks are drawing power:

>E.getPowerUsage()
={
  device: { CPU: 295, polling: 187, BLE_periph: 665 },
  total: 1147 }

On Bangle.js and Puck.js where the battery is about 200mAh (or 200,000uAh) you can do 200000/E.getPowerUsage().total to get the expected battery life in hours.

Bear in mind this is very much an estimate - we are able to check average CPU usage and get a reasonably accurate figure, as well as for Bluetooth, but other sensors (GPS, accelerometer, etc) are estimated based on the current state... If you turn on GPS for a minute every hour and only check E.getPowerUsage() during that hour when the GPS is off, it will return 0 for GPS power usage.

Even so, hopefully this will be a handy tool for Espruino users!

Hi - what you've got there looks pretty good to me. The magnetometer has a DC offset on it, so you need to account for that with min/max which is what you're doing.

Are you sure that when you upload this you're turning the Puck 360 degrees around (and maybe rolling at different angles as well) first? That allows min/max to be calibrated and will give you much more accurate readings.

You'd hope that when you do this, vmax.sub(vmin) will have roughly the same values in each axis (which would be the earth's magnetic field strength), and if you measure c.mag() that should stay about the same size no matter where you hold the Puck too.

edit: just to add the Puck would also need to be held perpendicular to the magnetic field when using Math.atan2(c.x,c.y) - if it's off-axis then some of the field ends up in c.z which will make the values for angle seem very nonlinear

I think this might help - short, but I think it contains the jist of it: https://www.espruino.com/Fonts#custom-fo­nts

You'll need a string containing a column-first, most significant bit first, 1 bit per pixel bitmap containing the font bitmap. Optionally you can also have another string containing the widths of each character.

and you can just load the file as a string with require("Storage").read("filename") - the string will be kept in flash and will be loaded on demand. If it's too big to send in one go you can use E.pipe to pipe it to the HTTP response

Well, that was a nightmare. Pretty much everything was broken.

But I have now fixed setServices, onWrite, and notifications/indications, so I think it should be ok if you try a 'cutting edge' build now

Thanks for looking into this!

You can force the console to stay on Serial1 even when connected with BLE with Serial1.setConsole(1) which really helps with debugging.

Also ESP32.setBLE_Debug(7) can help to display extra info too

I looked and there is some code for handling writes there, but on trying the code above and writing I get:

Uncaught Error: Too much recursion - the stack is about to overflow
Execution Interrupted

Is this what you see too? I'll have a look and see if I can figure out what's broken

Is this possible via command line too?

yes!

--storage fn:data.bin    : Load 'data.bin' from disk and write it to Storage as 'fn'

I think that works - can't remember for sure now - it's possible it attempts to write using Flash though

Good question!

I have a font converter at https://github.com/espruino/EspruinoWebT­ools/blob/master/fontconverter.js which I'm using for most stuff now (like creating the font pack apps, and hopefully at some point https://www.espruino.com/Font+Converter), but it doesn't handle BDF yet.

I've got a very hacky tool that I don't think I ever released, which I've attached below. It loads BDF and spits out a C file that can be compiled into Espruino.

If you were up for a challenge it'd be awesome if you could add the BDF loading code from that tool into the main https://github.com/espruino/EspruinoWebT­ools/blob/master/fontconverter.js - that way you could export to JS (or a PBF file) to try things out more easily.

That code should work

do I need to set the watchdog's timeout higher than my code timeout?

Yes, at least twice - I'd generally go for ~5 times the interval, just in case.

One thing to note is that once you added the watchdog you can't change it or its interval until the device physically reboots (reset() won't cut it). It's done in hardware as a failsafe so once it's been added, it can't be undone (until a reboot/power cycle)

I think you've misunderstood - there is an actual button for uploads!

• Go to https://www.espruino.com/ide/
  
• Connect to your device
  
• Click the Storage icon (4 discs, basically in the middle of the screen)
  
• Click Upload Files
  
• Upload your file using the file chooser
  
  

Uploading your way will work but as you noted it's messy!

In your case, you can ignore the "exports" is not defined error. It's because after upload the IDE is trying to run your module as if it's a normal app - but it's a module.

it would be worth having a way of using it as a connected dashboard

Yes, I know. I wanted to make an 'Espruino' integration for Home Assistant so that you could connect and send data to Espruino devices via Bluetooth, but I haven't got around to it yet.

But I think if I make a new board with this, I'd stick WiFi on it anyway. It'll be a bit more expensive because of the display anyway, and even if it's not used by some people being able to connect to a WiFi network would be super helpful

It looks like it's just displaying whatever temperature value it gets - ideally it'd be using locale: https://www.espruino.com/Bangle.js+Local­e

we could just run/eval a js file as a step from the json test definition.

Yes - that sounds like a great plan for the future

Thanks!

Well, really it was a few things:

• we might want to have some data beforehand (eg to say we need to load app X as well) - but that could be in JSON in a comment at the start of JS I guess
  
• Ideally we want to be able to write a command to the emulator and wait for it to complete so we know where the test failed if it did (but I guess if we wrote the whole JS file and then ran it, exceptions would give line numbers)
  
• Writing JS to the console isn't quite the same as normal JS - writing for (var i=0;i<10;i++) and then print("Hello") on a newline will run the loop and THEN the print.
  
• If you let people write JS they'll try to be clever and it'll no longer be a set of 'do this check that' but something far more complicated
  
• I was expecting some commands of the JSON might be doing more in the test harness than just running on the device (eg saving and comparing screenshots) - but maybe we could have the emulator send out some text like COMPARE IMAGE FOOBAR.png followed by the image's base64 and then the test harness could interpret that.
  
  

But yes, potentially we could just have JS files and work around that stuff above. There's nothing in place at the moment, so if you wanted to do a PR I'm all for it.

Oof. Yes, I guess that's doable!

On the Starfield watch we did I just used the whole buffer but I used the corners to store extra data. So as the hands moved we stored what was in the background behind them in the corner of the screen so we didn't have to redraw everything - it worked quite well.

is there way to see how much space I have?

require("Storage").getStats()

Ideally if you're writing data that fast, you could look at writing binary data - see the second example on https://www.espruino.com/Data+Collection­#flash-memory

It looks like we don't support a poll interval less than 10ms (100Hz): https://github.com/espruino/Espruino/blo­b/8f3a9cb52/libs/banglejs/jswrap_bangle.­c#L2487

So you can't do above 100Hz. I'm not sure what happened with 400Hz but maybe it failed with out of memory before it got started.

The Accelerometer does have a built-in FIFO which we don't actually use at the moment.

It might be possible to change the Espruino firmware to use it, but also you could probably use accelRd to read the data directly from the FIFO at a much lower level, and then you don't need to change PollInterval at all.

Thats a tight build if the compiler changed the size enough to make it not fit!

Welcome to my world. It's a constant fight to try and get everything in - if you look back at the commits you'll see I've spent literally months making small commits to try and shave a few bytes off here and there.

Hi,

That's great! It's really good to see it used for this kind of thing.

It looks like the changes in your fork aren't something I could pull back as they delete a bunch of stuff and change the API, but if you did want to contribute something back that added connectBluetooth/etc without changing the rest then I'd be happy to pull that in.