21 Replies Latest reply on Jan 29, 2015 8:04 PM by shreesha

    FreeRTOS ported to the PSoC 4

    nickjohnson

      I've ported FreeRTOS to PSoC 4 - which really was extremely trivial. It's simply the Cortex M0 port with some configuration & glue from the PSoC 5 demo.

      The attached demo app creates three tasks that toggle the red, green and blue LEDs on the PSoC 4 pioneer board at slightly different rates, resulting in a pleasing (if somewhat psychedelic) light show. Adapting this demo for your own purposes should be straightforward.

      Note that because the PSoC Capsense component makes (undocumented) use of the systick timer, it's not currently possible to use FreeRTOS and the PSoC Capsense component together.

        • Re: FreeRTOS ported to the PSoC 4
          nickjohnson

          Correction: The CapSense component does not use SysTick; the issue was an unrelated interrupt issue.

            • Re: FreeRTOS ported to the PSoC 4
              yfs

              Nice job Nick. I downloaded that and it ran like a charm. Did you run into the problem where you have to enable interrupts before you start CapSense? It's caught me a few times.

               

              I added CapSense to your design and use it to vary the blink rate. I had to adjust the RAM allocation settings a bit though. In the CYDWR file I changed the stack to 0x80 (only used by main() anyway) and made the heap 0 (the task memory is allocated from a heap controlled by FreeRTOS). I also reduced the default task stack to 50 short ints. The CapSense needs a little more, so I doubled that value.

               

              -- Mark.

                • Re: FreeRTOS ported to the PSoC 4
                  nickjohnson

                  I did indeed run into that issue. Why did you need to shift the stack?

                    • Re: FreeRTOS ported to the PSoC 4
                      yfs

                      Well, your code worked fine - I did not have to change a thing.

                       

                      I then added a CapSense component and a task to monitor it periodically. That caused PSoC Creator to complain that I was out of RAM. I just made a few changes to make it fit. The main cause of the problem was that Creator assumes you want it to pick your stack and heap size. FreeRTOS does that for you and so I had a large amount of RAM allocated that was never going to be used. In the FreeRTOSDemo.cydwr file I changed the stack size to about 80 bytes, which is plenty to run main() and kick off the RTOS. I set the heap size to 0 bytes because it is not used by FreeRTOS at all.

                       

                      That freed up a lot of room for the task stacks and FreeRTOS heap. I believe that FreeRTOS allocates task control blocks and stacks out on array of size configTOTAL_HEAP_SIZE (ucHeap). I have not had a chance to really dig into RAM usage memory with FreeRTOS though - I just wanted to play with your "port", ran into a problem and solved it. I hope to take a closer look in the new year.

                       

                      -- Mark.

                  • Re: FreeRTOS ported to the PSoC 4
                    igutekunst@gmail.com

                    I am having some issues that appear to be because the CapSense uses interrupt 15. You say it does not? However, if change interrupt 15 to point to the SysTick ISR in FreeRTOS, then it no longer works. Specifically, the Capsense_Start() function never returns.

                     

                    --Isaac

                      • Re: FreeRTOS ported to the PSoC 4
                        yfs

                        The interrupt numbers should not be an issue. And CapSense is independent of SYSTICK.The issue with our CapSense software is that you must enable interrupts before calling CapSense_Start(). If you do not the software waits for a condition that gets set from an ISR that cannot fire, so it does not return. The macro to enable interrupts is CyGlobalIntEnable,so make sure your code is something like this...

                         

                        CyGlobalIntEnable;

                        CapSense_Start();

                         

                        We are fixing this problem in our next s/w release (and we will make sure the code you write today will still work once we make that change).

                         

                        -- Mark.

                          • Re: FreeRTOS ported to the PSoC 4
                            igutekunst@gmail.com

                            I'm still concerned.

                             

                            In my main code, I copy the interrupt handler address into vector 15 with:

                             

                            CyRamVectors[ 15 ] = ( cyisraddress ) xPortSysTickHandler;

                             

                            The xPortSysTickHandler is defined in port.c and is responsible for activating the scheduler.

                             

                            The interrupt tab in my .cydwr file shows the capsense peripheral as using interrupt 15. Even with enabling interrupts before calling capsense_Start(), execution stops after FreeRTOS is started (and the new ISR is installed).

                             

                            Isaac

                              • Re: FreeRTOS ported to the PSoC 4
                                yfs

                                Hello!

                                 

                                You are confusing exception and interrupt vectors. In the ARM architecture you have an internal SYSTICK exception that gets triggered by the M3. The handler for this has to be installed in slot 15 - the "exception" number for SYSTICK. The interrupts that are generated by the PSoC CapSense block are handled by the M3 interrupt block and, coincidentally, by "interrupt" number 15. CapSense is definitely not using SYSTICK and you are not clashing interrupts. PSoC Creator just happens to pick that number.

                                 

                                What I strongly suspect is happening here is that you are running out of SRAM. I had this same problem when I added CapSense to Nicholas' example. To determine if this is the case I recommend starting the debugger and putting a breakpoint at the beginning of pvPortMalloc() (this is line #95 in heap_1.c, but you may have elected to use a different heap file). Then run the code. Each time your application needs to grab memory it will break in this routine. Open the Call Stack window and you will see something like this.

                                 

                                 

                                The xWantedSize argument is the (decimal) number of bytes being requested from the heap. For each task you create this function is called twice - I am 99% sure this is for the task control block (a fixed-size piece of RAM to hold the task state, priority, pointer to the stack, and so on) and then for the stack that is allocated to the task. In the example you grab 68 bytes for the task control blocks and 400 bytes for the stacks. At some point you will see that the debugger stops hitting that breakpoint and your application is hung. Press the halt button (looks like a VCR pause button - if you are old enough to know what one of those is. Er, was). You will be in vApplicationMallocFailedHook().

                                 

                                So, if you do all that, and it does what I think it will do,you have a memory allocation problem. The good news is that it is easily fixed.

                                 

                                Firstly, be aware that PSoC Creator allocates default stack and heap for you. It allows you to set the size of these memory areas without having to learn about linker scripts and other unpleasantness! But, with an RTOS, the OS handles this stuff for you as well. You want to make sure you give as much memory as you can to the OS. So, open the "cydwr" file - the resources file in PSoC Creator - and find the System tab. In there you will see entries for the stack and heap size. Reduce the heap to 0 - I assume you are not using things like printf(). Reduce the stack to something very small. Start with 0x100 for now. That is plenty of room and you will be able to adjust that down later. This stack is only used by main() and the APIs it calls. As soon as the RTOS starts it will have used as much of this stack as it ever will so you can safely reduce the size and save space.

                                 

                                Next, take a look in FreeRTOSConfig.h and look for the following defines.

                                 

                                #define configMINIMAL_STACK_SIZE    ( ( unsigned short ) 100 )

                                #define configTOTAL_HEAP_SIZE        ( ( size_t ) ( 2048 ) )

                                 

                                The heap size gets used in a big array definition. This heap array is used to allocate that memory I wrote about above. You want to make it as big as you can. Experiment with it by making the size bigger and building the application. If you get too big you get errors like this from the linker "Build error: region RAM overflowed with stack". Remember that PSoC Creator also allocates the CYDWR stack (that I wrote about above) and your global variables and little bit of stuff for boot code - so you cannot just go to 4096 bytes (the total amount of RAM in that device), but you can get close to that number.

                                 

                                Next up,consider the minimal stack size. It is 100 - but those are longs, not bytes, so you are allocating a minimum of 400 bytes for every task. I think that is quite a lot for a minimum. Unless you plan to do a lot of computation in the IDLE task I would halve that - at least. The IDLE task is what runs when none of "your" tasks are doing anything. It typically does nothing and so you only need enough of a minimum stack to store the task's state. I have used 50 without issue.

                                 

                                Lastly, look at the tasks you are creating and the amount of stack they request. In Nicholas' code he has this:

                                 

                                xTaskCreate(vBlinkTaskGreen, (signed portCHAR *) "BlinkGreen", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 3, NULL);

                                 

                                There is nothing wrong with that but he is asking for 100 longs - 400 bytes! That is quite a big stack for a task that blinks an LED. Because I reduce my minimum stack to 50 I save a lot of space and can create more tasks - or ones that need a bigger stack. Please note that I am not criticizing the code Nicholas wrote here - he is expecting to add more interesting code to those tasks (or that you will) and so a little head room is a very good thing. I think you just happened to run out!

                                 

                                I hope this advice helps. With small devices like this you really need to be frugal with SRAM when running an RTOS. I would set the minimum for the IDLE task, and then think carefully about each of my own task's needs (setting the value in the xTaskCreate() call). It's good to go through the exercise I outlined here a few times, so you get the hang of things, and then it becomes quite easy to partition up your RAM in a real application. Happy scheduling!

                                 

                                -- Mark.

                        • Re: FreeRTOS ported to the PSoC 4
                          nickjohnson

                          Ah, good catch. I had wondered why so much RAM was unavailable for the FreeRTOS stack.

                          • Re: FreeRTOS ported to the PSoC 4
                            elaguna

                            Hello,

                             

                            Im very new to RTOS. I purchased a PSOC4 pioneer kit. i have gotten really familier with how to use it vie the example projects.  what would be the best way to get started using FreeRTOS. Where does my main() go? I would like to run the sample projects with FreeRTOS to learn. How can this be done?

                             

                            Steve,

                            • Re: FreeRTOS ported to the PSoC 4
                              yfs

                              I took Nicholas' project and it worked out of the box. I think that is good place to start for you, Steve. I'd never used Free RTOS before and I was learning about it in minutes.

                              -- Mark.

                              • Re: FreeRTOS ported to the PSoC 4
                                elaguna

                                Thanks guy

                                I figured it out got it working. now i am trying to figure what benefits this gives me? watched a couple rtos video and they said the task scheduling techniques and queues between task.

                                  • Re: FreeRTOS ported to the PSoC 4
                                    yfs

                                    Yes, I like to use an RTOS with CapSense. I put the CapSense scanning code in one task and push the results into a queue or a mailbox. Then I can write "application code" that just uses the queue for instructions - it does not have to worry about all the scanning and reading and interpreting finger activity.

                                    One nice feature of FreeRTOS is the idea of co-routines - these can save you a lot of SRAM because, unlike tasks, they share a stack.

                                    -- Mark.

                                  • Re: FreeRTOS ported to the PSoC 4
                                    yfs

                                    That's appreciated. As you might have guessed - I had just been through the process of setting up the RAM for FreeRTOS and so the info was fresh in my mind!

                                     

                                    -- Mark.

                                    • Re: FreeRTOS ported to the PSoC 4
                                      shreesha

                                      Hi,

                                      I have posted this question in one of the threads in freertos.org but thought I would get a faster response if I repeat it here.

                                      Is it possible to port this FreeRTOS demo to the PSoC 4 prototyping kit? It has the same MCU CY8C4245AXI-483...

                                      If yes, what are the changes that I need to make?

                                      If no, is there a separate version of FreeRTOS for the prototyping kit? Please provide me one in that case.

                                      Thanks in advance and regards,

                                      Shreesha

                                        • Re: FreeRTOS ported to the PSoC 4
                                          yfs

                                          I answered this on the freertos.org site but they have a moderator and so it was not immediately posted. You may have missed it. Here's the beef...

                                           

                                          Yes, that's definitely possible. You just need to change the example into a bootloadable project.

                                          From the main Project menu, select Build Settings. In the dialog, find Code Settings and the Application Type option. Use the pull-down to choose "Bootloadable".

                                          In the System tab of the Component Catalog, find the Bootloadable component. Add it to your TopDesign and configure it to work with your bootloader project. Here is a screenshot of my configuration.

                                          Assuming you used the Demo project, when you build and download the project the blue LED will glow quite dimly because it is being driven by a PWM. You can vary that brightness by running your finger along the pin-holes on the top of the kit.

                                           

                                          Let me know ho you get on.

                                           

                                          -- Mark.

                                        • Re: FreeRTOS ported to the PSoC 4
                                          amgalbu

                                          Thanks for sharing!

                                          I used FreeRTOS in the past and I liked it very much. Nice to have also on the PSoc4. I will give a try!