8 PWM, 8 A/D, serial and more. Can this be done with the STM32F030C8Tx?

[martincho]

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

[MM..1]

I mean all this will work ok, and third UART isnt necessary, debuging over SWD work ok.

TIM1 have four pwms and too TIM3 then you have 8...usw

[waclawek.jan]

Attached one of the possible solutions.

I believe I could pull out the debug UART using SPI, although the good old bitbanging is an option too.

JW

[martincho]

Nice, thank you. I ended-up with a similar layout after playing with it some more. In my case I had to relocate UART2 in order not to lose SWCLK and SWDIO. That eliminated ADC2 and 3, which I replaced with 8 and 9.

 

I am going to try your configuration and see what it looks like. I would much rather all the A/D inputs together in the corner rather than have a UART in the middle of it all.

I neglected to add that I also need one set of inputs for a quadrature encoder. I don't think I can do this in hardware (could be wrong) given the intense use of timers. Being that this is for a low speed user interface knob, it would not be too difficult to implement in software. If all PWM generation is happening in hardware I'll have plenty of time for that.

Thanks.

[martincho]

I only have SWCLK and SWDIO. Is that enough to debug? In studying various application notes it seemed to me that you need SYS_JTDO_SWO for serial debug (printf from debugger). This chip does not offer that signal.

[martincho]

Ah, OK, what's missing in your configuration are the SYS_SWCLK and SYS_SWDIO pins. This forces moving UART2 to the opposite corner, which, in turn, eliminates A/D inputs 2 and 3. That's what I ran across. I think what I put together above might be a solution. I'll need to implement encoder knob input and a debug UART in software, which should not be a problem.

[Piranha]

For printf style (and also more complex data monitoring/streaming) debugging purposes a SEGGER RTT can be used. It works with the basic 2-wire SWD without SWO pin, but requires a few additional lines of code and a J-Link debug probe.

[waclawek.jan]

> what's missing in your configuration are the SYS_SWCLK and SYS_SWDIO pins.

Sorry I overlooked that.

JW

[martincho]

I'll look into that, thanks.

[martincho]

No worries, I've been going back and forth on this for a while. I think I have a good compromise here. All the intensive stuff is in hardware now. I can do the encoder and a bit-bang UART in code. I think I'm good to go at this point. Thanks for taking the time to look into this.