|
feel better now, dan. you remind me of my kids when they were small. 
|
|
|
|
|
|
This is true. I have a friend who used to make ginger ale and root beer and sell it at festivals. He mentioned the recipes are virtually the same. The main differences are root beer has a bit more vanilla and has caramel for coloring.
"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?"
|
|
|
|
|
I think you will find "Root beer" is very much a north american thing, certainly not in Oz.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
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
|
|
|
|
|
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 
|
|
|
|
|
I think this might be one of the rare cases where the code doesn't quite speak for itself and one could consider if a comment potentially could be somewhat beneficial to some individuals in the future. 
|
|
|
|
|
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
|
|
|
|
|
honey the codewitch wrote: and the one that is wired on a breadboard only works when they are disabled
Years ago, on basically a breadboard of a controller using some archaic 8 bit processor that the engineer had wired up, everything worked fine.
When we went to production with PCB's of the schematic, the assembly code would occasionally just blow up, randomly, anywhere. The hardware engineer blamed my code.
One dark and stormy night, I sat on the workbench with an oscilloscope and several probes and discovered there was a race condition on the address select line -- you know, those old processors that had 16 bit address lines but spit out the lower and upper 8 bits serially with an LSB/MSB line to be used as a latch.
Turns out that on the prototype hand-wired board, the latch wire was long enough for the address lines to have settled. On the PCB, the latch trace was really short. So occasionally and randomly, the latch would occur before the address lines to have settled.
We cut the trace, added about 3 inches of wirewrap wire, and everything ran solidly.
The hardware engineer was impressed. It actually was quite a turning point for our work relationship - he never trusted software geeks before, and now he did.
|
|
|
|
|
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
|
|
|
|
|
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
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 
|
|
|
|
|
Well.. that's a new one!
But it certainly a good problem to have!
|
|
|
|
|
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
|
|
|
|
|
You just need to get yourself a More Magic switch
Keep Calm and Carry On
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Thought of the Day will be making a brief return over the festive period, starting Monday (and probably but not definitely ending the following Friday).
So how long are you folks shutting down for? I assume most companies are working up to or on Christmas Eve and restarting in the new year?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
1. Cool
2. You assume correctly in my circumstance.
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
I think our company is following that plan. But as usual, I've booked two weeks off, so today is my last day until 4th January. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
