Introduction
The availability of the GFE boards and associated hardware is expected to precipitate the development of multiple avionics projects. The purpose of this document is to serve as a preliminary discussion of PSAS avionics firmware organization and development.
General Considerations
PSAS has a transient set of developers for any project.
The current ad-hoc project development practices are considered a barrier to participation for new members. Reducing the barriers to participation may be a higher priority than the inefficiencies introduced by moving towards standard group practices.
‘Mil-Spec’ type project organization requirements will create a barrier to participation. (See Consideration 2). Hypothetically, we can find a balance.
Proposal
We decided not to use an RTOS. FreeRTOS, our leading contender, is just too much to chew on for many of our volunteers, seems brittle to compiler changes, and doesn't offer enough benefit to use. We're going "bare metal" for this system. We will, however, have a shared peripheral library for all nodes to use.
We have n git repositories:
- Each node gets its own repo.
- The common peripheral library has its own repo.
- The common communication protocol files (header files, etc) has it's own repo.
- The common code files become submodules in the node repos.
We chose this structure because:
- Each node can choose its own version of the common files, and this is reproducible since that version is checked into the parent repo.
- Changes in the local common files don't break it for everyone else.
- Git submodules aren't terribly difficult to deal with.
Rules:
- Peer review before code flies.
- Peer review prior to committing to common code.
- Code must be "released" (and not changed) at the T-1 week at the go/no go decision.
- Code must be committed to fly, and tagged with the flight number.