Search results for:

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.

Ok, so I finally got the 2 bit color working rather than just black and white on it. The pixels go:

x0y0b0 x1y0b0 x0y0b1 x1y0b1
x0y1b0 x1y1b0 x0y1b1 x1y1b1
...

So the two bits of color aren't even next to each other!

I was expecting greyscale, but what I actually got was better. You get cyan and red, and then I guess the two mix to make black.

So you could kind of use it to antialias text and it wouldn't notice, but you actually get colour!

I merged that PR as the code looks like an improvement, but the original code isn't broken. Uploading by copy/pasting into a templated str is a pretty bad idea as if you have any escape characters in strings they need double-escaping like "\\x00" or they will cause problems(as you noticed!)

Upload via the IDE menu is much safer

yes, you can do that, but that's only checking that the idle loop is working. If something happened (low memory, undefined/etc value) that caused your code to keep failing it wouldn't catch that.

And no, it doesn't add any noticeable power usage :)

Thanks - yes, that's the datasheet I used - but I could really do with a bit more info about how the greyscale is handled on ST7301 (I think there are different modes).

It was this one: https://www.aliexpress.com/item/10050053­00414591.html - KD042WQTMN001

So not super cheap, but not bad one-off (although you need an FPC breakout) for it.

It's a really nice display though. Around 85x65mm viewable area, with maybe a 3mm border. When running in the low power more I reckon it's using about 100uA or less, and it's really sharp.

I'm seriously considering it for a new Pixl.js type device assuming I can get them in quantity cheap enough.

Just a note to say I finally got an ST7301 400x300 LCD working. I don't have a datasheet (do you have one?) but I just used your exact code, changed the window (0x2A/2B) for writing and write 2 bits per pixel, and it works!

Ideally I'd know what I'm setting everything to though as I assume I need to adjust all the voltages to get greyscale on it (which it should do). I can get something that looks a bit different but it's not grey :)

Definitely from a technical standpoint, round watches are a total pain - you still need to store and transmit a square buffer even for the round screen, so you're wasting 1/4 of your memory and bandwidth.

I can see the appeal of round watches, but I think that for Bangle.js where we're trying to be quite 'down to earth', round isn't a great fit.

And yes, I'd love a bigger display and smaller bezel too, but display choices are pretty limited. For some reason, 1.28" screens seem kind of a standard for transflective displays. There might be some ST7301 based ones coming out at some point, but I haven't seen anything yet

Probably the best idea is to use the hardware watchdog - that's what they have them built in for: https://www.espruino.com/Reference#l_E_e­nableWatchdog

So:

E.enableWatchdog(10, false);
setInterval(function() {
   // your code here
    E.kickWatchdog();
}, 2000);

If the function doesn't complete to the point that kickWatchdog is called, the whole device will restart.

But you might also want to look at https://www.espruino.com/Debugger#debugg­ing-when-not-connected - at least then when it stops working you can maybe connect and get some idea what happened?

You can upload them using the normal Storage button in the middle of the IDE screen and uploading the file from eg https://www.espruino.com/modules/MQTT.mi­n.js to a file called MQTT

I don't think the IDE is smart enough to know that the modules are actually installed on the device and to not re-upload them, but nothing stops you from renaming it MyMQTT on the device, and then doing require("MyMQTT");

The watch shape really comes down to the display. I think the memory LCD is a good fit for Espruino - it's low power, and low enough pixel count the processor can update it quickly. Having to go for round limits your options a bit - it'll also ensure the vast majority of existing apps won't work... That seems like a bit hit to take just for aesthetics.

For ear buds - I just wonder what features Espruino could add in an ear bud? I guess if it had some voice recognition and synthesis built in, and then with JS you could script what happened - but that's quite a step away from the kind of things Espruino is normally used for!

Hi! Yes, I think you could do something... I definitely remember seeing some GSM/etc breakout board that had headphone/mic jacks on it.

Even the phone modules are generally pretty easy to wire up so you could do a custom PCB with a Espruino MDBT42/MDBT50 and phone modules, and an Epaper or LCD slapped on it.

However it's quite a lot of work, and I'm not sure the end result would be much better than a Nokia candybar phone ;)