phil-levis
commented
11 years ago This has come up before. There are four solutions I know of:
1) Use dependent, ordered initialization like Boomerang did. The challenge is that it depends on unique() resolution order, which is undefined in the nesC compiler. So changes to nesC would break it.
2) Use more levels of init. E.g., HardwareInit, SoftwareInit, PeripheralInit, where the first two relate to the MCU only.
3) Do not use split-phase calls in Init. Request resources immediately.
4) Initialize peripherals in Boot.booted().
Of these, the conclusion was that 3) is the best answer. Since Init is blocking, there is no parallelism and serialized execution is expected. Therefore there shouldn't be split-phase calls. They end up moving initialization outside of Init. For example, adding another Init as in approach 2) doesn't help if the new, later Init is called before the resource is granted. You'd end up needing some kind of barrier on resource grants.
Phil
Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal
On Jul 8, 2013, at 5:41 PM, Eric Decker notifications@github.com wrote:
Using non-immediate arbitration from SoftwareInit (the one called from boot up) is problematic.
Some code (for example the cc2420x driver) uses arbitration via Resource.request to access arbitrated resources (ie. the SPI bus) during initilization. This gets called from SoftwareInit on the way up.
Resource.request uses an Arbiter which uses data structures (typically FIFO) that also get initilized by SoftwareInit. But the order of initilization isn't specified so this initilization may happen after users of the arbiters try to access these structures.
It sort of works even unitiliized but that is just because not because of reasonable design.
This should be fixed. One reasonable way is to introduce a first level initilization, say SystemInit with the same symantics as Init. Critical system code would use this to initialize key system components prior to use by other components.
— Reply to this email directly or view it on GitHub.
cire831
andrasbiro
Using non-immediate arbitration from SoftwareInit (the one called from boot up) is problematic.
Some code (for example the cc2420x driver) uses arbitration via Resource.request to access arbitrated resources (ie. the SPI bus) during initilization. This gets called from SoftwareInit on the way up.
Resource.request uses an Arbiter which uses data structures (typically FIFO) that also get initilized by SoftwareInit. But the order of initilization isn't specified so this initilization may happen after users of the arbiters try to access these structures.
It sort of works even unitiliized but that is just because not because of reasonable design.
This should be fixed. One reasonable way is to introduce a first level initilization, say SystemInit with the same symantics as Init. Critical system code would use this to initialize key system components prior to use by other components.
Another approach would be to force the initilization code to use Resource.immediateRequest instead. Which doesn't use the data structures that need to be initilized but this approach makes a boat load of assumption about what works and what doesn't. A better approach is given above because it is structured to initilize explicitly those components that are dependencies of later components.