M5Paper e-ink device for DIY

[hobnail]

Originally Posted by Quoth

That sort of structure is for junk compilers, or pseudo code for assembler for some sort of very primitive microcontroller. Easy to get wrong too.

Whatever floats your boat. I prefer it for simple code like this rather than having the code march off the screen to the right.

[murraypaul]

Clearly you are both wrong, and the only possible correct answer is this:

switch( current_state )
{
case 0: set_lights_green(); break;
case 1: set_lights_red(); break;
default: set_lights_blue();
}



(That is a smily. It indicates that I did not mean the first sentence to be taken seriously, it was a joke.)

[Quoth]

No, @murraypaul, that's fine and safer than returns and one of the ideas I suggested.

[hobnail]

Originally Posted by Quoth

No, @murraypaul, that's fine and safer than returns and one of the ideas I suggested.

Gotta watch out for those dangerous returns.

[j.p.s]

Originally Posted by hobnail

Gotta watch out for those dangerous returns.

About once every 10 years or so I forget to include a break at the end of a new case in a switch block.

[hobnail]

Originally Posted by j.p.s

About once every 10 years or so I forget to include a break at the end of a new case in a switch block.

Now I can blame you: I was going to resist pointing out how switch statements are sketchy because it's perfectly valid to leave out the break, in those weird off-the-wall situations where you want it to fall through. And isn't it the case in C that the value for the case must be a number, int or char? I think in some languages it can be a string or other stuff.

[andyh2000]

UIFlow for m5paper coming in beta this week; full release after Chinese New Year.

https://twitter.com/M5Stack/status/1356465337177280513



Andrew

[Quoth]

Originally Posted by hobnail

Gotta watch out for those dangerous returns.

The problem is more subtle.
1) The section MUST be in a separate function or procedure
2) Fails if copied and pasted into bigger piece of code, the Case, Select or nested ifs do not.
3) You might want the same thing related to that piece of code done after each option. The version with returns incorrectly separates it to where it's called.
4) A call and return may be slower and use more stack. Depends on language and CPU. The Case, Select or nested ifs may translate to skips or short jumps or a jump table.

As a general principle there should only be a return before the last statement in a procedure/function that's return if it's a special error trap.

[jbjb]

Originally Posted by murraypaul

Clearly you are both wrong, and the only possible correct answer is this:

switch( current_state )
{
case 0: set_lights_green(); break;
case 1: set_lights_red(); break;
default: set_lights_blue();
}

For safety, I'd suggest adding a 'break' at the end of the default case - just in case somebody adds another case to the switch and puts it at the end, without noticing the lack of break on the default:

switch( current_state )
{
case 0: set_lights_green(); break;
case 1: set_lights_red(); break;
default: set_lights_blue(); // oops, no break - falls through
case 2: set_lights_yellow(); break;
}

You could (reasonably) argue that putting the 'case 2' after the default is messy, but best to protect against it just in case.

[hobnail]

I've always wanted a little weather station. A sensor/thermometer outside for the temp and then get things like the forecast, sunrise/sunset, barometer, etc. from Open Weather Map.

[stevenaleach]

I'm waiting impatiently for two ESP32 devices to arrive now - one, an M5Paper from DigiKey, and the second an M5Faces kit from AdaFruit because... well... I'll figure out lots of becauses for that little bit of kit I'm sure ;-)

The Paper though: I think I've figured out how I plan to put it to work: With .PDF as an intermediary format, books/papers/notes/etc. can be converted (thanks to the Python pdf2Image library on PyPi) to greyscale images of any desired size. I'll be going with 960 X 1706 ((Y/X)*Y, Y) - that means text that is too small to read in portrait mode (down-scaled by .5625 to native screen resolution) can be read in landscape, scrolling a full-page width window down a quarter screen at a time (that allows for some overlap since the page will take 3.259 landscape-screens to cover). With images adjusted to four-bit per pixel and run-length encoded (with RLE for both pixels in lines and for entire lines since there will be so much white-space involved), tons of "books" should fit on an SD card.

Now the goal of all that is to turn the paper into something I can "print-to" from the computer. Since I can print to .PDF from any application (which might be a desktop publishing program, might be a web browser if I simply want to "print out" a page I'm looking at), and since it would be so easy to set up custom scripts to convert from ePub/Mobi/Markdown/etc. to a .PDF, that means I can convert all the documents I wish I could print if I only had a printer sitting here (I don't) and carry them in a relatively high resolution in my pocket.

I'm picturing an interface where all of the basic features can be accessed with just the three buttons (so page turning or scrolling depending on orientation with the "up" and "down" buttons, center button to select menu to return to library, to jump to a page, to change screen orientation. That way the resulting code could be run on any MicroPython device hooked up to an eInk display regardless of whether the touch interface is available or not....

but... if the touch interface is there, that also allows pinched scroll and zoom (which might come in handy even in portrait view where you might need to upscale to 2X or more to view tiny text underneath an image in a technical document for instance.

Features using the touch-screen should be enabled and disabled from the menu because by relying on the buttons alone, the device can sleep with just the ULP and RTC running (Main cores, memory, wireless, and display powered down) and can be woken for page-turn events, with the current document filename stored in flash and the current page-number and scroll position stored in RTC memory -

Now I'll probably try to also extract plain-text for each .PDF page as well, and store that on the SD along with each page to make texts searchable (just returning a list of pages that a search string appears on - since the page is a bitmap, it won't be able to highlight search results.. .but that's fine).

I'm liking this plan - using .PDF as an intermediary format makes sense, and the 1.7777 upscaled 1706x960 virtual screen size *SHOULD* do quite nicely with most any documents (It would *almost* fill my laptop screen, and it's a whole lot bigger than the 1360x768 display I have turned in portrait orientation next to my laptop that I often use to read .PDFs on. I'd imagine, then, that with 1.25 times the pixel width (in landscape mode, compared to my existing side-monitor in portrait), the M5Paper with it's crisp eInk pixels aught to do just fine as a reader for any and all content I can convert to .PDF if it isn't there already.

[stevenaleach]

OH... and the RLE encoding can be improved since many (most?) pages of most PDFs (those containing text only and no images) will be black and white only (or may have four or fewer shades used). By including a Bits-Per-Pixel specification at the beginning of each page, followed by a pallet (so any two or four out of the 16 possible shades of grey can map to one and two-bit representations as appropriate), black and white pages will take up significantly less storage at eight pixels per byte instead of two (and thus RLE compressed in packs of eight as well). Preserve 8-bit color depth for pages with photographic images (perhaps identified by the script as pages with over a threshold number of shades in use) so that the device can better interpolate while scaling the full-sized image down to the reader's display before 'rounding' to 4 bits - that *SHOULD* improve the quality of down-sampled photos (though they'll look the same in landscape scrolled view since they won't be resized). I think just making note of which pages are really one-bit should be a huge space-safer, with most text-only documents being packed into eight-pixel per byte, run-length encoded horizontally and vertically, high-quality documents pre-rendered on the computer should take up very little space on the reader.

[andyh2000]

As per title the preview version of UIFlow for the m5paper has been released. Shame I can't buy one at the moment.

Andrew

[Adoby]

[Elektron]

Huh. Shame I can't get one...