Most recent activity
-
I'd share my code, but I don't feel it's ready.. I'd like to implement a queue for all commands, since it's possible that during a full refresh (which will return to the event loop) another command could be requested at a bad time. But then I can share a simple clock that updates every minute (fast refresh) an updates full every hour. I just have some other work ahead of that... :-/
-
My understanding is you don't get both.. you get one or the other. Mode 1 for slow, but no ghosting and known state (you should always START with this), or Mode 2 for faster, some ghosting. And according to what I've read, make sure you revert to full refresh regularly to keep the screen "healthy"
From the spec, I see parameters B1 and B9 for command 0x22... but I don't understand their use. I use CF for a Mode 2, and if you don't call the command it appears to default to Mode 1 (after reset anyway)
-
I'm pretty sure that's full refresh (mode 1) and partial refresh (mode 2). From the recommendations, it says if you use partial (which looks nicer and is faster), make sure that you occasionally do a full refresh to reset the display to known values. Also, power it off whenever you can.. not only does it save power, but the higher voltage can cause permanent damage.
In my case, I'm setting up my desk clock to do a partial refresh every minute, and full refresh on the hour (like a visual "chime"). But I haven't powered it down (or put it to sleep) in 3 weeks! Guess I'd better get on that...
-
there may be other commands that need to be "waited" for. If you look at C source for these (heltec, waveshare) you'll see the spots where they wait for BUSY to clear. seeing BUSY go hi/lo a lot means your just sending commands, should not be a problem. But if the timing is off, you'll get weird effects like you've been seeing
-
You can run Espruino on both of those. I just flashed the Watchy the other day and it works while plugged in (just drains the battery quickly). Pinetime is running an NRF52832 so it runs Espruino as well, but I think you have to open the case to get to the SWD pins (the default bootloader is not compatible with Espruino OTA update).
-
Glad to hear. You lit a fire under me to get the whole BUSY thing working the way I wanted. In my haste, my original code just used timeouts for calls, which meant you had to be very careful when you called subsequent functions. So thanks for that! I think I'll fallback on timeouts for when the target device is a low-memory MCU (no Promises).
-
I get the same thing here... there's some trouble with the Promises somewhere. Did you try running my gist? I've got it working on both Watchy and a 52832 breakout board with a WaveShare. I can't look into it right now though...
-
What tablet is that? I think I need one...
-
As for the Watchy, I wanted an e-ink watch to develop with. But I eschew the big compile, push full firmware approach for just tweaking watch faces, so I'm a huge fan of Espruino everywhere. Fortunately, it's an ESP32 so I just pushed a existing build to it and it ran OOB. It also ran out of battery in 30 minutes... as ESP32s need a lot of power management to last on a battery. I hope to tweak the firmware to do what the Watchy code does: shutdown completely and wake on RTC or button press. Some day...
No setTimeout(); has to be a check for BUSY going low (or is already low). You can say "don't do anything" while it's doing a full redraw and right now that's exactly what I am doing, but someone else who may use this module may not heed that and see issues and not understand. So it's trying to foolproof the driver. In particular, I would override g.flip()/g.setPartial()/g.reset() so they all get queued and only perform in the intended order and when BUSY is low