#tinyusb

1 messages ยท Page 15 of 1

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Regarding the example, currently the loading of data is done within a callback function tud_audio_tx_done_pre_load_cb(), hence, within audio_task() there is not much left to do... I did not put samples into the buffer from the audio_task() because i thought it would be pretty unreliable to generate a sample frequency of 48 kHz using wait() functions. So i put everything at once within the callback. This is of course not the way to do it later when you have real samples but much ...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Regarding the example, currently the loading of data is done within a callback function tud_audio_tx_done_pre_load_cb(), hence, within audio_task() there is not much left to do... I did not put samples into the buffer from the audio_task() because i thought it would be pretty unreliable to generate a sample frequency of 48 kHz using wait() functions. So i put everything at once within the callback. This is of course not the way to do it later when you have real samples...

fallow birchBOT
fallow birchBOT
#
maxnet
[hathach/tinyusb] Issue opened: #718 tud\_network\_mac\_address should be initialized by hardware ID but is const

Is your feature request related to a problem? Please describe.

https://github.com/hathach/tinyusb/blob/master/examples/device/net_lwip_webserver/src/main.c#L61 mentions that ideally the MAC should be generated by hardware ID.
However the variable is declared const in https://github.com/hathach/tinyusb/blob/master/src/class/net/net_device.h#L62 and in https://github.com/hathach/tinyusb/blob/master/lib/networking/rndis_reports.c#L39

Describe the solution you'd like

Remove "co...

fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I see this MCU's USB IP is very different from the other ones, and that seems to be causing trouble. There's no way we can find if a SETUP request was sent using the IP , even a PID OUT raises the same interrupt as PID SETUP. Because of this the driver I implement, calls back to setup_received even when a PID OUT is received.

I see even in TI's USB stack for this MCU, they are checking if the control packet was a standard request in the driver itself. Shall I add a similar check?...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

If I remember correctly the maximum CFG_TUD_AUDIO_N_AS_INT is 3. I think it's possible to get n_bytes_per_sample[] from the defines.

For example if CFG_TUD_AUDIO_N_AS_INT = 2, CFG_TUD_AUDIO_N_BYTES_PER_SAMPLE_XX_AS_1 and CFG_TUD_AUDIO_N_BYTES_PER_SAMPLE_XX_AS_2 should be defined if support fifo are used.

Element size of fifo could be fixed to the greater one.

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

I just realized that there is a bit more to generalize, the driver should be able to support multiple audio functions. Yet, in C it is a bit difficult to allow such a flexibility e.g. if you have two audio functions, one has no EPs at all (just for controlling of attached audio equipment) and one for streaming with EPs and support FIFOs. (I don't know when such a setup would make sense but USB allows for it ^^). Right now, the first audio function would also setup support FIFOs without needin...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I see this MCU's USB IP is very different from the other ones, and that seems to be causing trouble. There's no way we can find if a SETUP request was sent using the IP , even a PID OUT is treated the same as PID SETUP by the IP. Because of this the driver I implement, calls back to setup_received even when a PID OUT is received.

I see even in TI's USB stack for this MCU, they are checking if the control packet was a standard request in the driver itself. Shall I add a simil...

#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

Sure @hathach , I'll try doing so, also, just wanted to ask one question related to the stack, is it possible that in any CONTROL transfer, the stack sends a data of more than 64 bytes? Because currently, while returning the Configuration descriptors, I see the device returns 98 bytes in a single transaction (which is more than max allowed) . Due to this the PC (host) treats it as an erroneous situation and the enumeration fails.

#
hathach
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

that stack can send 98 bytes without any issue, it will break it into 2 packets,

  • the 1st is 64 bytes then dcd xfer complete is called
  • usbd will schedule another 34 bytes, then dcd xfer complete is called
  • usbd will schedule another 0 bytes (on opposite zero endpoint) for ACK

here is the LOG=2 on other mcu.

USBD Setup Received 80 06 00 02 00 00 62 00
  Get Descriptor Configuration[0]
  Queue EP 80 with 64 bytes
USBD Xfer Complete on EP 80 with 64 bytes
  Queue EP 80 ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-build\-lpc177x8x
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

I am currently a bit puzzeled how to design the driver in such a way that it can be generalized conviniently for multiple audio functions. Especially the buffers are a bit tricky. Picture the following:

  • two audio driver functions i.e. CFG_TUD_AUDIO = 2
  • none uses support FIFOs to keep this easy
  • the first uses EP IN but needs an additional linear buffer because usbd_edpt_iso_xfer() is not available for the target MCU
  • the second does not use EP's at all but only controls audio eq...
fallow birchBOT
fallow birchBOT
#
khpeterson
[hathach/tinyusb] Pull request opened: #723 fix for nrf52840 epout dma race condition

Fix for https://github.com/adafruit/Adafruit_nRF52_Bootloader/issues/195.

Addresses race condition between writing SIZE.EPOUT=0 and xfer->data_received flag. Since NR52840 always auto ACKs after DMA completion the code should always wait for data_received to be sure the transfer is complete. This doesn't work when starting a sequence of transfers so timeout and write SIZE.EPOUT in this case. If one could differentiate the start/end of a packet sequence at this level of the code then the...

fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] Pull request opened: #724 USB TMC Updates

Describe the PR
Adds alignment to buffers in usbtmc_interface_state_t struct.
Updates the visaQuery.py script for PyVisa module import deprecation and to support Linux.

Additional context
It was found that the CFG_TUSB_MEM_ALIGN attributes were missing from the buffers in the usbtmc_interface_state_t struct. This caused exceptions due to alignment issues on the XCore platform. This addition is untested on other platforms.
Additionally the existing visaQuery.py script was hard...

tardy umbra
#

I am working on a project where we want to replace a computer (the Host) with an STM32 microcontroller. The device uses a standard FTDI USB to serial converter as the main mechanism to communicate between the computer and controller. Instead of using the computer, I want to use STM32F4 as a host to communicate with the device.

STM32 -> USB -> FTDI -> Machine controller

STM32 natively supports USB CDC communication but does not support communication with FTDI chips. On ST website there is an article about an ST partner who developed a commercial USB Stack that supports CDC-FTDI, but since the project is still in an experimental phase I am looking for other alternatives https://www.st.com/en/embedded-software/hcc-usb-stack.html

I would appreciate your expert opinion on this ๐Ÿ™ . Does tinyUSB lib or libopencm3 have support for communication with FTDI chips ?

#

<@&617066238840930324>

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #724 USB TMC Updates

the modificaiton of usbtmc_device.c looks OK to me. Though can you also add the CFG_TUSB_MEM_SECTION to the usbtmc_state as well at line 128

CFG_TUSB_MEM_SECTION static usbtmc_interface_state_t usbtmc_state =
{
    .itf_id = 0xFF,
};

For the visaQuery.py changes, I have no idea, @pigrew do you have time to help reviewing this.

#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

@PanRe there is no need to support multiple audio functions right with this PR. We can do it later on, Sometimes, a cool-down period is what is needed for a brilliant idea. I have switched back and forth between works. Although It takes a bit of time when revising an unresolved issue, we will have a fresh look at it and could resolve it in a much better/cleaner way (done it multiple times). Just leave it to solve later on if needed. There is already lots of works in this PR :)

fallow birchBOT
#
jgressmann
[hathach/tinyusb] New review comment on pull request #717: SAM E54 XPlained Pro: free PLL1 for application

The extra quotes turn the defined value into a proper C string. The C string itself doesn't contain the quotes.

I see your point regarding the board define. I could argue that freeing up a PLL1 is targeted at writing board specific code as well.

I am uncertain what is the best way to proceed here. From the TinyUSB project side I can see a desire to keep the examples board agnostic. From an application developer point of view I want to the stack to be as resource friendly and configurab...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

True, but i really would like to come up with an interface or a way to initialize the audio driver which does not need to be changed afterwards. The users would not appreciate this i guess ^^. But if it is too complicated i would leave it as it is.

