<p>Highly embedded (limited code and ram size) projects pose unique challenges for code organization.</p>

<p>I have seen quite a few projects with no organization at all. (Mostly by hardware engineers who, in my experience are not typically concerned with non-functional aspects of code.)</p>

<p>However, I have been trying to organize my code accordingly:</p>

<ol>
<li>hardware specific (drivers, initialization)</li>
<li>application specific (not likely to be reused)</li>
<li>reusable, hardware independent</li>
</ol>

<p>For each module I try to keep the purpose to one of these three types.</p>

<p>Due to limited size of embedded projects and the emphasis on performance, it is often keep this organization.</p>

<p>For some context, my current project is a limited DSP application on a MSP430 with 8k flash and 256 bytes ram.</p>

I've worked with some sensors like the Tmote Sky, I too have seen poor organization, and I have to admit i have contributed to it. Anyway I'd say that some confusion has to be, because loading too much modules or too much part of program will be (imho) resource killing too, so try to be aware of a threshold between organization and usability on the low resources.
Obviously this don't mean let caos begin, but for example try to get a look on the organization of the
tinyOS
source code and applications, it's an idea on what I'm trying to say.