This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What is the best place to update characteristics from?

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()?

Parents
  • I tend to handle processing / transmitting data in the ble_on_radio_active_evt handler, testing for if(!radioactive). This is convenient as I know that I have time until the next radioactive period without expecting interruption from the softdevice. It's not ideal if you need minimum latency though as the packets can only be transmitted after the next connection interval.

Reply
  • I tend to handle processing / transmitting data in the ble_on_radio_active_evt handler, testing for if(!radioactive). This is convenient as I know that I have time until the next radioactive period without expecting interruption from the softdevice. It's not ideal if you need minimum latency though as the packets can only be transmitted after the next connection interval.

Children
No Data
Related