Added non-critical faults and included test in can_handler.c #87
Conversation
There was a problem hiding this comment.
Great start, i defintely like the ideas here.
I really liked the counter you added to keep track of how many of one of these faults happened, thats something i hadnt thought of but makes a lot of sense, but i have an idea to tweak this structure:
what if the non critical fault struct, instead of a 32 bit int like we orignially said, we have a single uint8_t representing each NC fault, each one that acts as a counter. this way we eliminate the need for the single, bitwise 32 bit int, but the entire struct is just a bunch of integers that represent the counts for each fault. In this case, for the CAN fault dfor example, every time we get one, we simply increment this value, much like you already do
Core/Src/can_handler.c
Outdated
|
|
||
| ringbuffer_t* can1_rx_queue = NULL; | ||
| ringbuffer_t* can2_rx_queue = NULL; | ||
| nc_fault_collection_t* nc_fault_collection = NULL; |
There was a problem hiding this comment.
nit picking but, no need to make this a pointer. Right now, no memory is allocated for it so it would fail, but rather than adding a malloc() for it just make this a direct struct object
Core/Src/can_handler.c
Outdated
| // TODO add non crtical fault capability - could create one for failed can receieve | ||
| return; | ||
| } | ||
|
|
||
|
|
||
| nc_fault_collection->can_receivals += 1; |
There was a problem hiding this comment.
i see what ur thinking, and i have an idea to tweak this slightly but to achieve the same thing. See top message for that
Core/Src/stateMachine.c
Outdated
| void sm_nc_fault_collect(nc_fault_collection_t *nc_fault_data) { | ||
|
|
||
| bool condition; | ||
|
|
There was a problem hiding this comment.
This was on me for not mentioning, so my bad, but for these, there shouldnt be any need for our timer system/debounce. Thinking about a fault like a CAN message failure - that would be binary, it either happens or doesnt, and so no timer debounce should be needed.
This is different than our ciritcal faults because those constantly stream data, and if we get .0001s of bad data, we want to start a timer to make sure that data stays bad for a longer period of time. So, i think this part can be scrapped
Changes
Added a collection system for non-critical faults and also made a test example for when CAN does not fails to receive a message.
Notes
Hopefully this system works for non critical faults. Also, I was not sure how and where to initialize a timeout for the nertimer to check if the condition is true for a certain duration of time before adding the fault code to the fault status.
Test Cases
To Do
Any remaining things that need to get done
Checklist
It can be helpful to check the
ChecksandFiles changedtabs.Please reach out to your Project Lead if anything is unclear.
Please request reviewers and ping on slack only after you've gone through this whole checklist.
Closes #81