Burns,
That is a great summary and was very helpful for me. Many thanks.
How do I get hold of a LaunchPad so I can try this? Do I order one online, or do we have some "in stock"? I'm happy to order one if someone points me to the right thing. I assume it is not the same as the old Fox breakout boards.
To help think how a PACSAT might work in FreeRTOS, here is a summary of the PACSAT prototype code.
The pi-pacsat starts a thread which listens to the TNC and stores any received frames in a circular buffer. This makes sure we never miss a frame even if we are busy preparing to transmit something or actually transmitting. The link is full duplex so we always need to be ready to store the data even if we can't process it immediately. This could be interrupt driven, but I poll.
A second "processing" thread processes the received frames and then takes the next action in each of two "state" machines, transmitting frames as needed. It does that in a continual loop forever. The state machines are the Broadcast State Machine and the Uplink State Machine. (I also call the uplink FTL0 as that is the name of the protocol). In fact the state machines are a set of state machines. There are up to 10 broadcast state machines for stations requesting broadcasts and up to 4 uplink state machines for stations uploading files. In reality we just keep track of a few variables to know where we are in each state machine and who asked for what.
I assume this would translate into 3 RTOS tasks if we also need one for the "TNC". The state machines generate transmitted frames and those are sent out by the transmitter. Currently those are sent non blocking and the "TNC" queues them for transmission. But I keep just one or two frames in the queue. The TNC does handle some of the details of the AX.25 protocol. NAK/ACK frames are not "processed" by the code. The TNC sends them automatically and immediately. We think we would need a separate task to handle that.
If this sounds directionally correct then perhaps we take your description and this and put them in a software architecture doc.
73 Chris
On Wed, Nov 16, 2022 at 12:40 PM Bob Stricklin via pacsat-dev < pacsat-dev@amsat.org> wrote:
Nice write up Burns.
It sounds like the RTOS is being used as more of a dedicated task system and not really an OS. One possible advantage to this may be the memory needs are better defined. You also can’t be lost in a faulty task or orphaned task. We can have memory leaks due to coding issues but hopefully those will be identified.
My interest for asking the question was to help build an understanding for how much memory we need on the board. The code size you are talking about is not too large.
I am not clear where the code will sit which is in non volatile memory, the start up code. Would this be placed in flash and transferred to MRAM on power up for execution. So two 170K blocks of memory would be needed. If the plan is not writing flash in orbit then how would changes be made to the program when problems develop?
If we have a Power on reset event (POR) where will the processor jump for the first code in a Fox or Pacsat? The CPU can probably be configured to go where you want in hardware, on chip or off chip.
I think you have all this thought though and would like to know what was the process for this? I will eventually see this in the schematics for the earlier designs but I am still working through those.
I have been trying to get operational on the existing satellites to get an idea of how much memory is being taken up by the user base. I still have a lot to learn in what is available to us in telemetry or how we can track this.
Bob
On Nov 16, 2022, at 10:13 AM, Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Bob asked about the amount of memory used by my FreeRTOS port. To be clear, there are two types of memory in the TMS570 (and in the STM32 as used in Fox-1 for that matter): Flash memory, which is non-volatile memory that holds that program and some constants, and RAM which is where volatile data is stored. In the past we have never planned to write the flash memory in orbit since it uses a charge pump which (we are told) is often the first thing to go in a radiation environment. It also has a limited number of write cycles (a few hundred or thousand?). Flash memory has an address and can be operated directly by the processor and code is generally executed directly out of it. This is totally different from the MRAM we have talked about. MRAM has no write cycle limit and seems to have a very good record in radiation. However MRAM is only accessible as a peripheral--it has no address and code can't be executed directly out of it.
The TMS570LS0914PGE, which is what is used on the RT-IHU has a total of 1280 KBytes of flash memory. The highest address in flash memory used by my OS port is 0x28aab8, which translates to about 170KBytes, of which 162 is code. And btw, the clock speed on this processor is 160MHz (or slower).
This processor also has 192KBytes of RAM of which 79K are currently used. However, 64K of that is used as heap storage by the OS of which only 32K is currently in use by the OS, so the heap could be made smaller. See below about this OS.
I think it is worth saying something about this RTOS (real time operating system) since this was a total surprise to me when I first started learning about it to write software for Fox-1. For those of us accustomed to Linux or WIndows or MacOS (or in my case an OS developer), one would hardly call this an operating system. It has three main functions:
- Creating tasks and switching the processor between them to give the
impression that they are operating simultaneously. This switching can be done either asynchronously (that is based on a timer), or it can be set up so that a task is switched away from only when that task blocks (i.e. it makes a call to wait for something).
- Timers. One can create timers which will call some code when it
expires. This code can then be used to release a blocked task. In other words one of the things that a task can wait for is for the timer to trigger.
- Mutexes (of various forms) and queues: These are really the same
thing---a task can wait on a mutex or queue, and a timer or another task or interrupt routine can release it by putting something in the queue.
That's it. Notice that I did not say anything about address spaces. All tasks share the same address space. If you are used to programming in Linux, think of the tasks as more like threads in a single process.
I also did not mention I/O. It is up to us to create all the I/O functions and to ensure that a task waiting for an I/O to complete does not block the rest of the tasks (i.e. it can't just loop). I have done this for all the peripherals used by Fox and Golf.
I also did not mention memory management. This is not strictly true. FreeRTOS does have a heap that one can use to alloc and free from. The OS itself uses it to allocate task, queue, and timer data structures. However, I would recommend never using this ourselves for two reasons. 1) We generally don't create and then destroy data structures. It is better to allocate them statically. 2) Deallocating data tends to leave holes in the heap so it is easy to get to a point where there is enough memory for an allocation you might want, but you can't allocate it because it is splintered. This is especially true with the relatively small amount of memory in our processor.
I hope this is helpful and forgive me if I have spent a lot of time stating the obvious. I'm kind of basing a lot of this on my memory of what I did not know 8 or 10 years ago when I started with all of this!
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Nov 15, 2022 at 9:54 PM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I believe that the easiest way to do this is to do a git clone (on a Linux system anyway). Then run CCS and I think you can import a CCS project. CCS/Eclipse has git builtin so after that you should be able to pull, checkin, merge, etc etc all from the IDE. Although I do checkin the CCS/Eclipse properties files, it might not be perfect so you may have to tweak around a bit to get it to work. If you have trouble lets work on it so we can try to figure out how to get it so multiple people with CCS can work together.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Nov 15, 2022 at 9:49 PM Jim McCullers wa4cwi@bellsouth.net wrote:
Thanks for the work Burns.
Any particular steps to import this into CCS?
Jim McCullers
WA4CWI
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:
- 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.
- 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.
- 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.
- 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.
73,
Burns Fisher, WB1FJ
*AMSAT**(R) **Engineering -- Flight Software*
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org