AerospaceNU / AerospaceNU/stm32-avionics
Data log rewrite/filesystem abstraction
- Linguagem predominante
- C
- Estrelas
- 5
- Forks
- 0
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Descrição
The current data log implementation (`common/system/tasks/data_log.cpp`) needs to be mostly/entirely rewritten to enable unit tests, support for different flash chips, and generally remove a lot of scary global state.
General refactoring things:
1. Refactor into a class to make it easier to use/pass around specific instances.
2. Currently, there are lots of static tracking variables at the top of the file. Global state is generally bad, but especially as static variables because there's not really a good way of "resetting" them for unit tests or such. We've also previously had bugs because a global variable was getting changed somewhere it shouldn't which then affects other places.
3. Generally, lots of long functions that do lots of math/address calculation that isn't particularly readable. Should be refactored into helper functions/possibly into the flash chip driver itself so that the high level logic is clear.
Fun additional improvement ideas:
1. Our current flash chips require full sector erases to erase any data. Essentially, we can "write" data and turn arbitrary stored 1s to 0s in binary, but we can't arbitrarily do the reverse - we have to erase the whole sector, changing it all back to 1s. We get around this issue for flight configurations (which we want to rewrite often, whenever the FCB is reconfigured) by writing packets to the front in a sort of array and using the latest written one as the most up to date one. It would be nice if this process could be more abstracted so that we can simulate a read/write/erase storage location even if one doesn't really exist.
2. We are planning changes to the sensor loop that allow certain sensors to record data faster than others, e.g. the IMU can update at 20 Hz while the barometers update at 0.5 Hz. We will run out of space quickly if we always write the entire log data struct (as we do currently) so some method of recording individual sensor data updates would be useful. This can still be done before the sensor changes in question are finished.
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Avaliação
Esta issue ainda não foi avaliada.