Is only bare metal code written for PIC microcontrollers?

As far as I am aware the PIC is not able to fully support an OS due to its architecture. Here I am talking about low range and mid range PICs like PIC18F for example. Is it true that only bare metal code is written when using these microcontrollers which means that the user program runs in an infinite loop. Is it true that no operating systems are used with the PIC microcontroller?

That depends on what you mean by 'operating system'. I have written several serial console programs that interact with PICs and even allow small programs to be loaded and run remotely. They certainly can't run major OS like Linux and Windows but the only limitation is the amount of memory they can address.

Brian.

By operating system I mean anything that in the industry is called OS. Could be RTOS, µC/OS-II or something even more basic. So how does the PIC load and run the program? That would require it to understand file allocation structure among many other things.

There is a free bootloader for PIC and also one from microchip that can be considered the first step towards an OS. Of course I too do not know what is the def of an OS

I have written (am writing) an operating system for the PIC 18F47J53 chip, The main difficulty is the lack of memory but you can write around this at the expense of performance.
A operating system for the 16F chips would be pointless although a boot loader would be of use.

I have no idea how bootloader releated to OS, but simple OS can be realized on PIC, even real time. If it is a general question - so yes, it is possible. But not a popular solution. Since we have ARM processor cheaper than any of PICs, reason to use last one is gone.

Although "operation system" covers a wider range of functionality, most people would expect at least the capability to load and execute programs. Even more interesting from a software developers viewpoint, a defined interface to access system services (API). Looking at PIC18 family, there are restrictions making it difficult to implement usual operation system features.

- a non-expandable hardware stack with only 31 levels
- code can be only executed out of flash memory

But as already mentioned, a simple bootloader can implement the capability to switch between different applications and update them. Can be seen as a basic file system.

FvM said:

Although "operation system" covers a wider range of functionality, most people would expect at least the capability to load and execute programs. Even more interesting from a software developers viewpoint, a defined interface to access system services (API). Looking at PIC18 family, there are restrictions making it difficult to implement usual operation system features.

- a non-expandable hardware stack with only 31 levels
- code can be only executed out of flash memory

But as already mentioned, a simple bootloader can implement the capability to switch between different applications and update them. Can be seen as a basic file system.

Click to expand...

The stack limit of 31 is only a problem if you are programming in "C" or other high level language, but is not a problem if programming in assembler.
The flash memory of my PIC18F chip has a minimum write endurance of 10,000 times at worse case conditions, at normal voltages and temperatures the write endurance is much higher. It is possible to write an operating system to minimize writes to the same area of the flash memory. The speed of writing to the flash memory although being slow the size of the user programs is also relatively small. And finally the cost of the PIC processor is very low so if the write endurance of the device is exceeded, if in a socket can be easily replaced.

The restrictions of the PIC18F architecture can be worked around with a bit of creative thinking.

When does a boot loader become a operating system is an interesting question, a boot loader just loads a program from either removable memory or serial interface or similar. A operating system does this plus allows the loaded program to call it to open, read, write, and close a program as well as perform input and output functions from keyboard, serial interface, USB, and display.

The stack limit of 31 is only a problem if you are programming in "C" or other high level language, but is not a problem if programming in assembler.

Click to expand...

If you think so...IMHO the specification of an operation system, even of a very limited single tasking OS would at least include the ability to run applications from different origin and to abstract from specific memory allocations. Doing this without a freely available stack is serious restriction.

But I agree that it's up to you to design a software system that is able to run at least two different applications alternatively and call the loader providing this function "operation system".

The stack can be implemented in software, even on PIC16 but it significanty increases the program size and there is a time penalty. A software stack size is only limited by available RAM. At the moment, the biggest PIC18 has 4K or RAM and 128K of program memory - you can do a lot in that! Of course you can also use external memory.

Brian.

If you're capable of using FORTH I would suggest you take a look at flashforth
or perhaps FORTHdsPIC

https://flashforth.com/
https://www.rs-online.com/designspark/electronics/blog/forthdspic-gets-its-compiler-more-bare-metal

I don't know if VFX forth has a PIC implementation - it is perhaps the best windows/linux release.
I have used Forth professionally a couple of times. I wish it was used more often.
I havn't used it on a PIC yet though - oddly enough I was looking at flashforth just 2 days ago for a pic project.

There are 2 drawbacks that may put you off:
1. It's not like anything else you've ever used and you will feel like a fish out of water - for a couple of hours
2. The lack of understanding that a good IDE is essential by forth producers is forever annoying.

For anyone not familiar with forth (and I realise many just can't cope with it's syntax) it is
an OS an interpreter a compiler and assembler and cross-compiler all in one.

The stack can be implemented in software, even on PIC16 but it significantly increases the program size and there is a time penalty. A software stack size is only limited by available RAM. At the moment, the biggest PIC18 has 4K or RAM and 128K of program memory - you can do a lot in that! Of course you can also use external memory.

Click to expand...

Yes, the procedure is described in a Microchip application note: https://ww1.microchip.com/downloads/en/AppNotes/00818a.pdf

External code memory is only supported by a few special PIC18 types, e.g. PIC18F8527 as far as I'm aware of.