northeastern-electric-racing / nerduino Goto Github PK

Since we migrated a lot of stuff to confluence, I think that people just need to know how to add the library to a project + how to implement some stuff

This ticket is kinda large, as it entails:

1. Getting the PWM working out of the AMC6821 in any fashion
2. Condensing proof-of-concept code into some nice, user-friendly functions that future devs should be able to easily use

Some references
AMC6821 Datasheet
Thread of My Experience with Texas Instruments
Sample PlatformIO Project with the Operation we Want with Different Board
Low Level Library Used for Hardware Interaction with Chip in that Implementation
My (Shitty) Code for trying to get it working

This might prove to be a bit annoying, but I think we might want to have dedicated CAN handlers for 1 "main" CAN line, and then add the option of creating a temporary line (Specifically for charger comms for shepherd)

NERduino has the capability of utilizing external SPI lines, so we need to figure out a way to utilize them all in code. We might need to switch the lines mid-operation to make this work so we need a way of abstracting that so it appears seamless to the user.

NERduino has the capability of utilizing external I2C lines and an onboard line, so we need to figure out a way to utilize them all in code. We might need to switch the lines mid-operation to make this work so we need a way of abstracting that so it appears seamless to the user.

When I created these functions, I just had the user pass an empty array through the functions to retrieve data, and I think I should enable the user to just set a variable equal to the function, or also pass an empty array. I also want to add operator overloading for the structs I defined or at least some way to make implementation easier for the user

I think that we can use macros to handle a lot of the boilerplate behind the CAN message handling right now.
I.e.

• Have enum or something of all CAN messages
• Have a total number of CAN messages
• For All CAN messages create each CAN callback

I think that this can be found within the I2C comms, where we wait forever until we hear a response.
This was made because of me being dumb, we should add timeouts/a class specific "I2C available" variable to prevent this