PY32f002B support

[usbalbin]

From a quick glance PY32f002B seems to be quite close to PY32f002A? I noticed A has TIM16(without output on any pin) while I think B instead has TIM14 with one output. B also has 24kB flash instead of 20kB as in A.

[creatoy]

According to the datasheet, yes, but from some information on the Internet, they may have the same peripherals, and all have 32k flash like f030 and f003 instead of 24k or 20k. Of course, these are not officially guaranteed. I reserved all peripherals when creating this repository, and I am not sure whether I should keep these unguaranteed resources.

And I will add the PY32F002B support later.

[usbalbin]

I personally would prefer if only the guaranteed peripherals and limits were visible by default. Since the manufacturer are fully within their right to remove these extra features at any time without notice. I also suppose (guessing here) it could be a binning thing, for example the devices who's pll does not pass some test might be demoted from F030 to 003 or 002 etc.

Users of this crate are still able to bypass all of this by simply using the py32f030, right?

And I will add the PY32F002B support later.

Great, awesome! :)

[creatoy]

You are right. I've added the py32f002b support, please let me known if you find any issue.

[usbalbin]

Awesome, thanks!

I have posted a draft pr to test out the changes

[usbalbin]

There are some weird things:

• I2C_SR1 bit 12 PECERR seems to be missing for py32f002b. The RM mentions PECERR in general but does not list the bit in I2C_SR1 as for the other chips. Seems a bit strange. Why describe an error if it can not be checked?
• py32f002b is missing some of its "high" gpio config registers which I suppose makes sense since it only seems to have 8 pins per port.
• SPI_CR2 bit 12 FRXTH is missing. The RM does not mention it at all. However that bit seems to be used in Spi::into_8bit_width and in turn the constructor :/ What do we do here? I have not looked into it enough to understand if/why it is needed.
• Is it possible to rename pu32f002b's TIM14 CCR1 ccr bits in the pac to be consistent with the other devices?(the other devices bit field is called ccr1)

  error[E0599]: no method named `ccr` found for mutable reference `&mut py32f0::py32f002b::tim14::ccr1::W` in the current scope
   --> src/pwm.rs:776:63
    |
  776 |                     unsafe { (*$TIMX::ptr()).ccr1.write(|w| w.ccr().bits(duty.into())) }
    |                                                               ^^^ help: there is a method with a similar name: `ccr1`
  ...
  874 | pwm_1_channel!(TIM14: (tim14, tim14en, tim14rst, apbenr2, apbrstr2),);
    | --------------------------------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `pwm_1_channel` (in Nightly builds, run with -Z macro-backtrace for more info)

[creatoy]

There are some weird things:

• I2C_SR1 bit 12 PECERR seems to be missing for py32f002b. The RM mentions PECERR in general but does not list the bit in I2C_SR1 as for the other chips. Seems a bit strange. Why describe an error if it can not be checked?

I couldn't find this bit in the svd file either, but I found it in the RM of f002a. I'll add it in and wait for someone test if it works.

• SPI_CR2 bit 12 FRXTH is missing. The RM does not mention it at all. However that bit seems to be used in Spi::into_8bit_width and in turn the constructor :/ What do we do here? I have not looked into it enough to understand if/why it is needed.

The FRXTH bit controls the FIFO receive threshold, it not in the f002b's svd file either, maybe they removed this bit or just let us use the default value 0. And into_8bit_width sets FRXTH and DS bit, selects the bit width of the spi communication. You can remove the FRXTH bit operation in this function, just use the DS bit.

• Is it possible to rename pu32f002b's TIM14 CCR1 ccr bits in the pac to be consistent with the other devices?(the other devices bit field is called ccr1)

  error[E0599]: no method named `ccr` found for mutable reference `&mut py32f0::py32f002b::tim14::ccr1::W` in the current scope
   --> src/pwm.rs:776:63
    |
  776 |                     unsafe { (*$TIMX::ptr()).ccr1.write(|w| w.ccr().bits(duty.into())) }
    |                                                               ^^^ help: there is a method with a similar name: `ccr1`
  ...
  874 | pwm_1_channel!(TIM14: (tim14, tim14en, tim14rst, apbenr2, apbrstr2),);
    | --------------------------------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `pwm_1_channel` (in Nightly builds, run with -Z macro-backtrace for more info)

Oh I forgot to change it, I'll fix it later

[usbalbin]

Thanks!

I just noticed that on page 280 of the RM FRXTH is mentioned however it is split between two lines like:

FRX
TH

as being part of SPI_CR2. Still feels a bit strange

[creatoy]

Yeah, it's strange. And I try to find the FRXTH or FRX_TH bit define in PY32F002B official ll/hal driver, there is nothing find. Maybe it is not exists or useless.