For those of you that live on the northern hemisphere the "Dark Times" have begun. Time to stay at home instead of strolling through the nature, much time to evaluate something new.
I have written a simple RTOS (Real-Time Operating System) and I want to give it to the PSoC community. At first I provide you with a script to make you comfortable with the general concepts of RTOSses. Read that first, I would be glad for any comments on it.
The supplied project archive is made for the CY8CKIT-044 PSoC® 4 M-Series Pioneer Kit and is using some of the on-board hardware, as the accelerometer and the daylight sensor. The project needs a terminal emulation program on the PC and will display its result on the computer screen.
The RTOS (I named it ARTS) would run on a CY8CKIT-043 PSoC® 4 M-Series Prototyping Kit, but due to the lack of additional hardware it could be a bit boring to watch an LED blinking. When you have set up some external hardware as sensors or actuators it can get interesting again.
I have to admit, there is no manual for ARTS. I did my very best to describe the APIs in the ARTS.h file. I would suggest you to go through that description. Any comments welcome.
Having only the PSoC 4M prototyping kit and still being a n00b to RTOSes i did the boring task of toggling an LED and another task that prints a message to a terminal emulator using the Software UART component.
The project didn't worked until i increased the heap size to 0x400, with 0x300 the HardFault error/routine is triggered which in this project turns the LED on "for ever", i still don't know how to calculate the heap size.
And the only comment i have is maybe all the routines related with ARTS can have the ARTS_ prefix, a component having the ARTS header and source file would be great aswell :D.
"And the only comment i have is maybe all the routines related with ARTS can have the ARTS_ prefix" The routines ARTS uses internally should be declared as "static", so they cannot be seen from outsides. All APIs have got the ARTS_ prefix, or did I forget one?
I have run into a issue using the PRoC 256K and am wondering if you think your ARTS could help me. My application uses the PRoC ADC to read acceleration values and I need to insure that I maintain a read every 20 ms. The ADC data is written to external flash and transmitted over BLE every 20 ms. The problem I am having is that when the BLE connection gets weak my ADC reads are getting blocked by CyBle_ProcessEvents() so I start dropping ADC reads. Do you think putting the BLE and the ADC separate tasks using you ARTS could solve this issue?
N o, that will not help you. Storing data in flash is consuming a considerable amount of time. I would suggest you to use a "Circular Buffer" to store the ADC results in sram and read them off when BLE is available. With a buffer depth of 100 you will be able to bridge 2 seconds.
I created the ARTS Project mostly for educational purposes. So indeed there is a lot to learn from. I wrote my first RTOS in 1980 using PASCAL running on a Z80 Controlling a (real) concrete mixer systrem. I even had an RTOS for a PSoC1, but it left too few of the tight resources. Since Cypress decides to support Free RTOS I did not continue the ARTS Project.
Due to an Error in the Forum Software I cannot log in using my old account, so I needed to create a new one.