|
|
Started learning Rust; bought a book, took as Udemy class but, as usual I got side tracked on 20 other things and haven't got back to it.
The last research I did someone was porting Rust to the AVR platform, don't know how that has progressed, but would love to see it.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
I originally started with the rust book (https://doc.rust-lang.org/book/README.html) and I found it quite good. This was some time ago, and I see they have a complete rewrite which they recommend now. I'd start there.
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|
As you might have discovered yourself, there are plenty of resources out there. The free official Rust Book[^] is a quality resource. Microsoft's Learn content also has a good set of tutorials on Rust - Take your first steps with Rust - Learn | Microsoft Docs[^]. As someone else suggested, solving exercism.org's Rust track - Rust on Exercism[^] - is a good way to get good at the language.
Finally, if you get stuck on something please feel free to hit me up and I'll be happy to answer questions that you may have. The Rust community is generally quite friendly and you should feel free to ask questions on the The Rust Programming Language Forum[^]. Good luck and happy trails!
|
|
|
|
|
Alec Baldwin tried learning "Rust," but that didn't turn out too well.
Will Rogers never met me.
|
|
|
|
|
|
I wrote a video display driver for an RA8875 display controller.
I need it because I use it in one of my commercial projects.
Well, it works "fine" (a bit slow, but the controller is slow) except in one demo.
I am trying to draw a series of rounded rectangles of random size, random coordinates and random colors.
The code is relatively simple and should be innocuous. It also works when it's used as part of a larger routine.
But when I simplify the code, remove the big routine, and just run a lines demo followed by the rounded rectangles the whole MCU freezes solid during the 3rd iteration. (Always in the same place but that doesn't matter because even randomization yields the same result boot to boot. There's no real RTC or any sort of non-determinism so freezing in the same spot every time isn't much of a clue in this case).
I need to fix this, or at the very least verify it will never happen in my commercial project but I am totally stumped.
What a morning.
To err is human. Fortune favors the monsters.
|
|
|
|
|
If your "main" can't call your new extracted routine, then you still have dependencies. That's what I use "statics" for (real or simulated).
"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
|
|
|
|
|
it can call it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I know sfa about this. But could it be a timing thing, like the simplified code running too fast and overloading the MCU?
|
|
|
|
|
It doesn't happen when it's part of a larger routine, and basically it's just spinning a loop for 90 iterations drawing rounded rectangles - using draw::filled_rounded_rectangle<>() . The 3rd time it begins that loop (which itself is part of a larger loop) it freezes about 5 or so iterations in.
Not when it's part of the larger subroutine though.
To err is human. Fortune favors the monsters.
|
|
|
|
|
you may be cheated of memory captured by calling routine. i.e. statics, call stack, ...
|
|
|
|
|
A long time ago I got assigned to fix an issue that sounds similar. C code, back in the DOS days. The previous person that worked on it couldn't solve it and jacked up the stack size. This allowed it to run longer, but didn't fix the underlying problem.
Turns out it was using calling convention (Pascal? It has been a long time...) so that the called routine would clear the stack and not the caller. And the function signature did not exactly match between the two. As a result, two bytes of the stack were not released. After X-iterations through that routine, it ran out of stack space and crashed.
After correcting the function signature, app ran. Could also trim back the stack to a tenth its size...
Not sure if any of that helps. But maybe it will trigger some out of the box thinking....
|
|
|
|
|
I wish it was a stack leak issue. It's not too hard to track those down once you identify them. But yeah, thanks.
The ESP32 will notify you if it reboots due to stack overflow vs. something else, so that's helpful. It doesn't freeze though. Or at least, it shouldn't.
Arduino disables the watchdog timer I think, but if it didn't, this would be causing a reboot.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Back in the day when I did deal with this was the early 90's, and the diagnostics weren't as good. The only way I found this issue was to trace through the generated assembler for that code.
I actually enjoy a challenging bug hunt, it really gets the creative juices going. And solving a hard one is quite satisfying.
I don't do much embedded controller work anymore, or I would offer to look at this with you...
|
|
|
|
|
Does it happen with straight rectangles? At the same spot?
What happens if you add a fixed offset to each rounded or straight rect?
What happens if you change the seed for the pseudo random generator?
How is the corner rounding calculated?
Try to round only one corner of each rect. Which corner blows? See previous. This might be useful as a primitive. Roundedrectwithcornerfkags
|
|
|
|
|
It doesn't stall with any other driver. The rounded rect code has nothing to do with the driver, which is completely decoupled from it.
I will try changing the seed, but i'm not sure what it will tell me if the problem changes with it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I am thinking there is an issue/edge in underlying trigonometry code that is calculating the rounded corners.
Changing the seed might work without issue or blow up on a different iteration. It would help point to an edge case.
Also, is it possible that it is blowing on the first pixel of the next figure?
Have you tried displaying rounded rects starting at 1 pixel and increasing 1 pixel per iteration?
Did random kick out a negative due to sign issues?
|
|
|
|
|
4, again:
🟩⬜🟨⬜⬜
🟩⬜⬜⬜🟨
🟩⬜⬜🟩⬜
🟩🟩🟩🟩🟩
⬜⬜⬜⬜⬜
⬜⬜⬜⬜⬜
"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!
|
|
|
|
|
Woke up at 12:45 am and.did the puzzle.
Wordle 273 4/6
⬜⬜🟨⬜⬜
⬜🟩⬜🟨⬜
🟩🟩⬜⬜⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 273 3/6
⬜🟩🟨⬜⬜
🟩🟩🟨⬜⬜
🟩🟩🟩🟩🟩
"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
|
|
|
|
|
Wordle 273 4/6
⬜🟩🟨⬜⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
|
Today, that song would've been called "Hey boy hey girl hey agender hey transgender hey bigender hey cisgender hey genderfluid hey genderqueer hey intersex hey gender variant hey third gender hey Apache attack helicopter"
And people would still cancel them because the title is not inclusive enough.
|
|
|
|
|
You Joke, but my wife is a nurse and they had to change the check-in program to something like that !
Ed
|
|
|
|