I am developing a real-time system which triggers an interrupt every few milliseconds. That data is collected in the interrupt. When a memory buffer is full, the data is then processed.
Currently they are 512 byte buffers. I eliminated the heap to free room. This is called on every interrupt to store the data. After the buffer is full, processing occurs (I know -- still in interrupt context)
array_y[array_counter] = y_sample;
array_x[array_counter] = x_sample;
array_counter++;
array_counter &= array_bitmask; // wrap around @ 10 bit boundary
if (array_counter == 0)
{
// Disable collecting of samples
process_samples();
// Enable collecting of samples
}
One thing leads to another
void process_samples()
{
...
on_processing_complete();
...
}
and another
void on_processing_complete()
{
...
if (m_callback != NULL)
m_callback(...);
}
void hrCallbackFn(...)
{
...
ble_hrs_heart_rate_measurement_send(&m_hrs, ...);
...
}
And finally we work our way down to a call to the softdevice to do handle value notification, sd_ble_gatts_hvx. This hangs at a hard fault. I suspect the issue is calling this from within an interrupt context (bad pracice).
My question is: How/Where do I offload the signal processing to be in a 'main thread' priority as opposed to the interrupt context. I am used to having freeRTOS or ucos to give me an event system. Please advise (operating systems are not a requirement for this project).
Is it sufficient to have a 'volatile' variable flag and process before the power_manage(); call in main()?
