C: Returning an array from a function into a variable

[IDEngineer]

tell me any programming language that is as fast as C/C++/assembly yet as safe as ADA/Phyton/Java?

"Safety" is mostly a function {wink} of the person behind the keyboard, not the choice of language. Many may find this shocking, but it is actually possible to write "safe" code in Assembly, or C, or C++.

"Safe" languages are attempts to make programming errors less likely or less harmful. But they are most definitely NOT a requirement to achieve "safe" code. And by the way, they are definitely not a guarantee of "good" code either.

[IDEngineer]

inside the EE_Reads function around the lines that actually need it, no need to have disable during the overhead for calling and returning from the function

Exactly.

Also, it's likely the actual number of instructions that need interrupt protection is extremely small. For example, in the Microchip PIC family the only thing time sensitive about writing to on-chip EEPROM/flash is the "magic sequence" that enables writes. The writes themselves are not time sensitive, and in fact complete asynchronously from the code that causes them (so the CPU can go off and do other things if desired while the write finishes).

Reading from EEPROM/flash has no timing constraints at all. I wonder if the target hardware in the OP's system really, actually needs interrupt protection for READS from EEPROM/flash....

[mikerj]

inside the EE_Reads function around the lines that actually need it, no need to have disable during the overhead for calling and returning from the function

Exactly.

Also, it's likely the actual number of instructions that need interrupt protection is extremely small. For example, in the Microchip PIC family the only thing time sensitive about writing to on-chip EEPROM/flash is the "magic sequence" that enables writes. The writes themselves are not time sensitive, and in fact complete asynchronously from the code that causes them (so the CPU can go off and do other things if desired while the write finishes).

Reading from EEPROM/flash has no timing constraints at all. I wonder if the target hardware in the OP's system really, actually needs interrupt protection for READS from EEPROM/flash....

As always care is needed given the limited context provided.  It's possible the OP is attempting to call EE_Reads() from both an interrupt handler and the main loop, in which case moving the interrupt enable/disable inside the function invites problems.

[IDEngineer]

It's possible the OP is attempting to call EE_Reads() from both an interrupt handler and the main loop, in which case moving the interrupt enable/disable inside the function invites problems.

If he's already inside the ISR, disabling interrupts won't change anything. Unless he's working in a multi-priority interrupt system, which I strongly suspect he's not given the tone of his questions.

A much bigger potential problem, if he's doing what you suggest, is that his ISR could invoke the function while the foreground is already in it. Is his read function safely re-entrant?

If he's trying to use non-reentrant code both inside and outside his ISR, he has a lot more to worry about besides passing a (potentially local, and thus locally deallocated) array on his stack which was his original problem. I would humbly submit that he's in way over his head and needs to seriously reconsider his overall architecture. It's very, very seldom that an ISR should be sharing executable code with the foreground, or calling functions at all. That's a pretty dense minefield for someone who doesn't think to pass a pointer instead of an entire array.

[noname4me]

Just to add a little about the application:

The reading and writing to the EEPROM (actually flash emulating EEPROM) on an STM32F103C8T6 is to be done only at the beginning of the application for setup/calibration functions.

The USB will be used to communicate with the application to pass parameters to the application to store/read from the EEPROM.

Otherwise, the application reads from ADCs about once every 250ms (interrupt handled), outputs a PWM signal, and spits out the readings over UART.  There are other bits that are changed in order to alter the state of connected hardware.

The EEPROM is read/written only in polling mode, because there was no requirement to read/write the EEPROM after the initial start of the application.  I disabled the interrupts because I was fearful of having the flash "unlocked" while the interrupts were active, just in case something unintended happened.

I will take on board the suggestion to move the disabling of the interrupts for only those functions that need to have the interrupts disabled - this will probably mean moving it to the EE_Writes() function, and removing it from the EE_Reads() function, but I will test this later today, as I will need to ensure that I am not opening the flash up to random writes.

The reason why I didn't pass the pointer in the first place, and used a returned array was because this was a library that I had downloaded online and was using in my own code.

When I tested the code some time ago, this worked as it was, so I did not think to refactor it in any way (don't fix what ain't broke) - but you are correct that I am a beginner in terms of programming.  My main focus is to build R&D protoypes that allow me to test other aspect of the design, the firmware is ancillary to that function.

All the tips, and discussions around it are really helpful to me to understand how I should be thinking about the code/system architecture, so all is appreciated  - like I said, any tips will be welcomed.

[NorthGuy]

The EEPROM is read/written only in polling mode, because there was no requirement to read/write the EEPROM after the initial start of the application.  I disabled the interrupts because I was fearful of having the flash "unlocked" while the interrupts were active, just in case something unintended happened.

How about you finish all the initialization first, then enable interrupts?

There's no need for each initialization piece to worry about interrupts. It is better to let all  your initialization code run with interrupts are disabled. Most importantly, the initialization that comes after you have read EEPROM, can still enjoy disabled interrupts (which is not the case with your current code).

[noname4me]

Hi,

I just looked again at the code:

During development I have a function "processUSB()" running in a while(1) loop so that I can test this function - actually, this code will not run on those boards on which this setup has already run (there will be a "setup performed" flag that once written to, will signal the code to skip this part of the application.

Long story short: Yes, this code can be run before interrupts are even enabled in the first place.

Do you know if the HAL USB implementation uses interrupts?

That would be the only reason why I would need interrupts enabled at the point this code will run...