I have an application that requires a low BOM cost, hence my selection of the STM32F030C8Tx.
My requirements are as follows:
2 UARTs operating at a maximum rate of 115200
1 UART operating at a rate between 9600 and 115200
8 PWM outputs, 8 bits is fine, anywhere between 1 kHz and 10 kHz is OK
8 A/D inputs, 10 bit resolution is fine
1 I2C channel
1 SPI channel
2 Digital outputs
2 Digital inputs
Internal clock will likely be maxed out at 48 MHz unless I can get away with less.
The STM32F030C8Tx only has two UARTs. Since the third serial port is only for debugging I was planning on bit-banging it. My guess is I should be able to do 9600 no problem. Again, debug only.
The problem seems to be in the requirement to have 8 PWM's and 8 A/D's at the same time. I quickly start losing the ability to have one or the other.
My first thought was, OK, bit-bang the PWM outputs as well. If using a timer interrupt this would be a 256 kHz interrupt, which gives me 3.9 microseconds to make eight comparisons and toggle outputs as necessary. I'll have a Nucleo board in hand next week to test this hypothesis. That's roughly 230 instructions per PWM tick...with a degree of intelligent coding I likely don't have to drive the pins at 256 kHz. In other words, I only have to address transitions.
What I don't understand with the timers is this setting of "PWM without output" in MX. Googling for this produces a pile of unrelated results.
If I can use this mode to produce eight interrupts at the counter timeout (or transitions) this would be perfect. I can tolerate jitter at all PWM edges, which means I can take my time servicing the outputs.
If this "PWM without output" approach works, I can then map the digital outputs any way I want and get the eight A/D inputs at the same time. The serial ports would then not be an issue either. If I don't have the clock cycles to bit-bang a UART I can easily set it up to use an external SPI or I2C UART for development purposes.
I think that pretty much defines it. I am not super familiar with this architecture and tools (migrating products from other architectures to STM32-land) and don't have a tangible sense of what might be possible.
Any and all advice on this would be appreciated.
Thanks,
-Martin
