Critical features for embedded operating system

doul

doul

Hello all.

Is there some operating system masters here ? In the scope of a minimalist industrial grade Programmable Logic Controller, what are the critical features for embedded operating system ?

The system is a preemptive stack based context switch, I have :

- serious stack overflow control
- avoid any software or hardware deadlocks (watchdog)
- manage resource access (abstraction layers, system calls, mutexes, semaphore, ... )
- be real timed
- error handling / recover
- task priority
- inter task communication
- debugging capabilities

I have unix in mind for model, like error handling with return value of functions. I also think about Apollo Guidance Computer for his high hardware and software efficiency.
 
doul said:
I also think about Apollo Guidance Computer for his high hardware and software efficiency.
Click to expand...
In case you don't know - there is a talk about the Apollo guidance systems on the CCC website where they dissect that thing very good.
 
Crivens said:
In case you don't know - there is a talk about the Apollo guidance systems on the CCC website where they dissect that thing very good.
Click to expand...
Thanks, I didn't know, it's interesting.

This not really FreeBSD related, I have a running base system for AVR MCU, I could talk about if someone is interested. It's a hybrid cooperative / preemptive system, with stack stored switched context.
 
Apollo Guidance Computer :-)

Guidance computer:
Processor Discrete silicon integrated circuit (IC) chips (RTL based)
Frequency 2.048 MHz
Memory
15-bit wordlength + 1-bit parity
2048 words RAM (magnetic-core memory)
36,864 words ROM (core rope memory)

Ports:
DSKY, IMU, Hand Controller, Rendezvous Radar (LM), Landing Radar (LM), Telemetry Receiver, Engine Command, Reaction Control System

They've made it to the Moon and back guided by 36K words of Assembly code on ROM with 2K words of RAM to communicate, control and manage 7 data ports, with these software tools - https://www.ibiblio.org/apollo/assembly_language_manual.html#gsc.tab=0

I think those days NASA used some type of OIT (Outer Intelligence Technologies) for their Moon trips :-/ :)
 
Something wrong with Pi and Arduino boards?

If you want to learn about programming embedded OSes and microcontrollers, those are generally pretty good places to start. Phishfry is the FreeBSD Forums' resident expert on that stuff.

Especially, with Arduino boards, if you get a kit, it can be pretty easy to connect it via a USB or COM port to your laptop, and do fun stuff.

BTW, I only learned very recently (like in the last couple weeks) that OCD stands for On-Chip Debugger...
 
The board I'm using is an Arduino mega (ATMega 2560 MCU), I use AVR tool chain without any Arduino software.

Why AVR ? Because :
- right now I've some boards to play with (Arduino uno, mega and Controllino PLC)
- I know them
- AVR are descending from the legacy MCU Intel 8051, father of all MCU !
 
doul said:
- error handling / recover
Click to expand...

I'm working on implementation of a system wide error handler with a fault-tolerant design, errors are sorted by criticality, then action is done by criticality and occur count.

Not critical error is handled by tasks themselves, these error behave like test function and are integrated in program flow : stop reading a empty buffer or create a file if it's doesn't exist.

If a critical error occur the task have to : raise it and yield hand to system, the error will be handled without delay and before any other task start. Drastic action can be done by system like restart or kill faulty task/driver. All action and errors have to be logged for debugging purpose or power on self test.

I think I'll implement a data structure for errors :
- ID
- short name
- text to display/log
- occur counter
- max occur
- criticality (low/critical/fatal)

In addition I have to implement a timeout management to don't over load system with many retry attempt.

Finally I would like to know how FreeBSD handle errors ?
 
astyle said:
Well, there's /var/log/messages, and /var/crash, for starters.
Click to expand...
Okay, it's a beginning, thanks 👍

I've made a new diagram for my system layers, As you can see :
- system core can access to everything
- system call is a central node
- tasks are restricted to system call only

TaskMate_layers_v2.png


Any comment, advice, ... ?
 
You must log in or register to reply here.
Back
Top