7 Replies Latest reply on Feb 24, 2017 2:12 AM by user_1377889

    Real-tiime OS "ARTS"


      Hello Community!


      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.





        • 1. Re: Real-tiime OS "ARTS"

          Hi Bob, firstly thanks for sharing this :D.


          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.





          • 2. Re: Real-tiime OS "ARTS"

            Increase the heap size to its maximum. ARTS only uses heap memory (asides a few bytes for internals).


            and I increased the stack size.


            That's all. I wasn't quite sure whether the software UART would run. It does! fine!!





            • 3. Re: Real-tiime OS "ARTS"

              "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?





              • 4. Re: Real-tiime OS "ARTS"

                Maybe ARTS_Task and ARTS_ParameterTask would be a little more intuitive, still have to dive in deeper.





                • 5. Re: Real-tiime OS "ARTS"

                  Task() and ParameterTask() are just macros, the concept "Task" is unique to RTOSses, so I did not prepend them with "ARTS_"




                  Some tips to get your ARTS projects working:


                  In the System view of Creator: Set the stack size to 0x0200 and the heap to 0x3800 (lower that, when sram gets busted)


                  In ARTS.c: Set a breakpoint at ARTS_ErrorHalt() in case something goes wrong you will see where and why.


                  In your main.c: ARTS_CreateTask(YourTask,70,1) The second parameter is the task's stack size, use values > 60


                  To save flash, you may set ARTS.c optimization by right clicking on it in the Workspace Explorer window -> Build Settings -> ARM GCC -> Compiler -> Optimization and set to speed or size.


                  This feature you may use for any other .c module that you do not need to debug any more.





                  • 6. Re: Real-tiime OS "ARTS"

                    Hello Bob


                    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?





                    • 7. Re: Real-tiime OS "ARTS"

                      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.