|
Graeme_Grant wrote: C1 is still a beta. Not as described by ReSharper
But, I concede this one to you on points since you may be dealing with implanted memories.
cheers, bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I was just about to press the "Post Message" button on an "Oi!" message about the CCC ... and remembered it was Saturday ...
I'm losing track of the day of the week with Herself home full time!
"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!
|
|
|
|
|
|
The older you get, the faster it goes and the less of it you remember.
I don't think before I open my mouth, I like to be as surprised a everyone else.
PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
It's called: being in the moment. As long as it's a good day.
"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
|
|
|
|
|
Wait till you retire, losing track of the days is nothing, I have to check what month it is.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
No joke! I had to go back to work to remember what day it is!
Will Rogers never met me.
|
|
|
|
|
I find between Day-of-week pill containers and doctor appointments, it isn't too difficult to keep track and watch the days slip by.
|
|
|
|
|
I loved my work. I was always ahead of schedule, and turning out solid code because the frameworks and toolchains were just that easy. It was like taking a course that was an easy A, all the time. I was also able to be creative so I didn't get bored - I just kept all the challenge on the design and estimating side of things.
Could I be satisfied with that? No, of course not. I had to convince my team to move to an actual embedded platform instead of using the hobbyist stuff we were making things with before.
Now I'm fighting my toolchains and libraries at every heckin step. Every time I want to do something it takes 3 to 4 times as long as my own private internal estimates.
I actually got big mad yesterday. Like beyond reason and sense, I'm embarrassed to say. Like I had to apologize to people around me. All over computer stuff. At Zephyr RTOS specifically, after battling with it for a week and constantly taking two steps forward, three back. I haven't been that angry in as long as I can remember, and certainly not over something like that.
We haven't rolled any of this out professionally yet. I'm still in the exploratory phase, finding out what I just got myself into, and it isn't pretty.
My big worry is burn out. I stopped coding professionally on traditional scale machines because it got to the point where it sucked the joy out of it for me after doing it for a couple of decades. I left the field for years. I even went into fishpacking for a short period just to get the heck out and change things up!
I don't want that to happen here, and I'm hoping this spate of ugly passes, and I get my sea legs with this RTOS. I need it not be a constant struggle to do everything. I can't work like that, because it's too stressful. I'd rather cut up a bunch of frozen fish.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
Get some sleep. You have programmed your programming into a knot because of the need for speed. Back off, take a break then look at big picture in the AM. Do not let time dictate. Let solutions do that. Easy for me to say but like you say you did it to yourself. Which means you can solve it. Cliche: "Been there, done that."
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Triage, prioritize.
honey the codewitch wrote: using the hobbyist stuff we were making things with before. goback to that ?
RTOS does not deserve free work ... from you.
cut bait and fish and cleam and pack ... in dreams
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Our current way of doing things is not meeting some of our clients needs.
Particularly we need hardware that can drive 40 pin displays.
Arduino and the ESP-IDF do not support that. ESP32s are not a valid option.
STM32 has hardware that will do it, but is not Arduino compatible.
If we want to grow our abilities this is part of it. I will eventually muddle through. I just needed a break and I didn't take one.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
I worked a contract at the beginning of this year that was using STM32's, the company I was working with (Gunnebo) where using a custom compiler that looked to have been developed by "Thales".
It was essentially a C like language (They called it scripting, but it was compiled), for the most part it was regular C, but there where a few things that where not available (Can't remember exactly what now though), but in general if you can do plain old C, you can do this, it was very easy.
The actual hardware's firmware had this "kernel" running on it, and all I had to do was to create these easy C like scripts, run them through a single compiler tool, then put the resulting BIN file on an SD card and insert it into the SD reader on the device.
It also made updating the thing really, really easy too, you just edited using a simple text editor, ran it through the custom tool (In my case I had it as a custom key in my editor) and then copy the bin file.
Works wonderfully with a CI/CD system like jenkins, push the code, the rest is automatic.
I can't unfortunately give you the manual or anything, NDA's and all that crap, and all it was titled as was "Compiler System V9", so I can't give you a name for the system either.
I can tell you however that it was written by
"Dr Dave Rodgman" & "Sergey Gaishun" I don't know if that's any help in tracking it down.
A 3rd party company called "TTP" in Cambridge, England where also involved, but I've heard some not so good things about them, so I stayed away from them.
Anyway, my point here was that I was quite impressed by the way this system worked and how simple it was (I was up and running in a day) but I suspect it may not be easy to find out who to get in touch with to get a hold of it for testing.
|
|
|
|
|
Embedded tools can be hard to set up, but are usually very reliable once they are. Is there any support for the RTOS or some example bootstrapping code or standard development boards? They might help you get to the point where there is only one thing being fixed rather than the hardware and software at the same time.
As an alternative I wondered whether it would be possible to move over slowly, beginning with creating a board that runs a 40 pin display by being sent commands over whatever common bus will work, but keeping the main code where it is. The display board could then be fairly dumb and possibly just hardware rather than any software. The idea effectively being applying the strangler pattern to the current hardware. That might be easier than moving everything in one step in order to enable what is a small fraction of the current functionality, as there will only be a single thing to get working. This idea probably doesn't work for 100 reasons I haven't thought of but hopefully it is harmless to suggest it .
|
|
|
|
|
I don't understand why you would convince your team to make the jump without having done enough exploratory work to find those issues out, but it sounds like you need to go back to the old ways and cut your losses. A sucky experience, but hugely learning. If you do so and continue, I wouldn't be surprised if you eventually make something to take Zephyr RTOS's place which solves all the problems you've found.
While making apologies, focus on the positive! Something like, "I'm terribly sorry, and have learned a ton from this experience. Let's get back on track with the old stuff, and eventually maybe even create a framework that blows Zephyr RTOS out of the water!" or something....
Have fun! after the tears I have yet to find someone who doesn't make mistakes while they are learning. I include myself in that statement!
|
|
|
|
|
I think maybe I wasn't clear. All of this is in preparation. We aren't moving yet. We are working on it. This is part of the process.
ETA: I really need to add, we have to move off of our current platform in order to take work we've had to turn down because of the ESP32 and certification issues.
We can't continue development using the ESP32s going forward. Our current projects work, but we are turning down more jobs than we are taking, because we have to.
We need to move off this platform, regardless of what we move to.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
modified 31-Jul-23 9:23am.
|
|
|
|
|
I know the feeling! Take a day or two and do something relaxing.
I don't think before I open my mouth, I like to be as surprised a everyone else.
PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
You've confirmed the validity of feasibility studies, estimating and not compromising when it is self-defeating.
Working with "hardware" (PLC's, scales, CC readers, etc.), part of (my) "development" was creating "Windows" interfaces to each device for flashing, querying, testing, etc. Those "interfaces" always became part of the production system ... nobody can survive with "black boxes" alone; no matter how "good" they are. Visibility. (If you don't like "Windows", use something else).
Stress comes from uncertainty. I could "prove" where the problems lay. Without proper scaffolding, everything is just a stumble.
"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
|
|
|
|
|
Oh god, this brings me back 15 years ago when the company I worked for decided they needed to update their aging embedded controller that they used in all their products. These products were ocean-going drift weather buoys which needed absolute reliability since you could not get them back for repair.
Back then I was primarily a hardware designer, but I had used assembly extensively. My team was myself, a green hardware engineer I was mentoring, and our firmware guy. Since the old controller used an 8051 mcu, we had a huge library of code and even an in-house developed operating system for the architecture. There were lots of super fast and capable "super 8051" based devices available at that time so for me the obvious solution was to go with one of them.
The firmware guy had other ideas. He wanted an ARM based mcu that ST Micro had literally just released, its datasheet was only "preliminary" no app notes available yet. Also his great idea was to "simply" cross-compile all our source code with an ARM compiler and voila off to the races.
Me being the grizzled old team leader of course I tried to shut that down right away. He proceeded to go to the VP of operations (whom oversaw the VP of engineering and other VPs) and complain. The VP of operations was also a recent hire and thought that going with ARM was a great idea. Can you see where this going?
The near disaster that followed would take up far too much space to describe here but the resulting controller was plagued with bugs both with the ST mcu and of course the cross-compiled code. The firmware guy ended up leaving and the VP of operations demoted to production manager. He left after a short while as well. I was transferred over to production as well. At least I managed to stay employed there.
I'll mention the real big mcu bug though, it turned out to be an extreme EMI/ESD sensitivity so when data was transmitted to the satellite, around 2% of the time it would hard lock up the mcu. No amount of shielding helped. The on-chip watchdog locked with it as well. Even the tiny amount of static generated handling the buoy's plastic hull could do it. ST discontinued that mcu after only a year as well and put out an "improved" version, but by then the damage was done. We lost customers over it and went back to the old design until another team developed an MSP430 based controller that eventually replaced it. Good times.
|
|
|
|
|
That's a heck of a war story.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
I can sympathize.
When I wandered deep into the frustration of the seemingly impossible, I’d entertain the idea of working at an ice cream shop - where the toughest question was ”Do you want sprinkles on that?”
You mentioned leaving the field for a time, working in fishpacking. I immediately flashed on W. Somerset Maugham’s novel “The Razor’s Edge.” The protagonist, Larry(?), leaves everything behind, opting for an uncomplicated life, working for a time in a fishery.
I’m sure you’ll work through it to find your right path.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Dealing with toolchains and libraries is my definition of Hell. I just want to create, to make practical my ideas and needs. The logic is simple. The code is simple. The tools...just so often make it a nightmare by insisting on being clever. And my soul is sucked dry.
I feel your pain.
cheers
Chris Maunder
|
|
|
|
|
Had a discussion with one of my team just last week along similar lines. When "matter of principle" or "good money after bad" come into the conversation, it's time to flip the "go around" switch and get back to altitude and look around. Sometimes it comes down to saying I made a bad decision, let's move on.
I know it is more difficult with hardware involved, but I have a box somewhere of various GPS stuff and other assorted hardware that was shelved after time and money spent.
Relax, do something for a day that takes your mind off the issue. My choice would be fishing, not packing fish but whatever floats your boat 
|
|
|
|
|
Yeah, I find meditative reflection to be helpful, and I can do that with menial labor on someone else's agenda. It also paid marginally better than fishing. It was the polar opposite of what I was doing, while still being work, so it was appealing.
I'm not convinced this is a bad decision yet. The only thing ventured so far is my time and a few bucks for some evaluation boards.
It's just the learning curve is a vertical climb, and I've been fought every step of the way. If I can move past that and get somewhat comfortable, things will be okay. I'm going to spend some more time with it, including taking a course at the end of august on this stuff (much as I don't do well with course style learning, I am learning what I think they'll teach ahead of time and I intend to use the time for Q&A as much as possible)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
I am going through the same crap right now myself.
This toolchain does it this way; that one does it that way; this one has this feature; that one doesn't; this one's feature doesn't work; that one feature is obtuse; .....
Waaay back when, I had a simple makefile, simple library linkages, simple programming structures....Now, it takes two weeks just to set up a project build with all the options working correctly, all the libraries referencing the correct version, etc., etc., etc.
Just yesterday, I wanted to use kdbg on a Linux MX distribution (I have it working on a Linux Mint distro)---could not compile it because of missing modules...and I could find sources/libraries for the modules.
FRUSTRATION!
|
|
|
|
|