• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

Software Team Meeting May 31st, 2004

7:00pm - 10:00pm at James' house in Colton, OR

Agenda:

1. In-depth walkthrough of the code by James (Jay, can we photocopy some of your notes and diagrams a head of time? [yes, I'll bring 10 copies])
2. Do a demo hacking, compiling, transfering and running it on the FC
3. The PSAS network:
   1. Discuss 802.11b modes
   2. Go over configurations for wireless network cards for talking to the FC
   3. Discuss network topology
4. CAN driver stuff
   1. maybe smoke test uncanny driver on FC
   2. at least document steps to build, install, and test driver
5. Partition tasks to folks

• manager.c
  • reads from stdin
  • bart hates "foreach"
  • some spew stdout
  • "not filters,
  • originally canreader canwriter. open file descriptor would confuse multiple "can read" can write" processes,
  • currently only a single process handles can read and can write
  • start_task
  • takes options (flags), array of string arguments
  • makes sure the file exists
  • CAN file descriptor stored globally, dup2 parameter
  • kill_die
  • ignoring signals (it is handling orderly shutdoown
  • lets stderr know about killing children
  • while living children, waits for those children to die (finally)
    • Bails if wait error
  • bart says : instead of by count, walk through pid table for specific
  • sets that particular task pid to 0 and decrement total count
  • justin asks about race condition between signal handler and kill_die -
  • main
  • set up interrupt handler
  • skipped code
  • call startask in each loop
  • all tasks must be started or catastrophic failure
  • sleep is a chance to be scheduled (bart is going to hack off)
    • changing to schedyield (or whatever)
  • loop that revives dead children (bad children that spontaneously cacked)
  • bart: possibly add code to only restart a process once
  • add manager code to handle
    • mandatory
    • sequencer
    • smart
    • CAN_RW
    • non-mandatory (other)
    • fcnet
    • net2fc
    • logger
• question arises about what to do with signals (bart)
  • continues to have existing shutdown code.
  • startup a known list of tasks
  • if children dies, insert a sutiable replacement
  • because manager is extremely simple, if it receives an important signal, pass a sig term on to children, reap the child, and quit.
• SMART
  • signal processing code.
• Question on authorization code (justin)
• Logger.c
  • count - how many bytes to be written
  • /temp/fcfifolog - volatile - needs to be written "for real"
  • fifo_read makes sure that it can read from the fifo
  • blocks until there is data to be logged
• can_rw.c
  • select is called because there are two cases when can rw can be called - data is available for reading, or fifo has something to be read
  • can is opened
  • fifo is inited
  • fifo's are opened to different processes
  • race condition in that fifo's may be opened for write before the reader is running, filling the buffer and blocking.
  • FD_ZERO clears read_fds
  • fdset is a big bit array (used to be unsigned long)
  • select needs to go and test everything, or just up to what the max is.
  • max will either be fifo_fd or can_fd
  • data can be available on fifo, can, or both
  • because select is used, fifo_read is "guaranteed" not to block (JB wants to verify)
  • can writes are more important than can read
  • Ian updated driver so that fc can driver uses the same format as the PIC firmware
• Sequencer.c
  • Bart needs to fix "state fu"
  • Writes to fc2net, can_rw, and can_wtr
  • when timer goes off, fifo message is written to my fifo (and i get out of blocked fifo_read) - - -