I’ve reached a point where I’m reasonably happy with the current Gumsense situation. However, there are still improvements I’d like to make…
- At the moment, the Gumsense doesn’t support reading/writing the power rails through the I2C bus – they’re all toggled within the job execution routines. It also doesn’t support sampling of ADC channels upon request. These are relatively straightforward things to add, they’re just not a priority.
- The Tcl library could do with some sort of job-property-name-to-list-index association. I would have implemented jobs as associative arrays of properties from the start but the way associative arrays work in Tcl means that it’s not possible to return one from a C function.
- When one reads the sampled data from the Gumsense, it is necessary to pause job execution so that things don’t become overly complex when accessing the array of samples. After implementing it this way, I can see that this could be a potential problem, since it could potentially leave gaps in data series. So, by changing the way that the data is written to and read from the buffer, it should be possible to make this possible. If the buffer’s made to be circular, then it would make this easier.
- Because of the MSP430’s RAM limitations, the code is currently set to store 512 readings. In the future, I’d like to see the MSP430 using it’s own flash to store readings. Since my code is using ~6.1Kb of the MSP430F169’s 60Kb of program memory, there’s quite a lot of room for more!
- The current sample table size is set in the code to be 512. However, this could be increased by creating a custom linker script for the build, so that the table is given the maximum size possible.
- I’d like to reduce the boot time of the Gumstix. I’ve got some ideas about this:
- Profiling the boot would be a start. I may do this later, since the first stab is straightforward – just recompile the kernel with CONFIG_PRINTK_TIME set. This apparently causes timing information to be displayed along with printks.
- A fair amount of the boot time is taken up reading the JFFS2 volume. The first thing that I’d do is partition the Gumstix flash into two: a read-only ext2 (or something) volume, and a JFFS2 volume. A second thing that I’d like to investigate is moving the JFFS2 metadata onto an external non-volatile memory memory with better wearing than the flash (e.g. FRAM).
- I’d be interested to know how much time could be saved if during boot we could assume that the hardware we’d got was completely identical to the hardware we had in the last boot. I’m not really sure how much time could be saved here, but it could be interesting to pursue.
- Similarly, I’d like to reduce the shutdown time of the Gumstix. I already shaved 2 seconds off this by removing a 2 second sleep. There may be some other things that could be improved too…
- Make the Gumsense act as a watchdog for the Gumstix kernel. Reboot if stuff starts to go wrong.
- I used a modified version of qemu to simulate the Gumstix. I’d like to further modify it so that qemu can simulate the Gumsense as a peripheral.
Posted at 6:25 pm on Saturday 14th April 2007
Site by Rob Gilton. © 2008 - 2019