An RTOS which is pre-emptive must run a stack for each task.
One should still write tasks co-operatively (yield to RTOS if nothing to do) otherwise you just waste CPU time, but pre-emptiveness is pretty much essential for avionics with “connectivity” like serial, ethernet, CAN, etc.
The amount of asm is tiny and the code is provided with it. The port is anyway specific to the CPU e.g. STM 32F4xx.
AFAIK airliner avionics use some pricey RTOS products (several come up on a google) and anyway big firms feel much better paying a lot of money 
Avidyne has never been over-resourced and it is not surprising they went for Embedded NT or some such. So long as you strip out the crap (printing, most networking, etc) it should be reliable. Same with Embedded XP which remains widely used.
Delphi died about 25 years ago, anybody who was any good at it will now be over 60, and will have a beard touching the ground Great product but M$ VC++ killed it.
As I posted in the linked random avionics thread, using a PC OS running on PC hardware is just a painful death, or constant pain until death for another reason, in production terms. Fine for building up a Linkedin CV… The way to do this today is some decent ARM32 chip and then your long term production problems will be changing the LCD every so often. The CPUs will run, in some same or similar form, for ~30 years. I got >25 years out of an H8/300 (Hitachi is another long term outfit) and the last few years have been serviced by running down strategic stock of which I have enough for > 10 years.
Peter wrote:
I’d suggest you cannot do an RTOS without some asm code, simply because you need to manipulate the stack pointer and C does not give access to that
It depends. If you aren’t maintaining separate stacks for supervisor mode, and you’re not trying to multitask, the amount of asm you need may be very minimal or even none at all if the hardware defaults the stack pointer to something useful.
But generally you’ll want some asm (for example the ISR) because the C function entry/exit might do things that increase your interrupt latency (e.g. on ARM, the standard stuff it generates with a function pushes some registers that the interrupt response already pushed. On RISCV you can avoid some register shuffling early on in your ISR if you hand code it. Fortunately asm is very much easier to write efficiently on ARM/RISCV which you’ll find in embedded platforms, than it is with x86 or x86_64 (or some of the 8 bit chips you still find like Z80 or 6502). RISCV is probably the best I’ve found for this so far, but I’d still rather write most of the code in C :-)
I would be curious to see a RISCV implementation of Pascal. There is only one ABI defined for rv32/rv64 when it comes to how the stack and functions are defined, so if a Pascal compiler were to use the standard ABI then there’s no reason it couldn’t be mixed with C code.
Especially as today most students don’t do that in raw assembler
I’d suggest you cannot do an RTOS without some asm code, simply because you need to manipulate the stack pointer and C does not give access to that. You have to use some (usually inline) assembler. I could post code examples but it would be irrelevant to the topic, which nobody has answered in recent years
Airborne_Again wrote:
It’s not that difficult.
Only if you have quite a flexible definition of the “RT” in RTOS. Especially as today most students don’t do that in raw assembler but on a higher level abstraction and therefore can hardly control garbage collection timeouts – but this is a different story ;-)
Airborne_Again wrote:
I though it is the language implementation that supports the OS
I would have read the statement quoted by Peter as the marketing version of “… is the only RTOS for which compilers for Rust, C++ 17, … are commercially available”
A simple one… A very simple one
To sell one, it needs to be packed with features.
I can see why someone might want to use windows in avionics. It saves a lot of work if you want to do OTA updates for example. But the avionics near the start of this thread didn’t have that anyway AFAIK. Still, even support for reading CF and SD cards is worth a lot.
Peter wrote:
For example FreeRTOS could not be used with, say, Pascal, because the whole thing is in C (I have never used C++ and never want to).
Anytime you use a high-level language (e.g. Python, as opposed to C) you would need what you call a transition layer to access the OS API. Actually Python is much more tricky in this respect than Pascal would be.
I wrote one [RTOS] myself in the 1980s
Yes, it is not unusual that computer science students do this as part of their university programmes. It’s not that difficult.
I’ve been coding on top of FreeRTOS for a year or more and while you are right in principle, one still needs the right API for the language one is using.
For example FreeRTOS could not be used with, say, Pascal, because the whole thing is in C (I have never used C++ and never want to). One could do it by writing a translation layer, which moves the function parameters around; different languages tend to store function parameters in different registers, or differently on the stack.
The choice of development tools, operating systems, etc, is often made by management (read: at best, people who used to be programmers and when they reached the grand age of 40 they got sick of reading yet another 1000 page manual, so they moved into management) and not by the people who have to actually write the code That’s why you get BS websites like the Laravel one pushing the product to “web artisans” 
I would be surprised if Garmin used an in house written RTOS. I wrote one myself in the 1980s and a simple one is simple enough to do but it would be unusual.
Peter wrote:
VxWorks is the only RTOS to support C++17, Boost, Rust, Python, pandas, and more,
I though it is the language implementation that supports the OS and not the other way around? But what do I know, I’m only a computer scientist while the person who wrote the part that Peter quoted is probably a marketer of sorts.
Peter wrote:
Does anyone know what is used in GA avionics?
Peter, last I check (2 years ago, should a message on this forum) it was: VxWorks, LynxOS-178, Nucleus RTOS, INTEGRITY-178, SafeRTOS. For VxWorks I think it was Wind River.
If you google for RTOS and avionics you will find those…
