Electronics > Microcontrollers


<< < (41/44) > >>

Now, Patrick just posted the 1-wire protocol of debug:

I hope that this protocol be the same for ch32v307 and familly but addapting the transport to 2-wire interface (Man I need a weekend free to put a logic analyzer over CK and DIO lines on my ch32v307 board)

A tiny $1.50 WCH dev board from Muse labs, the nanoCH32V003. See https://linuxgizmos.com/the-nanoch32v003-is-a-risc-v-dev-board-available-for-1-50/


--- Quote from: westfw on February 03, 2023, 05:51:25 am ---I think it's fascinating that Chinese vendors seem to have started targeting American "hobbyists" - cheap development boards, free development environments, documentation in English (even if it's not very good documentation), chips for sale in retail quantities, etc...   I'm guessing it's due to the success of Espressif.  But it's certainly fun times!
--- End quote ---
I think of myself as more of a “frugal independent developer” than “hobbyist.”

I retired after a 20+ year full-time hardware/software design engineer position (at one company!). These days I still have plenty of projects but a much more limited budget compared to when my employer was willing to purchase (most) of the development supplies I requested.

I continue to support Arduino.cc, Raspberry Pi, adafruit, Sparkfun, and Teensy by frequently purchasing items directly from them. Without them we wouldn’t have either the hardware or the tools to make cost-effective embedded systems.

But I also find it irresistible to sample the enormous smorgasboard of Chinese clones, modules, boards, and tools. It costs almost nothing to try them out. Some items are junk. Others are quite well made and stable over time.

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? ;D

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? :-DD

so, the ATTiny8 is done for, right? end of an era  :-\


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod