Actions
Forum Thread Details
  • Replies 34 replies
  • Subscribers 244 subscribers
  • Views 4671 views
  • Users 0 members are here
Related

If I Had a Hammer

jack.chaney56

I used this as a clever draw to get more readers.  The actual intent is to start a discussion and get input from people for software.  Most of the discussions I have seen on the site are about inventing hardware solutions to popular problems.  I guess I am getting overloaded with how many ways there are to turn on an LED.  A significant amount of computer work is actually in the realm of information technology,  Too often what is lacking are skilled individuals that bring an array of tools to the task. The expression "If the only tool you have is a hammer, all your problems look like nails" is a problem I deal with in my professional life. I am constantly faced with vendors who provide the one pony circus (a million ways to make a state machine).

 

Embedded programming is a discipline that requires the developer to be expert at OS scheduling, database management, hardware interfacing, design architecture, and structured objects, as well as proper coding style, and best solution language. It is a constant process of sharpening the tool set to get the best solution. I have taken to putting some tools into retirement as well. Archiving example code and hint/help files is done periodically so I don't have to keep my COBOL skills current, but, by archiving properly, it is possible with a bit of effort, to blow the dust off a few brain cells, and get back in step with my Fortran lines starting in column 7. (...how old is this guy?)

 

Getting back to where I started with this, I wanted to put a call out to all you embedded PROGRAMMERS for tips and techniques and tricks learned that can become the foundation for tool boxes.

 

Tips like:

  • Thinking like a computer
  • Faster graphics and ray tracing
  • Integer only formulas
  • Weight loss (or wait loss) compression
  • T...I...M...I...N...G...

 

Again, some of these are done with hardware these days, but not all solutions have bottomless bank accounts. Sometimes a one chip 8-bit piece of hardware needs to run an 8 cylinder diesel fueling operation.

Parents

  • 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.

Reply

  • 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.

Children
  • in reply to 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 image.  I feel myself slipping into old man dinosaur mode, thinking, "I remember when I was starting out..."