fifo_full / memory_busy

Yep, that'd do it. Although it still brings up the question of what is allocating memory in an IRQ - which is something that probably needs looking at. Is Pastel clock using any sensors apart from accelerometer?

In the cutting edge releases you can now do process.memory(false) to avoid GC (and if you add it in your code it'll work on older firmwares, but will just do GC anyway)

Is Pastel clock using any sensors apart from accelerometer?

Not to my knowledge. It does not use the accelerometer either.
Do you think any of below might be suspect ?

const infoData = {
  ID_BLANK: { calc: () => '' },
  ID_DATE:  { calc: () => {var d = (new Date).toString().split(" "); return d[2] + ' ' + d[1] + ' ' + d[3];} },
  ID_DAY:   { calc: () => {var d = require("locale").dow(new Date).toLowerCase(); return d[0].toUpperCase() + d.substring(1);} },
  ID_SR:    { calc: () => 'Sunrise: ' + sunRise },
  ID_SS:    { calc: () => 'Sunset: ' + sunSet },
  ID_STEP:  { calc: () => 'Steps: ' + getSteps() },
  ID_BATT:  { calc: () => 'Battery: ' + E.getBattery() + '%' },
  ID_MEM:   { calc: () => {var val = process.memory(); return 'Ram: ' + Math.round(val.usage*100/val.total) + '%';} },
  ID_ID:    { calc: () => {var val = NRF.getAddress().split(':'); return 'Id: ' + val[4] + val[5];} },
  ID_FW:    { calc: () => 'Fw: ' + process.env.VERSION }
};

It gets steps from
Bangle.getHealthStatus("day").steps. I will be adding in the Idle timer functionality I did in lazybones at some point but that just watches Bangle.on('step',)

In the cutting edge releases you can now do process.memory(false)

Great. Will do an update to Pastel Clock to get rid of the GC possibility.

Thanks! What you've got there looks fine though. It's a strange one...

I see this error regularly on my Bangle JS 2, mostly stock and no Bluetooth connection.

Interesting it happens for you without a Bluetooth connection.

mostly stock

This is the problem though :) none of the 'stock' Bangles I have running here do this, so it must be something you installed.

I guess you could do a 'backup' of your Bangle and I can restore it to a Bangle here and see if I can reproduce.

I received my new bangle because the old ones bluetooth had issues. Should I send the old one, which quite reliably shows this error, back to you? Or can I backup the bangle with the debug ports?

It'd be great if you could send the old one back, yes. Then at least we can attempt to get the manufacturer to fix it, or at minimum try and see why there was the error.

In theory connecting via the debug port may be possible, but because your data is saved on memory that is not part of the chip, reading out saved data is pretty tricky. It's not something I have attempted.

Is there specific data on the Bangle that you need?

No just for you, in case the bangle gets lost in the mail. Alright, I will see to sending it back.

Great, thanks! I think more likely than not it'll be a hardware issue rather than software though

Did this patch make it in?

I'm seeing this error when receiving large http responses (16-20kB) from the openweathermap api through gadgetbridge.

Which message are you getting? Fifo full or memory busy?

If you try the cutting edge builds, some changes went in since 2v14 to improve the memory_busy situation.

In terms of fifo_full it could likely be because I'm not sure if Gadgetbridge implements any flow control right now (I have it on a branch but the changes messed deeply with code that is common to other watches so it's not merged yet). If you just turn off the 'increased MTU' in Gadgetbridge settings it'll probably fix it though

I've seen both actually, though the memory_busy seems to come up if it has been idle for a while.

I read another post of yours explaining memory_busy:

MEMORY_BUSY happens when something is happening to the variable store >which keeps it busy (that usually means garbage collection) and a new variable >is requested from inside an interrupt.

In my code, each time the weather is updated, I have to create some fairly large objects: first parsing the JSON http response, then cherrypicking the interesting data from the JSON into my own structure. Could this be what is triggering the garbage collection? I probably need to switch to a more efficient way to store it, like you describe here: http://forum.espruino.com/comments/14667057/

