MC Code fully done, includes the pwm encoding for kelly

[sardormirk]

Changed/Fixed MC code for interfacing with the Kelly:

• No longer receives/parses telemetry from the Kelly
• Used exclusively for controlling MC from RPI commands
• 2 PWM signal encoding for direction and speed (lead/lag of signal determines direction, freq of signal determines speed)
• Functions implemented for MC_drive, MC_stop, MC_change_direction, MC_set_throttle
• Added ramp slow down for MC_stop

How it works:

Two tasks

• ReceiveCommandThread parses incoming commands from RPI (CAN), and updates global mc_command struct (guarded using a mutex). CAN interrupt releases semaphore which this thread acquires before getting can frame (task is blocked if no command available)
• MC_CommandControlThread acquires semaphore released by ReceiveCommandThread that indicates a parsed command is stored in mc_command. It accesses mc_command and handles the command received via a switch case

5 Commands:
MC_IDLE, MC_START, MC_STOP, MC_THROTTLE, MC_DIRECTION

Builds successfully but not tested on hardware yet

[TharunGaneshram14]

so ur reducing the work done in the ISR and signaling another thread to pick up the message. Design seems fine but curious as to the reason

[TharunGaneshram14]

low key curious as to what we gain here by even having the 2 threads instead of just 1 loop without RTOS lol. We would save out on semaphore, mutex, and general RTOS overhead. We legit have to wait for receive thread to complete and then run control thread after anyways bc of the semaphore.

[TharunGaneshram14]

I guess, in the scenario where you have commands in rapid succession, having the receive thread at higher priority would allow for it to stay active and change the command instead of us rapidly switching modes on the pod

[TharunGaneshram14]

didn't stare too hard at your timer logic but overall seems legit