Sure, there are more power efficient platforms, but the project uses Selenium and PIL which I’m pretty sure won’t run on any of those boards.

I guess you could offload the rendering to a server, but then it’s no longer a self-contained, standalone solution. Trade-offs!

How does ESP32 compare to the products you listed?

I find the ESP32 much easier to develop for, you don't need to install any toolchains, just plug in and drop code into the virtual USB drive that shows up! I wish all microcontrollers were like that these days.

That sounds like a very specific bootloader that you're using

ESP-IDF is still very nice though, and being CMake based makes it easy to integrate outside code

It supports serial based uploads, which are still pretty nice with the bundled serial monitor (one key combo to build, upload, and restart) and OTA uploads

Oh sure, but it's still way better than the last time I had to deal with an STM32 and install about 5 different things, modify a "boards.txt" file (which there were 3 copies of on my system in different places and I had no idea which was the real one) and then hit the program button with one hand with a mouse in the air while carefully timing a short of a reset trace on a PCB with the other with my elbow holding down the PCB. STM32s really suck. Never had to do that with an ESP32, at least someone made a nice bootloader for it.

How do you handle SSL? I found this very cumbersome in my experiments with esp32

I never coded on Espressif, but in other SDKs (e.g., mosquitto, mbedtls) typically this is done when you open the connection at the application layer (HTTPS, MQTTS). You pass in the cert bytes either as binary or PEM text as a char[]. Use a CA root cert(s) from your OS/browser.

EDIT: grammar and typos.

It depends on whether you want to connect to random hosts or ones that you know beforehand. The latter is very easy, I just hardcode the certificate fingerprint. The former/dealing with CAs is harder, I've never done it.

The high-level client in esp-idf handles ssl out of the box and comes with a list of pre-installed root cas.

The question, of course, is: What if these CAs expire?

ESP32 is a very generic synthesized chip, not particularly ULP oriented.

On other hand, it's the most developer friendly company out there.

I've been unsuccessful getting any proper reaction from Innophase about SDK support. Their sales seem to not even understand what we are wanting from them, and keep sending us "enter these AT commands through USB-TTL"

ESP32 is also pretty much the one, and only wireless MCU you can buy on the open market, in any quantity, on a short notice. Nothing else comes with the supply chain security like this.

> ESP32 is a very generic synthesized chip, not particularly ULP oriented.

Maybe not, but setting it up to sleep most of the time and only boot once a day to fetch the calendar and update the display should sip power pretty sparingly; I expect you'd get months if not a year or more before needing to recharge the battery.

I wanted to try their Espressif ESP32 low power 802.11 part back in March but it wasn't shipping yet. Their website isn't clear but I'll poke around and see if it has been released yet.

I was going to say, I feel like an ESP32 might be a better fit for this, given that it’s designed for deep sleep.

Can you keep RPi most of the time hibernated? Does it still draw a lot of power in sleep?

I don't think it has a hibernate mode, but it has been a quite a hwile since I've downloaded the latest headless server build.

I am currently reading 428mA at 5.0V on the power supply that is driving it. It is headless and I'm not interacting with it. (400mA w/ethernet unplugged). So that's 2W. I'm running Buster Debian build. If you got a low power command, hit me with it and I'll try it! systemctl doesn't support hibernate. I don't do any low power linux programming mainly because Cortex-A class processors (heck, even M7's) are already far outside my power budget.

That is a crazy amount of power, compared to the InnoPhase T2 that draws ~300 MICRO Watts when connected and sleeping.

You don't really need to "hibernate"; shutting the entire system down and booting from scratch on each update is simpler and probably more reliable.

The problem (hibernate or not) is getting the Pi to wake up, since it doesn't have a real-time clock. OP is using a RTC hat to achieve this. I do wonder what kind of power consumption it uses while sleeping.

what a colossal kludge. what you're trying to accomplish is basically embedded programming 101: sleep mode + wakeup timer. RTC? pff.. even any MPU on-board oscillator with no crystal has good enough PPM and lower power than an RTC. your solution is like hunting quail with a nuke.

yes, but trying to generate a nice rendered image on a stand-alone uProcessor is pretty hard.

I don't like that it takes headless chrome to render, but it _works_ and fills a need for the maker.

I'm pretty sure they looked at the stuff they'd need to write (A layout engine, a anti aliasing library, a calendar parsing library, an image handling library) and thought "fuck that, lets use a pi".

It terms of time thats weeks full time, and even then might not be possible to fit on the uCPU of choice.

just buy a realtime hat with wake up ability, for $40 max, boom job done moving to making the thing look good.

Its not a product, its someone's hobby, leave them be.

> trying to generate a nice rendered image on a stand-alone uProcessor is pretty hard.

Did you see the rendering? It is very simple, and does not require PIL. There are plenty of embedded GUI libraries that are specifically for this kind of application (uFX, Qt). Why not learn something new?

I want HN to be a place where experts critique ideas, not a Facebook/Instagram like-fest ego-stroke. I was proposing a deeper dive to the OP so that s/he could develop better skills. I wasn't mocking OP, but I was mocking your bad idea because you didn't make anything, you just threw out a naive suggestion.

Did you come here to learn or to get some karma for a dopamine hit?

> I want HN to be a place where experts critique ideas

I was critiquing your world view that _everyone_ must at all times go really deep into software so that everything can fit inside 4mbit of flash.

I was also also critiquing your strongly held opinion that simply because a microprocessor has low power states, it doesn't mean that its quick, easy or indeed achievable to render a nice calendar entirely onboard. (it is of course possible, but I know it would take me a lot of time and be no fun.)

Perhaps the goal of the project was to get something that looked nice in a time frame that was reasonable. Perhaps the goal was not to spend time learning how to do antialiasing, font handling, calendar parsing in a power constrained environment.

The joy of the internet is that they have shared their work, now you can build on it and make a good looking eink calendar that's battery powered on some tiny ARM SoC with 4kb of ram.

Whilst you're at it, I propose that you go out of your comfort zone and remake this https://www.secretbatcave.co.uk/projects/stock-ticker-machin... to make it purely electro mechanical. it can't be that hard.

This very article shows how they use another product that just turns on the pi on a schedule (once a day) to render the updated calendar.