Intel Edison and RTEMS - Day Three

Overnight, I realized that the error the RTEMS hello world sample was failing with was RTEMS_UNSATISFIED (13) likely indicated a miscalculation in the RTEMS Workspace by . A quick look showed that the primary difference between the pc586-sse BSP variant and all other pc386 variant was that because of SSE, all tasks were forced to be floating point tasks. This results in the allocation of floating point contexts for all tasks and apparently the calculation is a bit too low on the x86 port. I switched the edison BSP variant to be compiled like the non-SSE pc586 and this solved the problem. A short time later, this output was posted to the RTEMS Users mailing list.

## Starting application at 0x0010000c ...
024rtemsWorkAreaStart=12FD40 MemSize=0x08x/0

bspstart.c
work_area_start = 0x12FD40
work_area_size = 1072497344 0x3FED02C0
end = 0x40000000
current stack pointer = 0x12FD18
heap_start = 0x133B72
heap_size = 1072481422
initialize device drivers
probe
Checking on /dev/main
probe
Register /dev/main
Register /dev/main as console
Console initialize complete
post driver hook
rtems start multitasking


*** BEGIN OF TEST HELLO WORLD ***
Hello World
*** END OF TEST HELLO WORLD ***

EXECUTIVE SHUTDOWN! Any key to reboot...

At this point, the next step was simply to remove most of the debug output and get a clean run. Then we tackled seeing if enabling the timer calibration code in the pc386/startup/bspstart.c file would work. The calibration failed and likely indicates some combination of interrupt controller or timer hardware is different from legacy PCs. Fixing this is left for future work.

The failure to have a working clock tick meant that we needed a fall back. RTEMS has a target independent fake clock tick driver which is a special IDLE thread which repeatedly calls rtems_clock_tick() each time it is executed. When a "clock tick" occurs which wakes up another task, the IDLE thread is preempted. This is an effective way to run most RTEMS tests on a simulator with no interrupt sources.

With the IDLE thread clock tick in place, Jeff and I ran the ticker example which has three tasks executing every 5, 10, or 15 seconds. It runs for 35 seconds. Jeff and I tuned a delay in the IDLE thread until time appeared to pass reasonably close to it would on real target hardware if the system were lightly loaded.

After a few iterations, we moved on to the fileio sample test. This demonstrates the shell, IDE file access, and requires user input. On the first run, the test hung and we had to disable the IDE driver because the Edison does not have one. On the second run, it just worked.

That was midday on day three (11 Dec) and that was all that could be done without writing new code. Plus Jeff needed to get the Edison, a BeagleBone Black, and a Raspberry Pi working from a small laptop and then boxed up with cables. OAR has a table and will show them at the Flight Software Workshop in a few days )16-18 December  )