Bob, I can check that memory info from the link map. But this is not linux, so commands like that are not available. I'll look at your attachment and see if there is code that I can port to run on the system to get an idea of the speed.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Tue, Nov 15, 2022 at 9:01 PM Bob Stricklin via pacsat-dev < pacsat-dev@amsat.org> wrote:
Nice job Burns.
Would you let us know how much memory RTOS takes up, OS, swap space, and heap or however RTOS defines it. Also how much memory does the code package you have working take up? Just wondering how this all shakes out.
Can you run the the linux command: sudo lshw -short
and post the results?
I have a also attached a pdf of some speed testing I did for Microwave Update 2019. If you can easily load the sysbench program and run the speed test that would be interesting.
73,
Bob
On Nov 15, 2022, at 4:14 PM, Jonathan Brandenburg via pacsat-dev < pacsat-dev@amsat.org> wrote:
This is fantastic work! Thank you, Burns! Jonathan
On 11/15/2022 3:25 PM, Burns Fisher (AMSAT) wrote:
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~~
-- Jonathan, KF5IDY
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