"overloaded" registers

[japaric]

File: STM32F30x.svd
Peripheral: TIM2

The SVD file specifies that two registers exist at offset 0x1C: CCMR2_Input and CCMR2_Output. The thing is that this register can be used differently depending on whether the TIM2 peripheral is configured in Output Compare Mode or in Input Compare Mode. By differently, I mean that the bits of this register have different meaning depending on the compare mode.

I'm not sure how to model this. We could use a union here but that's not stable. For now, I think, I'm just going to pick one register and ignore the other but emit a warning.

[cwoodall]

One approach would be to make both registers available but disable any constraints that would make read or write access to the register safe.

[etrombly]

Having a similar issue with an STM32F103. The MODE register of a GPIO configures it for input or output, the CNF register handles the configuration (open-drain, push-pull, etc) but the settings are different depending on the mode.

edit: not entirely the same issue, this could be handled by commands having aliases, the register is still the same.

[silven]

I think I've run into this as well.

Trying to use the generated file from: https://github.com/nicholastmosher/lpc176x5x-rs/blob/master/src/uart.rs which has a register called "DLL", but because it overlaps with the "RBR" register at offset 0x0, it cannot be used at all.

The SVD file used (https://github.com/raw/posborne/cmsis-svd/aa4721af946a253d18c8737b01d23e9c88a42e84/data/NXP/LPC176x5x_v0.2.svd) annotates this with "alternateRegister".

So, "+1" I guess.

[protomors]

To @etrombly. I solved this problem by changing field definitions in SVD file. CNF and MODE bits for the same pin are adjacent so instead of separate 2-bit fields I declared them as one 4-bit field. And then created enum for them according to the "Table 20. Port bit configuration table" in the reference manual. So now I can select mode with single call like "output10pp" (Output, push-pull, max speed 10MHz) or "input_floating".

But there are cases where such solution is not possible. I think that in situation like example with timers it will be best to generate API for both registers (maybe just print a warning about it during generation). And then programmer can use appropriate API depending of the mode.

Just checked SVD file for stm32f103. Registers CCMR1_Input and CCMR1_Output even have attribute alternateRegister which exists exactly for such cases. So I think that in cases where registers explicitly marked as alternate variants using this attribute svd2rust can give access to both. And in other cases overlapping registers should be considered error in SVD file.

[pftbest]

SVD files I am generating for MSP430 are also affected by this issue, but since the overlapping registers are not in the same peripheral, the svd2rust does not complain about them.

[japaric]

@pftbest

but since the overlapping registers are not in the same peripheral,

Could you elaborate on this? How can they be overlapping if the registers are in different peripherals? What would be an example of this in the SVD file you linked?

[pftbest]

How can they be overlapping if the registers are in different peripherals?

On MSP430 the peripheral (module) is a logical group of registers, not physical group. Each register of a peripheral may be placed in some random location in memory. In practice almost all peripherals overlap with each other, but it's not a problem since they have a different combination of registers and reserved fields inside.

But there are some peripherals that do contain overlapping registers, for example
USCI_B0_SPI_Mode and USCI_B0_I2C_Mode

[idubrov]

Adding some context here (as I keep stumbling at ccmr1_input/ccmr1_output registers on STM32 F103 chip).

First, unions are in Rust 1.19: rust-lang/rust#42068

However, using them at this point would require breaking the API as anonymous unions are not supported (i.e, instead of tim1.ccmr1_output(...) / tim1.ccmr1_input.write(...) access pattern would be like tim1.ccmr1_output.ccmr1_output.write(...) / tim1.ccmr1_output.ccmr1_input.write(...) (first ccmr1_output is the name of the group). Anonymous unions are currently discussed here.

[rnestler]

I think this currently bites me as well with the LPC11Uxx:

<register>
	<name>RBR</name>
	<description>Receiver Buffer Register. Contains the next received character to be read. (DLAB=0)</description>
	<addressOffset>0x000</addressOffset>
	<access>read-only</access>
	<resetValue>0</resetValue>
	<resetMask>0x00000000</resetMask>
	<readAction>modify</readAction>
	<fields>
		<field>
			<name>RBR</name>
			<description>The USART Receiver Buffer Register contains the oldest received byte in the USART RX FIFO.</description>
			<bitRange>[7:0]</bitRange>
		</field>
		<field>
			<name>RESERVED</name>
			<description>Reserved</description>
			<bitRange>[31:8]</bitRange>
		</field>
	</fields>
</register>
<register>
	<name>THR</name>
	<description>Transmit Holding Register. The next character to be transmitted is written here. (DLAB=0)</description>
	<alternateRegister>RBR</alternateRegister>
	<addressOffset>0x000</addressOffset>
	<access>write-only</access>
	<resetValue>0</resetValue>
	<resetMask>0x00000000</resetMask>
	<readAction>modify</readAction>
	<fields>
		<field>
			<name>THR</name>
			<description>Writing to the USART Transmit Holding Register causes the data to be stored in the USART transmit FIFO. The byte will be sent when it is the oldest byte in the FIFO and the transmitter is available.</description>
			<bitRange>[7:0]</bitRange>
		</field>
		<field>
			<name>RESERVED</name>
			<description>Reserved</description>
			<bitRange>[31:8]</bitRange>
		</field>
	</fields>
</register>

The receive and transmit buffer register are mapped to the same address. Here it would be actually the best to just have both available.