|
|
I am consistently 0/0.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Wordle 393 4/6
⬜⬜⬜⬜⬜
🟩⬜⬜⬜🟩
🟩⬜🟨⬜⬜
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I just got a neat little IoT widget but the screen appears to have been wired up to it at gunpoint.
A critical control line (RST on the display) is connected not directly to the MCU, but to a control line (IO4) on the power management circuit for the device. Because of this, the display has to be in part indirectly operated by fiddling with the power system on the device. My existing display drivers simply don't account for such a situation, so I have to fork a driver just for this device.
The source code provided for this device is not accurate to the device - meaning it doesn't work with it. I suspect there was an earlier edition of this device that was wired differently.
I'm in one of those positions where I have to write a bunch of code only to hope it will work when I'm done with it.
And a question just occurred to me.
I have a core driver that is general purpose but mostly works with this device. I could take a callback as one of the template parameters to mess with the RST pin but it adds complexity to the general purpose driver.
The other option is forking the driver for this device.
Anyone have any opinions on that?
To err is human. Fortune favors the monsters.
modified 16-Jul-22 10:52am.
|
|
|
|
|
And as soon as you finish they'll correct their mistake and it all will be for naught.
The most expensive tool is a cheap tool. Gareth Branwyn
JaxCoder.com
|
|
|
|
|
Mike Hanley said And as soon as you finish they'll correct their mistake and it all will be for naught.
So true. . .
But, if you don’t complete the work, they’ll never correct their mistake.
~Engineer’s Paradox
|
|
|
|
|
raddevus wrote: But, if you don’t complete the work, they’ll never correct their mistake.
~Engineer’s Paradox
The most expensive tool is a cheap tool. Gareth Branwyn
JaxCoder.com
|
|
|
|
|
A display that has to be partially controlled by fiddling with the device's power system?!
Either you have a high tolerance for nonsense or you love a challenge. Probably both.
|
|
|
|
|
The power system apparently has 4 controllable GPIO on it. They've hooked the reset line up to it. I think I found a way to hack it without modifying my driver by simply toggling the LCD's reset GPIO on startup outside the LCD driver itself.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Seems the quality control for the display is lacking.
Perhaps, you can sell your fixes before you share.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I think it was probably a design decision they made due to limited I/O available on the MCU. In IoT there are often compromises made, some severe - and I believe this is one of those cases.
To err is human. Fortune favors the monsters.
|
|
|
|
|
understood. you definitely know what you doing.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
In another life, I made a data acquisition program that had to work with hundreds of different devices that fell into just a few different categories. My choice was to make separate drivers for each device because they were dissimilar enough and trying to fit them into a one size fits all would add complications for users. Having separate drivers was a hassle for us because we had to manage and keep updated all those drivers, but I've always felt that it's better to inconvenience the programmer rather than the user (just because there are so many of them and they might come after you with their pitchforks).
Surely, other people had the opposite idea and made some super drivers that would combine all the features in an incomprehensible mess. I haven't seem any of those drivers ever used.
Now, mutatis mutandis, I would say you are at the beginning of a road where you face the same decision. You have no idea how clever those hardware engineers are to make the most annoying decisions from a software point of view. I'd bet that in a couple of weeks (or months) you will find another display that does something even more perplexing.
To sum it up: fork!
Mircea
|
|
|
|
|
Fortunately, I think I found a third option involving a minor, but acceptable hack wherein I tickle the reset line myself on boot and just tell the driver there is no reset line.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: The other option is forking the driver for this device.
Anyone have any opinions on that? That's forked up!
|
|
|
|
|
I plan to use this LiteDB in my small application, but can not find LiteDB.dll to download.
show I download source code to build my own version of LiteDB.dll, or just use nuget package to install for my project?
diligent hands rule....
|
|
|
|
|
|
Message Closed
modified 11-Nov-22 12:49pm.
|
|
|
|
|
on that page, I can not find where to download DLL. maybe I missed something...
diligent hands rule....
|
|
|
|
|
Usually it is installed from Visual Studio - Tools - NuGet Package Manager - Manage NuGet Packages
then browse for LiteDB.
You can also download the source code here: Release v5.0.12 · mbdavid/LiteDB · GitHub[^]
|
|
|
|
|
thanks, I build my own version of DLL and so far it is working...
diligent hands rule....
|
|
|
|
|
|
thanks for the link.
I build it in VS2019 and tested the DLL. it is working well...
diligent hands rule....
|
|
|
|
|
Is that lighter than SQLite, heavier, or about the same?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
lighter than SQLite I believe...
diligent hands rule....
|
|
|
|