ConfigureContinuousModeDualChannel callback seems to be synchronous

[WilliamAtSamraksh]

This is wrt version .11. It looks like the call back for the continuous dual ADC (ConfigureContinuousModeDualChannel) is synchronous. That is, the buffering code is waiting for the callback to complete before it resumes.

The problem is showing up in an app where the time it takes to process the buffer is larger than the time it takes to sample a buffer. Besides possible correctness issues (maybe samples are being overwritten or otherwise lost), things wind up going haywire in the class and eventually exceptions are thrown.

In the callback method, I have tracking on timing and also on invocations of the method. It does take longer than the callback interval, and is never called while still executing. Hence my observation that the behavior is synchronous.

It would be better to have the callback be called asynchronously and let the user check if that happens and decide what to do if things don't finish on time. Since it's the user's problem, pushing it back to the user would be better than having the class unexpectedly start throwing exceptions.

[Nathan-Stohs]

Bill, unfortunately I don't believe MF supports any way to do async callbacks as you describe.

The ADC itself will keep collecting samples the entire time (if setup to do so), but otherwise your observations are correct.

[Nathan-Stohs]

To clarify, I mean I don't think there is a way to do an async C-to-C# callback in MF. Perhaps a C# wrapper class could resolve at least some of these issues but I assume it would incur further performance penalties.

In other words, I think this can only be handled at the C# level and potentially the whole thing is a user problem.

[MichaelAtSamraksh]

• I think it is natural for users to try to do too much in the callback handler. We should guide users to solve fat callback handlers with threading.
• I created a C# class to help users determine callback delay and jitter. The code is in Samraksh\APPS\libTimingStatistics\ https://github.com/Samraksh/MF/blob/master/MicroFrameworkPK_v4_3/Samraksh/APPS/libTimingStatistics/TimingStatistics.cs
• Check if your TinyCLR build is optimized. You should either see "speed-optimized" or "no-speed-optimization" after the Compiler Version printout during the TinyCLR startup.
• For microphone processing, I used a circular buffer, the libTimingStatistics, and a C# thread for computations. In the C# callback handler, I only pushed data into the circular buffer, and signaled the compute thread to do the actual signal processing work. A separate compute thread prevented the callback handler from becoming backlogged. My circular buffer printed a warning when trying to add data to a full buffer, and had the option of overwriting old data or dropping new data. The libTimingStatistics helped profile jitter in the callback handler and slack in the computations, so I could tune the processing to what the eMote was capable of performing in-between ADC callbacks.

[WilliamAtSamraksh]

Mike's approach has pretty much the effect of an async callback, with the added flexibility of handling jitter in processing as well as buffer overruns. It adds the overhead of a separate thread with inter-thread communication.

However, if changing to async callback does not add overhead (it may even reduce it somewhat by not enqueuing callback invocations), then I think it's still the right thing to do. Either that, or else we need to beef up the exception handler in the continuous ADC class so that the exception thrown will make it obvious that the problem is an overburdened callback method.

Right now, users (like me) will point to the class as the culprit when in fact it's the application code. Avoiding this will reduce support effort.