My code is too fast :(
-
So to speak your intention is to fix the wrong wiring by software? Not sure whether this is the correct solution ;)
In this case it is, due to this code targeting primarily hand wired devices. Running everything at maximum leaves no room for any noise or capacitance tolerance, and that's a problem. It's kind of like making software that targets multiple platforms or environments. In those cases, sometimes you have to work with the lowest common denominator. The demo board my optimized code works on is all super high quality components and construction, very well engineered, because it was a board given out by vendors at trade shows, so Espressif put their best foot forward, making these boards absolutely top shelf, but I can't write my code to target that specifically.
Real programmers use butterflies
-
Well.. that's a new one! But it certainly a good problem to have! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Actually it's not. I don't know where the code needs to be slowed down. It could be anywhere. Yikes.
Real programmers use butterflies
-
So to speak your intention is to fix the wrong wiring by software? Not sure whether this is the correct solution ;)
-
Most probably a problem of slope rates (capacitive load of the wild wiring). Ok one can sometimes adjust this by clockrate as a workaround(?). But the chance to burn down the hardware doing like is also always present; not all signals have a schmitt trigger input circuit :)
-
I once stumbled upon a Thread.Sleep(1000) in some code. Asked about it, apparently the code ran too fast, giving no visual cue "while running" to the user. A Thread.Sleep made a light (on a scanner) briefly light up, letting the user know the thing was processed. I guess if it looks stupid and it works then it ain't stupid. Of course this thing actually worked and yours doesn't I guess :laugh:
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
-
My display code is too fast for my displays. Worse, it's only too fast for some displays. And not some models of displays, but certain specific displays are okay. Like, I have two ILI9341s and the one that is soldered together works with my optimizations and the one that is wired on a breadboard only works when they are disabled. *sigh* All that work only to help it fail. TFT_eSPI manages so Bodmer must be sticking delays in his code somewhere. What a zoo. Oh well, at least I'll be occupied today.
Real programmers use butterflies
-
My display code is too fast for my displays. Worse, it's only too fast for some displays. And not some models of displays, but certain specific displays are okay. Like, I have two ILI9341s and the one that is soldered together works with my optimizations and the one that is wired on a breadboard only works when they are disabled. *sigh* All that work only to help it fail. TFT_eSPI manages so Bodmer must be sticking delays in his code somewhere. What a zoo. Oh well, at least I'll be occupied today.
Real programmers use butterflies
The is usually an easier problem to fix than increasing speed. That's the problem I have fought over the last two years and defeated. Anyway, it sounds to me like you need configurable delay points with the ability to minimize them for certain devices and increase them for others. One that's one approach anyway.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
The is usually an easier problem to fix than increasing speed. That's the problem I have fought over the last two years and defeated. Anyway, it sounds to me like you need configurable delay points with the ability to minimize them for certain devices and increase them for others. One that's one approach anyway.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
That might be too complicated, given that 90% of the boards out there need the lowest common denominator code. I think I just need to find the sweet spot. But you're right - sometimes. Maybe most of the time, it's easier to speed things up than slow things down. Unless you can just throw another core at it (I have two)
Real programmers use butterflies
-
Sorry, I have to ask... did you try increasing the voltage yet? Just bypass those pesky 3v3 regulators, they are just slowing things down.
Umm, I want this to work for other people, not just me. I'm not writing it for just me. If the code is 10% slower but works with most devices it won't kill anyone.
Real programmers use butterflies
-
I once stumbled upon a Thread.Sleep(1000) in some code. Asked about it, apparently the code ran too fast, giving no visual cue "while running" to the user. A Thread.Sleep made a light (on a scanner) briefly light up, letting the user know the thing was processed. I guess if it looks stupid and it works then it ain't stupid. Of course this thing actually worked and yours doesn't I guess :laugh:
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
War story from ca1970: We built a factory data collection system for an extremely hostile environment. Part of the terminal was a reader for punched plastic cards, somewhat bigger than credit cards. The terminal "grabbed" the card when it detected the leading edge, sent the data to the host on the next poll cycle. When the host had verified the data, it told the terminal to eject the card. Initially this all happened too fast, and the UX was that the card had just "bounced" in the reader. We had to code in a delay of around 1 second before the users were happy.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
My display code is too fast for my displays. Worse, it's only too fast for some displays. And not some models of displays, but certain specific displays are okay. Like, I have two ILI9341s and the one that is soldered together works with my optimizations and the one that is wired on a breadboard only works when they are disabled. *sigh* All that work only to help it fail. TFT_eSPI manages so Bodmer must be sticking delays in his code somewhere. What a zoo. Oh well, at least I'll be occupied today.
Real programmers use butterflies
-
The wired breadboards work well up to about 1 MHz, then can have some strange behaviour above that. I suspect it is due to capacitance, but could be mistaken on that. The behaviour your describing fits into that kind of scenario. Ken
Absolutely. The thing is though, is that I have to be able to tolerate it. I know it's possible because I'm working with code that does it as a guide, but I'm clearly missing something.
Real programmers use butterflies
