Exactly, there is a big difference between multi-million dollar communications/observation satellites and cubesats, which can now be built and flown for under $100k. There is no reason or budget to use radhard chips with that sort of budget, when the thing will probably fail or re-enter the atmosphere before radiation damage matters.
The satellite I'm working on will be LEO, but fairly large, to do earth observation (SAR). The subsystem I'm working on uses a radiation hardened SPARC chip from Gaisler (Leon4). It's a fairly popular choice nowadays. We do use an RTOS, although I've largely been writing bare-metal boot loader code and drivers so it's not my area of expertise. Pretty much all of our buses/interconnects/CPUs/FPGAs are space-grade, with ECC/EDAC memory and nonvolatile storage.
The Gaisler drivers are hideous if you're doing anything more serious than basic interface testing. Good that you are rolling your own. Consider the -mflat compiler option which can improve timing jitter and reduce memory pressure by avoiding spilling of unused registers :D
Can you elaborate a bit regarding the -mflat compiler option? Why does it improve timing jitter etc? I am not sure I understand the description from the GCC docs. Is it disabling the register windows? Isn't that one of the big selling points of the SPARC architecture?
There is a finite number of register windows, usually 8 but only 7 can be used because the 8th serves as "sentinel" to detect over- and underflow.
Once register windows are full (a function call wants to activate the next register window but there is no unused window left) window overflow occurs and a trap handler is activated.
The trap handler "unwinds" the register windows and stores all the contents in memory (stack). Now the next function can continue with an empty set of register windows. Once you return from the function, the contents of the windows have to be restored (window underflow trap).
Problem is that the trap handlers can't know which of the registers in each window were in use. Therefore all have to be saved/restored. This ratio will worsen when you write smaller functions that use less register and nest deeper.
So there are two issues: 1. You can't really know at which point in your program that underflow/overflow occurs because it changes depending on the exact path of execution through the program. 2. Unnecessary memory write/read operations. While ca. 120 x 32-bit words is not that much, with an 8-bit wide SRAM, some waitstates and EDAC this might be noticeable. (Consider that the LEON processors have a data cache for read access but for writing only a "store buffer" that queues few memory writes)
Using -mflat every register is saved by the caller/callee (as ABI demands) on the stack. This means that the memory accesses are predictable and spread out over each function call.
So, my personal conclusion is that register windows are an intriguing idea on the surface but become useless when you aren't writing 80s spaghetti code. There were many similar ideas at that time, e.g., Am29000.
We’d considered using mflat, but we’re not that performance constrained (and prefer the slightly smaller binary size with register windows enabled). I may do some profiling of the under flow/overflow interrupts though since you’ve now got me second guessing myself.
Registers asr22/23 contain a cycle counter that you can use to time stuff. If it's not present, there's a register in the DSU that counts cycles but that requires an access via the AHB bus. You can measure a lot of things with those cycle counters, like context switch and interrupt handling times, memcpy vs naive for-loop, linear vs. binary search on small arrays...
I'd expect a few microseconds per overflow at most but it depends a lot on the characteristics of the system. Of course, if the application is not sensitive to a few microseconds here and a few microseconds there that optimization might not be worth it.
The satellite I'm working on will be LEO, but fairly large, to do earth observation (SAR). The subsystem I'm working on uses a radiation hardened SPARC chip from Gaisler (Leon4). It's a fairly popular choice nowadays. We do use an RTOS, although I've largely been writing bare-metal boot loader code and drivers so it's not my area of expertise. Pretty much all of our buses/interconnects/CPUs/FPGAs are space-grade, with ECC/EDAC memory and nonvolatile storage.