PSAS/ news/ 2003-10-07 - What's next, timelines, task lists

System Requirements

We decided to break up the requirements into "blocks", where "block 1" is the absolute minimum system we need to launch, "block 2" is the nice system we'd like to launch but it may be finally complete after several intermediate launches, and "block 3" is the future full functionality we've always been working towards.

[CP] = critical path: critical tasks with lots of unknowns

Block 1 Requirements:

Block 1 Software requirements:

Block 1 Questions:

Block 2 Requirements:

Block 3 Requirements:

The plan here is that we schedule a time that these subpieces are integrated but not tested, and that is the time at which we could plan a launch date.

Dead Tree Report

We need to write a report on our exploded rocket, where that left us, and where we are going.

Other ideas

Software discussion


We had a long talk about BlackboardArchitecture with threads and mutexes and condition variables, versus the existing FifoArchitecture structure. The process/FIFO environment has been fairly easy for people to develop and debug so far -- allowing us to actually develop an application. It seems to break down in fine-grained message dispatching, in the need to packetize the conversations between various tasks, and in the uncertainty of the contents of the producer/consumer mystery fifo (deadlocks? livelocks?). Moving to a new architecture requires someone to actually create a demonstration based around our existing application -- significant effort, but it would also clear up any possible Grass is Greener idealism about the scheme. Since the meeting the whole multi-headed issue of FlightComputerArchitectures has been given its own TWiki topic.

CAN Driver:

There is a class project afoot that Bart will coordinate. Needs lots of input from James, Ian. Hopefully a nice, clean 82527 implementation that gets us what we need. It's also likely the class will be able to buy another MOPS520 board to be able to write the driver.

?JamesPerkins and IanOsgood talked about findings on the current CAN driver and massaging it to do RTR messages without expecting a response with matching message id.

Bart's Requirement List:

  1. turn the existing RTR "read" into an ioctl
  2. exclusive open
  3. single file descriptor can both read and write (driver would allocate two onchip message buffers for read/write open)


?LarryLeach reports it needs to be made working. First step: Andrew and Markus will get two prototype hardware boards together with firmware within the next few weeks.