I have a project here and was trying to get the above combo to work. If I use costates, the code works. If I switch to uCOSII, then reading the serial port F always succeeds with 0 bytes (using serFread()). Moving the same code into costate works. This problem almost suggests that uCOS and serialF share the same interrupt or something of that nature.
We would prefer using uCOS since the model is much closer to pthreads() and known multithreading environments. And using costates on this project will prove to be very difficult and complicate things.
I am having the exact same problem using serial Port E on the RCM4210. Everything works great with Costates, when I try using uCOS2 serErdUsed always returns true. I really don’t want to trash my uCOS code and start over. It will get very messy using Costates.
Looks like it’s you and me. On one side, at least I know I am not losing my marbles. On the other, the fact that you suffer from the same problem does not solve anything.
So let’s see if we can figure this one out. It almost seems like uCos is using an interrupt that is causing the port to trigger and believe it has received some characters. I will start looking into which timers uCos is using to see if I cannot find something. At least we have the source. I will let you know if I find something.
My problem solved. I was testing my code on the development board and had not wired up the Serial Port E. If it is left ‘open’ it triggers on the RxE port. I tied the TxE and RxE together and it is working fine.
I believe the issue here relates to signaling the RTOS from the serial interrupt. I am not sure if Rabbit ever added this to their serial interrupt routines, but to make the RTOS serial-aware, try adding a semaphore post in the interrupt routine. I uploaded an example of this in the file RS232.lib. Serial B and C were made RTOS-aware. I am running this on the 3000-series, so this is just a guide not the solution. Hope that helps.