|
Classic C bit-banging.
How we used to do arithmetic before we could afford an 8087.
The "kosher" version looks like this:
union
{
float f;
long n;
} mixup;
mixup.f = floatval;
longval = mixup.n;
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
That is a truly amazing resource. Thanks! 
|
|
|
|
|
..yes you can..il send you my pp acct.🤪🤪🤪🤪
|
|
|
|
|
raddevus wrote:
float fVal = 13.3892F;
printf("Float value ==> fVal :%f\n",fVal);
long lVal = * (long *) &fVal;
printf("float as long ==> lVal: %ld\n", lVal);
That 3rd line takes the address of the float &fVal and what!?! multiplies it times a long pointer? or something?!? 
That's not what it does. It casts the address of fVal to a pointer to a long, and then dereferences that pointer. It's completely unnecessary code. All he had to do was cast the fVal to long and then assign that.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: cast the fVal to long and then assign that.
NO!!!
Casting involves arithmetic conversion, whereas what we are talking about involves treating the data as a bit pattern.
(long)2.0 == 2
but the bit patterns are wildly different.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Unfortunately... 'type punning' (which is the name for casting pointers to pointers of different types) is considered undefined behavior in C and C++ and so frowned upon these days...
Instead, you can use a good old memcpy, which usually gets generated to the same code as the type punning case:
float fVal = 13.3892F;
printf("Float value ==> fVal :%f\n",fVal);
long lVal;
memcpy(&lVal, &fVal, sizeof(fVal));
printf("float as long ==> lVal: %ld\n", lVal);
This sort of thing is often done when you need to get to the individual bits and bytes of a variable, rather than the quantity it represents. For example, a software implementation of floating point arithmetic would do this.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Ah, good to have a name for the thing.
Thanks for providing more insight.
|
|
|
|
|
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. 
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
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
|
|
|
|
|
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
modified 17-Jul-21 1:48am.
|
|
|
|
|
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
|
|
|
|
|
 Oh wow, your analogy is killing me with laughter. "fishing with a battleship" he he he.
"It is a cheap battleship" he feebly replies.. 
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. 
|
|
|
|
|
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.
|
|
|
|
|
DIV.JS[^]
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Not clicking on it, what is it?
|
|
|
|
|
HTML, but only using DIVs.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I'm surprised that hasn't become the new rage.
|
|
|
|
|
but still ... it's a funny joke
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
