With such a limited amount of memory, the application + OS will be fairly small. I have worked on projects that are several gigabytes of source code, and the number of modules in the thousands, and building installable binaries that are in the "gigabytes" range. When you get to that size, you definitely need to have your header files, etc, in the right place.
I think the following is a fairly decent concept, however:
- Source files per module. Modules may be separated into larger groups by "usage" (e.g. "Base/OS", "Graphics", "Audio", "Network", "UI", "Apps", etc).
- Each module has a list of "exported includes" (zero to fairly large), which, when the module is being built are copied to a general "${ROOT}/includes" type directory. That provides the EXTERNAL interface, but the object files produced as the module itself may use "${module}/includes" as well, where there are private declarations and definitions, not "public" to the users of the API.
This is roughly how most large projects work. If it works for large projects, it should be fine for smaller projects too. However, if the number of source files is a dozen or two, I don't really see much point in splitting it up at all - maybe a "src" and "includes", perhaps also a "include/private" if you want to ensure that API's are clean. Keeping it simple has great advantages!
Note that the "exports" part needs to be built before the actual modules are compiled, or you'll have to ensure that there is absolutely no cross-communication between modules [or at least ensure that no "early" modules need any of the "later" modules header files - which becomes quite hard if the system is getting large].
You should also have a set of rules about how and what you expose, and during code-review check that these rules are followed.