I have a pretty fancy (but not too dramatic) idea in my mind. All we need would be a way to setup arrays of different sizes by use of the C preprocessor! Given the following declared list
`
#define AUDIO_EP_IN_SZ_LIST (11, 22) // Size in b...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Personally I don't like cascade too many macros, it makes debug and understanding difficult.
How about support a max number of audio functions, for example 3, I believe nobody will use more functions. (Also USB descriptor length limit)
Then:

uint8_t audio_ep_in_sw_buffer_1[CFG_TUD_AUDIO_FUNC_1_EP_IN_SZ];
#if CFG_TUD_AUDIO > 1
uint8_t audio_ep_in_sw_buffer_2[CFG_TUD_AUDIO_FUNC_2_EP_IN_SZ];
#endif
#if CFG_TUD_AUDIO > 2
uint8_t audio_ep_in_sw_buffer_3[CFG_TUD_AUDIO_FUNC_3_EP_IN_SZ];...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #717: SAM E54 XPlained Pro: free PLL1 for application

I fully understand your approach to have optimum set up for specific board. However, I prefer having a generic even less optimized bsp code. Eventually all same5x boards (d5035_01 and same54 xplained) will be grouped into a family much like samd51/21 when adding new board is simply define pins for LED and Button and/or Uart. This will reduce effort to add and maintain bsp. So that I could have more time to spend on the stack itself. E.g with nrf5x, I will set up the internal RC as clock sourc...

fallow birchBOT
#
mammutserver
[hathach/tinyusb] Issue opened: #728 tud\_umount\_cb not executed

tud_mount_cb is working properly and the led turns on. When I disconnect the device from my computer tud_umount_cb should fire and turn off the led. However the led stays turned on.

void usb_task(void *UNUSED_PARAM(pvParameters)) {
	extern TaskHandle_t init_task_handle;
	xTaskNotifyGive(init_task_handle);

	TickType_t xPreviousWakeTime = xTaskGetTickCount();
	for (;;) {
		tud_task();
		vTaskDelayUntil_bounded(&xPreviousWakeTime, 1);
	}
}

void tud_mount_cb(void)
{
    HAL...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: cleanup\-make
robust walrus
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #724: USB TMC Updates

My putting a particular RM DLL path was a bad idea, in retrospect. It was a hacky way for me to get it working on my laptop, and I shouldn't have done it. Also, it may not work for all installs of Windows.

What are your thoughts about if we remove all of the os-detection, and just have a call to:

rm = visa.ResourceManager()

With that, one can create a .pyvisarc with the proper library path based on which VISA library the user wants (if pyVISA's auto-selection doesn't work)?
...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #723 fix for nrf52840 epout dma race condition

Thanks for raising the issue, you are right that we may have some sort of race condition with data_received. After reading back the nrf usb specs along with going through my own question on devzone https://devzone.nordicsemi.com/f/nordic-q-a/35362/usb-bulk-out-hardware-bug. I think we could have a better implementation, the SIZE.EPOUT[epnum] = 0 seem to be only needed once only. Though since it could affect many other projects, I will spend a bit of more time testing it out. Will post more...

fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] Issue opened: #732 Generic USB TMC demo support

The current tmc demo has a script called visaQuery.py that explicitly uses a Windows 64bit dll. Consequently, the current demo cannot be run on other platforms without local changes.

My putting a particular RM DLL path was a bad idea, in retrospect. It was a hacky way for me to get it working on my laptop, and I shouldn't have done it. Also, it may not work for all installs of Windows.

What are your thoughts about if we remove all of the os-detection, and just have a call to:

...

#
khpeterson
[hathach/tinyusb] New comment on pull request #723: fix for nrf52840 epout dma race condition

Thatโ€™s my conclusion too, only write SIZE.EPOUT[epnum] once to get things started. I tried that while debugging (by omitting the spin wait in my PR) but ended up in a hung state. From what I could tell it was necessary to kick of the DMA by writing SIZE.EPOUT[epnum] at the beginning of each packet sequence (e.g. for each firmware packet of roughly 512 bytes sent by the host). Anyway, I didnโ€™t try too hard so I was probably missing something else that caused the hang.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
jgressmann
[hathach/tinyusb] New review comment on pull request #717: SAM E54 XPlained Pro: free PLL1 for application

I am suprised to learn that you are not interested in BSP performance. It is my estimate that there are quite a few folks out there that will experience their respective board's performance by means of running the TinyUSB examples. Not all of them might have the technical background to realize that if performance is bad, it might not the USB stack's or the board's fault but simply due to the way the board was set up.

However, given your statement, I don't think this PR is useful to the Tin...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #717: SAM E54 XPlained Pro: free PLL1 for application

I am suprised to learn that you are not interested in BSP performance. It is my estimate that there are quite a few folks out there that will experience their respective board's performance by means of running the TinyUSB examples. Not all of them might have the technical background to realize that if performance is bad, it might not the USB stack's or the board's fault but simply due to the way the board was set up.

It is not up to this repo to get the performance out of BSP. Also the B...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-nrf\-dcd\-bulk\-out\-race
#
hathach
[hathach/tinyusb] Pull request opened: #733 fix race condition that could cause drop packet of Bulk OUT transfer

Describe the PR
related to #723, fix issue raised by adafruit/Adafruit_nRF52_Bootloader#195.

  • NRF_USBD->SIZE.EPOUT[epnum] only need to write once to enable Bulk/Interrupt transfer. We only need to do it in dcd_edpt_open() and dcd_edpt_clear_stall()
  • Separate Control and Bulk/Int OUT hanlding
  • Some minor comment and clean up

@khpeterson I have tested and tried it with your dfu file. Seem to work well without blocking wait. Would you mind trying this out.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: feather\-rp2040\-correct\-bootstage2
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
khpeterson
[hathach/tinyusb] New comment on pull request #733: fix race condition that could cause drop packet of Bulk OUT transfer

OK, I will run my repeat script overnight tonight and send you the result tomorrow morning.

On Mar 18, 2021, at 10:26 AM, Ha Thach @.@.>> wrote:

Running repeats successfully for an hour now - looks good to me. Good job on the quick fix.

I am looking to your final number. Btw, the race condition probably get worse with the zero length packet. CDC host driver normally will send ZLP when all data is sent and is multiple of 64 (endpoint size). Hope we finally fix th...

fallow birchBOT
#
jepler
[hathach/tinyusb] Issue opened: #735 midi: bad things happen if device doesn't read midi from host

We were testing midi on feather m7 rt1011, and @ladyada noticed that if MIDI was being sent out but not acted on by CIrcuitPython, "bad things happened". On Linux this manifested as being unable to ctrl-c in the REPL and getting messages in the kernel log: sound midiC4D0: rawmidi drain error (avail = 3934, buffer_size = 4096). Would probably need to throw out some data if buffers fill up? discarding is better than crashing

tiny jetty
#

Maybe this is the wrong place for me to ask - but I'm having some problems setting up a HID device that also has a WebUSB interface for configuring it. I can't get them both working at the same time - do I need to set it up with multiple configurations or something?

fallow birchBOT
#
khpeterson
[hathach/tinyusb] New comment on pull request #733: fix race condition that could cause drop packet of Bulk OUT transfer

OK, just finished a little more than 1 hour of repeats - 110 trials, no failures. Looks good to me

On Mar 18, 2021, at 10:31 AM, Ha Thach @.@.>> wrote:

1 hours is good enough for me, don't leave it running too long, it could degrade your nrf flash

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/hathach/tinyusb/pull/733#issuecomment-802148062, or unsubscribe<https://github.com/notificatio...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
belchercw
[hathach/tinyusb] Issue opened: #743 USB CDC not setting tx fifo back to non\-overwritable after windows 10 sleep/resume

Set Up

  • PC OS Windows10 Pro version 1909
  • Board imxrt1020_evk (note that issue seems like it would occur regardless of Board type)
  • Firmware examples/device/cdc_msc with the following modification:
    Replace cdc_task with the following code to allow triggering of writes greater than CFG_TUD_CDC_TX_BUFSIZE
//--------------------------------------------------------------------+
// USB CDC
//--------------------------------------------------------------------+
ui...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
belchercw
[hathach/tinyusb] New comment on issue #743: USB CDC not setting tx fifo back to non\-overwritable after windows 10 sleep/resume

Original bug report updated to specify "C" language for code fragment. Rebuilt with LOG=2 and here is the resulting log:

USBD init
CDC init
MSC init
USBD Bus Reset

USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ... OK
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ... OK
USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received 00 05 07 00 00 00 00 00
Set Address
USBD Xfer Complete on EP 80 with 0 ...

fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

So I didn't have time to test this until now, I'm only now trying.

I'm having a weird, unexpected issue, my device is hitting a HardFault on tusb_init I debugged the project and it seems to be failing at:

  // Init class drivers
  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }

because it tries to jump to init() on iteration i=1 but `init(...

fallow birchBOT
#
hackbeere
[hathach/tinyusb] Issue opened: #745 Example cdc\_dual\_ports: error while connecting

Board: stm32f411blackpill
OS: Ubuntu 20.04

Dmesg output:
[ 346.364923] usb 3-2.3: New USB device found, idVendor=cafe, idProduct=4002, bcdDevice= 1.00
[ 346.364929] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 346.364932] usb 3-2.3: Product: TinyUSB Device
[ 346.364935] usb 3-2.3: Manufacturer: TinyUSB
[ 346.364937] usb 3-2.3: SerialNumber: 123456
[ 346.383946] usb 3-2.3: can't set config #1, error -32

sudo lsusb -d cafe:4002 -v
Bus 003 Device 01...

fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

