And it worked great first time. I checked the doco and found out where the IP config was stored and was able to connect to web server over ethernet and see all the demo tasks running.
The FreeRTOS demo code talks about LED5 blinking at a 5 second interval when all the demo/tests are running fine, and a 200ms rate when one of them fails.
Now the LEDs on the RDK have a silk-screened number next to them. And LED5 as marked on the board was clearly blinking faster than 5 seconds.
So I was worried that one of the tests/demos was failing. Maybe the port wasn't working 100%?
I could see that it was creating a string with a message about the failing task:
Unfortunately the FreeRTOS demo doesn't drive the LCD on the RDK, so I couldn't easily display the message.
So I quickly included the code I wrote to drive the LCD and had it output the error messages generated in the demo test code.
The LCD was showing no error. What is going wrong? I added some code to have it display when all the tests were OK. Running that showed that everything was happy.
So what was going on with the LED?
It turns out some arbitrary mapping between the "LED5" describe in the FreeRTOS demo code and the LEDs on the board.
If you check the code ParTest.c#L102 you can see that LED5 is mapped to LED9!
That explains it. Why they did that I don't know. It certainly is confusing.
But it looks like the port is running happily.
As part of my fiddling, as well as adding an LCD driver, I also removed the Windows toolchain blobs, and code for all the other platform ports, just to make my greps more relevant.
You can find this code here:
It would be good to get the LCD driver included in the FreeRTOS upstream.
Next steps, more work on the hardware, and get some FreeRTOS tasks talking to the DS18S20 temperature sensor.