How do I get data out of an ISR safely?

[magene]

I've been making decent progress on learning how to use C/C++ to replace an existing C# embedded application. I've cut a few corners along the way and I'd like to see if I can clean up the worst ones. Right now I have an ISR getting pressure data from a UART instrument. My app is a pretty classic state machine and what ever state object is active will need that pressure data. Right now, the UART Callback ISR for the pressure instrument just writes the data to my StateVariable struct in main:

struct StateVariables
{
	double pressure;
	string pressureTimestamp;
};
static StateVariables SV;

void usart6RXIdleCallback(UART_HandleTypeDef *huart)
{
	const uint8_t engrMsgSize = 64;
	char engrMsg[engrMsgSize] = "";
	
	SV.pressureTimestamp = mcuRTC_SBE41.getCPFTimestamp();
	SV.pressure = parsePressureMsg(usart6RXBuffer, sizeof(usart6RXBuffer));
 

Any object that needs the latest pressure value just gets it from the SV struct and can check the time stamp to make sure it isn't a stale value. I understand my SV struct is really just a global variable and globals are not generally a good thing. Although in this case, the only thing that will ever write to the SV.pressure and SV.pressureTimestamp is the USART Callback. Regardless, a better solution would probably be to have the ISR publish the new pressure value to a list of subscribers or stuff it in a list of FIFOs but that seems like a lot of overhead to handle in an ISR that I'm trying to keep as simple as possible. This seems like a standard thing to do in an embedded system and I'd be very interested to learn how real programmers handle this.

Thanks - Gene

[TDK]

I think you're intuition is pointing you in the right direction.

Global variables are okay, if they have a purpose. Yours clearly does. Just make it a global variable and don't overthink it. It would be crazy to add the amount of overhead necessary for a publisher/subscriber system in order to avoid one simple global variable.

If it helps with organization, you can give global variables a prefix or suffix so that (1) you know they're global and (2) they are less likely to collide with local variables. Something like g_SV instead of just SV. If you stick to that scheme, everyone reading it will understand.

Also, you should declare variables modified within an ISR and accessed in the main thread as volatile to avoid the compiler optimizing things out, although it typically doesn't make a difference in most applications.

[magene]

Excellent. Not what I was expecting, but still very good to hear. I've done a fair amount of reading trying to educate myself about what the right way to handle this situation might be. I've read lots of posts about why globals, singletons and the like are inherently evil and will quickly lead to the downfall of humanity. But I haven't seen a viable alternative for a situation like this. Thanks for the comments.

[Pavel A.]

There' s saying that being rich but healthy is better than being poor but sick.

Same about embedded software: robust and reliable but simple is better than complicated but over-bloated.

-- pa

[gregstm]

My moto... keep it simple(=efficient). Global variables are ok when used carefully (..even used them when writing in the very strict Ada programming language). These days, now that I am no longer working in teams, I use lots of global variables. The most important thing I think is to use good/meaningful comments (and meaningful variable names), especially for complex code - it will help you understand your code when you return to it years later...

[magene]

I'm not a wildly experienced embedded programmer so I spend a lot of time trying to glean "best practices" from books and off the web. I'm developing a theory that all the religious fervor about globals, singletons and similar hotly debated programming topics are mostly coming from the non-embedded world. Embedded programmers seem to have a much more pragmatic approach.

Thanks to all for the help and comments.

[gregstm]

Good luck with your endeavours.. there always seemed to be some involved in programming who wanted to turn it into a priesthood... I remember when the "object oriented programming" became the craze in the 1980's - some in our management were wondering whether our near working project should be scrapped and restarted with OOD principles to make it better...