I have a driver for SD cards that originally was essentially single
threaded, non-event driven
and used busy waits when doing such things as reseting the card. The busy
wait is required
because the card doesn't provide any kind of h/w event for when it needs
attention. This requires
polling.
To avoid rewriting the driver we implemented a wrapper that made use of
threads.
Recently, we rewrote the SD driver and the wrapper to eliminate threads and
simplify the way
everything worked. The SD driver and associated wrapper became fully event
driven. This
greatly simplified the structure of the code as well as its function.
A simple metric of improvement is how much rom/code and data/ram is used.
Here are those
results.
Threads has some level of overhead which some of the code and ram reclaimed
below reflects.
The big win is the elimination of execution cost when context switching
between sync level and
thread activity.
Please note that the original implementation was done for expediency and was
not an implementation
that I would recommend if writing the code from scratch. In other words not
an optimal usage of
threads and was an inappropriate choice.
threads unopt optimized
40606 bytes in ROM 31506 bytes in ROM
8004 bytes in RAM 8004 bytes in RAM
no threads, event driven.
35824 bytes in ROM 27444 bytes in ROM
6338 bytes in RAM 6338 bytes in RAM
Thought I'd share what we've uncovered.
--
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
