Actions
Forum Thread Details
  • Replies 34 replies
  • Subscribers 244 subscribers
  • Views 4684 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.

  • Because this is a software focused discussion... I am giving a call-out for database folks out there.

     

    SQL has become relevant as a language, and has stabilized to a general standard, so, how about some solutions to odd queries.

     

    Jack

  • More software for falling objects, or phun with physics.  This one comes from my video gaming days, and once again showing floating point is highly overrated.

     

    First, units need to be abstracted, so they can be optimized to relate to real time and a form the computer understands, so let's start with time. The units for time, I like to use, are tics (not the bug). A tic is usually an update frequency of some sort. In my gaming days, it was usually 1/30th second (screen update), but lately for my engine management stuff, I upped it to 1mS.  For this I will go with the old tried and true,1/30th second.

     

    For distance, the unit I use is generically "dist", the advantage is, equations now become scale-able, based on the size of the playing field. Speed is always in units of dist/tic, and acceleration is dist/tic2.  In a coordinate universe, up is usually considered a positive direction, and gravity always has a downward action.  For this discussion we won't go into relative viewpoint stuff, because when the physicist was asked "what's up!?", she responded "why, the opposite direction from the local gravitational center". Back to our relative universe, up is the positive vector on the z axis. I need to establish that, because in a "first person" game play, gravity is often constant.  Looking up the information in my handy CRC Handbook of Chemistry and Physics, it says, acceleration due to gravity is -9.8m/s2 at earth's surface, and defining our unit dist as 1/4 inch we can make our conversion.

     

    meter     1000mm        1in            4dist        1sec2

    ------- = ------------ * ------------ * ---------- * -----------

    sec2        meter         25.4mm        in          900tic2

     

    and -9.8m/s2 works out to -1.7148dist/tic2 for integer operations -1 817/1143 dist/tic2

     

    Switching over to vector operations (of sorts), if an object at (x,y,z) is moving at motion vector [X,Y,Z], then at each tic the new object position will be (x+X, y+Y, z+Z). Also, for each tic acceleration action is accounted, and motion vector [X,Y,Z] is updated by {A,B,C} and the new motion vector is [X+A, Y+B, Z+C]. The acceleration due to gravity is {0, 0, -1 817/1143}.

     

    Now, how to deal with that pesky fractional part. It is the imposed error and is managed rather simply by using an error/correction method. In each instance, the numerator is added to the error (error starts as 0). so the first instance the result is 817, the second is 1634. When the error value is greater than the denominator, the motion vector gets an additional increment. In our gravity case subtract one more from [Z], then subtract the denominator from the error value.  The operation progresses 1634 - 1143, and the error value is now 491. The third instance the error is updated to 1308 and the value is greater than the denominator, so Z gets an extra 1 subtracted, and the error is corrected to 165. The pattern continues and gravity behaves exactly as expected.

     

    One more thing to consider. Because object(s) means there is more than one, and the operation gets repeated many times, and gravity isn't the only acceleration involved, error value should have a common denominator, so all the error values can just get added, and tested as a last step.  I like to use 1024, because it is large enough to manage a good amount of error, and if necessary it can be corrected using a logical shift.  This explains why I used it in my standard units for fixed point ratio.

  • in reply to jack.chaney56

    >how about some solutions to odd queries

     

    Versata did this quite well, with their "logic server". Most of a db based web application could be built with simple drag and drop. It was also quite easy to define specialized query objects using human-readable type of logic. You could build some very complex database queries without touching SQL.

     

    They got bought out by Trilogy, but I think the software is still there under some new name.

    Versata BRMS | Built for Big Business

     

    The same person who created that idea went on to later help form Espresso Logic, which has since been bought out by CA. https://www.ca.com/us/products/ca-live-api-creator.html

     

    Not sure how deep they've gotten into the magical SQL queries with the new product.

     

    (I worked for Versata in the early 2000s, before the dot-com bubble burst)

     

    Cheers,

    -Nico

  • in reply to jack.chaney56

    Hmmm. Line seems to have gone dead.

     

    Not sure if the topic drifted too far from a desired discussion, or if the last entry left people in a pile of dust.  Either way, I hope everyone a great universe, and will be happy to drop more info any time.

     

    Jack