Ok, I was unable to figure out why this looped more than once,

  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }```
but i forced it to loop once (i < 1) and after chasing some gremlins with clocks the device enumerated successfully! 

I have ordered a sltb009a efm32gg12 dev board from mouser which i will port and then i think we ca...
fallow birchBOT
#
eriklundh
[hathach/tinyusb] Issue opened: #746 cdc\_device DTR bit check breaks popular mcu flash tools, should be optional in src/class/cdc/cdc\_device\.c

Set Up

tinyusb @ 11c23f8**

  • Raspberry Pico
  • src/class/cdc/cdc_device.c

Describe The Bug

cdc_device.c throttles serial data if DTR is false
ESP32, flashing tools such as esptool.py assume no flow control and use DTR and RTS to reset ESP32 and put it in flash mode.
When e g Raspberry Pico is used as a USB to serial converter to ESP32, the cur...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

thank you, it is great to hear to get it working. If you could make an bsp for the board I have, that would be great, otherwise no problems at all, I found EFM32 dev board is rather expensive as well ( got it as freebie from energy micro a long time ago). I have also ordered sltb009a as well since that is probably most people will buy anyway. Looking forward to your PR.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: cleanup\-examples
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #746: cdc\_device DTR bit check breaks popular mcu flash tools, should be optional in src/class/cdc/cdc\_device\.c

Thanks for your information. There was actually a talk about ESP32 flashing before starting here.

CDC already changed that it's possible to receive and transmit data even if DTR bit is not set. The tud_cdc_n_connected API still checks this bit because some application might require a real terminal connection to be detected. That's why it should be kept within this function.

I guess in your case you just do not have ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

Ok I have now tested a couple different examples, all without issues after enumeration, but there is one common issue, every time after initialization the devices times out

[ 5845.144641] usb 3-4.3: USB disconnect, device number 25
[ 5889.104950] usb 3-4.3: new full-speed USB device number 26 using xhci_hcd

[ 5904.562516] usb 3-4.3: device descriptor read/64, error -110

[ 5904.767196] usb 3-4.3: New USB device found, idVendor=cafe, idProduct=4004, bcdDevice= 1.00
[ 5904.7672...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

Superb !! That is really great to hear Don't worry if you couldn't fix it for now. I think it is already more than enough to wrap up this PR. I am still waiting for the sltb009a to delivery (probably in 2,3 weeks since I am so back ordering other boards as well). I could help to troubleshoot it afterwards with follow-up PR ( just make sure we have an issue for it so that we don't forget). I am actually quite familiar with these kinds of problems with enumeration.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I try to test with the plot python script but look like soundevice does not detect device on my Linux. There is no need for you to look at this, I will pull out a windows machine to test with. Just curious to see if I miss something.

ValueError: No input device matching 'Microphone (MicNode) MME'

I try to list it but it doesn't seem to be detected. Maybe I miss something, it does appear in my ubuntu as input device (microphone) though :thinking: :thinking:

$ p...
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I try to test with the plot python script but look like soundevice does not detect device on my Linux. There is no need for you to look at this, I will pull out a windows machine to test with. Just curious to see if I miss something.

ValueError: No input device matching 'Microphone (MicNode) MME'

I try to list it but it doesn't seem to be detected. Maybe I miss something, it does appear in my ubuntu as input device (microphone) though ๐Ÿค” ๐Ÿค”

``...

fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Issue opened: #750 EFM32 Driver: error \-110 upon first enumeration

Ok I have now tested a couple different examples, all without issues after enumeration, but there is one common issue, every time after initialization the devices times out

[ 5845.144641] usb 3-4.3: USB disconnect, device number 25
[ 5889.104950] usb 3-4.3: new full-speed USB device number 26 using xhci_hcd

[ 5904.562516] usb 3-4.3: device descriptor read/64, error -110

[ 5904.767196] usb 3-4.3: New USB device found, idVendor=cafe, idProduct=4004, bcdDevice=...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

I see your point. Since dst_u8 is not word-aligned the compiler is not always willing to optimize memcpy out, for example in IAR I have to use highest optimization or it just call __aeabi_memcpy. There is __attribute__((__packed__)) for this kind of stuff.

You can do something like this:

typedef struct{
    int i;
} __attribute((__packed__)) unaligned_int_t;

unaligned_int_t* dst = (unaligned_int_t*)(f->buffer + (wRel * f->item_size));;
dst->i = *rx_fifo;

There i...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

@hathach

this complicate the code more than it should be

I don't see it complicate the code, it's a quite common way to do unaligned copy.

How much overhead we are talking about here

Unless I set optimization to high (which cause problem in step by step debugging), IAR generate this code and it stays for 43 cycles inside __aeabi_memcpy4 on my STM32L412.

        ADD      R0,SP,#+20     
        ADR.W    R1,?_0         
        MOVS     R2,#+16        
          CFI F...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

You are right, 43 cycles for a word is indeed quite a lot considering we are doing hundreds of this. And a bit of googling, also suggests it is common to address this. It is my bad. Though maybe we should declare it as global typedef for these to reduce duplication (could do this). btw do you think having these align would work instead of using packed struct ?

typedef uint64_t unaligned_uint64_t __attribute__ ((aligned(1)));
typedef uint32_t unaligned_uint32_t __attribute__ ((ali...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Mh interesting... i did not test it on linux. You may try the default device i.e. skip device=device. If it is the only input device than it should be the correct one!

Thank you very much, I will try it out, have to switch to other task to support a coming soon board for iMXRT https://www.adafruit.com/product/4950 . I will test this out again this weekend.

Just a short noticy, i found a bug which i fixed but did not push so far: please select the fifo buffer size to equal the EP...

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Unfortunately it's not work without struct, gcc simply ignored __attribute__ ((aligned(1))), I've also tried IAR (IAR now support most gcc syntaxes).

In IAR I can simply do dst = *(__packed uint32_t*)(f->buffer + (wRel * f->item_size)); but there is no packed pointer in gcc.

If src is not volatile shift + or and packed struct generate nearly the same code, on ARMv6M:

#Shift + Or
	ldr	r0, .LCPI0_0
	ldrb	r1, [r0, #5]
	lsls	r1, r1, #24
	ldrb	r2, [r0, #6]
	lsls	r2, r2, #16
...
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #749: Add sltb009a BSP

I don't really understand this issue

[perigoso@perigoso-desktop hid_generic_inout]$ make BOARD=sltb009a print-SRC_C
SRC_C = hw/mcu/silabs/cmsis-dfp-efm32gg12b/Device/SiliconLabs/EFM32GG12B/Source/system_efm32gg12b.c src/portable/silabs/efm32/dcd_efm32.c hw/bsp/board.c hw/bsp/sltb009a/sltb009a.c examples/device/hid_generic_inout/src/main.c examples/device/hid_generic_inout/src/usb_descriptors.c src/tusb.c src/common/tusb_fifo.c src/device/usbd.c src/device/usbd_control.c src/class/aud...
#
perigoso
[hathach/tinyusb] New comment on pull request #749: Add sltb009a BSP

I think this might be some oversight on the buildsystem
to clarify
the issue here is that there are two files named the same in the silabs cmsis, one in C and the other in assembly
hw/mcu/silabs/cmsis-dfp-efm32gg12b/Device/SiliconLabs/EFM32GG12B/Source/GCC/startup_efm32gg12b.S
hw/mcu/silabs/cmsis-dfp-efm32gg12b/Device/SiliconLabs/EFM32GG12B/Source/GCC/startup_efm32gg12b.c
the only file being included is the assembly one, and thats the only one we want to compile, but it seems the pro...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Thank you for your extra information. I have learned something new (still learn new thing with C every now and then). Using memcpy to replace shift-or is my bad. We have inline helper, maybe we can put them into usage here
https://github.com/hathach/tinyusb/blob/master/src/common/tusb_common.h#L85

I am still prefer doing thing more explicit than leaving it to compiler, especially if it is not too obvious. I really need to wrap up the review and merge this PR asap :sweat_smile:

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Well, take your time ^^. The more i do on generalizing this driver for multiple audio functions / audio streaming (AS) interfaces / alternate settings of AS interfaces, the more demanding this design gets... i will need some time more! I will find a way to not overcomplicate the design.
The generalization is finished in case no support FIFOs and encoding/decoding is required. I fixed it to three audio functions maximum available. Anyway, i want the support FIFOs and encoding/decoding include...

fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] Pull request opened: #754 Add DFU Class per Version 1\.1 Spec

Please review. I have some final testing to complete, and then some additional cleanup I would like to do. I attempted to best follow the existing structure and styling. Please let me know if anything is misplaced, desired debug missing, or any other general hygiene issue.

Describe the PR
This PR completes the DFU Class, resolving feature Issue #29. It extends the prior DFU Class stub, which implemented only a DFU RT detach flow.

Additional context
The class has been valid...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Issue opened: #755 Buildsystem does not allow a c and assembly source with the same name

Buildsystem does not allow a c and assembly source with the same name, where only one is supposed to be compiled.

I found this issue while trying to implement an example for the efm32 family in #749.

The Cmsis provided by silabs as both a c implementation and an assembly implementation for the startup, only one should be compiled, but the buildsystem right now tries to compile both, regardless of which is included.

I have followed up the issue and think it is in rules.MK where b...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #758 Add macro for unaligned access\.

Describe the PR
A proposition for unaligned access macro.

Then we can refactor unaligned accesses, for example:

uint16_t total_len;
// Use offsetof to avoid pointer to the odd/misaligned address
memcpy(&total_len, (uint8_t*) desc_bos + offsetof(tusb_desc_bos_t, wTotalLength), 2);

Into

uint16_t total_len;
TU_UNALIGNED_GET(total_len, &desc_bos->wTotalLength, uint16_t);

Additional context
It should works on TI compiler, need test.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #757 Add support for GR\-CITRUS

Superb ! brilliant works, thank you very much for your PR. Too bad that it seems like renesas boards is hard to find and very expensive as well. Therefore I couldn't perform any hand-on tests any will merge this as it is. Which looks really good, except for

  1. maybe move the submodule from renesas to renesas/rx63 to allow as more families later on
  2. I wonder if rx63n freertos start scheduler would return at all ?

once the submouldes is moved, I could help to fix the ci.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-755\-same\-name\-c\-s\-file
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: kkitayam\-add\_support\_for\_gr\_citrus
#
hathach
[hathach/tinyusb] New comment on pull request #757: Add support for GR\-CITRUS

@kkitayam I have fixed the ci issue caused by lacking the gnurx toolchain. Since rx63n has its own toolchain, it is best to move it into a family (currently with its own board). This is done by simply add the family.mk that include the board.mk. The build command is exactly the same as before make BOARD=gr_citrus. This allow us to run a seperate ci job that cached the gnurx toolchain for rx63n family only. This is push toward your branch already, please fetch/pull first before making additi...

fallow birchBOT
#
ned-pcs
[hathach/tinyusb] Issue opened: #761 CDC: tud\_cdc\_write returns 0

Set Up

  • Ubuntu 20.04
  • STM32F072-EVAL board
  • Firmware: custom app with just CDC, sending 22-byte messages as fast as possible. Using RTT for logging.
    • app waits until host connection before sending anything.

Describe The Bug
After 154 characters are sent successfully (7x22 byte messages), tud_cdc_write() returns 0 bytes written when 2 were requested.
The immediately prior tud_cdc_write() of 22 bytes returned 20 bytes written.

When tud_cdc_write() returns 0 bytes...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ned-pcs
[hathach/tinyusb] New comment on issue #761: CDC: tud\_cdc\_write returns 0

I agree, this is not a bug. I stated it badly (clearly one can't transmit at infinite speed).
Sorry to bother you.
My problem is that the overall CDC transmission throughput (in my app that acts as a CAN-to-slcan gateway) is not high enough in practice to keep up with messages being sent rapidly on a 250kbps CAN bus, though I had hoped that it would be.
I've added code to check FIFO space using tud_cdc_write_available() and drop packets if not enough space is available.
Perhaps double-b...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-more\-hid\-key
fallow birchBOT
#
ned-pcs
[hathach/tinyusb] New comment on issue #761: CDC: tud\_cdc\_write returns 0

Thanks for your attention. I don't think it'll be necessary to do that.
It turns out that what was happening was that there was not quite enough space for a whole message.
I added a check of tud_cdc_write_available(), and if that said that there wasn't enough space for a whole message, I did a tud_cdc_write_flush().
That fixed the issue!

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #757: Add support for GR\-CITRUS

You are right. The vTaskStartScheduler() never returns. I'll remove the reutrn 0 statement.

I had made the following misunderstand. In the function prototype of the main(), the return type is int. To match the type, I thought enabling return 0 is in a well mannered way.

However, after some googling, I found out that the main() can omit the return statement.
It is shown in https://stackoverflow.com/a/2890894

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enhance\-midi
#
hathach
[hathach/tinyusb] Pull request opened: #766 Enhance midi

Describe the PR
Fix #735. should also fix root cause of #377 . should also fix issue with https://github.com/adafruit/circuitpython/issues/4190
Root cause of the issue is TX fifo is overflow, though it is not handled safely by driver, which cause the data corruption to the usbd device control and cause the system to crash/hardfault. While fixing the issue, I have go through the whole improvement, including

  • Adding MIDI_CIN_ and MIDI_STATUS_ instead of using magic number in stream API...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-doc
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Ok guys the redesign is ready for review! I fixed it to 3 audio functions as discussed before. Because of this, there are a lot of #defines etc. to enable only the needed buffers etc. So please don't be shocked of this, it is the best we can do with the limited capability of the C preprocessor etc.
Please start with the audio_device.h as from there i hope the strucuture of the driver gets clear.
There are some "fast copy" functions, i leave them for @hathach to reformat to his prefered wa...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #754 Add DFU Class per Version 1\.1 Spec

Thank you very much for your PR. Sorry for late review, I haven't fully go through it yet. Though there is one thing I spotted. Since DFU mode & runtime is mutual exclusive. I would like to have it as separated driver. So that application that enable the rutnime does not need to also include the DFU mode which require more RAM & ROM. Could you separate the dfu functionalities into dfu _device.h/c, we will leave the dfu_rt code as it is (common enum/typedef move to dfu.h is spot-on)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #643: Double Buffering

after revising the code, I think software double buffering is implemented in the form of fifo. Hardware double buffering on dcd is currently not implemented, since it often needs to use 2 endpoint e.g 1 IN + 1 OUT for an double buffer OUT. currently stack does not support dcd specific option. I will close this issue for now, feel free to open new issue when there is new information.

fallow birchBOT
#
phdussud
[hathach/tinyusb] New comment on pull request #768: Fixed very slow implementation of \_ff\_mod

I have implemented a JTAG probe that receives over 6500 USB packets to program a FPGA. During my tests the wall clock programming goes from 2.5s to 4.5s as I repeat the programming and then goes back to 2.5s at the 10th programming and the cycle repeats. My fifo depth is 64, so mod will loop a 1000 times in the worst case. After the fix, the wall clock time is stable at 2.4s
This is on a Raspberry pico board.
Thanks,
Patrick

From: Ha Thach @.***>
Sent: S...

#
phdussud
[hathach/tinyusb] New comment on pull request #768: Fixed very slow implementation of \_ff\_mod

By the way, it I pulled my hair for a while before discovering the root cause of the slowdown. I donโ€™t know how to profile code on a Cortex-M0+ so I had to convince myself that it was communication problem first (using a LA I saw that the JTAG output was normal, except the programming bursts were more and more spaced out). I then looked at the state of my USB interface for the first time and for the 9th time. I noticed that the read and write pointers were super large on the 9th time. That su...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I made a few commit to comment out the dcd_edpt_xfer_fifo() the implementation for other ports except stm32 synopsys. I spotted a few untested code and a couple of issue with hardware fifo e.g in samg although it also use fifo its 32-bit register is written in bytes fashion, and nuc505 also has some odd issue with word and byte access as well. Therefore I think it is best to just on stm32 which is what we use to test this PR. dcd_edpt_xfer_fifo() is optional, I could do other ports in ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #754: Add DFU Class per Version 1\.1 Spec

Could you separate the dfu functionalities into dfu _device.h/c, we will leave the dfu_rt code as it is (common enum/typedef move to dfu.h is spot-on)

I will separate out class functionality of DFU mode from RT.

Thanks, I will do more review this week, need to pull out the DFU specs, kind of forgot it entirely ~.~ . This will be very helpful to bootloader project like https://github.com/adafruit/tinyuf2 . In fact, I will probably use tinyuf2 to test out this PR, since the flas...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I made a few commit to comment out the dcd_edpt_xfer_fifo() the implementation for other ports except stm32 synopsys. I spotted a few untested code and a couple of issue with hardware fifo e.g in samg although it also use fifo its 32-bit register is written in bytes fashion, and nuc505 also has some odd issue with word and byte access as well. Therefore I think it is best to just on stm32 which is what we use to test this PR. dcd_edpt_xfer_fifo() is optional, I could do other ...

#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

That i have to admit is true! When i wrote those, i was not aware of the hardware restictions... I would just not forget to implement those and do that in time before we forget how to implement them ^^.

yeah, those commented out code you have written is very useful. I only needs a bit of testing and tweaking to work with the unique hw fifo behavior of each MCU. We will do it later on :)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: unaligned\-access
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #772: add tu\_unaligned\_read32/write32

With a quick looking it should work :)

With IAR there is a little inconvenient is with inline function I can't disable Warning[Pa039]: use of address of unaligned structure member.
So we need to continue to use (uint8_t*) desc_bos + offsetof(tusb_desc_bos_t, wTotalLength) instead of &desc_bos->wTotalLength.

can the pragma suppress be added into the inline ? we can have temporarily add that for now and find an better/general way later on.

#
hathach
[hathach/tinyusb] New comment on pull request #772: add tu\_unaligned\_read32/write32

I guess @HiFiPhile knows more of this topic but in any case, could you provide an unaligned access to int16 too? This is required for fast half word copies in the audio encoding/deconding! Thanks :)

Yeah, I was initially want to add 16-bit version, but put it off since I am not sure if we would use it at all. Though since there are all inline, there is no generated code if not used. So here it is

#
HiFiPhile
[hathach/tinyusb] New comment on pull request #772: add tu\_unaligned\_read32/write32

With __attribute__((always_inline)) the warning can be disable using pragma:

__attribute__((always_inline)) static inline uint32_t tu_unaligned_read32(const void* mem)
{
  _Pragma ("diag_suppress=Pa039");
  tu_unaligned_uint32_t const* ua32 = (tu_unaligned_uint32_t const*) mem;
  return ua32->val;
  _Pragma ("diag_default=Pa039");
}

Without always_inline sometimes IAR don't like to inline the function especially in low optimization, the pragma doesn't work since the warn...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #772: add tu\_unaligned\_read32/write32

@HiFiPhile I added the TU_ATTR_ALWAYS_INLINE, and applied it to basic inline function. Though I don't like to suppress and unsuppress it here. It makes code look less readable, also not all unaligned access need to suppress this e.g uint8_t/void. I am fine with the offsetof() at the caller.

#ifdef __ICCARM__
  #define IAR_PA309_SUPPRESS    _Pragma("diag_suppress=Pa039")
  #define IAR_PA309_UNSUPPRESS  _Pragma ("diag_default=Pa039")
#else
  #define IAR_PA309_SUPPRESS
  #define...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
phdussud
[hathach/tinyusb] New review comment on pull request #768: Fixed very slow implementation of \_ff\_mod

@PanRe : I don't think your PR fixed this. The read pointer and the write pointers are not limited. Your PR will make the write pointer be equal to the read pointer but it does not limit the read pointer. The root cause if that the function _tu_fifo_correct_read_pointer is not called if cnt is not higher than the depth. For my case it is never true. Somewhere, there needs to be a check that the read and write pointers are not greater than their max values, regardless how many bytes are writt...

fallow birchBOT
fallow birchBOT
#
phdussud
[hathach/tinyusb] New review comment on pull request #768: Fixed very slow implementation of \_ff\_mod

Ok. The problem isn't with the vendor fifos but with _usbd_qdef which isn't correctly initialized. The fifo that is embedded in the _usbd_qdef has its max_pointer_idx and non_used_index_space left to 0.
//--------------------------------------------------------------------+
// DCD Event
//--------------------------------------------------------------------+

// Event queue
// OPT_MODE_DEVICE is used by OS NONE for mutex (disable usb isr)
OSAL_QUEUE_DEF(OPT_MODE_DEVICE, _usbd_qdef, CFG...

#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

In time, i will provide another audio example where the software encoding for two I2S streams i.e. 4 channels is used!

That would be awesome demo, though a bit of extra work may be required for the I2S driver. You could just do it in any native way that you would, I will try to catch-up and do board_i2s() abstraction later on.

#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

In time, i will provide another audio example where the software encoding for two I2S streams i.e. 4 channels is used!

That would be awesome demo, though a bit of extra work may be required for the I2S driver. You could just do it in any native way that you would, I will try to catch-up and do board_i2s() abstraction later on.

Well, it was the idea to do this in an abstract way similar to the current audio example. So there would be two dummy arrays which "simulate" the ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Well, it was the idea to do this in an abstract way similar to the current audio example. So there would be two dummy arrays which "simulate" the I2S data! The rest is MCU specific and i would leave that to the user!

Yeah, ah right, I was thinking on the actual I2S hardware, i2s encoding is super good already. The hardware come later :)

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

After successfully testing the ISO in without a single drop. I mostly do the fifo cleanup, rename and refactor. I haven't looked closely at the UAC 2.0 yet (need to pull out its doc), though having audio_device to take care of the fifo wrap-around is a bit of redundant. Since your latest push already move the wraparound handling into the fifo API. Please check to see if we could simply use write_n() and read_n() in the audio_device.c

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

This is an optimized code which conducts interleaved sample copies! I would strongly advise against doing this with write_n/read_n because it is dramatically inefficient! The way it is done here avoids the unnecessary overhead of updating the read and write pointers for every sample and furthermore, it does not use memcpy for the copy of 1,2,3, or 4 bytes (which by definition are all possible sample sizes in UAC2 type I format).

I understand your desire to put such code into fifo.c but thi...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Well, the write_n and read_n functions in fifo.c are general purpose functions where you can not tell anything of how much is to be copied etc. They are perfectly fine, but when it comes to optimized stuff they are simply too generall (most of the time). If you want to copy a bunch of samples in one rush from A to B they are perfect, but when you need those fancy interleaved copy stuff they are simply too inefficient...

I don't expect that any other fancy stuff is required ;)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #754 Add DFU Class per Version 1\.1 Spec

Thank you very much for your PR. I haven't go through all the changes just yet. Though I notice several changes that we could address first with DFU Runtime, still haven't looked at actual DFU mode yet.

  1. There is couple typo when comparing runtime state with DFU_REQUEST_DETACH, should be APP_DETACH
  2. Bitwise result must not be equal-check with 1, it is good as just bitwise alone
  3. the updated dfu runtime is more complicated than it should be. I think the existing/previous code i...
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

You are correct in that dfu runtime and dfu mode are exclusive. After I split the RT and Mode, I ran into an issue where because the tusb_config.h had:

#define CFG_TUD_DFU_RUNTIME 1
#define CFG_TUD_DFU_MODE    1

Which resulted in both DFU classes being initialized when tud_task() was called.

One possible solution to this would be to have separate builds, one for the app with RT and another for the bootloader with Mode. In the event than an application does not want to have...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

I don't think we would need to ask the app, I wonder why would bptj CFG_TUD_DFU_RUNTIME and CFG_TUD_DFU_MODE are enabled at the same time. And what would be the issue with both dfu mode and dfu rt are initialized. It really doesn't matter, the usb configuration descriptor will dictate which interface e.g itf = 0 for the DFU mode and which is used for DFU runtime should they are both enabled.

Please remove the the RUNTIME_AND_MODE we will treat each one as separated driver like msc vs cdc.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: remove\-submodule\-pico\-sdk
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New comment on pull request #754: Add DFU Class per Version 1\.1 Spec

I am expecting that you would like the nonstandard requests removed from the DFU mode, but I will wait until your review before I make this change.

To adhere to the spec, the finite state machine is verbose, with a fair bit of duplication. I opted for readability rather than compactness, which is why some things, such as get_state and get_status requests are in most states, rather than being checked at the request level.

fallow birchBOT
#
alisitsyn
[hathach/tinyusb] Pull request opened: #783 WIP: Add new Espressif target esp32s3 for tinyUSB

What happened in this PR

This PR adds support of a new Espressif chip ESP32-S3 into tinyusb project.
The chip peripheral is very similar compare to ESP32-S2 target and support is added as a family driver to allow following extension of the family and group the controllers with similar USB peripheral.

  1. Update the device controller driver for S family esp32sx:
    tinyusb/src/portable/espressif/esp32sx/dcd_esp32sx.c
  2. Add new esp32s3 based board in
    `tinyusb/hw/bsp/esp32s3_addax_1*...