For the FIFO_FULL, I already had "increased MTU" turned off. What branch is it on? I wonder if we could improve the transfer efficiency for APIs with JSON responses (what I imagine most people are using Bangle.http for) by either heatshrinking them and/or pre-decoding the JSON within GadgetBridge and transferring the equivalent of a Python pickle?

Could this be what is triggering the garbage collection?

Maybe - could you try cutting edge builds and see if that helps though. I imagine the MEMORY_BUSY stuff will go away.

FIFO_FULL happens when more data comes in than Bangle.js can handle - and in fact the issue may just be (without flow control) that you have a clock face that takes a long time to update. If it drew faster Bangle.js would be able to handle the data at the rate it comes in.

I wonder if we could improve the transfer efficiency for APIs with JSON responses

Yes. Personally I think the best solution there is really just to implement an XPath for JSON, inside Gadgetbridge. I believe there is a 'JSPath' implementation that could be pulled in - it seems crazy to send 20k of data over bluetooth when realistically all you care about is maybe 40 bytes of data.

realistically all you care about is maybe 40 bytes of data

In my case, I need, if efficiently packed before being sent to the watch, about 400 bytes, representing 48 hours of weather data.

I think in an ideal world, I would have a small program on the phone side (perhaps an embedded Espruino interpreter?) that handles the packing of that data, and then forwards the 400 bytes back to the watch. I think this is basically what "pebblekit for javascript" was designed for, though I don't think anything like that is implemented currently in gadgetbridge?

I don't think anything like that is implemented currently in gadgetbridge?

Well, Gadgetbridge does provide some Pebble support, but I'm not sure how easy it would be to repurpose that. That's an interesting thought though - rather than trying to include JSpath you could just include some JS to run inside Gadgetbridge.

I'm not sure how sensible it'd be to run Espruino, but Android does seem to have a few ways of running JS

Yeah, and it would certainly be more flexible. Imagine any sorts of tasks that would take a prohibitively large amount of ram or processing time if done on the watch. I think what we're describing here are what remote procedure calls are? Maybe we could leverage an existing RPC framework?

The reason I suggested embedding espruino was for the superficial benefit of having the same internal representation of data in both the phone and watch, though that small benefit is erased if we're serializing/deserializing the messages in a separate lib.

I get MEMORY_BUSY regularly. Pretty much any time I pick up the watch to put it on it will be showing that message.
This is what I've got installed. I just did an update on everything, so these aren't actually the versions I've been running.

• Battery Level Widget (v0.09)
  
• Bluetooth ID Widget (v0.03)
  
• BLE GATT Battery Service (v0.01) - I wrote this, so might be the problem.
  
• Bluetooth Widget (v0.08)
  
• Lock Widget (v0.06)
  
• About (v0.12)
  
• GPS Time (v0.05)
  
• Health Tracking (v0.15)
  
• Bootloader (v0.48)
  
• Bluetooth Music Swipe Controls (v0.01) - Only installed this fairly recently, so presumably not the problem.
  
• Scheduler (v0.13)
  
• Alarms & Timers (v0.33)
  
• Anton Clock (v0.09)
  
• Settings (v0.49)
  
• Launcher (v0.14)
  

Do you have a Bangle.js 1 or 2?

This is Bangle.js 2. I never saw the message on my 1.

And you're on the latest firmware?

This could be the BLE GATT Battery Service - just because it's updating the Bluetooth advertising issue and that's something that uses JS data from an interrupt and could maybe cause MEMORY_BUSY

I thought I fixed this on 2v15 firmware though. But maybe you could try uninstalling it for a bit and see if that fixes the problem. If it does, I can have a look with it here and see if I can manage to debug exactly what's going wrong

I still get the fifo_full error more and more. Any Ideas?
I'm running the bangle GB app on my Galaxy S20 with Stock Android 13. In GB the MTU option ist disabled.

Is it the app from the play store, or the F-droid nightlies? I think the Play Store one still doesn't have flow control enabled

It's the Play Store app.

Changed to the f-droid apk and no fifo_full so far. Knocking on wood.

Do you plan to add flow control to the play store version as well? Unfortunately, my doesn't device doesn't allow third party store installations.
I'm getting the PIPE_FULL error quite often