|
The guy sounds like a real ass. I'm betting many more jump ship.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Hmmm... maybe I shouldn't join this meeting which just popped up. 
|
|
|
|
|
Garg has done this at least once before, so no one should accept his "apology". I hope every single senior executive leaves his company.
|
|
|
|
|
This guy appears to have shot himself in the foot. Good luck with the SPAC funding.
"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?"
|
|
|
|
|
Rick York wrote: This guy appears to have shot himself in the foot head.
I can see him "leaving for new opportunities" sometime in the near future.
Anyone can manage a company when everything is perfect; handling problems is the true measure of a good manager.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
A lot of CEOs are high functioning psychopaths. Sounds like he's one.
|
|
|
|
|
OriginalGriff wrote: I wouldn't call "three" a "mass", but that's journalism for you
We're talking about the company leadership, three (in a day, from the looks of it) is a big number.
Cheers,
Vikram.
|
|
|
|
|
Only the right air letters come down to earth. (11)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Right - R
Come - anagram indicator?
R + AIR LETTERS = TERRESTRIAL
|
|
|
|
|
Yep! YUAT (is an anagram of an acronym) 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Oh very good, I was nowhere with this one.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
|
 TBH I don't think Azure is much better. I've not used AWS since the very early days, but would bet that's 'up there' too!
|
|
|
|
|
I've spent two (three?) elephanting days trying to write code to communicate with a TFT display over an 8 bit parallel bus and have gotten absolutely nowhere.
I even have a reference implementation someone else wrote that works that I've been following.
I went as far as to log every time a pin went high and low, and compared the output of theirs with mine, and am not seeing any significant differences.
I'm completely flummoxed. This is some nonsense. I rarely have this much difficulty with code.
The problem is there's no decent debugger, so everything has to be logged, but it's time sensitive too (i think). Then there's the fact that I have a layer to do the 8-bit bus I/O (software bit banging the pins on and off) and then built on top of that are the actual display drivers, and the trouble is there's just a lot of complicated code that all has to work right before you get *anything* to show up on the display.
I'm just airing this because sometimes putting a problem out in the world makes a solution come to me.
Real programmers use butterflies
|
|
|
|
|
Forgive me in advance but you have a logic analyzer to watch the bus right?
If you don't, beg, borrow or steal one.
|
|
|
|
|
I need 12 lines: 8 data lines and the 4 control lines (DC/CS/WR/RD)
My salae has 8. I don't have the money for a good 16 line analyzer. I could buy a car for that.
Real programmers use butterflies
modified 7-Dec-21 21:02pm.
|
|
|
|
|
|
Not me. I don't buy new cars. The most I've ever paid for one is $5000.
Real programmers use butterflies
|
|
|
|
|
Have you verified that the reference application will work with your hardware? I would do that first or all else will be hopeless.
When I have been in a similar position I did that first and then I cloned the sample and gradually tweaked it while verifying it still works very often.
"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?"
|
|
|
|
|
Yes, I have.
I want to clone but, it's written significantly different than mine.
It relies very heavily on the preprocessor, and uses static variables such that you can't actually use that code to control multiple screens on a single device.
Despite it being a class (TFT_eSPI), it just delegates to "global" (static) members defined in CPP source files.
I don't want my code to operate like that for a number reasons, not the least of which is that my codebase is already in use and I don't want to dramatically change the behavior of existing driver code, even as I add new drivers and improve the performance of the old ones.
Edited to add: I've been trying to think of a way to do it incrementally without completely breaking encapsulation but so far ... wait I may have just come up with an idea. 
Real programmers use butterflies
|
|
|
|
|
Teaching my granny to suck eggs here, I'm sure, but...
When I've met this before, it's generally timing: making sure all lines are firing at the right moments so the "data" lines are stable before the rise in the "Write" pulse gets to the critical level.
To check that, you don't need all data lines - just a couple and the control lines.
See exactly what the reference code is doing, and compare that to your code. You may find a signal is lagging or leading the data and that can ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) up the whole thing. Or that the whole of your code is too efficient (I've had that and it's a PITA) and you are just too quick for the display.
Good luck!
"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!
|
|
|
|
|
I was going to suggest this too. Watch the control signals and at least one data, preferably one you know changes the most.
Also,
honey the codewitch wrote: I have a layer to do the 8-bit bus I/O (software bit banging the pins on and off)
might be the source of the problem depending on how it is implemented. Since it is a parallel bus all bits have to change at the same time (using ANDs or ORs or XORs) otherwise the different rise times of the bits can trigger a bad command or cause the command to be ignored.
|
|
|
|
|
No 4 channel oscilloscope handy? - if not, maybe time to steal one somewhere. Even for my hobby tinkering it is extremely useful.
Of course there is a crazy price range here but the cheaper ones (for example Rigol 1054Z) are in a range where I prefer not driving any car that can be bought for the same price.
Synchronization would be tricky though - maybe you will have to sacrifice a data line to see CS on both for synchronization. Or you need to find a 4 channel scope with external sync, but not sure about the price range of those - from what I read, external trigger input is more of a thing with dual channel scopes (so maybe get two of those)
|
|
|
|
|
Make soup.
Really, stop what you're doing and go make soup with all the scraps you have in the fridge.
I helps.
I did that yesterday and by miracle (and RTFM) , InstallShield decided to work this morning.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: Make soup.
Chicken soup, by preference. Get some real use out of the dead chickens that you've been waving over your code...
(Sorry, there appears to be no Chicken Soup for the Engineer's Soul  )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
