Memory map comparison

Memory map comparison

Memory map comparison

Could you add the GT field to GTPR as well?

Hi @adamgreig , thanks for the review. I had deliberately left the GT field out because:

As far as I could see the Guard Time bits are only used in SmartCard mode² ³, and it looks like the SmartCard mode is only present on USART peripherals¹.

The prescaler (PSC) bits are used for both IrDA (on UART and USART peripherals) and also for SmartCards (USARTs only), so I only put the PSC bits in the PR (the PR only applies to UART peripherals, and not to USART peripherals).

I don't really know anything about Smartcard communication, but I suppose it's conceivable that SmartCards can actually be used with UARTs (contrary to what the datasheet says)¹.

So.... I don't know whether it's best to leave out the GT field, or put it in. I think it's probably either not present, or maybe present but not actually usable for anything, BICBW.

Happy to go with whatever you think is best.

References:

RM0430 (STM32F412/423 reference manual, rev 8, 23-May-2018):

1. Table 157 "UART features" p.885
2. "28.4.11 Smartcard" p.915
3. "28.6.7 Guard time and prescaler register (USART_GTPR)" p.933

Ah, thanks, I missed that it wasn't present on the UARTs. Some of the RMs confirm this explicitly with a note that GT is not available on the UART fields. However, we don't distinguish the UARTs and USARTs for stm32f4; they all derive from the same USART register block, so I think we should add GT here so that it's usable for USARTs and just won't do anything for UARTs, same as the other smartcard mode features.

Hi @adamgreig I had a bit of a dig around in the crates :-).

we don't distinguish the UARTs and USARTs for stm32f4; they all derive from the same USART register block

Unless I'm misunderstanding you, I don't think this is the case - the UARTs seem to be defined separately from the USARTs in the SVDs, and are a subset of them (well... 401, 407 and 469 all define UARTs distinctly, with the USART-specific fields not present, but the 413 SVD just re-uses the USART definition for the UART - so this PR corrects that too, and makes 413 consistent with the others).

So, other USART-only fields are not present in the UART definitions exported by the stm32f4 crate at the moment. e.g. on all of the UART peripherals, several fields are missing e.g. for CR3 (whereas the PAC does have these fields on USART definitions):

FIELD 04w01 NACK: Smartcard NACK enable
FIELD 05w01 SCEN: Smartcard mode enable

FIELD 08w01 RTSE: RTS enable
FIELD 09w01 CTSE: CTS enable
FIELD 10w01 CTSIE: CTS interrupt enable

See: https://docs.rs/stm32f4/latest/stm32f4/stm32f469/usart1/cr3/index.html vs
https://docs.rs/stm32f4/latest/stm32f4/stm32f469/uart4/cr3/index.html

i.e. the UARTs are already (significantly) a subset of the USARTs in API presented by the stm32f4 PAC crate.

stm32f4xx_hal is able to treat USART and UART peripherals as equivalent at the moment, because no USART-specific functionality is used.

In the future, if stm32f4xx_hal implements USART-only functionality (e.g. smartcard, hardware flow control), then it would have to make that functionality available only on USARTs e.g. by using the sort of restriction proposed by burrbull in stm32-rs/stm32f4xx-hal#466 (comment) (... but for that particular PR, the missing UART field turned out to be an SVD error - hence this PR).

So because of this, I think it might be more correct to omit the GT field from this PR after all.

What do you think?

Build succeeded:

• CI

now even worse.
UART4 was changed (some enums like stopbits are missed), but UART5,7,8 still depends on USART1

@burrbull does this just need repeating for uart5,7,8 or are you seeing problems with uart4 now? Looking at the memory map changes triggered by CI: https://github.com/stm32-rs/stm32-rs-mmaps/compare/pr-713-b732293 - I can't see any signs of stopbits being omitted for uart4. I'm building locally now to check.

yes. uart5,7,8 should be derived from uart4.
Also you need to add missed rules for enumeratedValues (not showable by mmaps)

You can use stm32-rs/stm32f4xx-hal#481 as base.

For more detail peripheral compare (with enums) you could use https://github.com/burrbull/svd-yaml-compare

Well, this has turned out to be quite the rabbit hole

~/prog/rust/stm32-rs$ git diff --stat
 devices/stm32f413.yaml | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 devices/stm32f427.yaml |  4 ++++
 devices/stm32f429.yaml |  4 ++++
 devices/stm32f469.yaml |  3 +++
 4 files changed, 86 insertions(+), 2 deletions(-)

~/prog/rust/stm32f4xx-hal$ git diff --stat
 src/serial.rs | 25 ++++++++-----------------
 1 file changed, 8 insertions(+), 17 deletions(-)

I have to go now, but will try to get this finished up later on today.