fallow birchBOT
fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

Hi @me-no-dev,

There seem to be changes included that need to be reverted, like submodules being removed.

The branch update is in progress (rebase to the latest master) and will be ready after testing soon.

Also to make the changes more clear, is it possible to not include the new example?

My intention is not addition of a new example but update the existing espressif examples to be able to compile them for new added board based on new esp32s3 chip - esp32s3_addax_1.

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #783 WIP: Add new Espressif target esp32s3 for tinyUSB

Thank you very much for your PR. It is great to have the new ESP32-S3 chip added. The changes look good, though I have a few feedback

  1. Please revert the submodules removal. They are important and needed to build for other platforms :)
  2. Can you move the esp32s3 into it own family hw/bsp/esp32s3 similar to esps2, it will help to group similar driver such as board_init() and ws2812 driver.

CI also needs to be update to build with esp32s3, though I could help with that.

fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

@hathach,

Thank you for your feedback and advices.

Please revert the submodules removal. They are important and needed to build for other platforms.

It seems that submodules were removed incidentally by script.

Can you move the esp32s3 into it own family hw/bsp/esp32s3 similar to esps2, it will help to group similar driver such as board_init() and ws2812 driver.

I am going to move it into the separated family folder hw/bsp/esp32sx how it was done in the latest master. All...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

It seems that submodules were removed incidentally by script.

no problem at all, just make sure you revert it

I am going to move it into the separated family folder hw/bsp/esp32sx how it was done in the latest master. All examples will inherit the same standard board functionality and ws2812 driver (exists on esp32s3_addax_1 board also).

I actually think it is better to keep family separated as esp32s2 and esp32s3 (rather than esp32sx), although IDF does an great job of dr...

fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

I actually think it is better to keep family separated as esp32s2 and esp32s3 (rather than esp32sx), although IDF does an great job of driver abstraction, It is still useful and more obvious to end-user. Yeah, I know there is a bit of code duplication but I am fine with it. Other mcu such as stm32 f2 f3 f4 is actually quite similar, but separated them make it easier to maintain and manage. Hope this makes sense

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

Actually the ESP32S (like F4 for STM) is the family and ESP32-S2, ESP32-S3 are actual chips inside this family. I personally think that this is logically correct. It is not an issue to follow your approach from make standpoint. As I understand the structure will be like below. Is this correct?

tinyusb_esp\hw\bsp\
                    esp32s2\ < --- esp32s2 family boards
                        boards\
                            adafruit_feather_esp32s2
            ...
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@hathach Are you still testing this PR or do you have any idea when it is ready for being merged?

Almost done, I am trying to convert the happy birthday to feed sample. Though I am sure, we will merge this by the end of this week, I promise :sweat_smile: . The audio driver is actually too overwhelmed for me to actually review it thoroughly. So I think it is best to do it as follow-up. Thank you for your patient.

fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

@hathatch,

Normally MCUs within families is only slightly different in ram & rom, pinout (and maybe an extra peripheral). I thought esp32s3 is totally different with extra core. Though you guys at espressif apparently understand it better, if you think their cores and peripheral is similar enough to be in the same group. So yes, please go ahead with esp32sx

You are right about the ESP32-S3. It has enough differences (cores, different peripheral and memory changes) and I can see the re...

#
hathach
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

Thank you very much @PanRe for spending massive amount of time, thought and effort into this brilliant awesome work. The amount of changes is huge, and the time for wrapping this up is also extensive long. But it is well worthy. Audio class v2.0 is very complicated one, It will definitely takes me lots more months to even come up with some (not) closed to your work. I feel confident that we can now merge this, unless you are still working on something else (saw recent push this morning).

...

#
hathach
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

You are right about the ESP32-S3. It has enough differences (cores, different peripheral and memory changes) and I can see the reason to divide them into two different family folders. I think it is better to get team opinion about this, cc @me-no-dev.

Actually, it is not a big deal, this bsp family folder thing is just an way to organize boards for testing stock examples in tinyusb repo. It should not make much of differences. Since most end-user people will just IDF platform, arduino or...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Interesting error! First, the Linux driver seems to want only 2 bytes for the sample frequency range descriptor since its length is 2... This is by far to less. But this is covered by the UAC2 specifications:

The actual parameter(s) for the Get request are returned in the data stage of the control transfer. The length
of the parameter block to return is indicated in the wLength field of the request. If the parameter block is
longer than what is indicated in the wLength field, only the ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I think the issue is not caused by the RANGE request with 2 bytes, usbd will auto truncate the response to match the length of requested by host (never sent more than what host ask for). I think host use 2 bytes to calculate the total length of the response, right afterwards it issue and same request with larger buffer (14 bytes). The software analyzer just doesn't interpreter it correctly (it probably expect more payload). We can safely ignore that

I take a look and capture a coupl...

#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe Oh, I see where the issue, I am using stm32f411disco, which board you are using, I think the the size 392 overflow my fifo allocation scheme for the chip.

  Open EP 81 with Size = 392
``

We did rework the scheme, maybe we still have it open for some chips. I am fine with this bug. I will create an separated issue for this, it would be good chance to update/enhance the fifo allocation scheme further. I think this PR is solid gold now, and good for merge :)
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I also use an STM32F411 but on a board built by my own and i don't have the disco board unfortunately! And i am pretty sure the USB stack is all fine because i use it in my custom examples and all works fine!

