So after playing around some time with my new Badger2350, here are some insights.
Hardware
The best you can get for a small RP2350 based e-Ink display. It is not perfect though. For example the Badger2350 lost the smart power management electronics compared to the Badger2040W. The latter had a current draw of 27µA@3.6V, while the new version draws 167µA@3.6V. Still very good and the claimed 100 days of standby is very conservative. I guess it could well be more than 200 days.
What is also missing is a connector for a few GPIOs. I won’t use the Badger2350 as a batch, so I really miss that. But the GPIO-connector was already lost going from the 2040 to the 2040W variant.
The PC-case is great, and very simple to disassemble. I hope some days the design-files will show up so it is easy to print some alternative (color) variants.
The only thing I don’t like on hardware side is the LiPo glued to the PCB.
Software
While the hardware is premier league, the software is a mixed bag. The low-level implementation of the power-management making use of the POWMAN-functions of the RP2350 is great. But only if you stick to Pimoroni MicroPython. If you use Arduino, PlatformIO or C with the SDK you will have a hard time making use of low-power applications. Ok, you can make it with a lot of copy&paste using the C-code behind the MicroPython implementation, but this is not straightforward.
Also, on UI side I am missing something for more advanced users. Please, please add LVGL support as an option. Lines, rectangles, stars and so on are ok for basic usage, but the function set is no where near the pro-level of the hardware.
Having said this, what you get as software is good to get you started. And as long as you stay in this very small niche ecosystem and don’t want to share code with a larger community, that is ok.
…is this something you could make use of for some LVGL fun?
I see this covers the Pico under the keyword „rp2“…
Yes, this is a MicroPython port with integrated LVGL. But that does not help if you need the Pimoroni MicroPython for their hardware-support.
I understand that Pimoroni is needed for an adaption layer between LVGL and their HW.
Actually, I create the UIs myself until now using my own libraries, which of course are highly device dependent and customized, but shown bars, sliders, pop-ups and windows as well. I do see the advantage of LVGL, which I was not aware of as of now…
In addition, I see that most of the LVGL stuff is in C. Another advantage of a Pimoroni adaption would be to have this fully integrated into the Python world, at least on programming level - knowing that fast routines would be anyways in C again. But this would be under the hood and not visible to the programmer….
So, I would also support your ask to Pimoroni to deal with it…
Maybe with would not only valid for the badgeware series, but also for the Interstate75 world and other display families…
Went down this rabbit hole… by implementing a GoodDisplay GDEY029F52 (296x128px) and GDEY029F51H (384*168px) BWRY 4-color e-ink display to my Badger2040 and 2040W (the high-res display is the one in front):
holy §%$!
you swapped the whole display on the Badger by a new coloured one with higher resolution, did I get this right…?
That’s right. I sacrificed the BadgerOS therefore and had to get along with MicroPython 1.28.00 for the start and had to „re-engineer“ all the apps new - referring to the new code to control the display and use the bigger screen. Also conversions of icons and images had to be done in advance on my laptop. But it worked.
I will continue now with an 2350 badger, since I bumped into the small amount of memory of the RP 2040.
The Pimoroni 2350 has a whopping 16MB flash, stunning 8MB PSRAM and even faster cores. Plus the battery an case comes on top!
Oh and I should mention, that a partial render has the same time consuming update process like the full render and takes whopping 21 seconds on the high res. display (which is 384x164px). There was a former 296x128px display, which had LUT tables memory in the controller, which sped up full render from 17sec to 11sec. So in any case not comparable at all with the 1.2sec for a partial render of the bw-displays. For me this is a „tolerable“ sacrifice for color. Since my use case is not depending on fast display rendering like in games.
Stay tuned, in about 4 weeks I get my Badger 2350 and then we make the pirate’s parrot colored! 😃
Edit: if it happens to be an you are in Berlin tomorrow at the GDG Berlin monthly meetup and opening the new AI center by Google in Berlin: try to find Ester from GDG Frankfurt. She‘s carrying one of the prototypes with the high res display.
It is not only about fast display rendering, but also about how long your battery lasts. Power is (about) linear in uptime, so minimizing uptime will maximize runtime. And yes, fast display rendering is useful not only in games. I am running a clock application on the Badger2040W, updating once a minute. Having it wildly flashing for 25% of the time is nothing you want.
Having said this, color displays have other advantages. It is all about the use case.
“enough interest” is the critical point. Having a dedicated fork of MicroPython for Pimoroni hardware does not help the community, indeed it fragments it.
At this stage, I am laying back totally relaxed, since I am using CircuitPython. Swap in a new display, then swap in the display driver and reuse all your existing code. That’s the big advantage: CP works across brands and architectures. So you have one big community to share code and drivers.
