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
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
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.
Burns Fisher, WB1FJ
*AMSAT(R) Engineering -- Flight Software*