Benchmarking Code

=How to Setup code to be benchmarked= We need to execute any piece of code that we think might slow down the whole loop (mathy functions, communication... most of it) about 1000 times (more? less? enough so it lasts long enough to time), time it, and compare to the total time for the whole code loop to execute. This will tell us which parts of the code are slow... and we'll use this to limit the number of times we run those parts in the final code. A "for loop" can be used to run a block of code, with some sort of Serial.println("DONE!!!!"); message that tells you when it's complete, so you can stop the timer. If you want to work on this, the first task is writing up a basic outline of the procedure you're following to benchmark on the Wiki; then choose some code to test and put it inside a For loop, compile the whole thing. Then, when the Arduino is around, run it on the actual micro-controller and time it.

Timing

 * What sort of system time logger does arduino have? this will be a better solution for fast functions to record their time than running it 10000000000000 times.
 * Time the whole function call, not just the contents of the function
 * call main program, will know if we even need to work on this at all; working from the top has this benefit, binary search
 * once we know which high-level functions are slowest, trace down through them and call subfunctions so we'll know whats being slow and can address it

Theres a built in function millis that returns the number of milliseconds since the current arduino program started running. Or similarly theres a micros function for more precision. Both of these functions return unsigned long's. Using these should be pretty trivial. We could do something like the following say.

unsigned long time; time = micros; //method to test testMethod; //display output Serial.print("Test method required "); Serial.print(micros-time); Serial.println(" micro seconds.") ; time=micros;

The micros counter wraps around after 70 minutes and millis 50 days so that won't be a problem if we are just testing functions. Here's the link to the arduino page on this http://arduino.cc/en/Reference/Millis.

Optimization Strategies

 * optimize speed of the code the main functions
 * dont worry about functions that arent called too frequently (tack)
 * how do we deal with functions which are toooooo slow?
 * speed up
 * call less frequently
 * using interrupts maybe might speed it up? seems like it would be most useful for data aquisition/feedback data from motors
 * sail more efficiently (ie set corridor width depending on wind speed, smaller for faster wind)

Boat Performance from speed of code execution
Not executing fast enough has implications.


 * rudder position (react to GPS coordinate,compass heading) - most important for station keeping; run separate program that updates faster for station-keeping (we need to do some thinking for station-keeping; determining when to start leaving & which direction & speed of leaving prediction; determining how to stay inside the box...)
 * off target (not pointing in the right direction)
 * might still be making progress towards our target, inefficient
 * off the course
 * might still be making progress towards our target


 * sail position (reacting to changes in wind/strong winds
 * fun project: set up wind sensor (or get some data that collects every second) and take a look
 * gusts
 * will be pushed around a lot more
 * heel too much
 * gusts go away in about 5 seconds and then return to the average direction/strength
 * dont want gust data to be taken as the wind condition, this will cause us to trim our sails wrong
 * averaging wind data could help with getting the general picture... but maybe not. think of way to get the best idea of the true, average wind conditions (reject some wind data)
 * direction of wind
 * affects efficiency of sailing (speed of boat)


 * canting keel in wrong position (detect pitch roll yaw of boat)
 * boat tipping too much one way, will probably completely stop forward motion
 * relate to boat heel (tipping)

Speed goals

 * response speed is reliant on the speed at which we can get reliable data
 * collect data for longer and averaging will mean that its more reliable, but slower response
 * no sense responding to data that hasnt changed
 * most efficient sailing: to respond properly to rocking from waves, changes in wind, execute loop in 1/4 second (???)
 * less efficient: 50% chance that we'll still be doing approximately the right thing, execute loop fast enough to meet this
 * also consider speed of implementing non-critical functions (ie. sending data back via zigbee that will help future runs, stress analysis)

= Benchmarking Results=

=External Links= Sample benchmarking of if-else-if vs switch-case