Change processor from STM32F303 to STM32F722

[ajn96]

Moving to STM32F722 will provide more resources (256KB RAM, 180MHz core clock) and capability for future algorithm development.

There are more EXTI vectors available (16). Would be nice to avoid any potential ISR overlap between Data Ready and PPS.

So for example, DIOx_Slave pins could be PA8, PB8, PC8, and PC7 (interrupts 7/8 for PPS)
DIOx_Master pins could be PA9, PB9, PC9, and PA10 (interrupts 9/10 for data ready)

SPI pins should be good to keep the same, with the exception of IMU CS, which needs to be on a timer output channel pin

[ajn96]

Will leave current firmware for F3 on branch when this change is made. Not planning on adding new features to F3 version afterwards

[ajn96]

@juchong Before we pull the trigger on this change we should probably have a deeper discussion (and maybe pull in other team members?) about the future of this platform. Current processor is fine for the "comms" operations the board performs currently (SPI, USB, or SD logging). Main advantage of going to different board would be potential for adding Kalmann filtering, pose estimates, or other IMU aware DSP. Need to figure out if that is something we want to do, and if it is worth the extra development effort to port design, and BoM cost / power consumption.

[juchong]

From my discussions with other internal teams, I've been told that the increased ”horsepower” will be greatly valued and will help merge several, independent efforts to create a reasonable sensor fusion platform. Some of the feature requests listed in the repository are a product of those discussions.

[ajn96]

Ok. Just wanted to make sure we had thought through everything. From my initial review, I think porting the firmware should be fairly straight forward, as long as there aren't any big whoopsies porting the hardware design over that require fixes in software. Most of the functionality offered by the F7 is a superset of the functionality offered F3. New processor should allow up to 1 second of buffered data capture from the high performance IMU's as well, which is a metric I know some folks were looking for.

[ajn96]

@juchong STM32F722 processor pin map for buffer board hardware rev C

[ajn96]

@juchong
https://www.analog.com/en/products/amplifiers/specialty-amplifiers/current-sense-amplifiers.html
Just saying. We're going to have the A/D running anyways

[juchong]

@ajn96 I don't think we picked a GPIO for triggering an IMU Reset (IMU_RST_OUT). We picked PA3 to act as IMU_RST_IN

[ajn96]

@ajn96 I don't think we picked a GPIO for triggering an IMU Reset (IMU_RST_OUT). We picked PA3 to act as IMU_RST_IN

I was intended PA_03 to drive the IMU reset line. What would the IMU reset input do? I think the host reset line should connect directly to the STM32 hardware reset input

[juchong]

Agreed. I forgot what the intended behavior was supposed to be

[juchong]

Here's the proposed schematic @ajn96
BufferBoardRedesign-02082021 - Feb 8 2021 - 12-50 PM.pdf

[juchong]

Updated schematic with slightly different (but more convenient) part numbers:
iSensor-SPI-Buffer-RevC - Feb 24 2021 - 11-22 AM.pdf

[ajn96]

Updated the pin map diagram with final net names: