If I Had a Hammer

Hi Jack,

I can sympathize.

Using high level programming languages hide a lot of detail you need to learn when going into embedded programming.

Luckily I learned assembly language programming on an old PDP-11 minicomputer.

That experience put me in a great position to dive into all of the microprocessors that came out after.

I think you will find most work today is done in C, which in my opinion was a slight step above assembly language, but is reasonable simple to learn and use.

Depending upon the vender you choose, most have extensive support libraries to implement both simple and complex applications on their products.

Embedded operating systems get interesting.  In my day, yes I am probably older than you, we made simple control systems when we could and used more exotic OS products when the situation warranted it.

I have built some very complex systems without needing an OS, but at the time, I had a great understanding of how the processors worked and how to exploit interrupts.

Timing analysis was my forte, and I did some amazing things just by understanding how to fit functions together using interrupt timers and sometimes hardware additions.

Everyone likes inexpensive tools and there are a host of those available free today.

Arduino, Texas Instruments, Raspberry Pi, MBED, Pickit, and others have excellent free support tools.

Take a good look at Energia, the Russians are making excellent progress with that tool to keep embedded software simple.

They provide very useful examples and have very useful debugging tools.  I wish this type of support had been around in my day.  I used to chase things with an Oscope and logic analyzer.  Both very expensive at the time.

There are also a number of free Operating Systems that you can pick up and learn.  Just be aware, it takes a while to get really proficient with each one.  My biggest problem with them is that you need to learn is what each OS does TO you.  Each OS has interesting implementations to efficiently facilitate your application.  Each can do interesting thing to your embedded software design, especially timing.

So feel free to set up a list of questions, pick a vendor to focus on, and get started.

I like TI, because they have a copious amount of documentation, a good of small to complex devices, all of which you can program with or without an OS using Energia or Code Composer Studio (CCS).

Luckily, there is plenty of support on the web for most of the processor lines, it just depends on what you want to do and how complex you want to get.

DAB

Woth similar background, I totally agree with you!

Enrico

Jack,

Unfortunately, good programmers are something that can't be developed. You can share the tools and examples but the ones that truly understand machine logic are the ones that will shine. There is something to be said for a hardware solution though. There are benefits, and limitations, to having a piece of hardware that has the same function as a set of software. I fully agree that there should be an array of tools and multiple options for completing the same task whether it be cleverly written code, an ASIC, FPGA, or a well designed feedback circuit etc.

Hi,

Thanks for all the feedback. I was hoping to spend most of my day today responding and entering discussions with a bunch of you, but sadly I still need to generate a paycheck, and some excrement has just contacted the rotary impeller, and I must attend to it.

to quote... "talk amongst yourselves"

Jack

Hi Jack,

Interesting discussion : ) I never studied Fortran (although friends did who were studying subjects like chemical engineering I think) but I still had to try to decipher it a while back, because some code I wanted to use was written in that language.

I archive off bits of code that I write, to save effort or at least be able to inspect it and improve on it the next time around.

Also, another tip could be to be prepared to get a book on a topic of interest (or even do a course) - many computing books get old quickly, but the knowledge at the right time is valuable and can save days/weeks of effort so it pays for itself.

Sometimes it is really instructive to think like a computer as you say, and along with that goes becoming comfortable occasionally inspecting compiled output, examining library files, etc. Also another nice tool (occasionally!) is being semi-aware (but not spend too much time on it) of the instruction set and what the compiler is doing, so that when it comes to the (rare) low-level troubleshooting, you have a rough idea of how to follow the content in memory.

shabaz

I have this condition that a good friend remarked about. I always code in assembly, but think in objects.  No matter what language I am coding in I tend to analyze the instructions as to how they compile. Carry over from my old 360 system days when the compile was a job that had to be accounted as well as the runtime. It has saved me countless times knowing what the computer is capable of doing from a bare metal level, before applying high level axioms to the problem.

I have noticed that more and more, the candidates for positions we are getting in (new graduates), are less and less familiar with the concepts of compiler design. I guess optimization is something best left to the experts at Microsoft .  I feel myself slipping into old man dinosaur mode, thinking, "I remember when I was starting out..."

Seems like you have touched a nerve among the more seasoned members.

A couple of your bullet point tips come right out of my teaching philosophy developed over a 25 year career of trying to get novice technologists to develop good coding habits.

Specifically, "Thinking like a computer" and "Integer only formulas".  I have based many embedded systems programming lectures and labs on those concepts.

I have spent many hours single stepping classes of young technologists through a block of code, getting them to process each instruction as if they were the CPU, predicting register values, asserting outputs, and following conditional branch instructions.

The "integer only formulas" approach was especially useful when using an 8-bit microcontroller and a non-floating point capable compiler to do things like Fahrenheit to Celsius temperature conversion.

Overall, I think the pedantic tedium I inflicted on my classes produced a net beneficial understanding of how computational hardware works in concert with code to accomplish useful things.

Ah, the good old days.

>"Integer only formulas"

I noticed even fairly recently (within the last year I think) the difference floating point math makes for firmware. I'm pretty sure it was an Arduino app for an ATTiny I was working on, and as soon as I introduced some floating point math the package size bloated to use up far too much space (we're talking magnitude difference). And the kicker was that it wasn't even something requiring floating point - with just minor tweaks I brought the app size down immensely.

I wish I could remember the exact example, but I'm sure it would be easy to replicate.

-Nico

ntewinkel,

Precisely what I was referring to. Fixed point for calculations saves tons and tons of calculation overhead and saves boatloads of memory. Time for my first contribution to the tools.

Fixed point elements, the 16 bit solution

All data elements have like conversions, and a single set of units. All conversions are done externally to the device, or at the UI level.

Values are all maintained as integers types are:

• Temperature -> absolute degrees K * 100 (0 degrees C stored as 27315)
• Angle in binary radians 360 degrees converts to 32768
• Ratios are all fixed point * 1024 or 100% == 1024
• Pressure is stored in kPa * 100 absolute (1 atm stored as 10129)

Limits of accuracy for equations are imposed based on 16 bit values

• angles (error +/- 0.0109 degrees)
• ratios < 6399.90% for unsigned or 3199.90% for signed (error +/- 0.049%)
• temperature < 655.35 degrees K or 382.20 degrees C (error +/- 0.005 degree C)
• pressure < 655.35 kPa or 6.47 atm (error +/- 50Pa)

Additional limitations based on sensor measurement could be greater

History: [JAC] Original creation when the earth was cooling, Copyright(c) 2016 Chaney Firmware...  Use it as much as you like, as long as I get credit

Jack

Back when I was doing karate, the students who had got to the top of their game went off and looked at other martial arts such as judo and taekwando. When they returned to karate their karate technique was better.

This also works with software and hence it can be useful to look at other languages and areas to improve your own area. I've seen this myself bringing better code segregation and testing to VBA after a period with C#. I'm now doing all my hobby projects in NodeJS to see what that can bring.