Full blown RTOS written in Thumb ARM assembly language to fit in 1024 bytes
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
stack_layout.jpgLayout of a task's stack when the scheduler activatesJPEG Image - 136.99 kB - 12/03/2016 at 15:46 |
|
|
memory_map.jpgThis is the RAM map. Currently I set a hard limit for the maximum number of tasks to 4JPEG Image - 34.63 kB - 12/02/2016 at 03:54 |
|
|
I finally managed to upload a video in which I talk a little bit about what an RTOS is and then I step through the code to show you the big building blocks.
I will try to upload some technical presentations as well soon.
Here is the youtube link :
I realised I made a mistake with the last diagram and used MSP for indexing instead of PSP.
I corrected the image and re-uploaded to this project.
Here it is as well :
A few people asked me why I defined these two macros in the assembly source file.
There is nothing wrong with "bl subroutine" or "bx lr" but these two macros help me read the code faster when I look for specific subroutines.
I call it "professional defect" since most of the days I stare at Intel assembly and I am used to mentally separate code blocks in a specific way.
Here is how a task's stack looks like when the scheduler activates :
First part (top 8 registers in the diagram) is automatically saved by the interrupt handler, the remaining 8 registers are saved by the following code :
stmia r1!,{r4-r7} // store r4-r7 and increment r1 for each one mov r2,r8 // r2, r3, r4 and r5 are already saved mov r3,r9 // so we can use them as intermediary regs mov r4,r10 mov r5,r11 stmia r1!,{r2-r5} // registers are in order on stack r4...r11
I used to get random faults from time to time and these things are quite hard to debug. After a lot of hours I managed to finally isolated the issue in the mutex handling system.
I redesigned the system, it's much more robust now and it didn't fail yet like the old system.
Good part: I have 32 max mutexes now since I store them as bits into a word
Bad part: I had to remove the string from the code :) It's now 1024 bytes without any string.
I will try to optimize some more size-wise so I can put back the string at least partially.
On another note, some more docs are coming, stay tuned !
I replaced the infinite loop in the idle task with "wfi" instruction. Theoretically this should put the processor to sleep until the next systick interrupt and this will save energy. I said theoretically because it needs some setup but it seems to work out of the box so I will keep it as an option.
I also uploaded the RAM memory map.
All sources are fully commented but proper video documentation will follow in the next couple of days.
If there is enough interest I might even make a step-by-step building videos.
Stay tuned
Create an account to leave a comment. Already have an account? Log In.
Is the source code for this project available? for public use?
Yes, there is a link to github on this page. The code is released in "public domain" or free for all uses
I was looking for something like this to use on a Teensy 3.6. My idea was to make some kind of Google Glass... But my knowledge of the matter isn't much. Better leave it to someone else.
awesome! submit the project to the 1kB contest hosted here at Hackaday. I've got mine there I should not say that eheheh... :-) Oh you did, great!
Thank you, I started this project because of the 1KB challenge :)
Yup, maybe a little bit less if I optimize more but I lose readability
Become a member to follow this project and never miss any updates
Impressive. RISC-V's compressed set is intended to compare favorably to Thumb-2. I don't suppose you have looked at that or would be interested in porting to RISC-V? It would be the first 1024 byte OS on RISC-V :)