"Typo" = grammatical mistake!

And we do not care about the RTOS programming or little endian machines, he said he is programming a PIC mcu. Embedded programming is different from RTOS.

 

No need, every budding future systems programmer designs an OS or two while learning. It's a good exercise in programming but mainly useless IMO as a practical matter on simple 8 bit machines as a improvement over big loop state machines and interrupt/dma driven I/O for optimized targeted applications. 10 years ago the 'industry pundits' declared 8-bit controllers dead because we would need all the fancy services of a >8-bit OS for fancy future applications. It's true that the complexity of even a simple thing like a ADC can be bewildering on 32-bit machines so having an RTOS abstraction layer helps but it mainly gets in the way of directly interacting with limited program state to hardware on a 8-bit machines simper interfaces in a sequential manner instead of partitioned tasks, scheduler and queues with a RTOS.

The biggest hang up I have right now conceptually is context switching. I've dabbled in C since I was a kid. Lately I've moved into the embedded realm after a job introduced me to PIC programming.

I just can't seem to wrap my head around how you can "pause" a function and then return to it, starting where you left off. I didn't think C was capable of something like that.

 

The biggest hang up I have right now conceptually is context switching. I've dabbled in C since I was a kid. Lately I've moved into the embedded realm after a job introduced me to PIC programming.

I just can't seem to wrap my head around how you can "pause" a function and then return to it, starting where you left off. I didn't think C was capable of something like that.

The C language doesn't provide a context switch primitive. The piece of code that does this is necessarily processor specific with abstract libraries compatible to the C language.

 

The C language doesn't provide a context switch primitive. The piece of code that does this is necessarily processor specific with abstract libraries compatible to the C language.

Interesting, I'll have to dig around in the chip datasheet and see what I can find. I have a feeling there is some inline assembly involved

 

The biggest hang up I have right now conceptually is context switching. I've dabbled in C since I was a kid. Lately I've moved into the embedded realm after a job introduced me to PIC programming.

I just can't seem to wrap my head around how you can "pause" a function and then return to it, starting where you left off. I didn't think C was capable of something like that.

This is almost always done using a stack. When one function calls another, the information needed by the new function, including parameters to the function and any local variables, are pushed onto a stack data structure. That gives the function its own workspace, but the workspace for the prior function is still there, its just buried down in the stack. When a function ends, it is responsible for cleaning up the stack so that, upon return, the stack is identical to how it was when the function was called except that the functions return value is no on top of the stack, which is where the calling function expects to find it.

You might consider working your way through the Nand-to-Tetris project. This will give you a very good idea how a compiler generates code for a high level language targeting a very simple processor.

 

Interesting, I'll have to dig around in the chip datasheet and see what I can find. I have a feeling there is some inline assembly involved

There usually is a need for some assembly (if the required libraries don't already exist) in the monitor design if you want to context switch RTOS multitasking type tasks with a scheduler instead of just calling and returning from functions and/or using interrupts. Don't be surprised if you don't see much help in the chip datasheet for RTOS design. You should to study a book like 'Operating Systems Concepts' to understand how the hardware can be used or abused to hack something on limited hardware not designed for OS type processes.

There are concurrent languages like Ada and most of the Modula-x family that do have language constructs for asynchronous tasks, process communications and synchronization. I wrote a very simple multitasking system for the Atari ST years (late 80's) ago in Modula-2 that used very little assembly but there was a large amount of state to save between context switches.