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

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

Reply

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

Children
  • in reply to Instructorman

    >"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

  • in reply to 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

  • in reply to jack.chaney56

    I did want to add a small note for the selection of the units for angle and ratio.

    Both of these are working on my conceptual approach of "thinking like a computer".

     

    People use degrees or radians for angular measurements, computers don't really know the difference, if the radian is conceptualized as pi * a value for units, then altering the number system slightly affords the ability to make 2*214 instead of 2*pi. Then because a 16 bit integer offers +/- for direction of rotation 215 is used to represent 2pi. The other advantage of this is independent of + or - of angles, location is determined by simply masking off the highest bit. Try it with a few operations. Another added benefit will be presented in a future installment.

     

    For ratio, this is simple because if you multiply by a ratio, you need to round and divide out the remainder in order to get back to a whole number portion. Using a power of 2 to represent 100% means, the divide instruction compiles to a right shift logical. In this case 10 bits. Also, rounding can be easily implemented by adding 512 (b0000000100000000) before the shift.

     

    Because pressure and temperature are on opposite sides of my favorite pV=nRT the fact that both are multiplied by 100 provides self canceling.

     

    Just thought I would explain,

    Jack