That's a good point. I do see developers overestimating the difficulty when supporting the use a 3rd part lib. I recently came across a library in our code base that's about 200 LOC including comments, line feeds, etc. The library is in C#, a language that takes a fair bit of vertical space due to braces. So, the actual LOCs are just over a 100. I asked the team why can't we write something this simple ourselves. The reality was they didn't know how to, and it isn't a habit to have even a cursory glance at the source of the dependency they were bringing in.
If anyone from Espressif seeing this, I love your MCUs. But can you please improve the ESP-IDF so that it's usable on BSD systems. The Linuxisms baked into its build system is unnecessary.
I think moving from Make in the old version of IDF to CMake was a mistake.
Love it or hate it, CMake is more or less the de facto build system for C/C++
And just like any build system for everything language/stack, there is a small group of hardcore "enthusiasts" who create and push their true build tech to rule them all and then there is the large majority of people who have to deal with it and just want to build the damn thing.
I didn't mean to sound like a hard-core BSD enthusiast, sorry. I was just very frustrated when they moved to cmake in their newer IDF, they added useless things that excluded BSDs. In its current state, it's untenable to patch it to make it work. This wasn't caused by the use of cmake. They could've moved to cmake, but done so with other OSes in mind, esp since they're already in our neighbourhood.
It should generally be easier to make a CMake buildsystem work well on the BSDs than hand-cobbled Makefiles, in terms of opportunities to introduce Linuxisms.
I wasn't really clear there. The Linux-specific stuff wasn't caused by Cmake. They are two independent things that happened as part of the same upgrade.
Considering that they are supporting Linux, there was no real reason to make it so Linux-specific that all other Unix-like systems got excluded.
I work on e-paper displays. Are you looking for something built with a Kindle?
This project of mine is similar to what you described with a power down mode. The power down and wake up can be automated. I'm looking to build a small business around such projects. Not sure how viable it is.
I made some stuff of mine for that display too, but the easiest way is to just use TRMNL's firmware, as it supports autoupdates and a few other nice features.
That's beautiful, thanks for sharing. I was wondering what may be the best way to do frames. Custom frames, here in Singapore, are a bit expensive relative to the rest of the parts.
3D printing is one good way, the other way I used is just to get a frame from IKEA and 3D print the inside white bit to my exact dimensions, which worked beautifully.
I should post that build too, with some photos, I really like it.
I built this dashboard. The price curves and text are rendered locally from the microcontroller and painted pixel by pixel. Letters use raster fonts stored locally, price curves are generated on the fly. It can be done, it takes a bit of care. Mine only has ~400KB memory. It must be a lot easier on the Kindle, I think it runs Java even.
Thanks for sharing your project, it is very cool! I'll check it out and see if I can get it to work.
Kindle is very hackable if you're ready to endure some weird quirks. E.g. You can install Python on kindle or do custom software using various tools like Gcc, clang, Perl etc.
CI/CD at it's finest :p I guess the 5-minutely updates is correlated with the rate of bug fixes they need to push... Surely, that can't be for new features.
Looking at the summary section, I'm not convinced these guys learned the right lesson yet.
A quick reference for a few simple tips for writing memory-efficient Pandas code and some tests for their effectiveness. Would love to hear your feedback and other techniques I could explore.
Love it! Any idea how long the display can last? I've been playing around with e-paper (nothing as impressive as this!) dashboards. I use Waveshare displays that has a max of 1 million refresh cycles. The display you've used seems more capable.
Hi, I'm Eric, Evertop's creator. The screen has a refresh rate of about 350ms, or almost 3 times per second. Of course the device is smart enough to not refresh the screen unless there's a change in displayed content, so it's not like it's actually always refreshing 3 times per second. I've been using the same screen for probably an average of 1-2 hours per day for a little over two years, and can see little or no difference in the clarity of the text and graphics as compared to a brand new screen.
It's probably https://www.good-display.com/product/440.html which is also 1mil refresh cycles and a fast refresh time of 1.5sec - around 185 hours of screen updates, so ~3 months of 5hrs a day typing or a few years of e-reader style usage.
I can't really see a device like this getting used super heavily every day, so expecting it to still be usable from time to time for a few years seems reasonable to me.
That seems like a really short lifespan...? Like you can use it for a couple years, but only if you don't actually use it.
There's an obvious aesthetic draw to e-ink, but it seems like passive-matrix monochrome LCD (like the Playdate) would be similarly power-efficient (or better [1]), longer lasting, usable in full daylight, and with better refresh rates.
How good are the best monochrome LCD screens now? Like... most reflective background and feel the flattest? (The vertical offset between the liquid and the background always bugs me.) Playdate (a Sharp Memory LCD [2]) seems pretty good but surprisingly low contrast. I suppose because the liquid crystal still blocks light even when its off? (I'm unclear here)
Looks like the OLPC transflective LCD screens are actually manufactured now [3] (5" display for $50 [4], maybe 10" but I'm skeptical [5]). The overall OLPC design was actually pretty great [6], even if many of the components weren't so great; it would be cool to see that revisited by some hobbyist.
From what I can tell, a partial refresh of the display (updating a smaller portion of the screen) performs less wear on the display than a full refresh, but it can still accumulate over time. Additionally some displays will require a full refresh after a certain number of partial refreshes to deal with ghosting.
I read an article from someone doing a similar project and if you don't do a full refresh every so often then you'll actually wear out the display faster (he burned one out real quick). It actually needs those full refreshes after so many partial updates.
Huh, interesting. I don't know anything about it, but my Kobo Libra has settings for how often to refresh the whole screen (e.g. every N pages, at the end of the chapter, etc.).
it does not matter in practice, let's say you do a full refresh once a second, it would take more than 11 days to do 1 million refreshes, if you do full refresh once a minute, it would take 2 years
Those numbers don't seem high, at all, for me.
Typing would probably cause a refresh more often than every second and even if it's delayed to be once, every second, it's still only 11 days.
For the usage being discussed here, 1 million is extremely low. For its original intended usage, which might cause one to dozens of refreshes per day, it's more than it'll ever need.
For eink reader is more than enough, for digital typewriter eink is not good choice for display, there are high contrast lcd displays with in-pixel memory that can be used
I don't know about this display but I've tinkered a bit with Waveshare E-Ink, that has this disclaimer:
"For e-Paper displays that support partial refresh, please note that you cannot refresh them with the partial refresh mode all the time. After refreshing partially several times, you need to fully refresh EPD once. Otherwise, the display effect will be abnormal, which cannot be repaired!"
This is where education comes in. When we come cross a certain scale, we should know that O(n) comes into play, and study existing literature before trying to naively solve the problem. What would happen if the "AI" and web search didn't return anything? Would you have stuck with your implementation? What if you couldn't find a library with a usable license?
Once I had to look up a research paper to implement a computational geometry algorithm because I couldn't find it any of the typical Web sources. There were also no library to use with a license for our commercial use.
I'm not against use of "AI". But this increasing refusal of those who aspire to work in specialist domains like software development to systematically learn things is not great. That's just compounding on an already diminished capacity to process information skillfully.
In my context, the scale is small. It just passed the threshold where a naive implementation would be just fine.
> What would happen if the "AI" and web search didn't return anything? Would you have stuck with your implementation?
I was fairly certain there must exist some type of algorithm exactly for this purpose. I would have been flabbergasted if I couldn’t find something on the web. But it that failed, I would have asked friends and cracked open the algorithms textbooks.
> I'm not against use of "AI". But this increasing refusal of those who aspire to work in specialist domains like software development to systematically learn things is not great. That's just compounding on an already diminished capacity to process information skillfully.
I understand what you mean, and agree with you. I can also assure you that that is not how I use it.
There is a time and a place for everything. Software development is often about compromise and often it isn’t feasible to work out a solution from foundational principles and a comprehensive understanding of the domain.
Many developers use libraries effectively without knowing every time consideration of O(n) comes into play.
Competently implemented, in the right context, LLMs can be an effective form of abstraction.
I'm very sorry to hear that. I hope you'll find new, better work soon. Where I work, we do not have any open positions I'm aware of at the moment. But if you like we can connect. I'm trying to start my own start-up rn. But can't promise anything.
reply