I have the strong feeling that the error is somewhere in main.c, simply because i was not able to test the example of 4 channels as i pushed! I tested it with my own code and i have to apologize to not have tested the example in every detail! I think the error happens because after ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Puh, finally :D i am really glad you like the driver and everthing works!! This driver concludes my duty for the open source community and I am really reliefed this work finally finds its way into the main branch :D :D

Tested on windows and macos, all working fine. Thank you very much for your time and effort, who wouldn't like this awesome works of yours :). It one of the biggest and longest PR I have ever worked on. It is specially difficult, since audio require expertise to actually p...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe that is it, this awesome PR is finally merged. It has been on constant develop-test-review cycles, but I really enjoy working with you. I couldn't thank you enough. Also thanks @HiFiPhile for help with reviewing and testing PR as well. I am looking forward to more PRs and works from you :tada: :tada:

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

Actually, it is not a big deal, this bsp family folder thing is just an way to organize boards for testing stock examples in tinyusb repo. It should not make much of differences. Since most end-user people will just IDF platform, arduino or micropython/circuitpython. It is not really that important and can be easily changes later on if needed.

I agree with your opinion and pushed new commit to update PR according to our discussion. Please take a look when possible.

Yup, later on I w...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kapacuk
[hathach/tinyusb] Pull request opened: #789 When used with FreeRTOS, lower the interrupt priority for OTG\_FS\_IRQn

None of the FreeRTOS examples currently work with STM32F4, they all trigger this assert in lib/FreeRTOS-Kernel/portable/GCC/ARM_CM4F/port.c:

764 configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );

because the interrupt priority for OTG_FS is too high (that is, the value of ucCurrentPriority is too low).

The (almost) correct call to NVIC_SetPriority was commented out in hw/bsp/stm32f4/family.c.

I have a suspicion that other Cortex-M chips migh...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #789 When used with FreeRTOS, lower the interrupt priority for OTG\_FS\_IRQn

Thank for the fix, yeah, this is very common issue when using cortex m with freertos. I have this nvic setprio for most of family, but apparently not all of them. This is downside of having too many boards/ports, that sometime I couldn't do all the hand-on testing on actual hardware

Note: The issue is only occurred if default priority (on reset) of USB is too high, somehow my stmf411disco board work just fine without this patch.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: group\-f0
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kapacuk
[hathach/tinyusb] Issue opened: #791 Use different build directories for debug and release builds

Currently, when you build an example, the results are stored under _build/$(BOARD)/, regardless of the value of the DEBUG variable. So, if you have a fully compiled release build and type make DEBUG=1 nothing happens.

I think the debug and release builds should be kept in separate directories, and propose this change to the makefile:

--- a/examples/make.mk
+++ b/examples/make.mk
@@ -3,8 +3,11 @@
 # ---------------------------------------
 
 # Build directory
-BUILD := ...
fallow birchBOT
#
alisitsyn
[hathach/tinyusb] New review comment on pull request #783: WIP: Add new Espressif target esp32s3 for tinyUSB

the board.mk should not be included here. The reason is that depending on the family, it may need some variables define before the include of board.mk (e.g board linker overwrite family linker etc.. ) and some after. So it is best to remove and let the family.mk to decide.
This approach with included board.mk here was used in previous approach (with esp32sx family) to override the chip target settings. In this update it is not required any more. I removed the board.mk from es...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-ci
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-ci\-rp2040
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Actually, dcd_edpt_xfer_fifo() is not useful for ISO EPs alone, its a general way of getting data directly from a fifo into the usb hardware buffer without the need of a "middle" buffer. True, its primary use is for ISO but it could be of interest for other stuff too. Just wanted to mention that before removing all of it.

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Now I'm thinking next step : how to add DMA capacity to application layer properly.

Actually tusb_fifo is not exposed to application layer, and @hathach wants keep the fifo internally unless you have changed your idea :)

No matter using support fifo or not, data has to be read using tud_audio_read or tud_audio_read_support_ff, application layer needs to maintains another I2S fifo (or a ping-pong buffer) in order to transfer data to/from peripheral using DMA. (I believe audio is alwa...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

It is exactly indended to do it as you sketched it with

USB FIFO -> TUSB_FIFO -> Peripheral (DMA)
Or
USB FIFO -> TUSB_FIFO -> (DMA) -> APP_FIFO-> Peripheral (DMA)

Anything else would be a waste of time and memory. In case of one I2S, you can implement the above e.g. for TX, by init a DMA in circular mode and give the DMA the buffer of the FIFO as a start address. The DMA now may write samples into the FIFO buffer continuously. Next, you choose any suitable interrupt source (e.g. hal...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I implemented such a thing for a USART interface

Me too I've done something similar in #403, at that time DMA hasn't been added to tusb_fifo.

I think we are agreed in the same direction, now we need to decide how to implement it ;)

  • Expose the fifo ?
  • Add a callback in tusb_fifo to call DMA transfer ?
  • Add DMA callback in audio_device ?
  • Some dark magic ?
fallow birchBOT
fallow birchBOT
#
kapacuk
[hathach/tinyusb] Pull request opened: #797 Create a new make rule for checking out submodules\.

Currently, if you do a fresh checkout of the tinyusb project and try to build a FreeRTOS example you get an error like this on the first run:

......
LINK _build/seeeduino_xiao/seeeduino_xiao-cdc_msc_freertos.elf
arm-none-eabi-gcc: error: _build/seeeduino_xiao/obj/lib/FreeRTOS-Kernel/list.o: No such file or directory
arm-none-eabi-gcc: error: _build/seeeduino_xiao/obj/lib/FreeRTOS-Kernel/queue.o: No such file or directory
arm-none-eabi-gcc: error: _build/seeeduino_xiao/obj/lib/Free...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #797: Create a new make rule for checking out submodules\.

yeah, the fetch submodules on-the-fly do not work well with -j option. And gcc may try to split task and I don't know, it doesn't seem to work well with dramatics file changes, similar to make -j clean all won't work. I was thinking of having submodule target, though I think just press up for previous target is much quicker. This is one-time issue, not a deal breaker though. Don't spend too much time on it :)

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #754 Add DFU Class per Version 1\.1 Spec

Thank you for your PR again. There are only several comments, but all is minor (except the timeout change), not really require much changing. Besides that I have 2 major requests

  1. Could you simplify the dfu_mode to just dfu (both in API and file name). I think it will be simpler and easier to read. If you think it is too much of a hassle, then I could help with the rename
  2. As part of adding new class, it typically requires to have an example to (a) to test the driver and (b) demonst...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe @HiFiPhile we can expose the tusb fifo if needed, previously there is no need for that. I have a question though, normally how do you set up a DMA toward I2S peripherals, I don't do audio so any simple virtual code would help.

In anyway we choose to expose the fifo, we will always need to support alternative API as well for MCU that aren't fifo based. Actually more MCUs can perform DMA directly from/to SRAM then I2S peripheral e.g
DMA DMA
USB...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@hathach I am not completely sure what you mean by zero_copy... Since we don't have kernel and user spaces here! Do you mean:
USB HW BUFFER --- (DMA) ---> FIFO --- (DMA) ---> I2S (1)
or
USB HW BUFFER --- (DMA) ---> I2S (2)
or
USB HW BUFFER --- (CPU) ---> FIFO --- (DMA) ---> I2S (3)
?
I am not as experienced as you what all the different MCUs are capable of but i know that the STM32F4 USB hardware buffers do not allow for (2), since the USB hardware buffer can not be written to any mo...

#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe zero copy is for other MCU with USB DMA, stm32 is fifo based. Wjich means application and driver simply pass pointer to USBD to schedule transfer. One it is transfer, the app/driver apparently cannot do anything else, application need to employ ping-pong (double) buffering its self. The API is just simply pass the pointer from app to usbd.

IMHO, this would not be useful for audio alone! As @HiFiPhile mentioned, CDC would also benefit from this which is a perfect application for a...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

how do you set up a DMA toward I2S peripherals, I don't do audio so any simple virtual code would help.

In TX case it's normally done with the DMA half finished IRQ.

void I2S_TxCpltCallback()
{
  // second half finished, filling it up again while first  half is playing
  FillBuffer  (&(buffer [I2S_BUFFER_SIZE  >> 1]), I2S_BUFFER_SIZE >> 1);
}

