cnlohr / ch32v003fun Goto Github PK

I notice that most of the examples ignore #defined values from the header file, in favour of simply using a number; example:

GPIOC->CFGLR &= ~(0xf<<(4*1));
instead of
GPIOC->CFGLR &= ~(0xf<<(4*GPIO_PinSource1));
where this already exists in the header:
ch32v003fun/ch32v003fun.h:3428:#define GPIO_PinSource1 ((uint8_t)0x01)

Or:
ADC1->SAMPTR2 |= 7<<(3*7); // 0:7 => 3/9/15/30/43/57/73/241 cycles
instead of
ADC1->SAMPTR2 |= ( ADC_SampleTime_241Cycles << (3 * ADC_Channel_7 ) ); // 0:7 => 3/9/15/30/43/57/73/241 cycles

My asks:
I feel like using the macros makes for more easily understood code, and that (for the purposes of 'canonical' examples), this is a desirable thing. Does anyone else feel like this is a useful thing? and if so:

1. I propose the creation of a 'style guide' for examples and contributions, stressing the use (where possible) of macros instead of digits
2. I'm not much of a coder, but I can start grooming the existing examples when I have time and motivation, and opening up PRs. Would this be acceptable?

https://github.com/cnlohr/ch32v003fun/wiki/Installation states under MacOS You can use the pre-compiled minichlink or go to minichlink dir and make it.

But there is no prebuilt executable for MacOS in the repo. Should there be one? It's kinda practical to have ready-made executables, but I guess most people will create them without any issues.

Good luck in decoding One Wire. They've announced they'd be publishing it just after the CNY ended, so let's see how that goes.

Once you figure out the encoding, I wonder if it bears any resemblance to the Official RISC-V debug protocol.
https://riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf

Clock recovery and serialization are, of course, tough nuts to crack, but it'd be nice if somme part of it matched the official specs. Their changes in OpenOCD indicated that it might resemelbe the RISC-V 0.1.3 debug spec, IIRC.

Good luck!

