Don't you just love it when there are inconsistencies between what a manufacturer's documentation
says and what code in their HAL/SPL/etc actually
does?
There are a couple of such inconsistencies I've noticed in the CH32V003 Reference Manual (as of latest available, v1.3).
First is to do with the RCC clock configuration register CFGR0. According to the Reference Manual, bits 10:8 are "reserved" and bits 15:11 are for ADCPRE (ADC clock source divider). But wait! The
library headers give bits 10:8 as for PPRE1 (APB1 clock source divider), bits 13:11 as PPRE2 (APB2 clock source divider), and only bits 15:14 for ADCPRE.
Did they decide to throw out the ability to run APB1 and APB2 at speeds different than the main AHB clock in order to have a greater range of dividers for the ADC? It may be that the docs are correct, because the
separate header file for the RCC peripheral defines its own set of values for the ADC prescaler field that match the docs, and they forgot to update the main header file (it seems to be a pattern that peripheral-specific header files define their own register constants, in duplication of the main header). Who to believe?
The second instance is with the I2C peripheral. The manual documents that bits 14:10 of the OAR1 register are "reserved", but yet the
I2C_AcknowledgedAddress_7bit constant in the I2C header file has the value 0x4000, which has bit 14 set, and this constant is always written to the register by the
I2C_Init function.
So what is this bit? It rang a bell in my memory, that I had seen something like this before. Lo and behold, the I2C peripheral of the STM8 has in its OARH register an ADDCONF bit 14 which is documented as "
This bit must set by software (must always be written as '1')". Hmmmmm... Are WCH using the
exact same I2C peripheral? Everything else seems to also be highly similar to that of the ST chip. Did they buy the same third-party implementation? Or did they clone it so well, they included the flaws too?