You expect me to use this with what, now?
-
I found a nearly 6" 7-color e-paper display, and my first thought is woo! Then I realize, I can't actually use it with anything because 640x448x4bits is too large for nearly any IoT device to hold in memory at a time, and they way these things are designed, you have to hold the frame buffer in memory, or you can only write full screens directly off of flash which isn't practical. So who designed this screen? Did they not think of memory requirements? They claim it's compatible with a Raspberry Pi, and yeah, it would be because I can get one with 1GB of memory or more. But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power? I'm trying to figure out a real world use case for this screen, and the only thing that can realistically run it other than a raspberry pi is maybe an ESP32 WROVER, which isn't the most popular device for commercial products for reasons.
Real programmers use butterflies
-
I found a nearly 6" 7-color e-paper display, and my first thought is woo! Then I realize, I can't actually use it with anything because 640x448x4bits is too large for nearly any IoT device to hold in memory at a time, and they way these things are designed, you have to hold the frame buffer in memory, or you can only write full screens directly off of flash which isn't practical. So who designed this screen? Did they not think of memory requirements? They claim it's compatible with a Raspberry Pi, and yeah, it would be because I can get one with 1GB of memory or more. But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power? I'm trying to figure out a real world use case for this screen, and the only thing that can realistically run it other than a raspberry pi is maybe an ESP32 WROVER, which isn't the most popular device for commercial products for reasons.
Real programmers use butterflies
I don't think all this IoT is good for you. Sounds very time-consuming and expensive. ;P
-
I found a nearly 6" 7-color e-paper display, and my first thought is woo! Then I realize, I can't actually use it with anything because 640x448x4bits is too large for nearly any IoT device to hold in memory at a time, and they way these things are designed, you have to hold the frame buffer in memory, or you can only write full screens directly off of flash which isn't practical. So who designed this screen? Did they not think of memory requirements? They claim it's compatible with a Raspberry Pi, and yeah, it would be because I can get one with 1GB of memory or more. But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power? I'm trying to figure out a real world use case for this screen, and the only thing that can realistically run it other than a raspberry pi is maybe an ESP32 WROVER, which isn't the most popular device for commercial products for reasons.
Real programmers use butterflies
There are four possibilities as I see it: (1) The screen manufacturer has a product and can manufacture it fairly cheaply as a loss leader to encourage computer hardware manufacturers. Build it and they will come, so to speak. (2) The screen manufacturer has made a mistake. They thought IoT devices or embedded devices were coming soon and they are not. (3) Or perhaps they are were correct and a new generation of devices are just about to be launched that can take advantage of their screen. It doesn't really need to be IoT; it could be embedded or self-build (although I regret to admit that the latter probably rarely constitutes a decent market size). (4) The manufacturer is willing to release this on the basis that it shows what they can do in the expectation that they'll never sell much more than engineering samples but it will generate sales for follow-on products.
-
There are four possibilities as I see it: (1) The screen manufacturer has a product and can manufacture it fairly cheaply as a loss leader to encourage computer hardware manufacturers. Build it and they will come, so to speak. (2) The screen manufacturer has made a mistake. They thought IoT devices or embedded devices were coming soon and they are not. (3) Or perhaps they are were correct and a new generation of devices are just about to be launched that can take advantage of their screen. It doesn't really need to be IoT; it could be embedded or self-build (although I regret to admit that the latter probably rarely constitutes a decent market size). (4) The manufacturer is willing to release this on the basis that it shows what they can do in the expectation that they'll never sell much more than engineering samples but it will generate sales for follow-on products.
You could very well be right. I will say that a 7 color e-paper display is neat technology, but I wish they made it in smaller versions, like 200x200 as well, so that they could be opened up to a lot more devices.
Real programmers use butterflies
-
I found a nearly 6" 7-color e-paper display, and my first thought is woo! Then I realize, I can't actually use it with anything because 640x448x4bits is too large for nearly any IoT device to hold in memory at a time, and they way these things are designed, you have to hold the frame buffer in memory, or you can only write full screens directly off of flash which isn't practical. So who designed this screen? Did they not think of memory requirements? They claim it's compatible with a Raspberry Pi, and yeah, it would be because I can get one with 1GB of memory or more. But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power? I'm trying to figure out a real world use case for this screen, and the only thing that can realistically run it other than a raspberry pi is maybe an ESP32 WROVER, which isn't the most popular device for commercial products for reasons.
Real programmers use butterflies
honey the codewitch wrote:
But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power?
Not exactly sure about the specs of your original question, but googling I found a CNC Lathe that has "Standard Program Memory, 1 GB". Which I suppose means you can add more memory than that. Would that answer your question - at least hypothetically?
-
I found a nearly 6" 7-color e-paper display, and my first thought is woo! Then I realize, I can't actually use it with anything because 640x448x4bits is too large for nearly any IoT device to hold in memory at a time, and they way these things are designed, you have to hold the frame buffer in memory, or you can only write full screens directly off of flash which isn't practical. So who designed this screen? Did they not think of memory requirements? They claim it's compatible with a Raspberry Pi, and yeah, it would be because I can get one with 1GB of memory or more. But who in the world is going to make a color e-reader with an $80 screen powered by a largish, power hungry $150 computer that usually requires fans and dedicated power? I'm trying to figure out a real world use case for this screen, and the only thing that can realistically run it other than a raspberry pi is maybe an ESP32 WROVER, which isn't the most popular device for commercial products for reasons.
Real programmers use butterflies
Never used an e-reader. Do they switch pages very fast? This looks like an el-cheapo bunch of memory: (running at 133 mhz) [2pcs ESP-PSRAM64H Chip - 64 Mbit Serial Pseudo SRAM - ElectroDragon](https://www.electrodragon.com/product/2pcs-esp-psram64h-chip-64-mbit-serial-pseudo-sram/) Don't see any reason you couldn't compute (say) 10 scanlines in actual ram, before blasting em to the device, ready to be dumped to screen after you'd rendered the whole page. I did phong-shaded surface renderings of 4d julia fractals at 640x480 back in dos using only 64 k of memory using a similar trick for the zbuffer... Of course, I've no idea how mem hungry the TTF stuff is, nor how many scanlines each line of text is high.
-
Never used an e-reader. Do they switch pages very fast? This looks like an el-cheapo bunch of memory: (running at 133 mhz) [2pcs ESP-PSRAM64H Chip - 64 Mbit Serial Pseudo SRAM - ElectroDragon](https://www.electrodragon.com/product/2pcs-esp-psram64h-chip-64-mbit-serial-pseudo-sram/) Don't see any reason you couldn't compute (say) 10 scanlines in actual ram, before blasting em to the device, ready to be dumped to screen after you'd rendered the whole page. I did phong-shaded surface renderings of 4d julia fractals at 640x480 back in dos using only 64 k of memory using a similar trick for the zbuffer... Of course, I've no idea how mem hungry the TTF stuff is, nor how many scanlines each line of text is high.
e-paper doesn't refresh very well, and you can't (usually) update just part of the screen at once - it's all or nothing. Anyway, I figured it out, for an ESP32 at least. Not probably for something like an ARM Cortex-M
Real programmers use butterflies
-
e-paper doesn't refresh very well, and you can't (usually) update just part of the screen at once - it's all or nothing. Anyway, I figured it out, for an ESP32 at least. Not probably for something like an ARM Cortex-M
Real programmers use butterflies
No, no, no - I mean send a few scanlines to the pseudo-ram before dumping a whole screen (I said page) to the display. 10 scanlines * 640 * 4 bits would only be (6400/2) bytes worth of uController ram. The STM32F103C8T6 has 20kb and runs at 72mhz. Last year they were $3.something US - now about a tenner. :( Heh heh - good thing I bought 5! Kinda neat (but probably pointless here) that the the esp32 lets you memory-map the pseudo-ram and access it like it's on-chip ram. I'd imagine a RaspberyPi Zero would make a potentially half decent brain for an e-reader - they're only 10 Australian pesos for 512MB and 1Ghz. 17 or so if you want the one with onboard wifi and blutooth. You're one smart bunny. Love reading about your exploits
-
No, no, no - I mean send a few scanlines to the pseudo-ram before dumping a whole screen (I said page) to the display. 10 scanlines * 640 * 4 bits would only be (6400/2) bytes worth of uController ram. The STM32F103C8T6 has 20kb and runs at 72mhz. Last year they were $3.something US - now about a tenner. :( Heh heh - good thing I bought 5! Kinda neat (but probably pointless here) that the the esp32 lets you memory-map the pseudo-ram and access it like it's on-chip ram. I'd imagine a RaspberyPi Zero would make a potentially half decent brain for an e-reader - they're only 10 Australian pesos for 512MB and 1Ghz. 17 or so if you want the one with onboard wifi and blutooth. You're one smart bunny. Love reading about your exploits
For $10 I'll just get an ESP32 WROOM devkit. You can get the chip itself for like $2 but that's without all the supporting hardware to make it go + program it. They're dual core 240MhZ with like 300kB of RAM available and 4MB of flash. WROVERs with the extra PSRAM aren't that much more, but are a little bit harder to come by reliably. The problem with a raspberry pi is they are power hungry as heck. It's a bit hamfisted for an e-reader. You may as well just run some EPUB reader software on a linux desktop over HDMI with it. The power saving from e-ink won't matter. I mean, if you really want to save on eye-strain get a nook because doing this with a raspberry pi is like going fishing with a battleship. And thank you! I appreciate it when people let me know they enjoy my work. I'm getting an E-PUB reader working on a WROOM. Right now I'm neck deep in making a zip library that allows you to stream the contents directly out of the zip file without loading them into RAM or storing them in flash uncompressed (but you can if you want/need to). EPUBs are just zips renamed, so I'm treating the entire zip archive as its own little read-only filesystem with all the EPUB html and image content. :) No RAM use - except for a small amount of temporary block buffer for the decompressing stream. My end goal is to get it running on a WROOM, and running quickly on a WROVER.
Real programmers use butterflies
-
For $10 I'll just get an ESP32 WROOM devkit. You can get the chip itself for like $2 but that's without all the supporting hardware to make it go + program it. They're dual core 240MhZ with like 300kB of RAM available and 4MB of flash. WROVERs with the extra PSRAM aren't that much more, but are a little bit harder to come by reliably. The problem with a raspberry pi is they are power hungry as heck. It's a bit hamfisted for an e-reader. You may as well just run some EPUB reader software on a linux desktop over HDMI with it. The power saving from e-ink won't matter. I mean, if you really want to save on eye-strain get a nook because doing this with a raspberry pi is like going fishing with a battleship. And thank you! I appreciate it when people let me know they enjoy my work. I'm getting an E-PUB reader working on a WROOM. Right now I'm neck deep in making a zip library that allows you to stream the contents directly out of the zip file without loading them into RAM or storing them in flash uncompressed (but you can if you want/need to). EPUBs are just zips renamed, so I'm treating the entire zip archive as its own little read-only filesystem with all the EPUB html and image content. :) No RAM use - except for a small amount of temporary block buffer for the decompressing stream. My end goal is to get it running on a WROOM, and running quickly on a WROVER.
Real programmers use butterflies
:laugh: Oh wow, your analogy is killing me with laughter. "fishing with a battleship" he he he. "It is a cheap battleship" he feebly replies.. :doh: Letting you know the tales of your adventures are fun reading are the least I could do.. You go gettem! Sounds like you're a long way through the task of beating those epubs into submission. Love it. :thumbsup:
-
For $10 I'll just get an ESP32 WROOM devkit. You can get the chip itself for like $2 but that's without all the supporting hardware to make it go + program it. They're dual core 240MhZ with like 300kB of RAM available and 4MB of flash. WROVERs with the extra PSRAM aren't that much more, but are a little bit harder to come by reliably. The problem with a raspberry pi is they are power hungry as heck. It's a bit hamfisted for an e-reader. You may as well just run some EPUB reader software on a linux desktop over HDMI with it. The power saving from e-ink won't matter. I mean, if you really want to save on eye-strain get a nook because doing this with a raspberry pi is like going fishing with a battleship. And thank you! I appreciate it when people let me know they enjoy my work. I'm getting an E-PUB reader working on a WROOM. Right now I'm neck deep in making a zip library that allows you to stream the contents directly out of the zip file without loading them into RAM or storing them in flash uncompressed (but you can if you want/need to). EPUBs are just zips renamed, so I'm treating the entire zip archive as its own little read-only filesystem with all the EPUB html and image content. :) No RAM use - except for a small amount of temporary block buffer for the decompressing stream. My end goal is to get it running on a WROOM, and running quickly on a WROVER.
Real programmers use butterflies
If you use it for a color e reader do you need to worry that much about power? It seems like a few physical switches would let the device be powered off most of the time. Click a switch to advance to the next page, power on, page renders, power off. (Screen still displays) Slow human reader will take seconds to read the page.
-
If you use it for a color e reader do you need to worry that much about power? It seems like a few physical switches would let the device be powered off most of the time. Click a switch to advance to the next page, power on, page renders, power off. (Screen still displays) Slow human reader will take seconds to read the page.
Powering an RPi off and on like that creates an issue, in that it runs an actual OS. Turning back on isn't instant. Sure it might be able to be done, but whatever can be saved in power on an RPi it still pales in comparison to the savings of using an ESP32 instead.
To err is human. Fortune favors the monsters.
