Feeling kind of overwhelmed at the moment

honey the codewitch

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.

Mike Hankey

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

Greg Utas

A display that has to be partially controlled by fiddling with the device's power system?! :laugh: Either you have a high tolerance for nonsense or you love a challenge. Probably both. :)

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

honey the codewitch

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.

Mircea Neacsu

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

honey the codewitch

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.

jmaida

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

honey the codewitch

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.

jmaida

understood. you definitely know what you doing.

"A little time, a little trouble, your better day" Badfinger

raddevus

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 :rolleyes:

Mike Hankey

raddevus wrote:

But, if you don’t complete the work, they’ll never correct their mistake. ~Engineer’s Paradox

:thumbsup:

The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com

Sander Rossel

honey the codewitch wrote:

The other option is forking the driver for this device. Anyone have any opinions on that?

That's forked up!

Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript