FWT-7 I'll VCing U in court. #2
Conversation
…en the two pinouts, will fix), and stubbed out the Hardmon process method.
…he input & output data for the MCUC, including the Powertrain CAN line (lots of assumptions), but NOT including the canOpen.
…ing information from powertrain CAN messages.
… is so much stuff in this that is unfinished/just makes assumptions about how stuff in the future will be implemented, mostly HIB and all the can IDs are just complete guesses). Also none of the accessoryCan stuff is implemented cause it's on CANopen and we have yet to determine all the dictionaries we need to use, and exactly how it's gonna work.
…an expert coding genius. Also fixed some issues in hardmon that I noticed lol.
mjmagee991
changed the title
There was a problem hiding this comment.
Move these to a folder called datasheets/. This isn't a perfect solution, but it's better than having a unique folder like this
| /** | ||
| * Driver for the Hardware Monitor | ||
| */ | ||
|
|
| struct reqGPIO { | ||
| //model input pins | ||
| IO::GPIO& ignitionCheckGPIO; | ||
| IO::GPIO& ignition3V3GPIO; |
There was a problem hiding this comment.
Why are there two ignition GPIOs? Is one of them for self test?
| IO::GPIO& lvssStatus3V3GPIO; | ||
| IO::GPIO& mcStatusGPIO; | ||
|
|
||
| IO::GPIO& ucStateZeroGPIO; |
There was a problem hiding this comment.
An array of GPIOs would be better here
|
|
||
| IO::GPIO& eStopCheckGPIO; | ||
| IO::GPIO& watchdogGPIO; | ||
| IO::GPIO& eStop3V3GPIO; |
| // discuss it more with the EES and maybe Matt. | ||
| if (inverterDischarge) { | ||
| powertrainCAN.setMCInverterDischarge(true); | ||
| powertrainCAN.sendMCMessage(); |
There was a problem hiding this comment.
The Hardmon should only send a message if we've determined the MCUC is no longer trustworthy. Is that decided by the model or by our code?
| inverterEnable = outputs.Inverter_EN_CAN; | ||
| ucFault = outputs.Fault; | ||
| watchdog = outputs.Watchdog; | ||
| ucState[0] = outputs.uC_State & 0b00000001; |
There was a problem hiding this comment.
If you're going to use bit-shifting here, you don't need to specify 1 like with bits
| ucState[0] = outputs.uC_State & 0b00000001; | |
| ucState[0] = outputs.uC_State & 0x01; |
| //We will send accessory CAN SelfTest message over CANopen | ||
| //Send the powertrainCanSelfTest message | ||
| if (powertrainCanSelfTestOut) { | ||
| powertrainCAN.sendUCSelfTestMessage(); |
There was a problem hiding this comment.
I was thinking that self test should be handled entirely before we get to the process loop
| gpios.canSelfTestGPIO.writePin(canSelfTest ? IO::GPIO::State::HIGH : IO::GPIO::State::LOW); | ||
|
|
||
| //Send the Motor Controller CAN message (set values first) | ||
| powertrainCAN.setMCInverterEnable(inverterEnable); |
There was a problem hiding this comment.
Would it be better to pass in a struct to send the message instead of setting a bunch of variables independently?
|
|
||
| VCU::MCUC mcuc(gpios, ptCAN); | ||
| ptCAN.addIRQHandler(powertrainCANInterrupt, reinterpret_cast<void*>(mcuc.getPowertrainQueue())); | ||
|
|
There was a problem hiding this comment.
Might handle self-test here
Initial setup for the main method for both the Hardmon and MCUC main targets.
Implemented:
Powertrain (raw) CAN stuff
Simulink model integration
Main control loops for both models.
Reading my own code and having a seizure
Unimplemented:
Accessory (CANopen) CAN stuff
Correct Powertrain CAN message ids & format (all my HIB format stuff is a total guess)
Happiness