search

sfuphantom / hercules-phantom-lib

A common firmware library for all Team Phantom PCBs based off of the TMS570LS1224/1227 Hercules line
0 stars 0 forks source link

SPI Driver #14

Open ManojBR105 opened 3 months ago

ManojBR105 commented 3 months ago

(Explain how this peripheral could potentially be used in the car)

Deliverables:

ManojBR105 commented 3 months ago

So basically we have only 2 SPI module pins that are accessible on the VCU board, that are MIBSPI1 and MIBSPI3.

All function names can be consistent with uart functions.

rafguevara14 commented 3 months ago

So basically we have only 2 SPI module pins that are accessible on the VCU board, that are MIBSPI1 and MIBSPI3.

  • MIBSPI1

    • CS0: connected to DAC on VCU board (VCU and BMS?)
    • CS1: NC
    • CS2: NC
    • CS3: NA on this package
    • CS4: NC
    • CS5: N2HET1[24] used for other functions (Alert Signal)
    • ENA: NC

  • MIBSPI3

    • CS0: available on header (connected to ADC on HV board (BMS) extra on VCU)
    • CS1: available on header (HET1[25])
    • CS2: Used for I2C
    • CS3: Used for I2C
    • CS4: NC
    • CS5: available on header
    • ENA: same pin as CS5

  • Board-level abstraction will have 4 Options for SPI

    • SPI1_CS0, SPI3_CS(0/1/5)
    • Configure both ports in master mode
    • No ENA function (since none of the use cases require this functionality)

  • Basic functions to be implemented

    • [ ] Configuration

    • [ ] Port selection

    • [ ] Pin selection

    • [ ] Word Size

    • [ ] Clk: frequency

    • [ ] Send Words

    • [ ] Receive Words

    • [ ] Interrupt Callback

All function names can be consistent with uart functions.

So is that a total of 4 functions or are you having a function for port selection, pin selection, etc?

One thing to note for the interrupt callback, make sure to read how the VCU firmware is designed to deal with interrupts. This will probably alleviate your worry about long interrupt handlers

image

The Ready To Drive signal would be a potential interrupt. Inside the ISR we would call an ISR-safe freeRTOS function and then the program would exit the ISR and the scheduler would run the callback when appropriate in this thread. This library is designed around the FreeRTOS environment so your drivers shouldn't focus on deferred interrupt handling. Keep the focus on abstracting hardware configurations

ManojBR105 commented 3 months ago

I will use struct for all the 4 configurations and 1 function for configuration.

Thanks for the information, I think I understand what you are trying to say. Here are 2 ways that we can set Interrupts.

  1. Set Interrupt so that the user gets a callback every time the hardware receives data/transmits data.

    • this works well for receiving only one byte/word of data, but when you want to receive more than one word, it needs extra coding effort by the user.
    • doesn't work for transmit, in transmit we need to make sure we write data to TD (Transmit Data Register) before enabling Interrupt, otherwise, the MCU will be going into this interrupt continuously.

  2. Set Interrupts only when a listen_for_receive/transmit function is called and disable interrupt after receiving a callback, this can be enabled again by calling the function again in the ISR-safe freeRTOS function

    • works for any size of data, as we can set the callback to happen at a specific length, it can be set to 1 as well
    • safely handles transmit as well
    • This might be a little inconvenient compared to the previous method, but has a lot of advantages and safety.

We can also combine these and implement receiving in method 1 and transmitting in method 2. But we already have the implementation and this is why even HAL drivers use this method. Also, we can reuse the UART code in SPI since their interrupt architectures are the same. Let me know what you think.