ChibiOS Free Embedded RTOS

I tried to link boot_double_tap_check function from pico-sdk which allow us to enter bootloader by double push the reset button.
The function has __attribute__((constructor)) attribute, so it called before main function.
In the case of pico-sdk based program, runtime_init function is called before ...

Please add structure definition for PWM register.
diff --git a/os/common/ext/RP/RP2040/rp2040.h b/os/common/ext/RP/RP2040/rp2040.h
index 01c911d..7423d88 100644
--- a/os/common/ext/RP/RP2040/rp2040.h
+++ b/os/common/ext/RP/RP2040/rp2040.h
@@ -896,6 +896,67 @@ struct {
} CLR ...

Hi hanya, I've sent you a PR on github which fixes this and some other issues, please check it at m
Hi xyz, thanks for your PR. I have fixed some of them before I notice your PR. But I did not noticed about wrong setting of buffer offset.

I added shell example. After few fix, ChibiOS/RT Shell is ...

I have updated code a bit. Now USB state can be reached to configured state.
The lsusb command shows correct information about its descriptors.
HID test code seems working but there are some data error shown, maybe PID problem.
The shell through CDC does not start yet.

Thank you for your response. I will try to choose collect mode for set address.
And I found the following description about the SET_ADDRESS request in the pico-sdk.
From pico-sdk, dev_lowlevel.c
/**
* @brief Handles a SET_ADDR request from the host. The actual setting of the device address ...

I tried to write USB low level but it did not work well. The code is here: m
USB driver: m
Test code: m

It looks the device can respond to GET_DESCRIPTOR request. But the state does not proceed from SET_ADDRESS state.
The address received from the host is set to USB->DEVADDRCTRL register in usb_lld ...

Some base addresses are wrong defined in rp2040.h file.
#define __USB_BASE (__AHBPERIPH_BASE + 0x01100000U)
#define __PIO0_BASE (__AHBPERIPH_BASE + 0x02000000U)
#define __PIO1_BASE (__AHBPERIPH_BASE + 0x03000000U)

USB is 0x50110000, PIOs are 0x50200000 and 0x50300000. Another zero is added to ...