(and please just close this if you don't dig conversations in your issue tracker)

The readme says Optional (not needed, can be configured as output if fuse set): NRST is on PD7.
To avoid unnecessary confusion and datasheet reading It might be good to mention that PD7 by default is a GPIO.

The link for the Prep wiki page is broken (text and url are exchanged):

[https://github.com/cnlohr/ch32v003fun/wiki/Installation](wiki page here)

should be

[wiki page here](https://github.com/cnlohr/ch32v003fun/wiki/Installation)

Hi Cnlohr,

At first - many thanks for your effort and for all contributors! It's very useful project and I'm very happy using it! I hope it will be available for CH32V103 too :-)

I tried to use an example I2C_OLED with partially success... OLED working as expected but serial output doesn't work - no one message appeared on serial console. To confirm that any connection and configuration is ok, I used other example: UARTDEMO where everything works fine and each message are visible on my console:

I compared both examples and I can't find any difference between into serial initialization, so I suppose the issue coming somewhere else in rest of code. Could you please advise where I shall to look?

Best Regards,
pancio

Right now, -u sometimes will not properly erase and then boot into the application which will cause the application to boot-back-up after an unbrick operation. -a will also halt the processor, so, unbricking with -a will actually put the processor in a totally safe-to-program state.

I am trying to run 3 PWM on TIM1 (to control a common anode RGB LED), but i am confused by something :
There is 4 OC channel, so normally we can run up to 4GPIOs on TIM1, however in the driver there is also only two channels here :

Currently only the blue channel works (T1CH1) both the green and red stay off, probably floating otherwise the LED would be full ON (it is a common anode).

In my case i try to run these ports :

//R : PA2 T1CH2N 
//G : PC6 T1CH3N
//B : PD2 T1CH1

and that is how i started to modify the init:

void t1pwm_init(void){

    //R PA2 T1CH2N
    //G PC6 T1CH3N
    //B PD2 T1CH1

	// Enable GPIOA, GPIOC, GPIOD and TIM1
	RCC->APB2PCENR |= RCC_APB2Periph_GPIOA |
					  RCC_APB2Periph_GPIOD |
					  RCC_APB2Periph_GPIOC |
					  RCC_APB2Periph_TIM1;

	// PD0 is T1CH1N, 50MHz Output PP CNF = 10: Mux PP, MODE = 11: Out 50MHz
	//GPIOD->CFGLR &= ~(GPIO_CFGLR_MODE0 | GPIO_CFGLR_CNF0);
	//GPIOD->CFGLR |= GPIO_CFGLR_CNF0_1 | GPIO_CFGLR_MODE0_0 | GPIO_CFGLR_MODE0_1;

	// PC4 is T1CH4, 50MHz Output PP CNF = 10: Mux PP, MODE = 11: Out 50MHz
	//GPIOC->CFGLR &= ~(GPIO_CFGLR_MODE4 | GPIO_CFGLR_CNF4);
	//GPIOC->CFGLR |= GPIO_CFGLR_CNF4_1 | GPIO_CFGLR_MODE4_0 | GPIO_CFGLR_MODE4_1;



	// PD2 is T1CH1, 50MHz Output PP CNF = 10: Mux PP, MODE = 11: Out 50MHz
	GPIOD->CFGLR &= ~(GPIO_CFGLR_MODE2 | GPIO_CFGLR_CNF2);
	GPIOD->CFGLR |= GPIO_CFGLR_CNF2_1 | GPIO_CFGLR_MODE2_0 | GPIO_CFGLR_MODE2_1;

	// PA2 is T1CH2N, 50MHz Output PP CNF = 10: Mux PP, MODE = 11: Out 50MHz
	GPIOA->CFGLR &= ~(GPIO_CFGLR_MODE2 | GPIO_CFGLR_CNF2);
	GPIOA->CFGLR |= GPIO_CFGLR_CNF2_1 | GPIO_CFGLR_MODE2_0 | GPIO_CFGLR_MODE2_1;

	// PC6 is T1CH3N, 50MHz Output PP CNF = 10: Mux PP, MODE = 11: Out 50MHz
	GPIOC->CFGLR &= ~(GPIO_CFGLR_MODE6 | GPIO_CFGLR_CNF6);
	GPIOC->CFGLR |= GPIO_CFGLR_CNF6_1 | GPIO_CFGLR_MODE6_0 | GPIO_CFGLR_MODE6_1;



	// Reset TIM1 to init all regs
	RCC->APB2PRSTR |= RCC_APB2Periph_TIM1;
	RCC->APB2PRSTR &= ~RCC_APB2Periph_TIM1;

	// CTLR1: default is up, events generated, edge align
	// SMCFGR: default clk input is CK_INT

	// Prescaler
	TIM1->PSC = 0x0000;

	// Auto Reload - sets period
	TIM1->ATRLR = 255;

	// Reload immediately
	TIM1->SWEVGR |= TIM_UG;

	// Enable CH1N output, positive pol
	//TIM1->CCER |= TIM_CC1NE | TIM_CC1NP;

	// Enable CH4 output, positive pol
	//TIM1->CCER |= TIM_CC4E | TIM_CC4P;


	// Enable CH1 output, positive pol
	TIM1->CCER |= TIM_CC1E | TIM_CC1P;

	// Enable CH2N output, positive pol
	TIM1->CCER |= TIM_CC2NE | TIM_CC2NP;

	// Enable CH3N output, positive pol
	TIM1->CCER |= TIM_CC3NE | TIM_CC3NP;


	// CH1 Mode is output, PWM1 (CC1S = 00, OC1M = 110)
	TIM1->CHCTLR1 |= TIM_OC1M_2 | TIM_OC1M_1;

	// CH2 Mode is output, PWM1 (CC1S = 00, OC1M = 110)
	TIM1->CHCTLR2 |= TIM_OC4M_2 | TIM_OC4M_1;


	// Set the Capture Compare Register value to 50% initially
	TIM1->CH1CVR = 128;
	TIM1->CH2CVR = 128;
	TIM1->CH3CVR = 128;
	TIM1->CH4CVR = 128;

	// Enable TIM1 outputs
	TIM1->BDTR |= TIM_MOE;

	// Enable TIM1
	TIM1->CTLR1 |= TIM_CEN;

	u32 count=0;

	while(1)
	{
		t1pwm_setpw(0, count); // Ch 1
		t1pwm_setpw(1, (count + 64)&255);	// Ch 2
		t1pwm_setpw(2, (count + 128)&255);	// Ch 3
		count++;
		count &= 255;
		Delay_Ms(5);
	}
}

Hi Charles,

thank you for working on the ch32v003fun SDK! It's very exciting to be able to use CH32V003 without any proprietary software (if combined with aappleby/PicoRVD).

Would it be possible to provide a link to the sources for the included libgcc.a and the way you built it? I appreciate the included binary as it's very convenient to have everything in place, but I would also like to know how to update this libgcc.a, when necessary.

I got some error message at try to program ch32v003's 8-pin package. It works on fresh chip but crashes when i try to upload new code.

Found ESP32S2 Programmer
Error: Setup chip failed. Got code ffffffff
Could not setup interface.

I also tried minichlink -u mode.

Found ESP32S2 Programmer
Entering Unbrick Mode
Connection starting
/0/ffffffff
/0/ffffffff
...
lots of ffffffff
...
ioctl (GFEATURE): Connection timed out
Error: Got error -1 when sending hid feature report.
Error: Flash is not unlocked (CTLR = ffeffdff)

Unfortunately, due to a breaking change in RISC-V ISA 20191213 (https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4)

... the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the I extension, become two standalone extensions: Zicsr and Zifencei;...

gcc 12.x now requires -march=rv32ec_zicsr in order to compile csrr* instructions. Although it is an easy fix when supporting just the latest gcc 12.x risc-v toolchains, the question is how to do it while keeping backward compatibility with older gcc toolchains? E.g. a conditional parameter assignment in makefile based on gcc version?

As introduced in exti example. Be it function call, register pressure or pure size optimization.

see:
https://www.eevblog.com/forum/microcontrollers/bizarre-problem-on-ch32v003-with-systick-isr-corrupting-uart-tx-data
https://www.reddit.com/r/RISCV/comments/126262j/notes_on_wch_fast_interrupts/

HI,

There is very good reason to use CH32V003 as successor for ATMEGA family, so it will be very helpfully to have method to read, write and modify on whole port e.g.:
GPIOD_OUTDR = 0b10111111; all bits set as PULL-UP input in PD
GPIOA_BSHR = 0b10111111; reset all bits in PA
GPIOC_BSHS = 0b10110000; set four MSB bits in PC

I know that it's possible using defined bu user structure but above is more easier...

Wondering what device you are using for this?

I bought one of these recently https://www.ebay.com.au/itm/304645792686

It has the more powerful CH32V307VCT6

Reproduction:

1. make in examples/blink (flashes successfully)
2. riscv-none-embed-gdb -ex "target remote :2000" blink.elf
3. b main
4. continue
5. step

Output:

riscv-none-embed-gdb -ex "target remote :2000" blink.elf
GNU gdb (xPack GNU RISC-V Embedded GCC, 64-bit) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=riscv-none-embed".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/sifive/freedom-tools/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from blink.elf...
Remote debugging using :2000
InterruptVectorDefault () at ../../ch32v003fun/ch32v003fun.c:968
968		return 1;
(gdb) b main
Breakpoint 1 at 0xa0: file ../../ch32v003fun/ch32v003fun.c, line 831.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at ../../ch32v003fun/ch32v003fun.c:831
831		RCC->CFGR0 = RCC_HPRE_DIV1 | RCC_PLLSRC_HSI_Mul2;      // PLLCLK = HSI * 2 = 48 MHz; HCLK = SYSCLK = APB1
(gdb) step

The last command hangs eternally. minichlink output shows no sign of errors.

$ ./minichlink -G
Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : ab-c8-ab-cd-13-de-bc-49
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup
GDBServer Running

Logs with set debug remote 1:

(gdb) step 
Sending packet: $m80,40#65...Ack
Packet received: 920100009401000096010000980100009a0100009c0100009e010000000000000290000000000000000000000000000000000000000000000000000000000000
Sending packet: $Z1,a0,2#a6...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: OK

It seems to wait for more packets after the last one? Maybe some "event" packet or the state of the registers or something?

The installation instructions are ambiguous. It would be helpful if the paths and folder references were explicit, rather than vague. They could even include links to the correct references. As they exist, they assume many things that are not evident

$ riscv-none-embed-gdb -ex "target remote :2000" blink.elf
..
(gdb) set debug remote 1
(gdb) load
Sending packet: $vFlashErase:00000000,00000200#bc...Ack
Packet received: 
Remote target does not support flash erase

That should be easy to implement especially since the tool can flash already..

Hello,

It seems the wch_link_command payload in LEControl3v3() function to disable 3v3 output is not correct (most likely copy-paste error) https://github.com/cnlohr/ch32v003fun/blob/master/minichlink/pgm-wch-linke.c#L180 - according to the actual data sent by WCH-LinkUtility it should be "\x81\x0d\x01\x0a" (reply 82 0d 01 0a).

I can submit PR if needed...

Sorry for the next chaotic bug report.

I have a written a simple demo that loads the shift register with latch (74HC595) over the SPI.
The crazy thing is that the SPI works, but with double speed, so SCK has 25 MHz instead of 10 MHz.
MOSI is showing a correspondent data output.
But the shifted data could not be latched, because the GPIO pin access does not work!

So I did go back to your GPIO example and there is no Port activity.
To be sure that it is not my breakout board I use the original WCH board now.
Again no port activity.

Here is the compiler output:

$ make
riscv64-unknown-elf-gcc -o GPIO.elf ../../ch32v003fun/ch32v003fun.c GPIO.c wiring.c -DTINYVECTOR -g -Os -flto -ffunction-sections -static-libgcc -march=rv32ec -mabi=ilp32e -I/usr/include/newlib -I../../ch32v003fun/../extralibs -I../../ch32v003fun -nostdlib -I. -Wall -T ../../ch32v003fun/ch32v003fun.ld -Wl,--gc-sections -L../../ch32v003fun/../misc -lgcc
riscv64-unknown-elf-size GPIO.elf
   text    data     bss     dec     hex filename
    672       0       4     676     2a4 GPIO.elf
riscv64-unknown-elf-objdump -S GPIO.elf > GPIO.lst
riscv64-unknown-elf-objdump -t GPIO.elf > GPIO.map
riscv64-unknown-elf-objcopy -O binary GPIO.elf GPIO.bin
riscv64-unknown-elf-objcopy -O ihex GPIO.elf GPIO.hex
make -C ../../minichlink all
make[1]: Verzeichnis „/win/WCH/ch32v003fun/minichlink“ wird betreten
make[1]: Für das Ziel „all“ ist nichts zu tun.
make[1]: Verzeichnis „/win/WCH/ch32v003fun/minichlink“ wird verlassen
../../minichlink/minichlink -w GPIO.bin flash -b
Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : 39-ca-ab-cd-a1-d8-bc-41
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup
Image written.

The gcc is

$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-elf/8.3.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --target=riscv64-unknown-elf --prefix=/usr --infodir=/usr/share/doc/gcc-riscv64-unknown-elf/info --mandir=/usr/share/man --htmldir=/usr/share/doc/gcc-riscv64-unknown-elf/html --pdfdir=/usr/share/doc/gcc-riscv64-unknown-elf/pdf --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --with-pkgversion= --disable-shared --disable-threads --enable-languages=c,c++ --enable-tls --with-newlib --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --with-system-zlib --enable-checking=yes --enable-multilib --with-abi=lp64d --disable-libstdcxx-pch --disable-libstdcxx --disable-fixinc --with-arch=rv64imafdc --with-gnu-as --with-gnu-ld --with-as=/usr/lib/riscv64-unknown-elf/bin/as --with-ld=/usr/lib/riscv64-unknown-elf/bin/ld AR_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ar AS_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/as NM_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/nm LD_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ld OBJDUMP_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/objdump RANLIB_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ranlib READELF_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/readelf STRIP_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/strip CFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' LDFLAGS='-Wl,-z,relro -Wl,-z,now' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3RxXtW/gcc-riscv64-unknown-elf-8.3.0.2019.08+dfsg=. -fstack-protector-strong' 'CFLAGS_FOR_TARGET=-Os -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os -mcmodel=medany'
Thread model: single
gcc version 8.3.0 () 

Installed as package gcc-riscv64-unknown-elf 8.3.0.2019.08+dfsg-1 in Debian GNU/Linux 11 (bullseye).

The blink program compiled in the Moun River Studio works.
So what is going on?

While the minichlink binary has various ways of reseting / resuming from halt, these do not seem to be exposed to GDB at all. Specifically, OpenOCD supports monitor reset, monitor halt, et cetera. minichlink doesn't support that.

(gdb) monitor reset
Sending packet: $qRcmd,7265736574#37...Ack
Packet received: 
Target does not support this command.

Hello, I was able to fully compile minichlink in my computer.

I also copied minichlink/99-WCH-LinkE.rules to /etc/udev/rules.d/ with root priviledges.

But when I try to dump my ch32v003 flash memory, I get:

$ ./minichlink -r 0x08000000 16384 flash.bin
Found WCH LinkE
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : 70-56-ab-cd-d8-6b-bc-48
PFlags       : ff-ff-ff-ff
Part Type (B): 00-31-05-00
Interface Setup
Error: memory value request out of range

Hi,
I'd like to report a bug that I've got no idea how to solve.
I am using two OSes: Manjaro and Kubuntu 22.10
About a week ago I was using Kubuntu to upload using the WCH-Link E.
Then I spent a week tryping to wrap my head around SPI, now "sudo make" builds an .elf but doesn't upload. I'm using the latest "unified makefile".
With blink I get elf and bin but no upload.
On manjaro I can remember make always calling minichlink to upload.
On Kubuntu everything just worked, no issues, and I haven't run updates since.
Strange thing is: when I manually call minichlink with the right bin, it gets flashed like it used to.
But sudo make just successfully builds, no errors, no "programmer-not-found".
Seems like it just doesn't call minchlink and in some examples doesn't generate a .bin file, just the elf.
Maybe it's fine for yall on Windows?
After restoring blink to the "old" style of makefile
d71a050
that one just works again!
I even did a fresh wipe and clone from master an hour ago!

@bmx ran into an issue with this - trying to use it on CH32V307 boards.

I did not know it even could run on a 307. I don't mind trying to support this some moving forwards, but I think I need a way to identify if it's a 307 or a 003? Do you know much about this? Are the debug protocols similar?

6f896b6

Side-note: If we can discuss this on the Discord for this project that would be helpful.

Thank you for this nice project, that gives a much more direct hardware access to the MCU as the MounRiver Studio and works fine in Linux.

At this moment I am trying to test a little breakout board I have made for the use of this interesting MCU.
https://www.mikrocontroller.net/topic/548353#7427694
Without the knowledge of your project details I have choosen to implement the same interesting IC's like WS2811 and PT8211. :-)

For the first test I tried to use the DAC, but I used an TDA1387 instead of an PT8211 and get an curious output on the sine channel. The pin WS is of course connected to PC4 and not to PC3 as suggested in the diagram (jumper bridge).

The other channel works as expected.

I am not familiar with the use of an DMA and your example uses the hardware on a high level.
You already commented your code a much, but at this time I have no idea why this output happens?

TIM1CH4 generates the signal for WS and interrupts to fill the buffer for the DMA.
But how this works in detail?
The DAC buffer is filled in a mystery way and the output is only strange for one channel.

Is it possible to output a wave directly from the flash with the DMA?

Has someone tips for a low skilled programmer to learn?

I thought that this project was mostly about moving away from a (the official) HAL and go more towards a direct to the metal approach, so the discussions about GPIO abstractions and functions for easier access to them makes me a bit confused since it feels very Arduino'esqe.

Is this project going slowly towards an Arduino-styled HAL or will it stay metal with just small demo/example codes for doing common tasks?

Have you looked at a two stage boot loader process which would open this device up to the class of people who won't use a WCHLink? Companies making hobbyist devices would flash in the first stage during production. That first stage would then allow the hobbyist to update the flash using the UART, eliminating the need for the WCHLink. I don't know how feasible this is given the tiny amount of flash/ram.

EDIT: Following conversation, implementations and code samples are only for educational purposes.

I want to emulate a onewire device with using cheap ch32v003. I found some examples developed for other architectures like AVRs or PICs.

https://github.com/cogsy23/aowslave
https://github.com/MarkusLange/OneWireSlave
https://github.com/lamlamngo/onewire-slave-emulator

All of them are interrupt driven, I tried to write my code with ch32v003fun. But interrupt example is not very clear. For example, i need falling and rising (change) interrupts for PC1. Also i need cli and sei commands on AVRs.

#define cli() (NVIC_DisableIRQ( EXTI7_0_IRQn ))
#define sei() (NVIC_EnableIRQ( EXTI7_0_IRQn ))

Is that ok or not? How can i use it properly?

I think I followed the instructions correctly but got...

make -C ../../minichlink all
make[1]: Entering directory '/home/Mike/Risk5/ch32v003fun/minichlink'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/Mike/Risk5/ch32v003fun/minichlink'
../../minichlink/minichlink -w blink.bin flash -b
Found WCH Link
WCH Programmer is CH549 version 2.7
link error, nothing connected to linker
Could not setup interface.
make: *** [../../ch32v003fun/ch32v003fun.mk:53: cv_flash] Error 223
Mike@mx:~/Risk5/ch32v003fun/examples/blink

Issue solved... I had two programmers plugged in ... oops sorry...

• Ability to program option bytes reliably.
• GDB support.

Hi, you could consider using whole or parts of my more optimized startup code available here.

There are also other size optimizations like gp covering whole sram, .rodata before .text for 0 offset addressing or .srodata before .rodata (usually I see that the embedded toolchains are preconfigured to disable small data to conserve sram space)

while(1) is 202 bytes (188 without static initializers)

with 1KiB bootloader it should grow by 4 bytes, above it's more complicated

By erasing whole flash

Per #118 (comment).

I tried to use the <stdlib.h> for simple functions like itoa, utoa, but this does not work.
(I am able to find every silly problem ;-)

Let us take this shortened example:

// Could be defined here, or in the processor defines.
#define SYSTEM_CORE_CLOCK 48000000
#define APB_CLOCK SYSTEM_CORE_CLOCK

#include "ch32v003fun.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

uint32_t count = 42;
char lpuffer[17] ;		//< string buffer for LCD-line
ultoa(count, lpuffer, 10);

int main() {
	while(1) {}
}

This leads to an undefined reference to `ultoa'

$ make build
riscv64-unknown-elf-gcc -o spi_lcd.elf ../../ch32v003fun/ch32v003fun.c spi_lcd.c -g -Os -flto -ffunction-sections -static-libgcc -march=rv32ec -mabi=ilp32e -I/usr/include/newlib -I../../ch32v003fun/../extralibs -I../../ch32v003fun -nostdlib -I. -Wall -T ../../ch32v003fun/ch32v003fun.ld -Wl,--gc-sections -L../../ch32v003fun/../misc -lgcc
spi_lcd.c: In function 'main':
spi_lcd.c:34:3: warning: implicit declaration of function 'ultoa'; did you mean 'utoa'? [-Wimplicit-function-declaration]
   ultoa(count, lpuffer, 10);
   ^~~~~
   utoa
/usr/lib/riscv64-unknown-elf/bin/ld: /tmp/ccN4ShTe.ltrans0.ltrans.o: in function `.L0 ':
/win/WCH/K/examples/spi_lcd/lcd.c:110: undefined reference to `ultoa'
collect2: error: ld returned 1 exit status
make: *** [../../ch32v003fun/ch32v003fun.mk:24: spi_lcd.elf] Fehler 1

or with utoa

$ make build
riscv64-unknown-elf-gcc -o spi_lcd.elf ../../ch32v003fun/ch32v003fun.c spi_lcd.c -g -Os -flto -ffunction-sections -static-libgcc -march=rv32ec -mabi=ilp32e -I/usr/include/newlib -I../../ch32v003fun/../extralibs -I../../ch32v003fun -nostdlib -I. -Wall -T ../../ch32v003fun/ch32v003fun.ld -Wl,--gc-sections -L../../ch32v003fun/../misc -lgcc
/usr/lib/riscv64-unknown-elf/bin/ld: /tmp/ccUvYmUs.ltrans0.ltrans.o: in function `.L0 ':
/win/WCH/K/examples/spi_lcd/lcd.c:110: undefined reference to `utoa'
collect2: error: ld returned 1 exit status
make: *** [../../ch32v003fun/ch32v003fun.mk:24: spi_lcd.elf] Fehler 1

What must be done?

I know you're probably busy working on the rv003usb project right now, but any chance you can create a "ch32v307fun.c" file based off the CH32V307_startup files that OpenWCH has here?

The eval boards have a lot more IO and even 100M ethernet. I followed your lead on adapting the header files provided by OpenWCH but have gotten hung up on some of the Assembly instructions that would be used by the linker. I can provide my work so far if that'd help put everything in context but your ch32v003fun repo is by far smoother than MounRiver Studio.

-wrcrooks

Compiler goes mimimi with -Wall on certain code files, this could lead to bugs if someone expects standard-compliant libc functions.

src\embedlibc.c: In function '__puts_uart':
src\embedlibc.c:18:1: warning: no return statement in function returning non-void [-Wreturn-type]
 }
 ^
In file included from src/ch32v00x.h:2396,
                 from src\startup_ch32v003.c:8:
src/ch32v00x_conf.h:1784:13: warning: 'DelaySysTick' defined but not used [-Wunused-function]
 static void DelaySysTick( uint32_t n )
             ^~~~~~~~~~~~
c:\users\max\.platformio\packages\toolchain-riscv\riscv-none-embed\include\string.h: In function 'memset':
src\embedlibc.c:108:1: warning: control reaches end of non-void function [-Wreturn-type]
 void *memset(void *dest, int c, size_t n) { unsigned char *s = dest; for (; n; n--, s++) *s = c; }
 ^~~~
c:\users\max\.platformio\packages\toolchain-riscv\riscv-none-embed\include\string.h: In function 'strcpy':
src\embedlibc.c:109:1: warning: control reaches end of non-void function [-Wreturn-type]
 char *strcpy(char *d, const char *s) { for (; (*d=*s); s++, d++); }
 ^~~~
c:\users\max\.platformio\packages\toolchain-riscv\riscv-none-embed\include\string.h: In function 'strncpy':
src\embedlibc.c:110:1: warning: control reaches end of non-void function [-Wreturn-type]
 char *strncpy(char *d, const char *s, size_t n) { for (; n && (*d=*s); n--, s++, d++); }
 ^~~~

Some pins on the 8-pin package have multiple functions, as well as multiple assignments.

Port D4 and port D5 are both listed as available on pin 8, for example, as well as having default and remapped functions available for each. I would find it helpful to have an example showing how to select between GPIOs on that pin, as well as between the alternate functions. (e.g. an example implementation of the content discussed in chapter 7 of the RM http://www.wch-ic.com/downloads/file/358.html )

examples/uartdemo is currently TX only, the ch32v003fun.c code also initializes the UART in TX only mode.

It would be nice to add support for UART RX and interfacing it with standard I/O functions, so probably getc() / getchar() / fgets().

See some example code at #151 (comment), this uses its own user-made function instead of stdio functions.

When looking for a way to reset the ch32v003 through minichlink using Link-E, I've noticed, that:
-t should disable it (poweroff) so I can later bring it back with -3

• power-off as expected
• gets stuck at Found WCH Link for a couple of seconds
• then errors out with Error sending WCH command (on recv): 81 0d 01 ff
• power is returned automatically (wanted too do that manually in the next step)

-a runs fine but doesn't halt execution (blink still continues), which I'd then want to reset with -b

Am I using both wrong?
Ideally, I'd like to have PD7 available for other stuff.

Some related suggestions:

• What do you think of the idea of having reset in the makefile so it's accessible from anywhere?
• Maybe add an option that resets it but places it in a state expecting a flash, but without the erase-program cycle of -u? With the standby examples, I've often had to use -u to flash anything because it would be awake for such a short time it wouldn't communicate at all.