-
-
I have had some problems connecting with Web Bluetooth on Chrome after a while that just requires a restart of Chrome. As it's often my main browser, this can be a pain.
So, try installing Chrome Canary just for Bangle / Espruino so it can be restarted easily. I've taken care not to install any extensions or do Google log-in on Canary, so there are no bookmarks or other distractions. That way, I'm less likely to accidentally use Canary for other things.
-
Incidentally, @Gordon... any chance of a double-buffered 240 x 240 x 1bpp display mode? That, combined with the suggested
composeImage()
function using Flash-backed images would allow for some very neat tricks. Colour is overrated. :)(It'd preclude widgets, I guess... unless support was added for monochrome widgets somehow)
-
At the moment, my beebclock draws the face and the hour and minute hands from scratch to an in-memory image every minute. Then it draws that image to the screen every second and then draws a line for the second hand. The only part that flickers is the second hand, which I think is acceptable. Otherwise, I think the power drain would just be too high, redrawing it all offscreen every second.
The problem is that the 240x240 buffer is a memory hog even at 1bpp. Fortunately for my watch face I only wanted 1bpp, so I can just about manage to do it in available memory.
- The unchanging watch face in Flash
- The watch face blitted from (1) with hour/minute hands, updated every minute in Flash
- The in-memory offscreen buffer blitted with (2) and second hand added, and blitted to screen every second.
- The unchanging watch face in Flash
-
As we can
drawImage()
direct from Flash thanks toStorage.read()
memory-mapping Flash, then other than performance and (I guess) rewrite cycle wear, is there any reason not to use Storage for storing offscreen buffers?For example, if I have a complicated clock-face redraw every minute (hour and minute hand update), I can
Storage.write()
it, and thendrawImage()
it every second during that minute and just slap the second hand on quickly....?
-
-
I'm having this same problem right now. It was working last night, but it's stuck "Searching for GPS time" now.
I've DFU'ed 2.05 release, and so forth, no luck. I've booted with various combinations of BTN1 and BTN2 held down, as described in https://www.espruino.com/Bangle.js#resetting-without-loading-any-code
Best I've managed is with BTN1 held through "====", getting to the logo screen with
-> Bluetooth
showing, but can't get it to speak to anything yet.I've still got a few things to try.
Of course, I literally just posted my other Bangle to my Dad about half an hour ago, to give him something to do during lockdown. :(
-
-
-
-
(For my part, as the original author of the Espruino module, I can't say. It worked when I wrote it, but I've long since switched to using a BME280 sensor for combined pressure, temperature, humidity. I've been meaning to upgrade to the BME680 that also does VOC air quality measurements. Sorry I'm of no help.)
-
EDIT: Problem fixed. Looks like feverish Reset button pushing while flashing actually got it to work. It's behaving itself now.
Nothing to see here...!Hi,
I've been trying to get an ST7735R LCD running on an Adafruit Feather HUZZAH32 (ESP32) board, which is a whole other conversation, but to verify the hardware I flashed Espruino v1.95 onto the board. It worked successfully with a few tweaks, but I don't think Espruino's going to be fast enough for what I'm trying to do, and I need to go back to compiled code.
Unfortunately, the Arduino IDE and
esptool
are both refusing point-blank to flash the board since I flashed it with Espruino. (It was working before)Meanwhile, the Espruino console is happily responding through the Web IDE.
I've tried different power, slower baudrate, holding down reset, etc. No dice.
Is the Espruino-supplied bootloader not responding, or something like that?
Any ideas welcomed.
Arduino/hardware/espressif/esp32/tools/esptool \ --chip esp32 \ --port /dev/tty.SLAB_USBtoUART \ --baud 921600 \ --before default_reset \ --after hard_reset \ write_flash \ -z \ --flash_mode dio \ --flash_freq 80m \ --flash_size detect \ 0xe000 Arduino/hardware/espressif/esp32/tools/partitions/boot_app0.bin \ 0x1000 Arduino/hardware/espressif/esp32/tools/sdk/bin/bootloader_dio_80m.bin \ 0x10000 ss7735r_test.ino.bin \ 0x8000 ss7735r_test.ino.partitions.bin esptool.py v2.1 Connecting........_ Chip is ESP32D0WDQ6 (revision 1) Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB Compressed 8192 bytes to 47... A fatal error occurred: Timed out waiting for packet content
EDIT: Scrolling back through my terminal window, I found:
./esptool.py --port /dev/cu.SLAB_USBtoUART --baud 921600 flash_id esptool.py v2.1 Connecting........_ Detecting chip type... ESP32 Chip is ESP32D0WDQ6 (revision 1) Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Manufacturer: c8 Device: 4016 Detected flash size: 4MB Hard resetting...
When done now, it returns Manufacturer
ff
and Deviceffff
. No idea if that helps. -
-
To be honest I care less about the actual money as the underhanded and stupid way Patreon have done it. Rather than sending each individual customer an email (or link) saying "You currently pay this much and your creators get this much; now you will pay this much and your creators will get this much", they've tried to spin it as a tiny change that's good for everyone involved.
It's not clear yet but it's possible this is not just a shameless cash grab and is either something Patreon are forced to do or that there's a hidden subtlety that does actually make this better than it sounds. Even so, I don't reward companies that shoot themselves in the foot with opaque misleading communications.
I honestly don't understand why Patreon needs so many millions in VC funding, for example. Could such a system not be funded purely by equitable transparent fees -- or even with a crowdfunded operation themselves -- in a Community Interest Company / Social Benefit Corporation that limits shareholder return? Why does everything need to be in pursuit of maximum profit, rather than covering costs and making a modest profit?
Bah.
It looks like this is an ongoing developing story, so I'll wait until the dust settles before I pull the plug on Patreon. I have a feeling a competitor will rise as their logical alternative, the beneficiary of Patreon's hubris.
-
Hi @Gordon,
In response to Patreon's shameless cash grab, I'm going to close my account with them. Have you a preferred alternative platform for pledging support?
Tom
-
Yeah. The springy pin goes through a slot, then loops back and goes through-hole to solder on the other side. The kink in the pin just before it goes through the slot keeps the ESP32 board itself pulled against the base-board. It's 0.05" pitch as far as I can see, but obv. a different number of pins.
It's silk-screened to hell and back, so I can't see what the connections to the other gubbins on the board are, but some Stanley-knifing with extreme prejudice should work. Anyway, it wasn't expensive. I seem to remember mine came over on the slow boat from Shenzen, though.
-
@Gordon Have you seen this ESP-WROOM-32 (ESP32) programming board with spring contacts? I know the nRF52-based MDBT42Q is smaller, but I'm wondering if something similar could be made from one of these boards. I've found this one very easy to work with.
https://www.amazon.co.uk/Fixture-ESP-WROOM-32-Module-Minimum-Development/dp/B0713PR4RZ
(If you Google Image Search "ESP-WROOM-32 fixture" you'll see some better images. The ESP-WROOM-32 just clicks into place and stays there until you snap it out)
Looking at mine, I think you might be able to hack the contacts off one of these and onto your own board, with a Dremel, a tiny iron, some tweezers and a lot of patience.
Edit: or, come to think of it, if you don't need the short-edge contacts, you could probably just saw out the two rows of side contacts and move them closer together!
-
250ms seems to work. I've also eliminated a lot of the problems by encapsulating the entire program within
function init() {
so variables are local and aren't preserved. Also, byNRF.removeAllListeners()
,E.removeAllListeners()
,clearWatch()
.When I use serial, it tends to behave a little differently on the BLE side, and since serial will suck the battery dry -- I've used up two CR2032s this afternoon alone! Thank IKEA and Lidl for cheap cells -- it's not much use for the original purpose of testing power consumption. Saying that, the new firmware has seemed to stop the 3mA current draw when sleeping.
I'm having to unpair/pair the device on the iPad to get it to properly act, sometimes.
I've updated the Gist above with my current code, if interested. I'm going to try it out properly tonight.
-
After scrapping my FTDI232 for now and buying a new USB-to-Serial, I've finally got it talking via serial;
Serial1.setConsole(true);
, of course. Unfortunately, getting through the back-door just seems to confuse matters a bit :(I'm now getting a range of errors, including:
Uncaught Error: Got BLE error NRF_ERROR_INVALID_STATE at line 1 col 11 NRF.sleep();
on disconnect; the dreaded 13313 appeared once or twice, as well as
Uncaught Error: Got BLE error code 15
, although I think those were both due to old code being stored and/or general connection weirdness.Anyway, I'm going to clear this down and start again. I really appreciate your patience. :)
-
Ah, okay. I just tried your
setTimeout(...,1000)
hack (still on 1v92.103) and the LEDs went nuts: it disconnects (purple), sets a timeout for 1 second, reconnects before that timeout occurs (cyan), then sleeps per the timeout (disconnect, purple) and so on, until it happens to not connect before it sleeps! :)Thanks for the fix; I'm eager to try it. Have you got the most recent Puck binary, by any chance? I haven't got cross-compilation rigged up at the moment.
-
-
So any thoughts… problem with the firmware, or problem with my code? Or, my code is doing something legal but unexpected, perhaps? Hngh.
Re: multimeter, good tip! I was thinking that, but was intending instead to hook it up to another Puck (or possibly a Pico or Original) to do voltage monitoring and graph it over time to get some idea of likely battery life. However, with the preliminary check with the multimeter being two or three levels of magnitude more than I was expecting, I figured I'd raise that before I went too far with it.
-
@Gordon: it seems like a great idea, but I think I've hit a snag.
I'm running my current code on 1v92.103 (the nightly the last time I DFU'ed) and rigged it up to my Lidl multimeter (only the best quality kit for me...)
After startup but not connected, just advertising, it draws about 0.15mA.
While connected but idle, it draws about 0.35mA.
While sending data and flashing an LED, it draws about 5mA.All fine so far. However, if I force a disconnect with a triple-click which should trigger an
NRF.sleep()
, it'll draw around 3mA steadily!So, when it's purportedly "off" it seems to draw ten times the power of "on". Not good. Hmm. Any thoughts? Any chance you could give it a go? My equipment and skill level makes these figures somewhat less than conclusive.
(Edit to include photo of my test setup: desoldering braid separated by Post-It note)
-
If I remember correctly, Node-RED actually needs an old version of Node at the moment.. well, not older as such, but I think it only runs on Node 6.x (the long-term stable release), rather than the state-of-the-art Node 7.x. As a result, it doesn't support Promises and a host of other ES6 features.
One option is to use
nave
, which lets you have several versions of Node installed and switch between them as needed. That way, you can have Node-RED and EspruinoHub running in Node 6.x, and use another version for other scripts. Or, as you say, just reinstall with Node 6.x: most code should work with it.My version of
EspruinoHub.service
is substantially different as I don't use standard Node either: I install the base server version of Raspbian and do a custom install of Node into its own user.
Hi @TomWS! Did you progress this driver any further? It’d be interesting to merge it into the main tree; I have a few ePaper displays gathering dust that I’m intending to do something with before too long, and would very much like to see about getting partial updates working.