Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Current »

Current design:

TM is constantly running in its own thread performing the following:

TM calls UART driver functions to read and decode data from CV. This data is sent to PM through a PM-TM interface. This interface is already existing. The plan is to use the existing TM/PM comms interface to send and receive all the structs from ground and CV packed in a PITO/POTI struct

Data is received from PM through the interface. This data is sent to CV (and ground?) using the UART driver.

Finished Tasks:

  • Adjust TM reception so it only receives from CV in TM state manager using the UART driver function

    • Make the struct visible to both TM and PM

    • Still need to set UART pins

  • Implemented UART driver as cpp and hpp files

  • Talk to Aditya about ground comms implementation into TM

    • How the driver works

    • How and what do we send to ground

    • What function need to be called and where in TM do they need to be called

  • The plan is to use the existing TM/PM comms interface to send and receive all the structs from/to ground and CV packed in a PITO/POTI struct

  • New Reception Plan: Adjust the PIGO struct that already exists using the data the PM needs, and just use that struct in all the receiving UART functions this way we don't need to change names everywhere

  • Need to set UART pins with STM32 IDE

  • UART cant transmit constants?? So for now we just have it as a variable

  • Need to figure out the UART call back function multiple definition problem - gps.cpp

    • Can just have a condition that checks if its GPS stuff or FW-CV comms stuff

      • Maybe even check the startbyte if its not the startbyte then do whatever the GPS stuff is

  • Add Callback.cpp

  • Implement a queue for UART receive

    • Implement a circular queue of buf arrays of a temporary size

  • Create PR for whatever is currently finished (mentioned last meeting - Feb 1)

Questions Answered

  • Do we need to create the system for PM to receive structs from TM or does that already exist?

    • So far TM calls an imaginary function in PM which already exists or we need to create it

    • There is an old PM-TM interface, not sure how outdated it is (e.g. struct members)

  • How and where do we set the UART pins for ZP

  • Is there a new version of PM we need to use - this can prob be answered with the updates git workflow which I need some help setting up

  • Is there any implementation we need to consider for the ground comms, or do we strictly work with the FW-CV comms

To-do:

  • Need to figure out what the analyze and report functions do then create functions that do what they need

  • Go through ZP and rename all the POGI/PIGO structs

  • Figure out how to get the unit tests working

  • Talk to Ray about testing and data we can send and receive as tests

  • Talk to Aaditya about the Xbee test plan

Testing Plan:

  • Done:

    • Test byte/struct created

  • Use the Python script to send test bytes to the serial port and have TM receive it

  • Put breakpoints in many points of the code to verify the byte array, byte queue, and struct

  • Transmit test message to see if transmission works

    • Can be a char array or a struct converted to bytes

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.