ChibiOS Free Embedded RTOS

It is in ChibiOS/os/hal/lib/streams/chprintf.h. Here is the diff that fixes it for me: diff --git a/os/hal/lib/streams/chprintf.h b/os/hal/lib/streams/chprintf.h index e1e19b1c8..e45f157d0 100644 --- a/os/hal/lib/streams/chprintf.h +++ b/os/hal/lib/streams/chprintf.h @@ -27,6 +27,8 @@ #include <stda...

Hello! I use clang-format for automatically sorting include files by scope and name, and this leads to compilation problems with some headers. One such example is #include "chprintf.h" #include "hal.h" Since chprintf.h depends on type declarations from hal.h, this does not compil...

Just for reference, the repository location has changed: https://github.com/blus-audio/firmware

Hello! It seems to be very hard to find working code for a UAC 1.0 compliant sound card, so I built my own with various sources of inspiration. Here it is: https://github.com/elagil/usb-i2s-bridge The firmware is targeted at the STM32F401RB, but can be ported easily to more capable devices. This use...

I would probably check that no single OUT endpoint's maximum packet size is larger than the RX FIFO. Otherwise, not much can be done. There is no control over how many of which type of packet the host sends, so the RX FIFO should simply accomodate one of the largest packet that can occur. I suggest ...

I think I see the problem. On initializing an endpoint, only the allocation of memory for the TX FIFO is checked (hal_usb_lld.c:1023, marked with >>> below). For the RX FIFO that check does not exist. OTG_FS_GRXFSIZ is just set to the specified size of the RX FIFO, but there is no checking. If you l...

Where do I find that assertion? It is not in the function that I call for receiving on an OUT endpoint: void usbStartReceiveI(USBDriver *usbp, usbep_t ep, uint8_t *buf, size_t n) { USBOutEndpointState *osp; osalDbgCheckClassI(); osalDbgCheck((usbp != NULL) && (ep <= (usbep_t)USB_MAX_ENDPOINT...

Ok, I tried to increase STM32_USB_OTG1_RX_FIFO_SIZE to 1024 (from the default 512). Now, the maximum setting I can use is 948 bytes - which is exactly 512 bytes higher than before. So, the issue is definitely the RX FIFO running out. I wonder how this could be made obvious by means of some error cod...

Actually, I made another discovery. When I waste some time in the receive callback (just copy some values around, for example), then I begin to get zero packets, even at maximum packet size below of 436! So maybe it is a problem with processing time that is spent somewhere. Is that a possibility? Ed...

Yes, assertions are already enabled via CH_DBG_ENABLE_ASSERTS, but they don't fire.