The "main" branch of the PacSatx repository now has code which uses FreeRTOS and runs on the LaunchPad.  Rather than starting from scratch and doing a new OS port and adding some code to do a few things, I started from Golf-TEE and removed much of the stuff that relates to Golf-TEE.  Even if you go back to the root of this repo, you will not find anything that is not ok to be fully open source. 

I left stuff in there that might be useful to PacSat.  For example, there are I2c, SPI and CAN drivers, as well as device support code for a number of devices, including MRAM, temp sensors, serial port etc.

You will find that there are four tasks started up in the OS:  Console, CAN, Command, and Radio.  Here is the general idea:

1) Console:  This is the task that interacts with a user during debugging and testing phases.  I've left in the entire typed command parsing but taken out a lot of commands.  The serial line that is used for console is actually implemented by the N2Het.  The Rx and Tx lines are on the outside row of the LaunchPad, pins 25 and 27.  This is TTL levels at 38,400 baud.  (Ha, don't ask which is tx and which is rx.  I just reversed the lines till it worked).  You need a ground, too naturally.

2) CAN:  Because CAN messages can arrive asynchronously, the easiest way to implement them is with a separate task.  It works together with canDriver.c to send and receive CAN messages and to dispatch the received messages.  Often these received messages on Golf will be telemetry, so they are dispatched to a telemetry collection task.  That is removed to simplify the PacSat code.  I don't know if we will use CAN at all, but the basic code is there.

3) Radio:  This task drives the AX5043 both for transmitting BPSK telemetry and receiving AFSK commands.  You will also see that this task can be set up as either a receiver or a transmitter.  On Golf, it depends which of the two TMS570 processors it is running on.  We have to design how this works for pacsat.

The tasks that generate telemetry have been removed, so you will see a few dead-end calls that are supposed to fetch telemetry data to give to the 5043 on the transmit side.  On the receive side, the AFSK data received is handed off to the command task.

4) Command:  This task gets a message from the Radio task when there is command data available.  Its job is to decode and validate the command and then to execute it.  Note that I often say "encrypt" or "decrypt" for commands.  In fact, the commands themselves are not encrypted.  However, they are validated by the standard method of transmitting an encrypted digest of the command and then decrypting the digest and comparing it against the digest of the received command.  (This is pretty much the same way that downloading Windows upgrades works).  The encryption/decryption requires a key.  There is a default key that will be used normally.  When we are approaching flight time, we will generate a "real" key to match the "real" command software and load it into the MRAM where the software can read it, but no human can. 

My proposed next plan, subject to whatever we as a group decide, is to determine how to attach the AX5043 Rasp Pi shield to the LaunchPad and try to ensure that there is code both to receive AFSK and to transmit BPSK.  Eventually, we will need to change this to AX.25 or whatever we decide to use for our message protocol, but at least we will know how to hook up the 5043 electrically and have some code to do a bit of testing.