RogerClark wrote:Re: Using Alternative pin config's
I'm not sure if we need to use this feature
It's the essence of the ARM I/O architecture!!! It's how you tailor the MCU to what you need to do - since there are more on-chip I/O devices than package pins. Esp. in the 64 pin packages!!!
It's NOT a reason to avoid the use Cube. I've done Cube based projects where I elected to use I/O function A on certain pins, and B on others, and juggle these to get the peripherals I need connected to pins. It's not sensible to hard-code I/O to pins when, say, you have 4 UARTs on the chip, but you have a 64 pin package and need only 2 UARTs and you have SPI, SDIO 4, I2C, FSMC, etc. Next project, you have different I/O needs. Yes, with a fixed-board type mindset, this is copper and solder. But no, the same board can have pins' alternate functions mapped as needed by software. Just look at any serious ARM based board and you'll see the colorful crib sheet card showing what I/O thing can be used on one or more pins, at the software's choice.
In this one
there are about 3 alternatives on most pin - software selected.
On STM32F4's there are 6 or more. So if project #1 needs I/O collection A on certain pins, but the same board is used on project #2 which needs different I/O collection, it's just software, not solder, not a new board.
Alternate pin choices by software is so fundamental to today's processors that cram so many I/O devices on the chip, and only a die or 144 pin packaged chip can get every I/O device connected to a pin, simultaneously.
Without Cube, managing the alternate pin choices becomes a lot of hand coding beyond journeyman level. And Cube inputs from you the register config for each chosen peripheral. That's ESSENTIAL, in these complex chips. Then Cube spits out the driver init and ISR and DMA handling code that would have taken you weeks/months to learn and many days/weeks to code.
I sincerely apologize if I''ve misunderstood the opening statement, in this post, in which case, I'd delete my post, here.