void I2S_TxHalfCpltCallback()
{
  // first half finished, filling it up again while second half is playing
  FillBuffer  (&(buffer ...
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New comment on pull request #754: Add DFU Class per Version 1\.1 Spec 
1. Could you simplify the `dfu_mode` to just `dfu` (both in API and file name). I think it will be simpler and easier to read. If you think it is too much of a hassle, then I could help with the rename

I can do this. It's funny that you asked for that. When I separated the RT and DFU mode portions I had everything named DFU, and then added MODE so it was consistent with RT. I will change things from dfu_mode to dfu as I go through the rest of your comments.

2. As part of ad...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #754: Add DFU Class per Version 1\.1 Spec

I can do this. It's funny that you asked for that. When I separated the RT and DFU mode portions I had everything named DFU, and then added MODE so it was consistent with RT. I will change things from dfu_mode to dfu as I go through the rest of your comments.

Actually, I meant to split the runtime from the actual DFU mode, have them as separated drivers. Though words can be misleading, English is not my 1st language after all. That is ok if you don't want to make the rename, I could do i...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New branch created: edpt\_ISO\_xfer
#
PanRe
[hathach/tinyusb] New branch created: uac2\_fix\_cs\_as\_int\_alt\_set\_0
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I think what you sketched above is a speaker application, what i always have as RX case in mind (since the MCU is receiving...). Is that so?
Ok, so in a first step i would setup some function get_ep_in_ff_handler(), get_ep_out_ff_handler(), get_support_ff_xy_handler(), such that the user can use them as required?! I will setup a new branch for this when i find the time!

fallow birchBOT
#
CraigHutchinson
[hathach/tinyusb] Issue opened: #799 No callback for Application to handle DCD\_EVENT\_BUS\_RESET

During an EMC test the USB bus event DCD_EVENT_BUS_RESET is triggering. However the application code is using the callbacks to determine the line state of as CDC device.

As no callback event occurs the application cannot detect this event. The application must explicitly poll tud_cdc_connected() as a workaround which is not ideal.

https://github.com/hathach/tinyusb/blob/c5f440a6aa39a09487000e7ce408d252dc7641f0/src/device/usbd.c#L466

I am not sure if there needs to be a new callbac...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I think what you sketched above is a speaker application

Yes, That's for TX case.

Something like

tu_fifo_t* tud_audio_get_rx_fifo(uint8_t itf)
{
    return &_audio_itf[itf].rx_ff;
}

Should be enough in first place. Then depending if really needed we can add callback if fifo count is over/under watermark.

I'm also thinking about enhancing tu_fifo_get_linear_r/w_info by returning both (wrapped part) pointers in one call.

  • Some DMAs, ex. in SAMDx, SAME70, E...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@HiFiPhile @PanRe thank for the code, to be honest I don't have much clues on these audio things. It probably depends on you two for the implementation. I will try to make it as portable as possible for other MCUs later on as follow up PRs. That is the main reason, I would suggest to keep all the new changes within audio and stm32.

Yeah, it is true that most DMA capable DCD can schedule multiple transfer at the same time, but that is not portable. I once included the API for such things....

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I'll update DMA & tusb_fifo on SAME70 when I have time.

Yeah, it is true that most DMA capable DCD can schedule multiple transfer at the same time, but that is not portable. I once included the API for such things.

You are ahead of me :) I agree we don't need an API for such things, I only want to transfer all the data in once in dcd_edpt_xfer_fifo.

fallow birchBOT
#
fate100
[hathach/tinyusb] New comment on issue #611: Half of the data accepted by running uac2\_headset using esp32s2 is lost

I used the new driver to try the uac2_headset example again, but when I run it on the computer(windows), the USB Audio driver does not work properly, so I canโ€™t find the TinyUSB Device.
In addition, I also tried to use esp32s2 to run audio_test, but it also failed to start the device.
I suspect there is something wrong with the descriptors, but I am not very clear about the USB_Audio protocol.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
dhalbert
[hathach/tinyusb] Issue opened: #802 tud\_hid\_descriptor\_report\_cb\(\) does not provide the length of the report descriptor

The HID report descriptor is supplied dynamically by tud_hid_descriptor_report_cb(), but the length is not passed back. The report descriptor does not include its own length. The length has to have been set previously in p_hid->report_desc_len. It is set in hidd_open(), since the length must be set in the HID descriptor (not the HID report descriptor).

I am not sure what the utility of this callback is, then. You could substitute an HID Report Descriptor of identical length, but that...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New branch created: audio\_make\_dma\_ready
#
PanRe
[hathach/tinyusb] Pull request opened: #804 Implement functions to allow for DMA usage in audio driver\.

Describe the PR
Follow the discussion in #593, this attempts to implement functions to allow for DMA usage in audio functions.

  • Add tud_audio_n_get_ep_out_ff(), tud_audio_n_get_ep_in_ff(),
    tud_audio_n_get_rx_support_ff(), and tud_audio_n_get_tx_support_ff()
  • Change get_linear_read/write_info() to return linear and wrapped part
    at once
  • Adjusted affected code in audio_device.c and tested with
    audio_4_channel.
fallow birchBOT
#
PanRe
[hathach/tinyusb] New branch created: edpt\_ISO\_xfer
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: lpc55\-port1\-hs
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #808 Lpc55 port1 hs

Describe the PR
This PR implement Port1 Highspeed for lpc55 and lpc546xx/lpc540xx (not tested on actual hardware). There is a few gotcha

  • LPC55 highspeed usb can only write/access to USB RAM (0x40100000), attribute((section("m_usb_global")))
  • USB RAM does not support unaligned access despite it is cortex M4. Extra macro TUP_MCU_STRICT_ALIGN is used to overwrite ARCH one, extra effort is also needed to prevent compiler to generate optimized code that result in unaligned acces...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #807: mcu\-link: Board support for MCU\-LINK with LPC55S69JBD64

That is why I asked. The MCU-Link board only comes with the SWD controller header loaded. The debug header for the local LPC55 is empty on the back. I'll try to add MCU-Link to TinyUF2, but I probably can't get to it until June.

There is actually no need to add mcu-link to tinyuf2. Tinyuf2 is meant for maker like you to ease the boards making. Evk is just convenient board that most people will have on their desk, so it got supported. Mcu-link is an nice cheap dev board, people use this ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
torstenmay
[hathach/tinyusb] Pull request opened: #809 Esp32s2 \- make net lwip webserver workable

Describe the PR
I made the example workable on esp32s2 dev board - saola.

What has been adapted:

  • use cmake system
  • use esp-idf sdk config
  • fix queue handling as the old implementation caused a dead lock.
  • ip_addr_t -> ip4_addr_t
  • There is still some #if 0 ... #endif and I need some input how to adapt this correctly.
  • I switched of fthe webserver. Question: Should I simply port to the already available webserver inside esp-idf?

Additional context
https://github.c...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #804 Implement functions to allow for DMA usage in audio driver\.

thanks @PanRe for another great PR. Sorry the in cross include between pico and fifo is getting out of control. I temporarily fixed it by alternating the include order a bit and push the update. Will definitely fix it more properly later on with an overall include revise.

Except from that, I have an a couple of feedback, that I think we could simplify the API for the read/write buffer info. Let me know if that makes sense to you.

#
hathach
[hathach/tinyusb] New review comment on pull request #804: Implement functions to allow for DMA usage in audio driver\.

nice idea, It could simplify the application usage for these direct buffer access. Though the name is not quite right since it is used for both read/write. Please change it to tu_fifo_buffer_info_t . I think the member name should be changed as well to simply buffer1 and buffer2, the lin/wrap will cause user question for those that aren't familiar with fifo implementation.

typedef struct
{
  uint16_t len1                      ; ///< length in item size of first buffer
  uint16_...
#
hathach
[hathach/tinyusb] New review comment on pull request #804: Implement functions to allow for DMA usage in audio driver\.
  1. Do we ever need to use offset. If not I think we can drop that parameter for a simpler code.
  2. I think we could just drop n as well, just return len1 and len2 as it is available from buffer. This API would be like query the current buffer state of the fifo. And we could rename function to tu_fifo_get_read_info() or tu_fifo_get_read_buffer_info()
  3. As general of thumb, we shouldn't return a struct object (> 4 bytes), it should be passed from application to fill out data. Functi...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-lpc15
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #810 Fix lpc15

Describe the PR

  • Tested lpc15 working, it can still has issue getting usb started, probably due to some PHY, clock setup stable/delay issue. walkaround is flash it a couple of time until it works. Will look further later on if there is a need.
  • Move lpc15 into its own family
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-lpc54
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #804: Implement functions to allow for DMA usage in audio driver\.

I don't know if offset will be needed or when the offset came up the first time... we can remove it completely from the fifo.c, i.e. also from the write and read functions.

Yeah, I think offset is is kind of needed for peek_at() initialy, which is trivial with initial implementation. Though If needed, we can just removed the peek_at(offset), and just implement peek() to look at current index only. peek_at random offset is not used by any class driver/application so far. So we don't rea...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #804: Implement functions to allow for DMA usage in audio driver\.

Ok i have but one question, the first time i implemented the get_read_info() i did it without struct but with poiners get_read_info(* uint16_t len_1, * uint16_t len_2, ...). However, the CI compilers complained, that len_1 etc. were potentially uninitialized and aborted with an error. To fix this, i came up with the struct at the very end. Now, if i change it to get_read_info(* buffer_info into), then i bet the compiler complains again. This would force the user to always init the str...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

from my point of view, USB DFU will be only used as transport layer as bootloader. There are probably more transport such as cdc/uart/msc/hid as well. What DFU should do is invoked callback when receiving the final packet tud_dfu_device_data_done_check_cb. That would be then up to application/bootloader to decide whether it want to perform checksum and reset to app or failed the DFU. For BUS_RESET, I think we just treat it as data reset for now.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

Yes, so this concern one of my prior comments. I am very open to changing it, but here is some background for how it came to be.

I opted for the current setup where there is a very verbose state machine, but it is explicit in the behaviour to expect on any given request. An earlier iteration had all behaviour inside of dfu_moded_control_xfer_cb. This was incredibly difficult to follow, since each request ended up containing a switch for every single possible state, where most resulted i...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

This firmware check determines whether a DFU_GETSTATUS results in dfuMANIFEST, signifying that the firmware is invalid/inprogress, or dfuIDLE if manifesting was completed, from table A.2.7 in the V1.1 spec.

WIth the other changes made, primarily the reset behaviour, the manifestation portions don't really offer anything anymore.
If the class is only responsible for the setup and transfer of firmware, and we want to leave it up to the application for the rest, then the manifestation can be...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Makurisan
[hathach/tinyusb] New comment on issue #812: Stack with usb hub and keyboard doesn't enumerate completeley

Set Up

  • PC OS
    Windows 10
  • Board*
    Samg55
  • Firmware
    4 Port Hub with keyboard attached

Describe The Bug
If I attach the Hub and the keyboard the enumeration stops at GetDeviceDescriptor
To Reproduce

tusb_init(); // initialize tinyusb stack

while (true) {
	tuh_task();
}

Steps to reproduce the behavior:

  1. plug in the hub
  2. plug in the keyboard
  3. See error stop on GetPortStatus

Screenshots
![image](https://user-images.githubu...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #754: Add DFU Class per Version 1\.1 Spec

Yeah, that is the approach. Bootloader application is the one in charge of performing checksum, jump app. From my experience working with a couple of bootloader project tinyuf2 and Adafruit_nRF52_Bootloader . DFU class will only be one of supported transport together with msc (drag and drop firmware), HID, WebUSB, CDC, or even BLE/WIFI OTA. Typically each transport will let the bootloader know when...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #804 Implement functions to allow for DMA usage in audio driver\.

superb ! Thank you for your effort, great PR as usual. the removal of offset make the whole fifo API much cleaner any easier to read/understand. FIFO should be supported offset (random) in the first place. It is my bad to introduce such operation with peek (since I thought it could be handy). Should user need to peek randomly, the new get_read_info() can be used to do it. I have a couple of minor clean up, along with a couple of unit test for new read/write info will push and merge it asap.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #812: Stack with usb hub and keyboard doesn't enumerate completeley

Thanks for updating the issue following the template. The SamG55 host driver is unfortunately not supported yet. I am surprised that you could get this far. Are you implementing the host driver locally. Looking at the log, look like the stack could recognize the hub and usb device attach event and able to communicate up to getting 8 bytes of device descriptor. The code that run up to the log is at https://github.com/hathach/tinyusb/blob/master/src/host/usbh.c#L745.

  1. Did you implement the...
fallow birchBOT
#
Makurisan
[hathach/tinyusb] New comment on issue #812: Stack with usb hub and keyboard doesn't enumerate completeley
  1. No I didnt implement or changed on hcd_frame_number.
  2. Yes, I do it if I saved my tests.
  3. Yes, I did test it with different hubs but always the same result.

I come nearer to the problem. In the file usbh.c at line 739 you initiate the reset after the 8 byte descriptor and normally the enumeration comes back with SetAddress after the second reset. This does not happen. What happens is that the stack blocks. I see on the code that you have had problem with the Reset and therefore...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #812: Stack with usb hub and keyboard doesn't enumerate completeley

@Makurisan try to implement the hcd_uframe_number(), it is probably the issue, the reset must stay long enough. Your problem wihtout implement it is

  1. osal_task_delay() (based on frame number): is not last long enough
  2. tuh_task() is called, but the port change status is not occurred yet. This may mess up with the follow up call.

hcd_uframe_number() is easy to implement, just return the current micro-frame number. Since SAMG is full-host, you need to multiple norma frame number it wit...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New comment on pull request #754: Add DFU Class per Version 1\.1 Spec

I added an example app for review. I added a separate example, rather than updating the RT example. The reason for this was to avoid requiring that the app reboot/support dynamic configuration (my device does not). dfu-util will give a warning that the device already is in dfu mode, but will still perform the upload or download requested.

I unfortunately do not have my platform ported to run within the TinyUSB repo so I was unable to test, as we discussed earlier. I have tested upload ...

fallow birchBOT
fallow birchBOT
#
arilink
[hathach/tinyusb] Issue opened: #818 Can TinyUSB support STM32 G series chips?

Set Up

  • PC OS e.g Ubuntu 20.04 / Windows 10/ macOS 10.15
  • Board e.g Feather nRF52840 Express (if custom specify your MCUs)
  • Firmware e.g examples/device/cdc_msc

Describe The Bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. See error

Screenshots

If applicable, add screenshots, bus capture to help explain your problem.

Log

If applicable, p...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
corvus-ossifragus
[hathach/tinyusb] Pull request opened: #822 Issue \#709

Revert a change that was made to rp2040_usb.c that causes slow speed devices to not get configured by the host. It seems likely it is the same as Issue #709.

A low-speed mouse that works with the old TinyUSB source code in the Pico SDK does not work with the latest master from the main repo. This pull request reverts the change that causes this problem. After this line is changed, the mouse works with either version of code.

The reverted change limits the entire data transfer to only 8...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #822 Issue \#709

This has conflict with usbd ISO transfer, which can have max packet size of 1023 #657

The reverted change limits the entire data transfer to only 8 bytes for low-speed devices, not just the data packets. So, when the higher level logic requests the 18 byte Device Descriptor, this line of code reduces it to 8 bytes. Lower-level code requests an 8 byte IN packet and signals Last Transfer to the USB controller. Higher-level code may then try to request the remaining 10 bytes, but whatever h...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: minor\-cleanup
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #827 audio\_device: Fix build error

ep_in_as_intf_num was incorrectly used to access out interface
which is defined for 'in' interface.
Code related to 'out' endpoint should use ep_out_as_intf_num instead.

Describe the PR
Speaker only devices would not build due to incorrect variable usage.
Probably in/out devices would use incorrect variable even if there is no build error.

Additional context

fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #829 Allow build for NRF5340 MCU

Describe the PR
There is not definition NRF_USBD in NRF5340 headers.
There is however NRF_USBD definition in both cases
NRF52 has:

#define NRF_USBD                    ((NRF_USBD_Type*)          NRF_USBD_BASE)

and NRF5340 has:

#define NRF_USBD         NRF_USBD_S
#define NRF_USBD_S                  ((NRF_USBD_Type*)          NRF_USBD_S_BASE)

When common definition is used file can be build for both families.
Additional context

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #829 Allow build for NRF5340 MCU

we need to cast the NRF_USBD to uint8_t* first before doing arithmetic operator on it. Though It probably cause gcc to throw warning when casting back to uint32_t* (cast that increases alignment). I think it probably better to have ifdef to unify the base name.

Note: I notice that the base address for secure and non-secure is different as well, one thing we need to keep it in mind later on.

fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #829: Allow build for NRF5340 MCU

we need to cast the NRF_USBD to uint8_t* first before doing arithmetic operator on it. Though It probably cause gcc to throw warning when casting back to uint32_t* (cast that increases alignment). I think it probably better to have ifdef to unify the base name.

Note: I notice that the base address for secure and non-secure is different as well, one thing we need to keep it in mind later on.

Missing cast fixed.

For now errata 166 does not apply to NRF5340 so whatever you choos...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #829: Allow build for NRF5340 MCU

yeah, just quickly check the 53 errata, not only 166 but all of other errata is not needed for 5340 as well. I think it would be better if we could wrap these errata walkaround with #ifdef NRF52_SERIES. I have push to update the PR. Please let me know if it work on your hardware.

I actually have an PDK 5340 here, but too bad, it doesn't have USB connector populated on the board (!!). I will try to solder one and test it out later on. Though It seems like 5340 revA doesn't have working US...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
corvus-ossifragus
[hathach/tinyusb] New comment on pull request #822: Issue \#709

I was thinking about this issue, and it seems like a low-speed device is very unlikely to be doing ISO transfers. So, it may not be pretty, but maybe something like this until a better solution is found:
ifย (TUSB_SPEED_LOW==tuh_device_get_speed(ep->dev_addr))
ย {
ย ย ย ep->transfer_sizeย =ย total_lenย >ย 64ย ?ย 64ย :ย total_len;
ย }
ย else
ย {
ย ย ย ep->transfer_sizeย =ย tu_min16(total_len,ย ep->wMaxPacketSize);
ย }
โ€‹

May 8, 2021, 4:19 AM by @.***:

@hathach> commented on this pull request.

...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #822: Issue \#709

I was thinking about this issue, and it seems like a low-speed device is very unlikely to be doing ISO transfers.

I think isochronous transfers are not allowed on low-speed busses:

USB 2.0 spec 5.12.6:

These requirements limit isochronous transfers to full-speed and high-speed
devices only, because low-speed devices do not see SOFs on the bus.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #822: Issue \#709

Low speed device only support interrupt transfer, however as mentioned above this is out of specs from rp2040 hcd. I would like to look at the datasheet and test it out before making the changes. The reason is doing 64 bytes transfer on 8-bytes buffer can cause buffer overrun and could corrupt other part of memory.

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #832 Skip allocate hardware fifo for CDC notification endpoint with esp32s2

Is your feature request related to a problem? Please describe.

ESP32-S2 has only 5 available endpoint-in FIFOs (including EP0) but 7 available EP IN numbers. In normal CDC virtual com, notification endpoint isn't used, we can save in fifo by enabled but not allocate fifo for it.

Describe the solution you'd like

A sensible/portable way to on/off this feature without too much breaking in the cdc driver.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-hid
fallow birchBOT
#
dhalbert
[hathach/tinyusb] Issue opened: #835 Please provide all details at least for Setup/Describe/Reproduce

The signature of tud_hid_report_complete_cb() is

void tud_hid_boot_mode_cb(uint8_t itf, uint8_t boot_mode);

However, the boot_mode argument is a bool taken from:
https://github.com/hathach/tinyusb/blob/2d15e1183064a35cc646a46bddf2b82915114cc8/src/class/hid/hid_device.c#L41-L55
boot_mode is passed using this code:
https://github.com/hathach/tinyusb/blob/2d15e1183064a35cc646a46bddf2b82915114cc8/src/class/hid/hid_device.c#L338
So should the signature instead be this?
...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-835\-hid\-cleanup
#
hathach
[hathach/tinyusb] Pull request opened: #837 Fix 835 hid cleanup

Describe the PR
Fix #835 and more

  • add tud_hid_n_interface_protocol()
  • rename tud_hid_n_boot_mode() to tud_hid_n_get_protocol()
  • rename tud_hid_boot_mode_cb() to tud_hid_set_protocol_cb()
  • use HID spec protocol value for get/set_protocol() instead of bool
  • add HID_PROTOCOL_BOOT/REPORT to avoid magic number 0,1
  • rename HID_PROTOCOL_NONE/KEYBOARD/MOUSE to HID_ITF_PROTOCOL_ to avoid
    confusion
  • rename itf to instance in multiple API to have a better meaning.
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enable\-ci\-esp32s3
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kaysievers
[hathach/tinyusb] Issue opened: #843 MIDI: race condition between device enumeration/configuration and packet read

Issuing a MIDI packet read/receive from the main loop disturbs the USB device enumeration/configuration. The host reports the following:

[   74.733249] usb 1-6: new full-speed USB device number 7 using xhci_hcd
[ ย  74.849035] usb 1-6: Device not responding to setup address.
[ ย  75.051975] usb 1-6: Device not responding to setup address.
[ ย  75.260382] usb 1-6: device not accepting address 7, error -71

Blocking in the device's main loop until the USB connection is established,...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kaysievers
[hathach/tinyusb] New comment on issue #843: MIDI: race condition between device enumeration/configuration and packet read

Here is a minimal Arduino sketch which produces the failure. Blocking in setup() until USB is ready is not an option, the device needs to work without USB connected too. And it would also fail the same way if the host triggers a reset/reenumeration of the connected device.

#include <Adafruit_TinyUSB.h>

Adafruit_USBD_MIDI usb;

void setup() {
  usb.begin();

  // Add this to make it work
  //delay(500);
}

void loop() {
  uint8_t packet[4];
  usb.readPacket(packet);
}
...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hid\-host\-get\-protocol\-when\-enum
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: house\-keeping
fallow birchBOT
#
doumdi
[hathach/tinyusb] Issue opened: #847 Examples for UAC2 with multiple microphones \(array\) and multiple sampling rates

Hi,

I would like to know if it would be technically possible with tinyusb to implement a multi-channel sound card that would be useful for beamforming applications.

I was thinking implementing this with RP2040 PIO using up to 16 PDM microphones @ 16kHz. Of course, the maximum sampling rate would depend on the number of channels fitting in a 1ms USB frame.

Adding an example for this kind of application would be awesome.

Any thoughts ?

Best regards,

Dominic

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
noodlefighter
[hathach/tinyusb] Pull request opened: #849 fix uac2\_headset example

Describe the PR
fix uac2_headset example

tud_audio_rx_done_cb() is departed, replace with
tud_audio_rx_done_pre_read_cb()

Additional context
test OK on esp32s2(with patch #552 , and run tud_task() in a separate task)

test method:
generate sine wave to uac device with python script:

# refer: https://pythonaudiosynthesisbasics.com/
import numpy as np
import sounddevice as sd

sample_rate = 44100
duration = 120.0
frequency = 440.0

x = np.linspace(0, durati...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-warnings
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #851 Migrate example build to CMake ?

Is your feature request related to a problem? Please describe.
CMake seems to make thing more manageable and modulo than plain make. Would it be benefit to migrate example building and adding an CMakelist.txt to src for faster integration.

Describe the solution you'd like
make BOARD= should still work as it is, the target will thin wrapper for running cmake with build-BOARD and execute make.

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #754 Add DFU Class per Version 1\.1 Spec

superb! thank you @xmos-jmccarthy very much for the PR. I am really appreciated your effort and patient throughout the whole PR reviews. It has been a bit busy due to the release of rp2040 in recent time. And I couldn't keep up with all the fix and pr. The example work great with both download and upload. Bravo !!! :tada: :tada: . And it is good for the merge now. Later on when integrating into another bootloader, I will do more actual testing on hardware. Should there is any improvement, ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #851: Migrate example build to CMake ?

Thank you for your suggestion, to be honest, I wouldn't want to move a finger to change something that already works :smile: . Though recently both Espressif and RPi release sdk that support tinyusb, and both use CMake as build tool. I have already learned CMake the ugly way (mostly copy & paste from all over the places). Although It works for now, I get to know CMake better and would like to make the tinyusb integration more smoothly on those platform.

A quick google suggest meson is a b...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-housekeeping
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
tannewt
[hathach/tinyusb] Issue opened: #855 Split examples into a separate repo

Is your feature request related to a problem? Please describe.
I was reading #851 and thought that another maintainability change would be to move the examples and the HALs used by them to a separate repo.

Describe the solution you'd like
TinyUSB is commonly submoduled into other repos (CircuitPython, pico-sdk and esp-idf all do this iirc). Splitting the examples and the HAL code for them would make the submodule of the TinyUSB core much smaller. The projects that submodule TinyU...

#
artouste
[hathach/tinyusb] Issue opened: #856 I2S and USB Class Audio

Hello
I recently used your tinyUSB library through the PICO2040 port of earlephilhower.
It is very pleasant to use with the MIDI protocol.

Today we easily find I2S ADC modules to experiment (it starts with the small I2S microphones)
Consider adding an audio class to your tnyusb lib to be able to do I2S -> ADC -> PICO -> USB AUDIO. ?

I do not realize the work that this requires of you, but I dream of it: D

Anyway, thank you for everything you have already achieved.

phil Artouste

fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.10\.0
#
hathach
[hathach/tinyusb] New tag created: 0\.10\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-rp2040
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] Pull request opened: #859 Adaptations for Renesas CCRX toolchain and Rx72N controller performed

As discussed in #785 this a draft PR for the port of tinyUSB to the CCRX toolchain and the RX72N device from Renesas.

It is still not complete and only the CDC device class is fully ported. But I guess it is good enough for a discussion.

The following points had to be overcome for porting it to the CCRX toolchain (and the Rx72N used in my project):

  • lack of the attribute directive
    • overcome the missing weak directive
    • overcome of the missing pack directive (used a ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Thank you very much for your effort to port the ccrx toolchain. I am not familiar with renesas toolchain, does it has trial with limited functionality ( I don't need all the features), only enough so that I could test this out hand-on before merging and possibly help with tweaking the implementation.

PS: this PR come at pretty good time, my rx65n cloud kit board just come, it will come handy, I still need to get the board ported those. But it is probably similar to existing rx72n.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Yes there is an evaluation version of the toolchain available. The trial period is the 60 days from the day the first build is executed after installing an evaluation edition. After the trial period exceeded the linkage is limit to 128 KB or smaller.

Here is the link to toolchain webside : CC-RX
I use the version without IDE.

The USB HW implementation of the Rx65N is equal to the one found on the Rx72N.

B...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #862: Fix host rp2040 with low speed device

Yup, the Data Toggle (PID) is toggled every packet. Following is the scheduling 108 bytes with endpoint with max packet size = 8.

  • Buffer 0 will start with 64 then 44 as last buf
  • 64 is 8 packets starting with DATA1, each packet, DT toggled which mean after 8 packet, it is still DATA1. i.e at the 9th packet (start of 44 bytes, transaction 87 in capture), the DT should remain the same (DATA1).

![image](https://user-images.githubusercontent.com/249515/120134401-375faf80-c1f8-11eb-8597-...

#
hathach
[hathach/tinyusb] New review comment on pull request #862: Fix host rp2040 with low speed device

PS: The log is there is on purpose, since I want to work more with rp2040 hcd/dcd, what I have in my mind is:

  • Double buffering starting with host
  • Make rp2040 common usb function more primitive, currently it handles also host and device specific code, making it more difficult to fix specific issue with either host/device (like above). Also it makes it difficult to follow in my taste.
  • Host and device mode should be able to both enabled, and dynamically run depending on what the softwar...
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

The Envision Kit HW only offers the host controller functionality (on a USB-A connector). On my Rx72N Envision Kit (which is equal as the Rx65N Envision Kit around the USB HW) I had to modify my board slightly, so it could be used as a function controller (remove the ISL6186USB Port Power Supply Controller and add a resistor).

Unfortunately there is no CCRX toolchain version for Linux (I use a Windows VM on my Linux host). Only a Linux version of their e2studio IDE (this is an eclipse bas...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-hcd
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

The Envision Kit HW only offers the host controller functionality (on a USB-A connector). On my Rx72N Envision Kit (which is equal as the Rx65N Envision Kit around the USB HW) I had to modify my board slightly, so it could be used as a function controller (remove the ISL6186USB Port Power Supply Controller and add a resistor).

Unfortunately there is no CCRX toolchain version for Linux (I use a Windows VM on my Linux host). Only a Linux version of their e2studio IDE (this is an eclips...

fallow birchBOT
#
kilograham
[hathach/tinyusb] Pull request opened: #865 Pico 0\.10\.0 \(test\)

Modifications for compatibility with rp2040 (1.2.0 SDK release)

  1. Uses tinyusb-0.10.0 branch of pico-sdk for github checks (due to circular dependency - this can undone post SDK release)

  2. Rework CMake build for examples

    • Examples should be CMake buildable from their own subdirectory; such a build will error out based on
      matching .skip.MCU_xxx or a mismatched .only.MCU_
    • It should be possible to build from a higher level and use .skip.MCU_ and .only.MCU_ to filter which
      ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #862: Fix host rp2040 with low speed device

I will try to explain as much as I could, as above example total transfer = 108 on endpoint with size = 8, which is broken into 2 sub transfers, both on buffer0 since we don't support double buffer just yet.

  • xfer1: transfer size = 64, start with DATA1, packet count = 8
  • xfer2: transfer size = 44, also start with DATA1, packet count = 5

if there is ever another xfer on the endpoint, it will start with DATA0 since the packet count is odd. Total transfer is broken in to 2 sub transfer ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #865 Pico 0\.10\.0 \(test\)

Superb !! Thank you very much for making this PR. I have recently planned to migrate build system to cmake as well, to have it easier to integrate to pico-sdk and others #851. However, I have just barely read pass the introduction section of "CMake for dummies" :sweat_smile: . This will help enormously to complete the migration later on. Though there are a few notes

  1. project(tinyusb_device_examples) doesn't seem to build, maybe I am doing it in a wrong way.
  2. bsp/family.cmake and `b...
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0 \(test\)

I have an issue running this CMakelits.txt file, it throws a warning when running cmake.

$ examples/device/build$ cmake .. -DFAMILY=rp2040 -DBOARD=raspberry_pi_pico -DPICO_BUILD_DOCS=0
CMake Warning at /home/hathach/Documents/code/pico/pico-sdk/src/rp2_common/tinyusb/CMakeLists.txt:14 (message):
  PICO_TINYUSB_PATH specified but content not present.

when running make with generated project, it has several missing include

/home/hathach/Dropbox/tinyusb/tinyusb/exampl...
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0 \(test\)

tinyusb_device and tinyusb_host are defined in picosdk, it won't allow me to add more driver with more source files without modifying the sdk. IMHO, I think we should have an FLAG to determine whether it will use the tinyusb_device from pico-sdk or including raw source from this repo. Cmakelist.txt examples from pico-sdk can set this flag to compile with the specific version come with sdk.

Note: there is issue when compiling upstream examples with sdk include source, sometime the API ...

#
kilograham
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0 \(test\)

bsp/family.cmake and bsp/family/rp2040/family.cmake are easily mistaken to each other. We should either rename it to bsp/family_common.cmake or move it to examples/example.cmake. You could give it any other name as well.

Yes i was thinking the same thing... family_common.cmake is probably better, since we are perhaps now using these for things other than examples (i.e. they would be used by the SDK tinyusb cmake build for peoples' own tinyusb based code too)

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #862: Fix host rp2040 with low speed device

correct

That isn't the case here, the controller is very smart to toggle the PID every packet as shown in the captured which is actual capture to develop this PR. We only need to write the correct initial PID.

You can either limit the ep->transfer_size to do several 8 byte transfers. OR you can start a 64 byte transfer in low speed mode and the hardware will flip the PID for you every 8 bytes.

I tried both way, both works. Actually the code used to limit transfer_size at 8 (max ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

yeah in the SDK build i skip the board name... i assumed you guys wanted it when building from build-family.py, but if not yes we can remove

Ok, please just remove BOARD from the project name, once this is merged, i will update the gnumake build to match as well.

Yes i was thinking the same thing... family_common.cmake is probably better, since we are perhaps now using these for things other than examples (i.e. they would be used by the SDK tinyusb cmake build for peoples' own tinyu...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

Except for this, I think the PR is ready for merge. In general, pico-sdk and tinyusb should not reply too much on other cmake defines/variable, that would make it easier to change in both sides without affecting others. I could imagine to do quite a bit of work with cmake when migrating all other ports to cmake in the future (just need to fix pending bugs first).

#
hathach
[hathach/tinyusb] Pull request opened: #868 Clean up Host HCD API

Describe the PR
Clean up , update some of host HCD API. Still there is plenty of host work.

  • remove obsolete hcd_pipe_queue_xfer()/hcd_pipe_xfer()
  • update hub driver
  • change hcd hcd_uframe_number() --> hcd_frame_number() , micro can be retrieved by optional API on high speed host if needed.
  • Update, fix endpoint number and transfer size on OHCI driver.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

Note also, I was not planning to futher disambiguate the builds for this SDK release (which is super imminent), so I'd prefer to merge this as is so that upstream tinyusb is compatible with (and can be merged into the raspberry-pi version by users wanting new stuff) until we fix in a point release. You've already released 0.10.0 anyway

fallow birchBOT
#
zhangslice
[hathach/tinyusb] New comment on pull request #867: porting the tinyusb on MM32 MCU

OK, I'll modify it and upload it again

------------------ย ๅŽŸๅง‹้‚ฎไปถย ------------------
ๅ‘ไปถไบบ: "hathach/tinyusb" @.>;
ๅ‘้€ๆ—ถ้—ด:ย 2021ๅนด6ๆœˆ1ๆ—ฅ(ๆ˜ŸๆœŸไบŒ) ไธ‹ๅˆ5:57
@.>;
@.>;"State @.>;
ไธป้ข˜:ย Re: [hathach/tinyusb] porting the tinyusb on M...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

I think the example in this repo should always built with relative path to this code

I've lost track of the context for this ; what relative path of what code?

I mean path to /src from the example.

Note also, I was not planning to futher disambiguate the builds for this SDK release (which is super imminent), so I'd prefer to merge this as is so that upstream tinyusb is compatible with (and can be merged into the raspberry-pi version by users wanting new stuff) until ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #869: Add MM32 SDK and USB driver

The following repository can be used, and the SDK will be updated if there are any updates or additions https://github.com/zhangslice/mm32sdk

thanks that repo would be useful, I notice that both Keil_core and IAR_Core within the cmsis is the same, without any file differences. you should just have it as CSMSIS/Core https://github.com/zhangslice/mm32sdk/tree/main/mm32f327x/CMSIS

do you want to merge them together ? I am fine If you still want to keep it that way though.

#
zhangslice
[hathach/tinyusb] New comment on pull request #869: Add MM32 SDK and USB driver

Well, thank you, that's a good suggestion

------------------ย ๅŽŸๅง‹้‚ฎไปถย ------------------
ๅ‘ไปถไบบ: "hathach/tinyusb" @.>;
ๅ‘้€ๆ—ถ้—ด:ย 2021ๅนด6ๆœˆ2ๆ—ฅ(ๆ˜ŸๆœŸไธ‰) ไธ‹ๅˆ2:24
@.>;
@.@.>;
ไธป้ข˜:ย Re: [hathach/tinyusb] Add MM32 SDK and USB driver (#869)

...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

@kilograham seems like you have issue with ci when moved to this. I take this requirement back. Please revert those moving commits if you still want it. I will merge the PR as it is previously (cmake source list in sdk), then make a release to 0.10.1.

I could follow it up to change later on. I need to update the cmake build anyway. you are probably working too much already on sdk 1.2.0. What do you say ?

fallow birchBOT
#
kilograham
[hathach/tinyusb] New review comment on pull request #865: Pico 0\.10\.0

almost fixed the issues - been busy with other stuff (which were unrelated - more to do with pico-examples maybe not having tinyusb/lwip sub module initialized in which case we shouldn't build lwip examples).

If we keep the lists separate, then there is no guarantee that things are in sync... so it is a bit of 6 of one a dozen of the other. You aren't going to unilaritarily break the SDK build any more than if you were to commit a bad tinyusb other change. We only pick it up a specific com...

#
kilograham
[hathach/tinyusb] New comment on pull request #865: Pico 0\.10\.0

Superb !! thank you very much for your effort. Everything is perfect. Please let me know if want to merge it now (or having any pending works).

I think i'm happy too; thanks. I also finally understood your other change (my brain was not in the context of USB enough :-) )

Let me know if it is easy to make a new tinyusb patch release, or whether i should just make one in raspberrypi

#
hathach
[hathach/tinyusb] New comment on pull request #865: Pico 0\.10\.0

Superb !! thank you very much for your effort. Everything is perfect. Please let me know if want to merge it now (or having any pending works).

I think i'm happy too; thanks. I also finally understood your other change (my brain was not in the context of USB enough :-) )

Let me know if it is easy to make a new tinyusb patch release, or whether i should just make one in raspberrypi

I will write some changelog and tag a release as 0.10.1 in a few minutes.

fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.10\.1
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
robert-rozee
[hathach/tinyusb] Issue opened: #872 CDC hardware flow control can not be disabled

in a particular user case i need to be able to disable CDC hardware flow control at the device end. it is not practical for the host end to simply assert DTR due to the need for backwards compatibility with other software. the feature i'm requesting is a flag to disable hardware flow control that is exposed via the api.

fyi, the hardware i working with is an RP2040.

my proposal is a bit of a hack, i'd welcome better suggestions. in class/cdc/cdc_device.c make the following chan...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] Pull request opened: #874 Add dcd\_edpt\_xfer\_fifo\(\) for RX63N

Describe the PR
Add dcd_edpt_xfer_fifo() for RX63N.

Additional context
I have confirmed this patch by using uac2_headset example. On the example, it seems that ISO IN/OUT are succeeded. But, many packets are dropped because performance issue.

audio_test has some issues. audio_test fails enumeration process. In windows 10, I needed to set 44100 into AUDIO_SAMPLE_RATE for enumeration process success. But enumeration is success, I have no observation regarding ISO IN transf...

fallow birchBOT
#
Algolian
[hathach/tinyusb] New comment on issue #858: HID Keyboard Endpoint Descriptor can not be according to standard causing \-EOVERFLOW\.

Now raspberry have updated the SDK so I think im on latest and gratest.
It is very easy to reproduce with hid_composite example.
Apply this little change:
Subject: [PATCH] Buffer overflow demo

This chages the endpoint buffer size from 16 to 8.
This is what usb keyboards when they are hid keyboard.

examples/device/hid_composite/src/tusb_config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/device/hid_composite/src/tusb_config.h b/examples/device...

fallow birchBOT
fallow birchBOT