BMS tesseracted#23
Conversation
mjmagee991
commented
Jul 21, 2025
mjmagee991
commented
- Added BQ reset pin
- Added error LED pin
- Added reset and error logic to take advantage of new pins
aclowmclaughlin
left a comment
aclowmclaughlin
left a comment
There was a problem hiding this comment.
Looks good- is there a reason that the bq reset wasn't implemented initially?
Not important just curious.
|
This has been validated on BMS v4 1 & 2. It should be good for merging now. |
ActuallyTaylor
left a comment
ActuallyTaylor
left a comment
There was a problem hiding this comment.
Looks good! Also runs well, I had no problems on the code end when validating the boards. Docs will come in a future PR.
Still needs a lot more work, but it turns out writing good docs is difficult. I will continue to work on this throughout the semester. Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
I finished up the documentation for checking the polarity. There is a paragraph style explanation with more detail and a bulleted list that is easier to follow. I aslo added a new command into the bq_interface that will read the current and convert it for you. This removes the need to use a direct memory read and then convert the hexadecimal. Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Updated EVT-Core to the latest version, then renamed the DEV namespace to dev because it fits the new EVT core standard Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
|
I am working on analyzing were the increased FLASH usage is coming from. At the moment, it appears to be a problem with the CI using the newest arm tools, and our development using version 12. I have also noticed that after updating EVT-Core it seems that even arm tools 12 creates binaries just too big. It also seems like building for release, consistently adds ~1k extra flash over the debug releases... Here are elf analysis of 3 build configurations (Debug, Release & CMAKE Build All). These are HTML files generated using an elf analysis tool: BMS Elf Analysis.zip |
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Originally, we were always using -Og which optomizas for debugging which increases binary size. Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
…lor/v4-validation-docs
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
This fixes CANopen for the bms. The initialization of CANopen was happening before the board was connected to the CAN network. This led it to just never setting up. Signed-off-by: Taylor Lineman <git@actuallytaylor.com>
|
The DEV1-BMS target will not build on the CI. The CI is putting out 4% bigger bin files than any physical hardware we have. We are just going to ignore this for now and fix the CI later... |
…lor/v4-validation-docs
3 participants
