On 3/4/2014 8:42 PM, Jon Elson wrote: > On 03/04/2014 11:48 AM, Charles Steinkuehler wrote: >> On 3/4/2014 10:55 AM, Jon Elson wrote: >>> Another way this can be dealt with is to have double buffers >>> shared between the two tasks, the "master" task swaps out a >>> pointer >>> to the most recent buffer when it is ready to be used by the >>> "slave" task. Not sure that is a great way to do things, but >>> it alleviates the deadlock situation. >> You are describing a degenerate ring buffer with two elements. > Yes, actually, but if the entire goal is to make sure all > variables passed are coherent, two buffers are all you need.
In these simple cases we are discussing, yes: Double buffering is enough. But it is not always enough. One example is the I2C inertial motion sensor we're using for a self-balancing robot to demonstrate some "non-traditional" uses of the new code Michael has been working on. The IMU update rate is slightly over 1 KHz, which means there could be two samples generated between runs of the 1 KHz servo thread. You _could_ just drop one of the samples, but if you feed them both (properly time-stamped) into the Kalman filter, you'll get better results. So this application needs three slots in the ring buffer (two for storage, and at least one to write into giving the servo thread some time to "do it's thing"). ...and the processing overhead for a 2-element double buffer (or even a single element buffer) vs. an N element ring buffer is essentially zero. The only real overhead comes from the extra memory used. Only the single-buffer case could be made faster, by limiting transfers to atomic data sizes only (ie: how HAL works today). But then you can't communicate anything like a set of six values from the IMU in a single transaction without building some cumbersome req/ack protocol out of HAL elements, which will then require either multiple HAL cycles to propagate or very careful handling of adding multiple threads to the thread list (so req can be seen, ack can be generated, req can be cleared, and ack can be cleared, all in one trip through a HAL function list). -- Charles Steinkuehler [email protected] ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
