thanks a lot, for this addaptation for this micro, I have a question, what its the clock frecuency more efficient for the freeRTOS? could be addapted the cmx stack usb with the freeRTOS? again, thanks
best regards
sorry for my bad english
Hi, I got problems, if I use more than 2 task, my program doesn't work, I think that its because of use of ram, how much ram use each task? regards
sorry for my bad english
Hi again, the problem that I haved was that was insuffycient ram, I change the configMINIMAL_STACK_SIZE (256) for 128, and start to works, sorry for my terrible english, I promisse that I going to learn
best regards
Hi think chip There is not an "optimal" frequency for FreeRTOS tick
That will depend on your application..
If system tick is too often, then you will waste time while running some same task because of system tick interrupting it too often to evaluate tasks states. If it is too slow, your time base may be too large. You will only switch between tasks when the system tick happens.
1ms is fine for a lot of applications...
Don't worry about your english. I am not a native speaker either..!
Eduardo
Are there any updates on this topic?
I want to implement FreeRTOS on an MCF51JM, I'm sure I can get the USB stuff running, but making FreeRTOS play nice with Processor Expert looks to be a larger task.
I'm using Codewarrior 6.3.
Thanks guys.
Bob
I had FreeRTOS v4p7 working in CodeWarrior 6.2. Not using Processor Expert though.
I have gotten spoiled by the convenience of Processor Expert, its benefits outweigh its limitations in my experience.
I have used FreeRTOS on other projects using other CPUs, the project I am working on now uses the Coldfire JM, so I would love to use FreeRTOS.
I saw your work, and may use it as a guide.
Thanks!!
Bob
for anyone following this thread, my prayers were answered in this thread:
https://community.freescale.com/thread/11692
Go to the last couple pages, there is a custom component (bean) posted.
it works with CW 6.3, Processor Expert 3.09, drop in, configure, and go.... works great.
Now I need to get the bootloader working, am going to use the badgeboard style, drag-n-drop software. CW is arguing with me. But I don't give up easily....
Regards,
Bob
Hi all
Seems like you have already solved your FreeRTOS issue
This might also helps
Here's another FreeRTOS port with the last 5.3.0 release for our newest MCF51CN12 MCU with Ethernet:
Some differences: it uses RTC and also force interrupts to improve RTOS performance
Sorry for the long link
Paolo
Hi Paolo Renzo, this version of MQX RTOS could be portable for MCF51JM128?
thanks
regards
Hi
Sorry but I don't know details about MQX. Shared sw and link was made with FreeRTOS and not with MQX. You may want to open a new conversation thread to ask for details about that.
I'm only able to answer FreeRTOS questions :smileyhappy:
Regards
Hi Paolo, i'm sorry, but the link that you says, send to me to a page of mqxrtos, could you repost again the link please
regards
sorry for my very bad english
Hi again, I download directly from the page www.freertos.org
new version 5.3.1
know the questions is if this version of freertos for mcf51cn128 could be portable for mcf51jm128?
the version that posted in this space for jm does not work well for me
regards
Hi.
I believe there are some errors in this port.
The "dummy save" and "dummy restore" should not be used. Instead, use some "naked" attribute for system ISRs. After the "dummy restore" instructions, registers D0 and D1 might be changed, and just after that task context is saved. That can cause errors in any very simple task.I.e., the context is modified by the system interruption!!!
Also, there is a wrong line that has been (accidentally I suppose) inserted in a system file (queue.c).
Besides in hardware.c functions, inline assembly is used, modifying directly cpu registers without saving their values before. That can lead to errors.
I had also some problem with memcpy from <string.h> in CodeWarrior 6.2 forColdfirev1. That need to be checked out more carefully. But anyway, replacing memcpy in queue.c by a "home made" code in C can fix that problem.
Soon I should be posting a version that works fine for MCF51JM128
Eduardo A.
Any updates on this project?
Bill
Hi Bill
I'm sorry for not answering before...(as I had said, that I would..!)
I have searched a little bit about some "naked" attribute, but Aff... it is not that easy to find such a "clear" information! So I was using the fixed version I explained before. (I have also changed that memcpy and the hardware issues...). For memcpy, I could not force the compiler to use my definition of memcpy... it was always taking the codewarrior implementation of memcpy, so I had to change in queue.c "memcpy" by "memcpy_alt". That is clearly not the best way to do it. But it works.. If you know how to force compiler to give preference to user functions instead of his owns, let me know!
In this version, two headers "hardware.h" and "usertasks.h" have been manually inserted into main.c, hardware.c and usertasks.c, because I'm using Codewarior "free", and I'm limited in number of files. I could change those for the includes, but I prefered to let it like that, so I'm sure that what I am posting here works... no mistakes. :smileyhappy:
Eduardo