#tinyusb

1 messages · Page 13 of 1

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

@hathach is it possible that instead of deciding based on DTR, actually to use the fact that data has not been sent/fifo is not empty? Or just leave it up to the application (returning 0 if no space available). I also have a case where DTR/RTS lines are used for different things and we need to communicate with the other end even when lines are low. The application itself can detect that the other end is alive, but bytes can not be sent in any way. (Actually one packet comes, proving connectio...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

If I want to create a transparent USB-UART bridge to use for flashing ESP devices, the app needs to handle particular DTR/RTS changes that will trigger the target to reboot in the proper mode, after which it needs to communicate with the target. Unfortunately the last change leaves both RTS and DTR low and further communication is impossible.

All starts as expected with both lines to high and baudrate update, then the series of 4 line changes are issued (while connected).

I still ...

robust walrus
#

the calibration numbers look suspicious

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #454: ESP32\-S2: Handle the fact that available EP IN FIFOs are less than the number of available EP INs

How will you force something like that only on one platform? Surely both ways would work. And yes, I totally agree that it's really weird that endpoints and fifos do not match, especially since you can split the whole fifo memory to more than 5... but :) next silicon I guess. I will be looking into DMA as well, as that is something that can remove the limitation.

We can bring up this PR when using DMA, though that may take long time since current contributors seems to be happy with FIFO ...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Here is the signal flow of such upload process:

  • Line State: DTR:1, RTS:1 (Connected)

  • Line Coding: baud, etc.

  • Reset Target

    1. Line State: DTR:0, RTS:1 (Disconnected)
    2. Line State: DTR:1, RTS:1 (Connected)
    3. Line State: DTR:1, RTS:0 (Connected)
    4. Line State: DTR:0, RTS:0 (Disconnected)

  • Send the firmware (but TinyUSB thinks we are disconnected, so it fails)

  • Line State: DTR:0, RTS:0 (Disconnected)

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #454: ESP32\-S2: Handle the fact that available EP IN FIFOs are less than the number of available EP INs

Maybe we could try to figure out how to tell DCD to skip FIFO assignment in portable fashion, then we could merge this PR.

I could not come up with one :(
Endpoints are opened as they are found in the descriptors (as far as I understand the flow), so in order for endpoint to not be opened, it have to be somehow designated by another api call or something. Or... can we define the EP transfer size as 0 in the descriptor and have the dcd not open it? or not assign fifo? Would that still wo...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #454: ESP32\-S2: Handle the fact that available EP IN FIFOs are less than the number of available EP INs

I don't like to add code that didn't run at all

Do you mean that you do not expect this to be ever needed? Because this code will run the same on STM (no reason fifo number to be the same a EP number. Designation is so internal that 99% of the dcd code do not care for that fifo number) and will run in more cases on ESP32S2. This is for the case where descriptors for multiple drivers are predefined by an upper layer library and loaded when necessary. You can fit into 6 endpoints constant ...

fallow birchBOT
#
ktemkin
[hathach/tinyusb] Pull request opened: #462 add BSP for Great Scott Gadgets' LUNA boards \(SAMD21\)

Describe the PR
This pull request adds support for Great Scott Gadget's LUNA USB multi-tool, which features a USB-attached SAMD21 "debug" microcontroller.

Additional context
LUNA hardware/software repository: https://github.com/greatscottgadgets/luna
More information about LUNA: https://luna.readthedocs.io/en/latest/

(The board uses a DFU bootloader; the linker script provided here places all device binaries after the protected boot region.)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check
  1. No, it is not in bootloader yet. The toggles interface with two fets to toggle RST and IO0 in the proper sequence to reset to bootloader. In reality a few milliseconds later is when the target is in bootloader.
  2. If we toggle the lines again, they will reset the target back into the firmware

Ok, so after a few ms of state iv, the device reset into bootloader. Why setting DTR to 1 again while in bootloader cause esp32s2 reset into application ? If I manually holding GPIO0 to force...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

If I manually holding GPIO0 to force bootloader mode, and then connect with another terminal, it will also set the DTR to 1 as well, in that case would it reset to app upon connection as well ?

My English level did not help me understand what you mean? If you manually hold IO0 and connect from another terminal (just regular terminal, not esptool) on connect the chip will enter bootloader.

Ok, so after a few ms of state iv, the device reset into bootloader. Why setting DTR to 1 again...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

because of the resulting switches of the fets. Any toggle of DTR at this point will cause the reset. Here is a schematic of such circuit:

OK, I am not good with hardware, so I am still failed to understand why DTR cannot be set again. It is native USB connection, DTR/RTS are software control line state and are not necessary hard-writed to anything. In my point of view, DTR is used to indicate active connection, you are using it for different purpose as hardware hack, and it is not reall...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

I get your point, but regular USB UARTs do not prevent the data flow when toggling the lines, therefore we have been using this for the last 6 years (as far as I remember, not sure for longer). I am not sure if this is a hack really, we have APIs to control the lines in all operating systems.

Could this just be made optional? So schemes where lines need to switch and data needs to flow can be handled?

#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

I get your point, but regular USB UARTs do not prevent the data flow when toggling the lines, therefore we have been using this for the last 6 years (as far as I remember, not sure for longer). I am not sure if this is a hack really, we have APIs to control the lines in all operating systems.

Could this just be made optional? So schemes where lines need to switch and data needs to flow can be handled?

sure, It is totally possible, however the stack will loose the ability to detect...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

This is not an S2 upload scenario. This is the scenario where we use an S2 just like Arduino uses ATMega chips for USB-UART and the S2 is just acting as USB-UART and passing data/toggles through to the target ESP (can be any ESP model. they all work the same).

In this case the application is well aware of when it is connected and when not, but we can not tell tinyusb that. Flush is the only issue. If we were just to receive data from the host and not need to talk back to it, it would have ...

#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

This is not an S2 upload scenario. This is the scenario where we use an S2 just like Arduino uses ATMega chips for USB-UART and the S2 is just acting as USB-UART and passing data/toggles through to the target ESP (can be any ESP model. they all work the same).

I see, seem like we are talking about totally different thing from the start. Could you explain it all again starting with the schematics. If you intend to use ATMega, you should probably want to use LUFA since TinyUSB doesn't supp...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

We intend to use ESP32-S2, not ATMega. ATMega was just an example that the Arduino guys use on their boards.

Schematics are irrelevant to the point where they are the reason why esptool sends those particular line changes. In the resulting application where we use the S2, we can handle that in software without transistors on the other end. They are necessary only on boards that use regular USB-UART chips.

The application schematic is one S2 with USB, directly connected with RX/TX/EN/IO0...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

The application schematic is one S2 with USB, directly connected with RX/TX/EN/IO0 to the target ESP on the board (the ESP that will run the user applications and have antenna etc.).

Goal is the S2 to act just like any other FTDI, SiLabs, etc. USB-UART chip and pass transparently RX/TX and LineState changes. Everything is working as expected, except tx flush, because the last LineState that esptool sends before starting communication with the bootloader, leaves DTR low.

I see, so ...

#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

@duempel after a lengthy discussion with @me-no-dev (there is a bit of misunderstanding at firs), you could just read the last 2,3 comments. I think there is actual a scenario where this option is a must. The DTR/CTS are used as proxy singal controlling to another target MCU pins rather than its original meaning of connection detection. in Arduino schematics, DTR is mostly connected to target mcu reset. Let's me know if you have any other opinion, otherwise, I think we can merge this PR.

fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Thanks @me-no-dev and @hathach for bringing up this PR again. I've followed your conversation the last days but was too busy to leave any comments.
I think it is important to get CDC working without DTR being set. The example @me-no-dev gave is just one of the reasons. There are a lot of proprietary software solution which do not set this bit as it should. I just run into this trap again when changing USB middleware of an existing project to TinyUSB for development cases. There will be a lot...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

But I am not sure if a define is a good way to ignore DTR. I was reviewing CDC implementation and think that the way we are currently checking tud_cdc_n_connected within tud_cdc_n_write_flush is not very useful.
Problem: DTR bit should be used to check if the data terminal is ready and able to receive new data. If DTR is not set and we send out the data, we can lose all of it, because we don't know if the terminal will take the data or not. But with our current implementation the...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

But we could tweak it to overwrite FIFO when DTR is not connected, and keep holding data in FIFO as long as possible.

This is a pretty good idea. If I understand you correctly we just have to set

p_cdc->tx_ff.overwritable = dtr?0:1;

within control request (e.g. here). This will enable that we can still write data to the buffer, even if we do not transfer them (in case no IN token are being reque...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

I just tested the behavior with one FTDI chip and also with STLink Virtual COM Port of Nucleo board. The FTDI seemed to never store and send old data after starting a new connection.

Personally I prefer the FTDI behavior, maybe it's not a big thing but in some case we may have data leak problem if we store old data.

But with the ACM model it could be difficult to detect the connection state without DTR.

FTDI is custom usb2uart, they wrote both PC driver and firmware, they...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Yes, as @hathach said the FTDI driver have much more possibilities to detect connection and disconnection events. I see a lot of control packets for connection management here.
But I think the way we want to go now is just fine. Every user can decide on his own if he wants to implement DTR checking for his application or not.

Let's me know if you have anything to add to my above proposed approach. CDC is most used interface, hopefully the changes won't break other project.

Maybe an o...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: improve\-highspeed
#
hathach
[hathach/tinyusb] Pull request opened: #464 Better support highspeed mode

Describe the PR
HS device can operate at FS mode e.g plugging into FS host. Therefore actual link speed should be checked when returning configuration descriptors and/or other related scenario when there is difference between fs/hs mode.

  • add tud_speed_get()
  • define both fs and hs configuration descriptor
  • rename CFG_TUD_CDC_EPSIZE to CFG_TUD_CDC_EP_BUFSIZE with default size of 64 for FS, and 512 for HS
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Maybe an option for fifo overwriting would be a nice feature to keep consistency? Something like CFG_TUD_CDC_DISABLE_UNCONNECTED_BUF_OVERWRITING with a shorter name . But this is just optional since write_available API can handle it.

IMHO, TX fifo must not be overwritten when we know there is client connected to drain data. Since most of the time, application will just call write() and check the written_bytes. Disabling overwrite will definitely cause loss of data for lots of current p...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

@hathach I think there is a misunderstanding. Currently overwrite is always disabled. Because current projects are not overwriting the buffer, I asked for an option which just optionally disables 2. of your comment to keep behavior as it was before.

Changes of behavior:

  • If DTR bit is set new and old implementation will work the same
  • If no DTR is set, flushing of both implementation will remove data from fifo, but...
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Thanks @HiFiPhile but since the new discussed implementation would differ from this PR's description I think it's better to open a new PR for this.

Maybe we can just merge this PR in the first step, as @hathach already wanted to here. Since this is a very easy concept and will not bring any other issues up to existing applications.

I could then create a new issue to discuss about other possibilities. Let's wait what @...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Thanks @HiFiPhile but since the new discussed implementation would differ from this PR's description I think it's better to open a new PR for this.

Yeah, it makes more sense to implement this on a separated PR. There should be a reference to this PR along with a sum up as well.

Maybe we can just merge this PR in the first step, as @hathach already wanted to here. Since this is a very easy concept and will not brin...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

If we are doing these changes to CDC class old applications have to be changed if they do not wish this behavior. Future applications can only make profit from it

Those applications will need to specifically enable the "do not check DTR" option. If they do, they should be aware of the consequences, as that is an option that you usually first need to learn the protocol in order to figure out that you need. Such applications then can/should detect on their own when they are connected or no...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

@hathach I think there is a misunderstanding. Currently overwrite is always disabled. Because current projects are not overwriting the buffer, I asked for an option which just optionally disables 2. of your comment to keep behavior as it was before.

Changes of behavior:

  • If DTR bit is set new and old implementation will work the same
  • If no DTR is set, flushing of both implementation will remove data fr...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

Those applications will need to specifically enable the "do not check DTR" option. If they do, they should be aware of the consequences, as that is an option that you usually first need to learn the protocol in order to figure out that you need. Such applications then can/should detect on their own when they are connected or not. I have also gotten old data in the UART before... that is not something strange.

We will use a more dynamic approach the compiler switch proposed in this PR.
...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #401: Add option to ignore DTR bit in CDC connection check

@hathach alright I will be opening a new issue with reference to this PR and writing a little summary of everything we've already discussed about. Also I can show up a draft PR with our favorite changes for now. But today I will most likely not be able to do that anymore.

@me-no-dev yes you are right about the "do not check DTR" option. But as @hathach already said we were already discussing about an other solution which is different from this PR's approach.

How do you actually know t...

fallow birchBOT
fallow birchBOT
fallow birchBOT
hazy raft
#

.-.

fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on issue #463: Auto\-flush for cdc device

My original experiments were with ESP-IDF which uses an older version of tinyusb. Now I tried to reproduce the issue with the following code but I'm getting CPU panics all the time:

void cdc_task(void* params)
{
  (void) params;

  uint8_t buf1[2] = {'a'};
  uint8_t buf2[2] = {'b'};

  // RTOS forever loop
  while ( 1 )
  {
    if ( tud_cdc_connected() )
    {
      // connected and there are data available
      if ( tud_cdc_available() )
      {
        int ret = tud_c...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #465 Compile issue with MSP430 gcc 9\.2\.0

Set up

  • PC OS : Ubuntu 20.04
  • Board : msp_exp430f5529lp
  • Firmware: examples/device/cdc_msc

Describe the bug
Failed to build due to a weird array-bound warning which I tried to fix but couldn't figure it out at this line
https://github.com/hathach/tinyusb/blob/master/src/portable/ti/msp430x5xx/dcd_msp430x5xx.c#L525

dcd_msp430x5xx.c:525:55: error: array subscript [65, 2097] is outside array bounds of 'volatile unsigned char[1]' [-Werror=array-bound...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
me-no-dev
[hathach/tinyusb] Pull request opened: #468 FreeRTOS: Yield from ISR to notify the USB task

If we do not yeld in ISR when we write to queue/give semaphore, the scheduler will not know of the change and will not check the queue untill the next OS tick. This change causes the task to be called immediately and makes communication many times faster.

Example reading the device descriptor

Before the change

After the change

@hathach this is also the progress with my USB decoder and direct result of it :)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #466 Remove 0xEE index string if statement & change TU\_ASSERT to TU\_VERIFY

thanks for the PR, now I need to spam all the examples tud_descriptor_string_cb() with the quote :D. Note this MS OS Descriptor is v1 and applied only to win7 and prio. Win8 and win10 use BOS to retrieve MS OS v2

// The 0xEE index string is a Microsoft OS Descriptors.	
// https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #454: ESP32\-S2: Handle the fact that available EP IN FIFOs are less than the number of available EP INs

Endpoints are opened as they are found in the descriptors (as far as I understand the flow), so in order for endpoint to not be opened, it have to be somehow designated by another api call or something. Or... can we define the EP transfer size as 0 in the descriptor and have the dcd not open it? or not assign fifo? Would that still work and enumerate fine? Will try!

Define EP size = 0 shouldn't be done, since it will potentially mess up with PC driver, and never guarantee to run. An wind...

#
hathach
[hathach/tinyusb] New branch created: followup\-pr466\-pr468
#
me-no-dev
[hathach/tinyusb] New comment on pull request #468: FreeRTOS: Yield from ISR to notify the USB task

Are you writing the USB decoder script with an OSC/Logic analyzer

Yes :) The LA that I have is not widely used or support everything, so some coding had to be done :) I added since SETUP decoding and I am currently adding CRC check and calculation. It's limited to 12Mbps USB and far from your LA, but it works great and shows everything the I might need to debug the bus up to driver level.

<img width="2464" alt="Screenshot 2020-07-21 at 17 23 11" src="https://user-images.githubusercont...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #468: FreeRTOS: Yield from ISR to notify the USB task

Are you writing the USB decoder script with an OSC/Logic analyzer

Yes :) The LA that I have is not widely used or support everything, so some coding had to be done :) I added since SETUP decoding and I am currently adding CRC check and calculation. It's limited to 12Mbps USB and far from your LA, but it works great and shows everything the I might need to debug the bus up to driver level.

Super cool, I am sure lots of people will find your decoding script useful. I am too lazy f...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #468: FreeRTOS: Yield from ISR to notify the USB task

I am sure lots of people will find your decoding script useful.

I will definitely publish it. I am not sure if others will find it useful if they do not have an LA from the same company. The good thing is that it's all in JavaScript, so in reality a web layer can be written to display the data and also to accept files from different LAs (I em pretty sure that the APP that my LA uses is just a web app with QT backend), but requires someone with the free time and will at hand :D

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #468: FreeRTOS: Yield from ISR to notify the USB task

Note to everyone: while working with nRF52 + freeRTOS, the USB IRQ can be triggered (BUS_RESET) before task scheduler is started, which will cause portYIELD_FROM_ISR -> SVCHandler run into hardfault. I could resolve this by moving the tud_init() next to vTaskStartScheduler().

https://github.com/adafruit/Adafruit_nRF52_Arduino/pull/542/files

This can be resolved completely by adding.

if(xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED) portYIELD_FROM_ISR(xHigherPriorityT...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-samd21\-missing\-setup
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #468: FreeRTOS: Yield from ISR to notify the USB task 
static bool _scheduler_started = false;
static bool check_if_scheduler_was_started(){
  _scheduler_started = (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED);
  return _scheduler_started;
}
...
if(_scheduler_started || check_if_scheduler_was_started()) portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

check_if_scheduler_was_started() should not be called once start was detected

it is an great idea, however, since osal_freertos is all static ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: call\-usbinit\-after\-kernel\-started
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #465: Compile issue with MSP430 gcc 9\.2\.0

@cr1901 thanks for creating a compiler explorer project.

GCC 9 release seems to did some enhancements to existing warnings (quote from GCC 9 Release):

-Warray-bounds detects more instances of out-of-bounds indices.

But I have no idea what they actually changed. 😂

Maybe the warning/error is caused by volatile attribute. When changing this line

volatile uint8_t * ep_buf = &USBSTABUFF + (ep_regs[BBAX] << 3);

to

volatile ui...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on issue #465: Compile issue with MSP430 gcc 9\.2\.0

@duempel AFAIU, the warning in this case is a side-effect of the real problem with my code as-written.

The original line is: #define EP_REGS(epnum, dir) &USBOEPCNF_1 + 64*dir + 8*(epnum - 1)

USBOEPCNF_1 is declared as a volatile unsigned char. The compiler treats USBOEPCNF_1 as a 1 byte object. When I take the address via &USBOEPCNF_1, I've created a volatile unsigned char *. I am invoking UB by doing pointer arithmetic- + 64*dir + 8*(epnum - 1)- to move past the storag...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #465: Compile issue with MSP430 gcc 9\.2\.0

@cr1901 thanks for this detailed description.

Short version: TI shouldn't have declared USBOEPCNF_1 as volatile unsigned char. It should've been something like #define USBOEPCNF_1 (*(volatile unsigned char *)0xdeadbeef) (example address). However, I tried to use TI's definition and work around it. And it lead to code that worked in old compiler versions but was flagged as UB in newer versions :).

Yes I agree with you. A different define could have been better at this point.

casti...

#
richfelker
[hathach/tinyusb] New comment on issue #465: Compile issue with MSP430 gcc 9\.2\.0

Yes, doing all the arithmetic as uintptr_t is preferable. Alternatively, if TI's headers could be fixed, the incorrect type volatile unsigned char could be changed to volatile unsigned char [] (unspecified size) in which case the compiler would have to assume any non-negative offset may be valid.

Indeed my original solution is arguably invalid because the compiler can prove that the resulting pointer still points to the same object of size one, and any arithmetic as pointers outsid...

last peak
#

STM32F0 and STM32F1 seem listed as supported boards. I have the official STM32 core installed in the Arduino IDE (v1.8.13), but I don't seem to be able to compile any of the sample sketches for either the STM32F030F4P6 or the STM32F103C8T6. I get this error: fatal error: Adafruit_TinyUSB_Core.h: No such file or directory. Can someone tell me what could be wrong here? BTW there's no TinyUSB in Tools -> USB Stack on the STM32F103C8T6 (Blue Pill) and on the STM32F030F4P6 there's no Tools -> USB Stack option, period!

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #465: Compile issue with MSP430 gcc 9\.2\.0

Short version: TI shouldn't have declared USBOEPCNF_1 as volatile unsigned char. It should've been something like #define USBOEPCNF_1 (*(volatile unsigned char *)0xdeadbeef) (example address). However, I tried to use TI's definition and work around it. And it lead to code that worked in old compiler versions but was flagged as UB in newer versions :).

This is spot-on, USBOEPCNF_1 is linker symbol defined by PROVIDE, it should really be declared as pointer by TI. Following TI's d...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-msp430\-warning
#
hathach
[hathach/tinyusb] New comment on pull request #412: suppress cast\-align warnings for net device driver

The changes to src/class/net/net_device.c seem unnecessary. The file could remain unchanged and the project still compiles without issue.

Which board and gcc version you are building. revert those changes still cause issue on multiple target e.g SAMD51/SAMD21/stm32f4 etc .. Hmm although we did declare notify with CFG_TUSB_MEM_ALIGN, I even go further with

CFG_TUSB_MEM_SECTION CFG_TUSB_MEM_ALIGN static union
{
  uint8_t rndis_buf[120] __attribute__ ((aligned(4))) ;
  struct...
fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #454: ESP32\-S2: Handle the fact that available EP IN FIFOs are less than the number of available EP INs

Maybe should clarify :)
This line here was missing: https://github.com/hathach/tinyusb/pull/454/files#diff-371e8160b188a80c1a3821c75d194adfR289

Code without it is assuming a clean peripheral registers and just setting the new values without clearing their masks before, which with persistence was causing previous FIFO to be 2, new FIFO to be 4 and resulting in 6, which first does not exists and second is not the correct value :)

fallow birchBOT
#
redmr2github
[hathach/tinyusb] Issue opened: #473 a little help with assert fail

Describe what the question is
Hi,

I didn't see forum or something of a wiki, so asking maybe a simple question regarding getting tinyusb integrated into a stm32 project. If there is a better medium, please let me know.

I have been evaluating USB on stm32h747 device on the stm32h747eval board - specifically cdc and msc. The ST driver/stack with freely available arm eabi gcc toolchain seems to perform poorly. This has been confirmed by ST. So, I'm trying to see if tinyusb stack m...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #412: suppress cast\-align warnings for net device driver

OK, the difference is that I'm using:

gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)

There doesn't seem to be much choice; it feels inelegant to workaround the misguided compiler, but I don't have a good alternative that isn't convoluted. Thanks for your patience.

I admit the changes is a bit odd to look at, maybe we could do it better later on by changing the declaration of noti...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-strict\-prototype
fallow birchBOT
fallow birchBOT
#
redmr2github
[hathach/tinyusb] New comment on issue #473: a little help with assert fail

This is going to sound stupid, but while I was cleaning up the project files and build scripts to make a tarball for bug submission - it now works! The only change in the source files was in the main.cpp file where I moved a printf statement... I'll monitor it for a few days to make sure things are stable.

But to answer your questions -
I don't have a supported board handy - but with minor edits to stm32h743eval files, and I can get the stock cdc_msc example code to work on stm32h747eva...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #473: a little help with assert fail

I am glad you work it out, that is why I always ask user to reproduce the issue with stock example + minimal changes on the supported board. In general, I can only help with usb issue, any customization with mcu clock, hw modification, flash config etc ... is out of knowledge. My advice whenever you have an issue, just start again from stock example, and try to do bisect from that.

Closed since this issue is resolved.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-nrf\-unplugg\-isr\-event
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: move\-dcdconnect\-to\-dcdinit
#
hathach
[hathach/tinyusb] Pull request opened: #478 enable pull\-up in dcd\_init\(\) instead of usbd

Describe the PR
Some MCU like nRF5x doesn't want to enable Pull-up when init. Pullup is preferably enabled within VBUS power detection, this help nrf5x to save (a little) more power than needed. Since nRF5x mostly run by itself on battery with bluetooth, this can help a bit (if any). In general, I think it may be just better to leave the dcd_init() to decide rather than usbd to force pull-up.

https://github.com/hathach/tinyusb/blob/master/src/portable/nordic/nrf5x/dcd_nrf5x.c#L808
...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-app\-driver\-2
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #476: Fix synopsys odd/even frame bit for IN ISO endpoints

I'm glad you're working on isochronous endpoints. I think there are a few more changes to do to get a full iso support. But these little change seems to get them working already. 👍

To focus on this PR's content: As you already mentioned I do not think that we need to set the EONUM bit within TXFE interrupt. Since a full iso transfer has to be sent within one frame, it's not useful to change this bit again. Did you try to run it without the changes to handle_ep_ints? I can not test it mys...

fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #476: Fix synopsys odd/even frame bit for IN ISO endpoints

@duempel my USB knowledge is very limited so I'm not sure what are the constraints on ISO. I simply added this code in two places just in case. My application did not use second path as whole data frame is sent in one packet.
I can drop it and if later some finds out that ISO packets needs this frame bit set in interrupt maybe some of you will remember and add it accordingly.
As to OUT ISO, I'm not there yet.

#
igrr
[hathach/tinyusb] New comment on pull request #479: add app driver as suggested by \#467

@hathach Am I right that this approach, compared to #385, does not allow the list of drivers to be defined dynamically, and we still need to know the list of drivers at compile time?

This option is certainly better than not having any way to customize the driver list, so 👍 on that. However the callback option still seems to be preferable since it allows both compile-time defied list of custom drivers, or run-time defined list of custom drivers.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #476: Fix synopsys odd/even frame bit for IN ISO endpoints

@hathach how does the stack react if you do not get dcd_event_xfer_complete? Will you schedule a new transfer or has the previous to be finished first? This is very important to iso endpoints because it can happen that we do not get the full transfer transmitted within one frame and in this case device driver won't invoke dcd_event_xfer_complete. We should introduce incomplete transfer interrupts IISOIXFR and IISOOXFR to isochronous endpoints maybe.

The stack should still wait fo...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-nrf\-disconnect
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
aauer1
[hathach/tinyusb] Issue opened: #481 STM32L0 WebUSB example: no data is received

Set up
I compiled the webusb_serial example for the STM32L053 discovery board.

  • PC OS : Ubuntu 18.04.4
  • Board : STM32L053 discovery
  • Firmware: examples/device/webusb_serial

Describe the bug
CDC is working as expected (ttyACM0 device is available and data is sent back on the CDC device and is also visible on the webusb example website)
But if I enter something on the webpage which should be transmitted to the board, it is not sent back. It seems that no d...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #479: add app driver as suggested by \#467

@hathach Am I right that this approach, compared to #385, does not allow the list of drivers to be defined dynamically, and we still need to know the list of drivers at compile time?

This option is certainly better than not having any way to customize the driver list, so on that. However the callback option still seems to be preferable since it allows both compile-time defied list of custom drivers, or run-time defined list of custom drivers.

@igrr yeah, this approach is very sta...

#
aauer1
[hathach/tinyusb] New comment on issue #481: STM32L0 WebUSB example: no data is received

I used the stm32l0538disco board which is already part of your source tree.

This is the debug output when the controller starts and is attached to the USB port of my PC. I think this is the normal enumeration process:
<pre>
USBD init
CDC init
VENDOR init
USBD Bus Reset
USBD Bus Reset
USBD Setup Received 80 06 00 01 00 00 40 00
Request Type: 80 Get Descriptor Device
Queue EP 80 with 18 bytes
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with zlp Status
USBD Xfer C...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #479: add app driver as suggested by \#467

@hathach I can try to give an example:

  • The ESP32 camera driver is a separate component that can benefit from having it's own webcam driver support that can be loaded if the component is in the project and enabled.
  • ESP32-Arduino will also be able to load it's own custom drivers (or the above camera driver) independent of what is precompiled from ESP-IDF.

I am sure @igrr could fill in more cases :)

#
duempel
[hathach/tinyusb] New comment on pull request #476: Fix synopsys odd/even frame bit for IN ISO endpoints

In case the data is not sent fast enough, dcd should detect this and let the stack know so that it could mark the endpoint as ready for next transfer.

Alright, our current ISO handling is not safe in this point. It can happen that we do not send out data and stack never gets a complete event. I'll write an issue to keep this in mind.

Though I don't think we need an extra INCOMPLETE event, ISO data is time-sensitive (audio/video), if it is sent late, it is just better to not send at ...

fallow birchBOT
#
igrr
[hathach/tinyusb] New comment on pull request #479: add app driver as suggested by \#467

Yes, pretty much what @me-no-dev said — the main reason for dynamic registration is to not centralize the knowledge of all the custom drivers in one place.
Which is not easy from the build system perspective — how to allow 3rd party components to contribute entries to CFG_TUD_APP_DRIVER_HEADER?
As an example, we have a virtual filesystem (VFS) component in IDF, which allows dynamic registration of filesystem drivers. The filesystem driver can be provided in a third party component, and VFS ...

fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] Issue opened: #482 Handling of CDC without setting control line states \(DTR\)

This is a follow up to #400 and #401

Is your feature request related to a problem? Please describe.
Within #400 and #401 it's been discussed if there is a need for CDC to work without the data terminal ready (DTR) bit being set. Usually terminal application will set this bit to tell the data communication equipment (DCE) device that the data terminal equipment (DTE) device is present. But this is no standard and there are cases in which the DTR bit is not set by DTE:

  • A lot...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
LadislavOzobot
[hathach/tinyusb] New comment on issue #166: USBD SET\_CONFIGURATION\(\) works only once

Hi!
Is there any progress on this issue/PR? I have just hit this problem on a project, where we have USB CDC and vendor class. It appears linux kernel sets the configuration, and some libraries (libusb) suggest we need to do set_configuration before other operations (not doing that fails other calls, as it depends on it to set some internal structures).

We have hotfixed it with the following patch (though it is VERY ughly, it seems to work so far):

Index: src/device/usbd.c
IDEA add...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #385: support class drivers implemented by application

I think IAR can only be smarter than gcc

I've already enabled every options. Frankly their optimization is not so impressive, many times with const restrict keywords it re-read everything from the stack.

Their advantages are functional safety, MISRA and easy to use, for example to write a ram routine instead of fiddle with linker options and copy the routine with memcpy, I can use simply the keyword __ramfunc.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-bt\-warning
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #486 Add dcd\_edpt\_close\(\) to synopsys

Describe the PR
Endpoint close was implemented only in one driver so far.
This function is needed for interfaces with several alternate settings.

The way FIFO is allocated in dcd_edpt_open() allows to correctly close
only one IN endpoint (the one that was opened last).

Stall and close share code as was suggested by TODO comment.

Additional context
FIFO allocation schema could be changed to allow closing endpoints.
It could be that FIFO allocation is not done during open ...

fallow birchBOT
#
Pillar1989
[hathach/tinyusb] Issue opened: #487 How to set usb HID Device interface name

I am using TinyUSB Arduino. My PC software requires me to provide a USB interface name. But TInyUSB can only set three strings: Manufacturer, Product Name, Serial number.
https://github.com/adafruit/Adafruit_TinyUSB_ArduinoCore/blob/2f485087fd64d3fafffad414f0dc316c685d33d9/Adafruit_USBD_Device.cpp#L361-L387

According to the standard USB HID protocol, it should be possible to include an interface name just like the one used in this code.
https://github.com/ARMmbed/DAPLink/blob/master/sour...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #430: Fix too strict checks on subclass and protocol entries of iad descriptor\.

@kasjer That depends on how you define near future ;). I eventually would like to but since i do this in my spare time it will take a little longer. Since uac is a bit more complex i am sure the review process will also be demanding. There are also some more features from the tinyusb stack i would need e.g. an implementation for closing EPs. This would be my next point working on. Finally, i only have a custom made board with microphones at my disposal so i can not test for anything else (e...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #430: Fix too strict checks on subclass and protocol entries of iad descriptor\.

Hi,

Certainly, i am happy if my code would be of use! I ran out of spare time recently so the work got stuck a bit. I already have a further developed version on my local repo available (which i have to push). From this point forward there sould not be much missing but to actually send audio data. Audio requests are already working and tested. The FIFOs within audio.c are not tested so far.

The driver right now supports at maximum one out, one in, one feedback, and one interrupt EP. T...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #430: Fix too strict checks on subclass and protocol entries of iad descriptor\.

Sure, but it will take a little time! Is there a reference on how the formating should look like? A definition or smth alike.--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 20.08.20, 10:23 schrieb kasjer notifications@github.com:

@PanRe thanks for sharing. I see that there are a lot of tabs in the code. Eventually someone will reformat it and then it will look like someone else did the hard work for audio. It would be great if you could ma...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #486: Add dcd\_edpt\_close\(\) to synopsys

Hi Hi, sorry for late response, I have been busy doing other work for Adafruit.

Describe the PR
Endpoint close was implemented only in one driver so far.
This function is needed for interfaces with several alternate settings.

The way FIFO is allocated in dcd_edpt_open() allows to correctly close
only one IN endpoint (the one that was opened last).

This is good start, we can focus on closing random endpoint later on when other thing work.

Stall and close shar...

#
hathach
[hathach/tinyusb] New review comment on pull request #434: Add TX callback to CDC device

This is still not ideal since we may not transfer all available bytes e.g flush send out 5 bytes, but the complete_cb() fill more 200 bytes just a few statement later. Ideally it should be

  if ( ep_addr == p_cdc->ep_in )
  {
    // invoke transmit callback to possibly refill tx fifo
    if ( tud_cdc_tx_complete_cb ) tud_cdc_tx_complete_cb(itf);

    if ( 0 == tud_cdc_n_write_flush(itf) )
    {
      // There is no data left, a ZLP should be sent if
      // xferred_bytes is ...
fallow birchBOT
fallow birchBOT
#
crosswick
[hathach/tinyusb] Issue opened: #489 Adding tinyusb \(webusb example\) to a vanilla STM32CubeIDE project

Hi all,

I hope this is a good place for a question like this - likely it's a matter of my own naiveté as relatively inexperienced programmer... but possibly it also is about how the tinyusb Getting Started info could be a bit clearer.

I've detailed the steps I've taken in an attempt to get the webusb_serial example up & running in the STM32CubeIDE, so that I learn how to add webusb functionality to projects I've already been developing in it; the full text of these steps I've shared wit...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-samg55\-build
#
hathach
[hathach/tinyusb] New review comment on pull request #490: add support for SAMD11 devices / add samd11\_xplained board

you could add -DCFG_EXAMPLE_MSC_READONLY to allow using ROM instead of RAM for read-only mass storage device. It can still be enumerated and show up the readme though PC won't be able to change the disk and/or readme contents. Here is how other small chip define this.
https://github.com/hathach/tinyusb/blob/master/hw/bsp/lpcxpresso1347/board.mk#L9

The macros is kind of required as well to pass CI build test.

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] Pull request opened: #492 WIP: ESP32\-S2 USB Persistent CDC

This PR adds support for persistent USB init for ESP32S2. This feature allows CDC to not re-enumerate when switching to and from Download mode. This feature should only be used with CDC and/or RT_DFU. Example is also provided.

WIP: For this example to work, a few fixes are needed in ESP-IDF. We have those in review currently and I will remove the WIP prefix once they are public. We can in a mean time use it to discuss the changes and make any necessary adjustments.

fallow birchBOT
fallow birchBOT
#
ktemkin
[hathach/tinyusb] New comment on pull request #490: add support for SAMD11 devices / add samd11\_xplained board

Thanks! I just rebased and plan to apply the other (MSX) fix later today. :)

Glad to be able to contribute! tinyusb’s been very useful to us so far, so it’s good to have a chance to contribute to it. :)

(As an aside, I must have been tired last night when juggling submodules; I just noticed that I used my fork’s master instead of creating a nice feature branch. Feels silly, but I suppose it works just as well.)

fallow birchBOT
#
ktemkin
[hathach/tinyusb] New comment on pull request #490: add support for SAMD11 devices / add samd11\_xplained board

Bit of a complication -- for the SAMD21, both ROM and RAM are pretty limited (16KiB flash, 4KiB SRAM). I've been able to fit tinyusb + some very useful stuff, but I don't think we're going to find an optimization that makes all of the examples work in the limited space (e.g. with _MSC_READONLY, the MSC examples now fit in RAM, but not in ROM).

Do you have a suggested workaround -- perhaps a way to disable those examples for a particular board?

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #490: add support for SAMD11 devices / add samd11\_xplained board

Thanks! I just rebased and plan to apply the other (MSC) fix later today. :)

Glad to be able to contribute! tinyusb’s been very useful to us, so it’s good to have a chance to contribute to it. :)

(As an aside, I must have been tired last night when juggling submodules; I just noticed that I used my fork’s master instead of creating a nice feature branch. Feels silly, but I suppose it works just as well.)

Thanks, I am glad you find it useful. No problem at all with the sub...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: followup\-490\-samd11
fallow birchBOT
fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #492: WIP: ESP32\-S2 USB Persistent CDC

Thanks @hathach !

If you want to give this a shot, there are two files in esp-idf that you need to edit. After that, you need to load the firmware once over UART and from then on can use the CDC instead. For Saola, you can go into the example folder and idf.py -p [port] flash monitor, given that you have the latest ESP-IDF and the changes applied and in PATH.

Here are the fixes:

  1. USB CLK will always reset
    <img width="502" alt="Screenshot 2020-08-22 at 16 22 09" src="https://user...
#
Thanos-Love-Ironman
[hathach/tinyusb] Issue opened: #494 cdc\_msc\_freertos project, the tud\_cdc\_connected\(\) return fail\.

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : stm32h743,designed by myself
  • Firmware: examples/device/cdc_msc_freertos

my project is cdc_smc_freertos project.
The msc device is working well with sd card while cdc function didn't.
tud_cdc_connected() return fail in cdc task which means usb is unconnected,but I do connect the usb with computer.Is it a bug?
Does someone have ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
theacodes
[hathach/tinyusb] Issue opened: #495 How to properly send SysEx messages

Hi, I'm trying to send sysex messages from tinyusb to a connected computer.

However, I can't seem to figure out the proper way to do it. I tried using tud_midi_send with the proper USD MIDI event packets:

tud_midi_send((uint8_t[4]){0x04, 0xF0, 0x00, 0x01});
tud_midi_send((uint8_t[4]){0x07, 0x02, 0x03, 0xF7});

However, MIDI Monitor shows that this comes across as invalid data:

![image](https://user-images.githubusercontent.com/250995/91000435-2f068400-e597-11ea-895c-682...

fallow birchBOT
#
theacodes
[hathach/tinyusb] New comment on issue #495: How to properly send SysEx messages

Actually, I'm generally just seeing a lot of weirdness with sending messages from my device. Receiving messages seems fine. But I've noticed that if I send more than one message, sometimes they don't get sent until after I send additional messages, and then those get held until I write more, and so on.

For example, I'm sending 3 CC messages in response to a single SysEX message:

tud_midi_send((uint8_t[4]){0x03, 0xB0, 0x5A, (result >> 12) & 0xF});
tud_midi_send((uint8_t[4]){0x03...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: improve\-midi
fallow birchBOT
#
diggit
[hathach/tinyusb] Issue opened: #496 STM32F2/STM32F4 workaround for USB334x HS fail

Describe the bug
It is already known in STM32 community, that F2 and F4 MCUs fail to work with USB334x (USB3341, USB3343, USB3346, USB3347) (and maybe others) external PHYs in HS mode and fall back to FS. It is timing problem on ULPI, more in module 2 in USB334x errata. Workaround was introduced by enabling bit USB_OTG_DCFG_XCVRDLY as mentioned in [this community forum thread](https://community.st.com/s/question/0D50X0000...

fallow birchBOT
fallow birchBOT
#
theacodes
[hathach/tinyusb] New comment on issue #495: How to properly send SysEx messages

Seems that branch helps with the simple messages above:

y
([176, 90, 1], 0.0)
([176, 90, 2], 0.000307125)
([176, 90, 3], 0.000307125)
y
([176, 90, 1], 1.173538513)
([176, 90, 2], 0.000331076)
([176, 90, 3], 0.000331076)
y
([176, 90, 1], 0.9214775070000001)
([176, 90, 2], 0.000272757)
([176, 90, 3], 0.000272757)

And with SysEx

y
([240, 0, 1, 2, 3, 247], 0.0)
y
([240, 1, 1, 2, 3, 247], 2.854390695)
y
([240, 2, 1, 2, 3, 247], 0.6649876130000001)
y
([240,...
fallow birchBOT
#
theacodes
[hathach/tinyusb] New comment on issue #495: How to properly send SysEx messages

Sounds good. Happy to keep testing the MIDI driver, and feel free to cc me
on the PR for this. :)

On Mon, Aug 24, 2020 at 1:34 PM Ha Thach notifications@github.com wrote:

@theacodes https://github.com/theacodes I am glad that helps you, let's
me know if you still have any other issue with MIDI driver. You could keep
this issue opened until you got it all sorted out. Then we could merge that
midi branch into master.

PS: I am noob with MIDI and instrument therefore the driver ...

fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #430: Fix too strict checks on subclass and protocol entries of iad descriptor\.

Hi @PanRe I createad pull request towards you branch that has some small fixes here and there.
I managed to run mono and stereo microphone using you code.
There is one thing that I want to change.
I need just one FIFO for stereo channels.
Data that I have is already PCM data (left and right channel interleaved).
With current implementation I feed left and right FIFOs only to put in together again and since I use
operation system with mutexes filling endpoint buffer with data from two FI...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #430: Fix too strict checks on subclass and protocol entries of iad descriptor\.

Thanks a lot thats good news! Unfortunately I am not able to look at the code the next days... But I will as soon as possible!Regarding the fifos, my intention was to offer both possibilities/modes, a fifo for every channel (as a test and quick and dirty possiblity) and one where the user can use his own "encoding" into the ep buffer (exactly what you ment). If you want to use this, set the tx fifo size to zero in the definitions. It might be, that there are a few fixes necessary ...

fallow birchBOT
#
crosswick
[hathach/tinyusb] Issue opened: #498 "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : macOS 10.14.6
  • Board : stm32f407disco
  • Firmware: examples/device/webusb_serial

Describe the bug
I've compiled the webusb_serial example as described in the readme and uploaded it with STM32CubeProgrammer. Then, with the board powered via the same USB connection (with an AC charger brick) and the mini-USB port connected to my laptop, the Chrome p...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: bsp\-itsy\-nrf52840
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
crosswick
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

Alright I've got the logging working; was a bit of a discovery for me to realize that I needed an extra serial-to-USB converter, and to find out which pins on the board I needed, and that the datarate should be 115200.

Here is the output; at the end is where I tried to connect by clicking the Connect button in the browser.

By the way: I have another piece of tinyusb/webusb hardware here that does immediately connect and work (https://webusb.hackz.one/)

USBDUSBD init
CDC init
VENDOR...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #492: WIP: ESP32\-S2 USB Persistent CDC

Thanks @hathach !

If you want to give this a shot, there are two files in esp-idf that you need to edit. After that, you need to load the firmware once over UART and from then on can use the CDC instead. For Saola, you can go into the example folder and idf.py -p [port] flash monitor, given that you have the latest ESP-IDF and the changes applied and in PATH.

While in monitor and over CDC, you can hit Ctrl+T Ctrl+A to rebuild and reflash, without getting out of the monit...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #501: How can I get the signals of DTR and RTS flow control in real time？

Maybe this:
https://github.com/hathach/tinyusb/blob/master/examples/device/webusb_serial/src/main.c#L169

I tried to get the DTR and RTS control signals using this interface function, but failed. Thanks again for the tip

there is no DTR/RTS equivalent for webusb, the pair process is between browser and OS. You need to implement the connect like the web example to send connect/disconnect event. You may want to look at webserial which use standard cdc instead.

fallow birchBOT
fallow birchBOT
#
stduinoiot
[hathach/tinyusb] New comment on issue #501: How can I get the signals of DTR and RTS flow control in real time？

Maybe this:
https://github.com/hathach/tinyusb/blob/master/examples/device/webusb_serial/src/main.c#L169

I tried to get the DTR and RTS control signals using this interface function, but failed. Thanks again for the tip

there is no DTR/RTS equivalent for webusb, the pair process is between browser and OS. You need to implement the connect like the web example to send connect/disconnect event. You may want to look at webserial which use standard cdc instead...

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] Issue opened: #502 Warm plug fail
  • PC OS : Windows 10/
  • Board : stm32h743 ,my own board
  • Firmware: examples/device/cdc_msc

Describe the bug
My project could not support USB warm unplugged since my board doesn't use VBUS sensing pin.(alternative function)
It is only working at the first plug when my board is not powered by USB cable.
Any solution???

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] Issue opened: #503 usb\_device\_task Priority set up

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : stm32h743
  • Firmware: examples/device/cdc_msc

Describe the bug
I am using latest ST sd card HAL Driver .I found out I have to set up usb_device_task with a high priority.Otherwise the TinyUSB won't work if I read sd card and open cdc port at the same time.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] Issue opened: #504 Convert EP buffers to ring buffers \(at least for ISO EPs\)

Hello,

Right now @kasjer and i are working on finalizing a working version for an audio 2.0 driver. During tests a possible bottleneck came up and i wanted your opinion on this issue. In general a FIFO is necessary in order to decouple the sampling process from the USB transmission process.

So the setup right now (e.g. for a microphone) is: Samples -> FIFO -> EP buffer -> USB FIFO, where -> means "put into".

As how tinyUSB is set up right now, all EP buffers are considered to be lin...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] Pull request opened: #506 CDC without DTR being set

As previously discussed, I'd like to share ideas how we could solve the DTR bit problem within CDC class. Sorry if you have been waiting for this. I couldn't work on it before since I've been on vacation. 🙈

Describe the PR
This PR is one possibility to solve #482 . The most important change is, that tud_cdc_n_connected(itf) is not checked within tud_cdc_n_write_flush anymore. This will allow us to transmit data, even if the host does not support control line states. In case the DT...

fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #502: Warm plug fail

Do I understand correctly that your board uses its own power supply and is not bus powered? Maybe this problem is related to #179 . I've also had problems with disconnecting and reconnecting without reseting the controller but had no time to search for the cause yet. Are you using FS or HS peripheral?

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #502: Warm plug fail

Do I understand correctly that your board uses its own power supply and is not bus powered? Maybe this problem is related to #179 . I've also had problems with disconnecting and reconnecting without reseting the controller but had no time to search for the cause yet. Are you using FS or HS peripheral?

Yes,I use FS peripheral.My DTR bit cannot be set by pc terminal.I don't know if it's relative to this issue.
But now I got an another issue.My cdc port will crash after transfer data for c...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Hello,

Right now @kasjer and i are working on finalizing a working version for an audio 2.0 driver. During tests a possible bottleneck came up and i wanted your opinion on this issue. In general a FIFO is necessary in order to decouple the sampling process from the USB transmission process.

So the setup right now (e.g. for a microphone) is: Samples -> FIFO -> EP buffer -> USB FIFO, where -> means "put into".

As how tinyUSB is set up right now, all EP buffers are conside...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

I don't see any information that I could analyze and help you with. If you want people feedback, you should fist capture the rtos task switching with freertos trace, segger system view etc ... and post the screenshot here. Also provide the your own analysis & its context such as where the is the time the issue happen and why the CPU is blocked on certain resource.

#
hathach
[hathach/tinyusb] New comment on issue #501: How can I get the signals of DTR and RTS flow control in real time？

So, now I'm confused: webserial is a completely different protocol from "webusb protocol talking to a serial device" (like the webusb_serial example)?

There is two web standard, the

  • webUSB is basically bind to any interface of an USB device, much like libusb claim interface. webUSB mostly used with vendor/custom class with either HID or BULK whichever the developer (device + web) like. webusb_serial is just an example that emulate the use of webusb like an virtual serial.
  • we...
fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Even if DMA is supported on a microcontroller, my opinion is that tinyusb shouldn't hard-require implementations (at least the non-iso part of the user API) to use DMA. Tinyusb should remain relatively easy to port, and I think hard-requiring DMA complicates this.

I'm not even sure if hard-requiring DMA is wise for iso xfers (STM32F4 and friends come to mind- they support iso, but I recall that nothing says you have to use DMA. And STM should be fast enough to process interrupts).

#
PanRe
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Oh i never ment to hard require a DMA for ISO EPs. Most often, a DMA can not be used at all e.g. in my case I have 4 microphones and I need to encode them into a PCM stream with the four samples interleaved. This (at least for STM32F4) can not be done by DMA. Converting the EP buffer into a ring buffer, however, would give you a nice opportunity to attach a DMA (in case of an I2S stream where stereo samples are already interleaved).Of course the user API shall not be broken!--Dies...

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

I don't see any information that I could analyze and help you with. If you want people feedback, you should fist capture the rtos task switching with freertos trace, segger system view etc ... and post the screenshot here. Also provide the your own analysis & its context such as where the is the time the issue happen and why the CPU is blocked on certain resource.

I really don't know what's the detail,I only found out it will stuck in OTG_FS_IRQHandler() infinite loop.

fallow birchBOT
fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

I don't see any information that I could analyze and help you with. If you want people feedback, you should fist capture the rtos task switching with freertos trace, segger system view etc ... and post the screenshot here. Also provide the your own analysis & its context such as where the is the time the issue happen and why the CPU is blocked on certain resource.

the reasons is usbd_edpt_busy(TUD_OPT_RHPORT, p_cdc->ep_in) always return false after open terminal couples of minutes.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #507 Race condition with cdc auto flush\(\) on transfer completion

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

Note: The race condition only happen if we use an additional mutex. Semaphore or any other type won't cause the issue. Explanation is below

void setup() {

  // put your ...
#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Also in your current implementation of the FIFOs i would recommend you not to store a count variable and modify it in both pull() and push() as the count variable might get messed up if two processes modify it (the writing of the count variable is not atomic). Rather i would compute count all time new.

I just remembered why I use count instead of computing it, since I don't want to waste 1 slot of storage, which could be 8/16 bytes depending on the item_size, the count variable is always...

fallow birchBOT
fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

you could take a look at this #507 for how to analyze and troubleshoot your issue. Since you are the only one that could reproduce the issue. These are mostly race condition, and these required to capture the whole picture of resource conflict between running task to be able to determine the root cause.

I don't think this is the cause,I have rewrite the FIFO with xStreamBuffer.There is mutex when call tud_cdc_n_write_flush in other high prioity task.
The MSC is also crash just like the...

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

you could take a look at this #507 for how to analyze and troubleshoot your issue. Since you are the only one that could reproduce the issue. These are mostly race condition, and these required to capture the whole picture of resource conflict between running task to be able to determine the root cause.

The MSC will crash soon even when I use no cdc function( no mutex).If I use cdc funtion at the same time,it will crash sooner.

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

you could take a look at this #507 for how to analyze and troubleshoot your issue. Since you are the only one that could reproduce the issue. These are mostly race condition, and these required to capture the whole picture of resource conflict between running task to be able to determine the root cause.

it will stuck in here as well (debug) when I read sd card and open pc terminal.
![image](https://user-images.githubusercontent.com/54545255/92455099-dc160900-f1f3-11ea-8bae-0effe49bfbe7....

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

144: loop continue to run !!! At this time, the usbd task should be the one running, since the mutex is released by loop, a context switch should happen, but it is NOT

Sorry, i dont know nrf, but in general FreeRTOS wont switch task if semaphore/mutex can be claimed (dont have to wait to claim it). Maybe yield() after release mutex can be helpful?

It does switch task when a mutex is released, however due to the simple implementation of FreeRTOS's priority inheritance, the LP lo...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Also in your current implementation of the FIFOs i would recommend you not to store a count variable and modify it in both pull() and push() as the count variable might get messed up if two processes modify it (the writing of the count variable is not atomic). Rather i would compute count all time new.

I just remembered why I use count instead of computing it, since I don't want to waste 1 slot of storage, which could be 8/16 bytes depending on the item_size, the count vari...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

@PanRe yeah, I found the unmasked approach is nice as well. Though the power of 2 limitation can be a bit too strict for now. Maybe we can go back to this later on when everything is figured out. Since I don't see much benefit to implement it for now.

Within TinyUSB, the mutex API won't ever be called within ISR, the only osal that invoked in ISR is osal_queue_send(osal_queue_t qhdl, void const * data, bool in_isr) with the sole purpose to put the usb event into the usbd task queue for ...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

As i mentioned before, i already figured it out how to handle non-power of two buffer sizes. I did that in my RERO project as well, where i built a ring buffer filled by DMA from USART.
Well we can pospone that surely but as i said then there is this extra copy process necessary since an additional FIFO is needed. If i have time left i prepare a PR for that.
For now, i will wait for @kasjer to finish his tests on the driver and as soon as this is finished i prepare a PR for you to get an au...

fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Hi there, I'm finishing speaker part. It turned out that for this to work correctly I need feedback endpoint and that is taking much time (also it was not clear to me what Windows really expect from audio device in terms of descriptors and it took me some time
to have it working, while Linux and Mac were happy with what I had originally). FIFO mechanics are not not affecting me, since I made some changes that use just one FIFO for all channels and this change alone drastically reduce CPU ti...

fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

There may be another problem that you should look at. Take a look at lines 143, 148, 154. If i understand it correctly then there is no space in Queue probably and queue wait ticks is set to 0. It looks to me there is some code that are trying to push another message to queue before previous got received. Is it possible?
Line 133 looks good, xQueueSendFromISR, but the others not really.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

There may be another problem that you should look at. Take a look at lines 143, 148, 154. If i understand it correctly then there is no space in Queue probably and queue wait ticks is set to 0. It looks to me there is some code that are trying to push another message to queue before previous got received. Is it possible?

I think it is the default mutex block time https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/master/include/semphr.h#L40 at those 143 148 154. I remembered freeRTOS imple...

#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

As i mentioned before, i already figured it out how to handle non-power of two buffer sizes. I did that in my RERO project as well, where i built a ring buffer filled by DMA from USART.
Well we can pospone that surely but as i said then there is this extra copy process necessary since an additional FIFO is needed. If i have time left i prepare a PR for that.
For now, i will wait for @kasjer to finish his tests on the driver and as soon as this is finished i prepare a PR for you to get...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #492: WIP: ESP32\-S2 USB Persistent CDC

do you know from which commit the issue start up happens, both tinyusb and IDF are moving, it could be a bit difficult to track.

I did not change anything that would cause that, but I am glad it happened anyway. I have not delved very deep yet, but the data endpoint is not working. Setup packets are OK. OUTs are NACKed. INs seem as well.

Does this also happen with example in this repo, I can help to take a look at the problem, just let's me know your IDF commit hash to make sure...

#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Hi there, I'm finishing speaker part. It turned out that for this to work correctly I need feedback endpoint and that is taking much time (also it was not clear to me what Windows really expect from audio device in terms of descriptors and it took me some time
to have it working, while Linux and Mac were happy with what I had originally). FIFO mechanics are not not affecting me, since I made some changes that use just one FIFO for all channels and this change alone drastically reduce CPU...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-edpt\-race
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #508 Fix edpt xfer race condition

Describe the PR

  • fix #507 introduce optional usbd_edpt_claim, usbd_edpt_release which can be ued to gain exclusive access to usbd_edpt_xfer
  • With class driver API() that submit transfer to endpoint. Currently usbd_edpt_busy() is checked before calling usbd_edpt_xfer() e.g
uint32_t tud_cdc_n_write_flush (uint8_t itf)
{
  cdcd_interface_t* p_cdc = &_cdcd_itf[itf];

  // skip if previous transfer not complete yet
  TU_VERIFY( !usbd_edpt_busy(TUD_OPT_RHPORT, p_cdc->ep_in)...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

My first guess is that you still need the mutexes in case two or more threads try to write into the buffer since you need to protect the write pointer. The same holds for two or more threads reading from the buffer as all of them try to modify the read pointer. What is getting better is that you not need to block the read function while you execute the write function and vice versa (so you could use two separate mutexes for write and read here).For the rest i need a closer look if...

fallow birchBOT
#
Thanos-Love-Ironman
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

Note: The race condition only happen if we use an additional mutex. Semaphore or any other type won't cause the issue. Explanati...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #503: usb\_device\_task Priority set up

It is not about the modification of tinyusb, it is your whole project. What you mentioned is not reproducible by anyone. And you literally didn't provide any information for troubleshooting/anallyzing it. You could try to file another issue for this problem with

  • A simplest modification to stock example to reproduce the issue. It is best to reproducible on one of the supported bsp. This makes sure other could reproduce it. Else It could be your own bug in other part of the project.
  • P...
fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #492: WIP: ESP32\-S2 USB Persistent CDC

it's against master IDF with the changes above. Funny enough it's triggered often with one board and not the other. Problem is that EP_IN becomes busy (XFER Complete not received) after a few bytes are sent.

// R-Read, S-Space, W-Written, F-Flushed
h
R:1,S:64,W:1,F:1
g
R:1,S:64,W:1,F:1
f
R:1,S:64,W:1,F:1
h
R:1,S:64,W:1,F:1
g
EP_IN BUSY:132

R:1,S:64,W:1,F:0
f
EP_IN BUSY:132

R:1,S:63,W:1,F:0
h
EP_IN BUSY:132

R:1,S:62,W:1,F:0
g
EP_IN BUSY:132

R:1,S:61,W:1,F:0
f...
fallow birchBOT
fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

Here is simplified example i am running on esp32 S2 (also FreeRTOS) to see if task are switching with mutex:

int wrsize;
void task(void* p)
{
  SemaphoreHandle_t mutex = xSemaphoreCreateMutex();
  delay(100);
  String text = String((char*)p);
  while (1) {
    if (xSemaphoreTake(mutex, portMAX_DELAY) == pdTRUE)
    {
      Serial.println(text);
      xSemaphoreGive(mutex);
    }
    delay(1); // to switch tasks and let setup run
  }
}

void setup() {
  // put your setup...
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

Now lets consider my original answer, both task should usae the same mutex:

int wrsize;
  SemaphoreHandle_t mutex = xSemaphoreCreateMutex();

void task(void* p)
{
//  SemaphoreHandle_t mutex = xSemaphoreCreateMutex();
  delay(100);
  String text = String((char*)p);
  while (1) {
    if (xSemaphoreTake(mutex, portMAX_DELAY) == pdTRUE)
    {
      Serial.println(text);
      xSemaphoreGive(mutex);
    }
    delay(1); // to switch tasks and let setup run, can be delay(1)
  }...
#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

@chegewara I am appreciate the time you spent testing out this issue. Though I am bit confused by your 2 example. Can I ask

  1. Did the Serial.printf() in your esp32s2 also use TinyUSB CDC as nrf52840 ?
  2. Are you trying to say FreeRTOS implementation is correct, in that case, please visit the link to freeRTOS forum I posted above here is the rtel response. And the code for this function hasn't changed since that anwser.
xTaskPriorityDisinherit when other mutexes are held
Posted by ...
fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion
  1. No, i am not using tinyusb at all in my test code, it was just test of freertos behavior with mutex
  2. yes, ive been reading all from link you posted at first place and i am also confused, thats why i prepared this test code

Im not saying that freertos works good or bad, but my understanding of freertos is telling me that all tasks should share the same mutex if you want to block HP by LP task.

Lets imagine situation you have 2 LP tasks and 2 HP tasks.

  • task1 and task2 are LP,
  • ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion
  1. No, i am not using tinyusb at all in my test code, it was just test of freertos behavior with mutex

I see, your 2 examples are not the same as the above sketch running on nrf52 with TinyUSB CDC for Serial.printf.

  1. yes, ive been reading all from link you posted at first place and i am also confused, thats why i prepared this test code

I think you completely misunderstand my point, it probably due to my bad writing. Please re-read my first post again, I will make a short sumu...

fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

Ok, here is quick test that proves your words with that case:

Setup3: priority = 1
Setup1: priority = 1
Setup2: priority = 21
task1 task1 task1
Setup3: priority = 21
Setup1: priority = 21
Setup2: priority = 21
task1 task1 task1
Setup3: priority = 21

When setup helds 2 mutexes, 1 shared with task priority 10, the other with task priority 21 and 1st mutex is not released, then priority of setup stays at highest inherited level. Only releasing all mutexes will let setup get b...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

@chegewara There is no need to post an example here to prove my words at all. I already having an example sketch and the rtel response above already nailed it down. You are probably interested in freeRTOS, but I am only interested in fixing my stack.

If you got my point now, would you mind if I remove all of our converstation so far on the FreeRTOS, it is a bit distraction with lots of lengthy example. I am worried people will be off-topic from the actual race condition. Thank you.

I...

signal ocean
#

Is anyone here familiar with running TinyUSB outside of arduino. I am working on a SAMD11 project with the same processor thats on the xplained boards. I am having trouble figuring out how to get started. I include tusb.h and a usb_config that is a copy of the composite hid example. I also #define CFG_TUSB_MCU OPT_MCU_SAMD11

Then when I try to do things like call the tinyusb handler in the IRQ it fails to find dcd_int_handler function. Which tells me I don't have everything defined as it should be. What should I be doing to get this running without the magic of board.mk files and the like

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #509 Add usbd\_edpt\_stream API\(\)

Is your feature request related to a problem? Please describe.
Currently stream endpoint (ep buf + fifo) are used by cdc, midi, vendor are very similar to each other e.g

  • read from fifo, if there is enough space --> submit transfer for epout
  • write to fifo, if there is enough data or flush() --> submit transfer for epin
  • on endpoint complete callback --> auto flush and/or auto prepare out transfer

The code is duplicated making it hard to maintain, since stream api is popular, m...

fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

Ideally it would be 1 mutex per endpiont, but that seems to be a lot of memory for edge case. Maybe only one general mutex is enough, and the edpt_claim()/edpt_release() is fast enough I guess. Let's me know what do you think about the PR and how we could improve it. I am open to any suggestion.

Usually I'd say that one mutex for claiming all endpoints should be ok. There is not much processing and high priority tasks can only be blocked very shortly. But this short blocking is not guara...

#
duempel
[hathach/tinyusb] New comment on issue #502: Warm plug fail

@Thanos-Love-Ironman I see you had some other problems which seem to stick together. Right now the information I have don't seem that there is actually a failure to usb because of warm plugging.

Does your Windows detects the USB device correctly (even after 2nd or 3rd plug)? Then the enumeration seem to work fine without any problems. The problem would be related to other system setups I guess.

But if the enumeration process will fail it could be because of the alternative function on U...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #501: How can I get the signals of DTR and RTS flow control in real time？

I am currently using the tud_cdc_n_get_line_state interface function for retrieving the DTR signal, but the RTS control signal is not yet retrieved.

Which terminal software are you using to test this? I once spotted a similar behaviour when using HTerm. Changes to RTS were only received after changing DTR as well. I'd recommend you to test your implementation with other terminals as well. (Maybe some applications think it's not useful to set RTS if they are actually not ready 🤷‍♂️?) Putt...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

Usually I'd say that one mutex for claiming all endpoints should be ok. There is not much processing and high priority tasks can only be blocked very shortly. But this short blocking is not guaranteed, as we can see with a setup like #507 . If the low priority task won't fall back to it's low priority after releasing the mutex other high prio tasks can be blocked for much longer than expected. This won't result in the error we saw before, but could cause problems to time critical tasks. I a...

#
hathach
[hathach/tinyusb] New comment on pull request #492: WIP: ESP32\-S2 USB Persistent CDC

Ok just to be clear, the issue only happens with this PR right ? Maybe we both miss something in the diff

Just this PR, happens sometimes on persistent reboot. Regular reboot with peripheral reset is fine. And hard to trigger on some boards, but not on others.

Oh, that is a mystery, maybe it is related to the bsp like pin drive, voltage etc.. unfortunately I couldn't help you to troubleshoot this since I have little exp/knowledge with persistent mode.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

@duempel oh, while removing the claimed bit, I realize there may be an issue. Since currently the edpt_claim() is optional. Using only 1 busy bit, the edpt_xfer() won't be able to force and check to see if the endpoint is currently transferring or not. E.g an API can call edpt_xfer() 2 times, and the busy is set just like using the claim_edpt() hmm. Maybe we can leave that later when forcing all API to use claim, however, it is not really necessary for endpoint that isn't directly involved ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #506 CDC without DTR being set

Thank you again, great PR, I think this over most of our discussion on this topic before. Strangely the code is actually much less than the discussion itself, which is actually a really good things, since we write less but cover most scenario. I only has a few comments, most importantly to remove the edpt_abort() since that is lots of works and may not needed since the case is not that severe. Most user won't even notice that. I like to add code step by step, it takes lots more time to get th...

#
hathach
[hathach/tinyusb] New review comment on pull request #506: CDC without DTR being set

I am thinking we don't really need this option. The default to continue to send still suite most people in most cases I think. If people really want to clear the fifo. There is a tud_cdc_line_state_cb() callback, we can add an extra cdc-write_clear() for user to clear it themself. Just in case people want to have one cdc interface that clear() and another that does not.

PS: We can always add this option if needed later, but it is much harder to remove it once added.

fallow birchBOT
fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion

I am thinking about it and i see 2 potential solutions:

  • use binary semaphore instead of mutex,

Binary semaphores and mutexes are very similar but have some subtle differences: Mutexes include a priority inheritance mechanism, binary semaphores do not. This makes binary semaphores the better choice for implementing synchronisation (between tasks or between tasks and an interrupt), and mutexes the better choice for implementing simple mutual exclusion.

https://www.freertos.org/Embedde...

#
hathach
[hathach/tinyusb] New comment on issue #507: Race condition with cdc auto flush\(\) on transfer completion
  • in tinyusb just before you are trying to claim mutex, store task priority, then right after releasing mutex restore task priority; im not sure if tinyusb allows to access more than 1 task to code that will try to claim mutex, because this wont work in such case (priority will be kept only for last task)

this is too much, a usb stack can never fix an RTOS kernel issue. We are better to leave the prio correction to the kernel. Else we will be gonna introduce more bugs. IMO, the alternat...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

Hi there, I'm finishing speaker part. It turned out that for this to work correctly I need feedback endpoint and that is taking much time (also it was not clear to me what Windows really expect from audio device in terms of descriptors and it took me some time
to have it working, while Linux and Mac were happy with what I had originally). FIFO mechanics are not not affecting me, since I made some changes that use just one FIFO for all channels and this change alone drastically re...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

Surely using more mutex will increase the chance of HP being blocked

Yes using more mutex will increase the chance of blocking. But I actually wanted to say that using more mutex objects we can decrease the chance of blocking since EP3 would not try to get the same mutex as EP2. Well but one is just fine for now. Don't need to waste ressources on this.

_prep_out_transaction() is also invoked by user via cdc_read().

Oh yeah, my fault. I just wonder if we would really need it in ...

fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

There are some more commits on my branch kasjer/uac2.
It's not all yet, since our work slightly diverged and I have conflicts which are mostly resolved.
You can take a look of what was done.
I also have changes to explicit feedback, that with proper descriptors works with Windows and Linux.
I noticed that @PanRe changes were adding FIFO bypass lately and my work uses FIFO for speaker and microphone so I hope we will not argue here (FIFO code had some minor discrepancies so maybe it was no...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

Yes using more mutex will increase the chance of blocking. But I actually wanted to say that using more mutex objects we can decrease the chance of blocking since EP3 would not try to get the same mutex as EP2. Well but one is just fine for now. Don't need to waste ressources on this.

Right, I thought of this as well, 16 mutex is lots of resources. 1 Mutex can easily occupies 32 or 64 bytes.

Oh yeah, my fault. I just wonder if we would really need it in user API but this can be di...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-hid\-gamepad\-template
fallow birchBOT
#
mzero
[hathach/tinyusb] New comment on issue #495: How to properly send SysEx messages

I think I found the bug!

If you send [0xf0, a, b, c, d, e, f, g, h, i..., z, 0xf7] (where the letters represent arbitrary payload values)
you get instead: [0xf0, a, b, c, a, b, d, a, b, e, a, b, f, a, b, .... z, a, b, 0xf7, a, b]
if you space that out in the three bytes of payload in each USB packet, you'll see the pattern:

[0xf0, a, b,
    c, a, b,
    d, a, b,
    e, a, b,
    f, a, b,
    .... 
    z, a, b,
 0xf7, a, b]

This is a bug in the USB MIDI encoder in...

fallow birchBOT
#
mzero
[hathach/tinyusb] Issue opened: #511 SysEx messages are improperly sent

Set up

  • PC OS : macOS 10.15
  • Board : Feather M0 Express

Describe the bug
SysEx messages are mangled when sent over USB.
Example:

  • Send F0 7A 00 01 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D F7
  • USB host receives:
00  F0 7D 00 01 7D 00 61 7D  00 62 7D 00 63 7D 00 64
10  7D 00 65 7D 00 66 7D 00  67 7D 00 68 7D 00 69 7D
20  00 6A 7D 00 6B 7D 00 6C  7D 00 6D 7D 00 F7

To reproduce
Build and run this sketch. It uses both the `Adafruit_Tiny...

#
mzero
[hathach/tinyusb] Pull request opened: #512 Fix a bug in writing SysEx messages\.

At the start of a new USB packet (4 bytes), while in the middle of a SysEx, the code mistakenly
set the buffer length to 4, not the target length. As a consequence, the 3rd and 4th bytes from
the last packet were included, after every byte of the SysEx after the first packet of three.

The fix is simple, as it was just a typo, as can bee seen from the other branches in the same
section of if/else statements: At the start of a new packet, the code should set up the target
length... the b...

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Issue opened: #513 weak symbol relocation error

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : STM32L072
  • Firmware: examples/device/cdc_msc

Describe the bug

Hi, I'm evaluating Segger Embedded Studio with gcc and segger linker and I got errors with all functions defined as weak while linking.
For example:

case DCD_EVENT_RESUME:
        if (tud_resume_cb) tud_resume_cb();
      break;
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #513: weak symbol relocation error

Hmm, I also use segger embedded studio for debugging occasionally and didn't have any issues with linking weak function. Have you tried out those project in the example https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_msc/ses

Note: some may be out of date and needs update to compile.

This behavior is specified in the AAELF ("ELF for the ARM Architecture") document:

I am aware of the direct use of weak function which expanded to NOP. However, I am not sure how oth...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #508: Fix edpt xfer race condition

@hathach all in all I feel good with these changes. In _prep_out_transaction maybe claiming the endpoint would make more sense if we do this before availability check. In case tud_task has a higher priority than the user task which is calling a tud_cdc_n_read for example. The user task then processes _prep_out_transaction and reads the available bytes in rx fifo. If the higher priority task then invokes cdcd_xfer_cb and write data to rx fifo there might be less space. In this case the _prep...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zlittell
[hathach/tinyusb] Issue opened: #515 SAMD11 HID Examples Send Tons of Random String Descriptors

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : SAMD11 XPLAINED
  • Firmware: examples/device/hid_composite
    examples/device/hid_generic_inout

Describe the bug
When programming either of these examples to the SAMD11, they constantly send String Descriptors to the host. It Doesn't seem like much of a pattern (it will sometimes send string index 1, the...

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #513: weak symbol relocation error

meanwhile can you compile with the nrf5x project here

I can compile this project since it's using gcc linker.

I think a solution to ensure compatibility between processors is to add a stub function instead using `if'

For example in usbd.c, change

// invoke callback
        if (tud_umount_cb) tud_umount_cb();

to

TU_ATTR_WEAK void tud_umount_cb(){}
  ...
        if (tud_umount_cb) tud_umount_cb();
fallow birchBOT
fallow birchBOT
#
stduinoiot
[hathach/tinyusb] Issue opened: #517 stm32f103bluepill's uart log function opened failed , how to open it ?

I want to use the UART log function of STM32F103Bluepill. The current code is as follows, which can be compiled and passed normally, but cannot receive and receive data in PA2 PA3 port.
`/*

  • The MIT License (MIT)
  • Copyright (c) 2019 Ha Thach (tinyusb.org)
  • This file is part of the TinyUSB stack.
    */

#include "../board.h"
#include "stm32f1xx_hal.h"

//--------------------------------------------------------------------+
// Forward USB interrupt events to TinyUSB IR...

#
stduinoiot
[hathach/tinyusb] New comment on issue #501: How can I get the signals of DTR and RTS flow control in real time？

I am currently using the tud_cdc_n_get_line_state interface function for retrieving the DTR signal, but the RTS control signal is not yet retrieved.

Which terminal software are you using to test this? I once spotted a similar behaviour when using HTerm. Changes to RTS were only received after changing DTR as well. I'd recommend you to test your implementation with other terminals as well. (Maybe some applications think it's not useful to set RTS if they are actually not ready 🤷‍♂️?...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #515: SAMD11 HID Examples Send Tons of Random String Descriptors

Thanks for filing the issue, are you using an IDE to compile the example, if yes then try to reproduce to see if the issue occur with existing makefile target.

Plugged in the EDBG and couldn't get anything on the COM port. Does logging work on the SAMD11?

Yeah, it doesn't work since uart API is not implemented on the board, maybe you could help to add the support for it ? https://github.com/hathach/tinyusb/blob/master/hw/bsp/samd11_xplained/samd11_xplained.c#L126

Since I don't h...

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #518 nrf5x iso support

Describe the PR
ISO endpoints were not covered in nrf5x driver.
Code deals with ISO IN and OUT endpoints.
Intermediate steps needed for ISO to work on NRF:

  • increasing number for device endpoints (it was 8).
  • increasing max endpoint size variable size
  • closing endpoints

Additional context
Code should not affect current non-ISO control flow.
It was tested with audio driver that @PanRe is going hopefully to submit soon :)

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #518: nrf5x iso support

Ah yes sorry for the delay! I promise to get the PR done by the end of this week! :)--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 21.09.20, 16:19 schrieb kasjer notifications@github.com:

Describe the PR ISO endpoints were not covered in nrf5x driver. Code deals with ISO IN and OUT endpoints. Intermediate steps needed for ISO to work on NRF:

increasing number for device endpoints (it was 8).
increasing max endpoint size variable s...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #516: Tusb fifo unmaksed pointers

Ah yes I see. Well this might by tricky since here we really need a true modulo result. But I have an idea how to solve this issue (I hope). I update the PR once I tested my idea.Am 21.09.20, 10:23 schrieb HiFiPhile notifications@github.com:

Hi,
Coud you avoid using modulo as much as possible ? As on Cortex-M0 and 8bit MCUs division cost many CPU cycles, now it's called in every write and read operation.
—You are receiving this because you authored the thread.Reply ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #515: SAMD11 HID Examples Send Tons of Random String Descriptors

It happens whether I use an IDE or just compile the examples using make. I will try to get some time to look at the uart stuff. Also I have a SAMD21 xplained board in the drawer and not sure if I can get one of the other examples to run on it.

thanks for confirmation, samd21 should work well, since it is widely tested with Adafruit M0 board, though the SAMD21 xplained it not part of supported boards, you may need to add a port for it. SAMD11 mcu is only ported recently, maybe it has some...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #516 Tusb fifo unmaksed pointers

Thank you very much for the great PR. It is a bit more complicated than I though, however, decoupling write() and read() and is able to use with DMA are indeed an incredible feature which will definitely has lots of benefit. Though I am hoping maybe we can make the code a bit simpler e.g like dropping (wAbs, rAbs) arguments if that is possible in parts of the API.

PS: Sorry for late response, I have been busy with other works, still trying to catch up.

#
hathach
[hathach/tinyusb] New review comment on pull request #516: Tusb fifo unmaksed pointers

hmm this math seems to be more complicated than it should be, can we change it to

idx -= (idx >= depth) ? depth : 0; 
or simply
if ( idx >= depth) idx -= depth

I still have a question, why wouldn't we do it twice, if needed, we could just do a. it is still much cheaper to run than % which cost 50 cycles or so on M0, this mostly only compare 1 and minus 1 90% of the time ?

while ( idx >= depth) idx -= depth;
#
hathach
[hathach/tinyusb] New review comment on pull request #516: Tusb fifo unmaksed pointers

These function aren't used yet, IMHO it is wroth to write unit test with various scenario to verify its behavior. Since fifo is primitive type, I have several existing tests for it here. If you have time and write couple of DMA read/write tests it would be great, not a problem if you don't, I could do it myself
https://github.com/hathach/tinyusb/blob/master/test/test/test_fifo.c

To run unit test, you will need to install Ruby, and install Ceedling via gem.
https://github.com/ThrowTheSwit...

#
hathach
[hathach/tinyusb] New comment on issue #513: weak symbol relocation error

meanwhile can you compile with the nrf5x project here

I can compile this project since it's using gcc linker.

I think a solution to ensure compatibility between processors is to add a stub function instead using `if'

For example in usbd.c, change

// invoke callback
        if (tud_umount_cb) tud_umount_cb();

to

TU_ATTR_WEAK void tud_umount_cb(){}
  ...
        if (tud_umount_cb) tud_umount_cb();

@HiFiPhile...

fallow birchBOT
fallow birchBOT
austere shuttle
#

does tinyusb HID work on valentyusb?

#

HID device

robust walrus
#

I would assume so. I think it's just a bulk endpoint

austere shuttle
#

cool 😎

#

I'm thinking about an ultra low latency gamepad project

austere shuttle
#

I found something even better, a HID example PR for LUNA that does everything in gateware, no CPU needed

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #516: Tusb fifo unmaksed pointers

Well this might be micro-optimization but the idea here was the following:

  • By design, the pointers are not allowed to become larger that 2*depth-1
  • As a result we can guarantee that executing 2 times idx -= depth & -(idx >= depth); is sufficient
  • There is a big discussion about branching, what is more efficient. Most people argue that branching may result in flushing the instruction pipeline and thus might result in worse delays. The version above simply avoids branching at all as th...
fallow birchBOT
fallow birchBOT
#
salkinium
[hathach/tinyusb] Pull request opened: #520 STM32F3 IRQ remap option and some minor improvements

Hi, thanks for this awesome library! I'm currently integrating TinyUSB into modm (https://github.com/modm-io/modm/pull/478) and I found some minor things to improve:

  1. I added a simple STM32F3_IRQ_REMAP, which can be defined in the config to remap the IRQs. The user must remap the IRQs in their hardware setup (it's just SYSCFG->CFGR1 |= SYSCFG_CFGR1_USB_IT_RMP;).
  2. We're using TinyUSB in C++, which doesn't define the __STDC_VERSION__ macro, thus throwing a warning. Just a simple f...
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #516: Tusb fifo unmaksed pointers

There is one idea left. Since write and read are decoupled we could introduce seperate mutexes for them. Right now write and read still block each other since they share a common mutex. I did not implement this so far since it would break the current API. I thought you know the project in more detail and i would leave it up to you to decide if its worth to implement it.

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach thanks for your review. I kept this draft pending as it is right now, because I hoped someone else could take a look and comment on it. Since I am defining a very new functionality for the CDC, some more ideas might be useful.
This is also the reason why I made this PR a little bit bigger than it will eventually become. Just to show an idea of the code to what we discussed before.

I'm a bit busy at the moment, but I'll work on the changes you recommended and push the update we ma...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] Pull request opened: #521 Uac2

Describe the PR
This PR adds a USB audio 2.0 (UAC2) driver.

First a very BIG thanks to @kasjer for helping finalizing and testing this driver! It took quiet some time to set all of this up and there definitely is room for improvement. But as a first start this sould be fine!

Additional context
In general

  • multiple audio functions (drivers) are useable in parallel.
  • at most one IN EP, one OUT EP, one feed back EP, and one INT EP are supported per audio function. This should...
fallow birchBOT
signal ocean
#

@robust walrus Hey I don't mean to bother you, but I was wondering if you have any experience using composite devices in tinyUSB. I tried to just put my own device descriptor in from another project and it didn't quite work. Then I tried just doubling the in/out example and that doesn't work either. So I am not sure if I am not doing it right or if TinyUSB just doesn't do multiple interfaces correctly.

robust walrus
#

@signal ocean circuitpython definitely uses composite devices

#

it doesn't use different configurations (I think that's the right term)

signal ocean
#

do they actually have 2 interfaces. I noticed the tinyusb composite example is a kbmouse over the same endpoints I think

robust walrus
#

ya, circuitpython is msc, cdc, hid and midi by default

signal ocean
#

I will dive into circuitpython and learn from there. I figured it was something I wasn't doing right, but figured theres always a chance I am spinning my wheels for no reason. Thanks!

robust walrus
#

np 🙂

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #377: MIDI data buffer full

it probably works better now.

The FIFOs still drop data, right? As long as that is the case, the current MIDI code cannot reliably work. MIDI packet flow needs to behave like a CDC serial line, just block, never drop anything.

Could you fix the MIDI FIFOs to work as expected?

The fifo is still overwritable for MIDI, I still haven't got time too look at this issue yet since the last time. I will try to do it later on.

#
hathach
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach thanks for your review. I kept this draft pending as it is right now, because I hoped someone else could take a look and comment on it. Since I am defining a very new functionality for the CDC, some more ideas might be useful.
This is also the reason why I made this PR a little bit bigger than it will eventually become. Just to show an idea of the code to what we discussed before.

I'm a bit busy at the moment, but I'll work on the changes you recommended and push the upda...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #516: Tusb fifo unmaksed pointers

There is one idea left. Since write and read are decoupled we could introduce seperate mutexes for them. Right now write and read still block each other since they share a common mutex. I did not implement this so far since it would break the current API. I thought you know the project in more detail and i would leave it up to you to decide if its worth to implement it.

yeah, it should though, I will implement it in a separate PR, no worries. I will carry more tests and try to merge this...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #516: Tusb fifo unmaksed pointers

We should let it stay at 2^15! The main reason is that the while loop is nothing else than the modulo operation in software without division and this can last extremely long!!! By limiting to 2^15 we guarantee that at most two iterations are required and thus we get a fast result. If you go back to 2^16 we are as slow as with modulo. E.g. think about doing the while loop for a depth of 100 and an index space size of 2^16, you end up staying in the while loop for 2^14 iterations if you are unl...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #518 nrf5x iso support

Thank you very much for this great PR, and sorry for being late with review (was busy with other works for last week :sleepy:). This look great, I only have a few minor comment,

  • the only issue is the if logic in the dcd_edpt_stall
  • There is lots of number 8 used for ISO endpoint, maybe we should have an enum EPNUM_ISO = 8 or any name like that just to make it easier to tell the diff when we refer to EP ISO or the count of CBI.
#
hathach
[hathach/tinyusb] New comment on pull request #521: Uac2

wow wow wow, this is astounding, thank you very much @PanRe and @kasjer for this awesome work. This is quite a lots of changes, please give me a few days for proper reviewing and testing. I may try to merge the fifo enhancement #516 first.

@hathach There might be the need to adjust the unit tests because it does not know anything of dcd_alloc_mem_for_conf() and it complains that this function is called too often. Can assist here? Thanks a lot!

no problem, don't worry about the...

#
hathach
[hathach/tinyusb] New comment on pull request #516: Tusb fifo unmaksed pointers

We should let it stay at 2^15! The main reason is that the while loop is nothing else than the modulo operation in software without division and this can last extremely long!!! By limiting to 2^15 we guarantee that at most two iterations are required and thus we get a fast result. If you go back to 2^16 we are as slow as with modulo. E.g. think about doing the while loop for a depth of 100 and an index space size of 2^16, you end up staying in the while loop for 2^14 iterations if you are u...

#
hathach
[hathach/tinyusb] New review comment on pull request #518: nrf5x iso support

@kasjer ah, not actually, currently the data_received is indicator for OUT endpoint, since nrf controller will auto ACK the first OUT packet even if we didn't schedule any transfer in the software. Therefore it is more like data_available for CBI than consumed, there for the consumed is not really correct for CBI usage. These naming is really difficult :weary:

signal ocean
#

I have played with composite devices a little more and now realize my issue is trying to fire up multiple HID interfaces. I want to use 2 hid interfaces for two different report descriptors. Does anyone know if TinyUSB is capable of this? It seems the issue is not being able to separate the report descriptors possibly? It does just seem like it should work though.

fallow birchBOT
#
zlittell
[hathach/tinyusb] Issue opened: #522 2\+ HID Interfaces on a single device

Describe what the question is
I see the composite example uses a keyboard and mouse on the same interface. When I try to add multiple interfaces I start to get "device not started" issues. The descriptors come in and then it stalls. Is what I am trying to do supported by TinyUSB? If so can someone who has experience with it give me some pointers on what needs to be done to get this type of device rolling.

Most other libraries have you list the report descriptors separately per interfa...

fallow birchBOT
fallow birchBOT
#
cr1901
[hathach/tinyusb] Issue opened: #523 Board Examples Support listed in

Is your feature request related to a problem? Please describe.
As tinyusb grows more device class and board support thanks to the wonderful contributors, I get a bit concerned about keeping track of:

Which boards supports which parts of tinyusb? And when were the examples last built and known to work?

This would have to be a collaborative effort, considering that I don't think anyone has all the boards that tinyusb supports.

Describe the solution you'd like
I...

fallow birchBOT
fallow birchBOT
#
zlittell
[hathach/tinyusb] Pull request opened: #524 Feature multiple hid interfaces

Describe the PR
Allows multiple hid interfaces within a single device. Includes example as well.

Additional context
https://github.com/hathach/tinyusb/commit/b7208d6f7e97e724853eb5d0e512a23005cc8790
This needs to be changed because it breaks all legacy hid usb_descriptors.c files. There should be a better way to do this, but I thought I would just get it done and then pose the question here. I need to be able to call tud_hid_descriptor_report_cb and pass desc_index as well as pa...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #523: Board Examples Support listed in

thanks @cr1901 it is a good idea, though I think having commit hash that last known good is too much of maintaining works. An example doesn't work on a specific MCU is mostly of: not enough RAM or ROM, not enough Endpoints, which are very static. Therefore I would consider it is a bug if it works in a previous commit but not at current latest. I think we could update the boards.md to become an table with additional notes on which example a board doesn't work or work with limited functiona...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #524 Feature multiple hid interfaces

Thank you for your PR, everything look good except for the tud_hid_descriptor_report_cb() that needs to be updated per review. Yeah, regarding the backward compatible, Ideally all the callback has need to have additional itf argument for application to know which interface that event occurred all, and this sadly break the existing code. The best approach now is

  • when CFG_TUD_HID == 1 we will keep the current single interface API and define the callback_n() version as macro that expa...
#
hathach
[hathach/tinyusb] New review comment on pull request #524: Feature multiple hid interfaces

I think there is a bit of mixing-up here. The wIndex is actually the interface number of the HID interface and not the desc_index. It just happens to be the same 0, 1 order as the example. It will be different, if we have additional class before and/or between the hid interface.

What we should do here is use the wIndex to figure out the index of the targeted interface in hid pool and pass it as itf to the callback. It is a foor-loop comparing the wIndex agains the itf_num of the in...

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #525 da1469x iso support

Describe the PR
ISO endpoints for DA146xx were not supported so far.
To enable them and in turn allow USB audio to work following changes were made to DA146xx driver.

  • Max endpoint size restriction was removed (64 bytes size of the internal FIFO).
    It was achieved by adding DMA support and also FIFO level interrupt that can be used when DMA is in use.
    (Only one endpoint in each direction can be used with DMA at a time).
  • dcd_edpt_close() function was added that will be ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zlittell
[hathach/tinyusb] New review comment on pull request #524: Feature multiple hid interfaces

We should be able to use the lower byte of wValue to determine the descriptor index. The setup packet has the correct index in it when sniffing with a beagle. I set up some traps to debug this and wValue is always 0x2200 instead of 0x2200 and then 0x2201. Trying to track down why, I feel like this is the right way to solve this problem if it isn't crazy. That way we are relying on the spec instead of a hack.

fallow birchBOT
signal ocean
#

Anybody in here that has a different device than a SAMD11 that can test the issue in https://github.com/hathach/tinyusb/pull/524#discussion_r499019634
should be able to change
uint8_t const * desc_report = tud_hid_descriptor_report_cb((uint8_t) request->wIndex);
to
uint8_t const * desc_report = tud_hid_descriptor_report_cb(desc_index);
and eventually get a 0x01 in there
I can't seem to figure out at what point the lower byte is dropped or why its dropped

GitHub
Feature multiple hid interfaces by zlittell · Pull Request #524 · h...

Describe the PR
References #522
Allows multiple hid interfaces within a single device. Includes example as well.
Additional context
b7208d6
This needs to be changed because it breaks all legacy hid...

fallow birchBOT
fallow birchBOT
#
zlittell
[hathach/tinyusb] Issue opened: #526 When receiving a Get Descriptor request, wValue does not contain lowerbyte\.

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : SAMD11_xplained
  • Firmware: examples/device/hid_multipleinterface

Describe the bug
When you read in a Get Descriptor request the high byte of wValue should be 0x22 which it is. The low byte should be the index of the descriptor, but it is always 0x00.

To reproduce
Steps to reproduce the behavior:

  1. Debug the Multiple...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
salkinium
[hathach/tinyusb] New review comment on pull request #520: STM32F3 IRQ remap option and some minor improvements

Not that big an issue, since I can reuse the tinyusb variadic helpers for that purpose, and redirect to our assertion mechanism:

// Redirect TinyUSB asserts to use modm_assert
#define MODM_ASSERT_1ARGS(_cond) \
	TU_VERIFY_DEFINE(_cond, modm_assert(0, "tu", \
		__FILE__ ":" MODM_STRINGIFY(__LINE__) " -> \"" #_cond "\""), false)

#define MODM_ASSERT_2ARGS(_cond, _ret) \
	TU_VERIFY_DEFINE(_cond, modm_assert_contin...
fallow birchBOT
#
zlittell
[hathach/tinyusb] New comment on issue #515: SAMD11 HID Examples Send Tons of Random String Descriptors

I haven't had a chance to test with another OS yet. I have tried it on different hardware but all windows.
Also I spent some time working on the UART today using the hid_composite example and it doesn't fit. I even tried to conserve space using masks to load the registers instead of including any of the HAL/HPL sercom functions. You can test this as well as just including LOG=2 without any of the functionality yet. It compiles fine but fails to program to the device.

#
PanRe
[hathach/tinyusb] New comment on pull request #521: Uac2

wow wow wow, this is astounding, thank you very much @PanRe and @kasjer for this awesome work. This is quite a lots of changes, please give me a few days for proper reviewing and testing. I may try to merge the fifo enhancement #516 first.

@hathach There might be the need to adjust the unit tests because it does not know anything of dcd_alloc_mem_for_conf() and it complains that this function is called too often. Can assist here? Thanks a lot!

no problem, don't w...

fallow birchBOT
#
zlittell
[hathach/tinyusb] New comment on pull request #521: Uac2

Everytime you try to turn debug or log on you will get the error back. It can be fixed by adding hw/mcu/microchip/samd11/hal/utils/src/utils_syscalls.c
to the SRC_C += in side board.mk for the samd11

this shouldn't be necessary since there is a -specs=nosys.specs in the rules.mk file, so it is probably correct that the linker is wrong, but I can't find where. It matches quite a few examples.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
gh2o
[hathach/tinyusb] Pull request opened: #529 stm32 fsdev: fix ISTR and CTR\_RX/TX race conditions

This PR fixes two race conditions in the stm32 fsdev driver:

  • USB->ISTR is a register where bits are cleared by writing 0. A non-atomic read-modify-write, as is done in reg16_clear_bits(), may inadvertently clear an interrupt flag that gets set between reading ISTR and writing ISTR, causing that interrupt to be dropped.
  • Within the EPxR registers, CTR_TX and CTR_RX are also cleared by writing 0. Ensure that pcd_clear_rx_ep_ctr and pcd_clear_tx_ep_ctr write a 1 to the bit they are not clea...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #529: stm32 fsdev: fix ISTR and CTR\_RX/TX race conditions

Thanks for finding so many issues. I had originally copied most of the code from the stm32 HAL, with these bugs included. Since then, the HAL was updated, but this driver was never fixed.

Everything looks good to me in this PR.

In my mind for the ISTR, I didn't want to change the reserved bits since the documentation doesn't say what they do, but that does create the race condition, so what you propose is correct. ST now does the same, so it should work nicely.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: PanRe\-uac2\-fix\-build
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #521 Uac2

Thank you very much for this superb PRs with lots of works and modification. Due to its large work, I have only reviewed a small portion of this PR. I got into issue with building audio_test example, and attempt to fix it with PR to PR here https://github.com/PanRe/tinyusb/pull/3

I got the stm32f411 enumerated as audio device and response to several of host messages. Though since the audio_test doesn't do much now, we couldn't verify its actual functionality. Though that is definitely can...

#
hathach
[hathach/tinyusb] New review comment on pull request #521: Uac2

I have issue with undef CFG_TUD_AUDIO_TX_DMA_RINGBUFFER_SIZE

 error: "CFG_TUD_AUDIO_TX_DMA_RINGBUFFER_SIZE" is not defined, evaluates to 0 [-Werror=undef]
   62 | #if CFG_TUD_AUDIO_TX_FIFO_SIZE && CFG_TUD_AUDIO_TX_DMA_RINGBUFFER_SIZE

I think we also need to have

#ifndef CFG_TUD_AUDIO_TX_DMA_RINGBUFFER_SIZE
#define CFG_TUD_AUDIO_TX_DMA_RINGBUFFER_SIZE 0
#endif
#
hathach
[hathach/tinyusb] New review comment on pull request #521: Uac2

To be honest, I don't like the introduction of this function. defragmenting is not a real issue, it is mostly switching between open/close ISO endpoint, which could be addressed in other way like introducing dcd_edpt_iso_open with additional max packet size of all alternate Itf. If you could revert this change and still having the audio_test example running. I will update the ISO and dcd to better support open/close endpoint.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #526: When receiving a Get Descriptor request, wValue does not contain lowerbyte\.

I think you mis-interpreter the request
https://github.com/hathach/tinyusb/blob/440e23c49181687790d9e18e62af501310b62d33/src/common/tusb_types.h#L432

From your capture screenshot the value is received correctly with value = 0x2200 and index = 0x0001 . As mentioned in the PR, the wIndex is the interface number and since each interface only has 1 hid descriptor, therefore the desc_index which is lower byte of wValue = 0x00 is correct.

I think you mixed up the HID report descriptor...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #521: Uac2

I see your reason why it would be better to have such a configuration parsing within USBD and not in DCD. This totally makes sense since other MCUs may need the same. However, i am not sure if handling ISO EPs without taking care of the remaining EPs is sufficient! Your idea of reserving space only for the ISO EPs is similar to my approach but i also take care that there is space for all used remaining EPs. So an overflow can be avoided and detected at compilation time. Every EP has its dedic...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #521: Uac2

Your idea of reserving space only for the ISO EPs is similar to my approach but i also take care that there is space for all used remaining EPs.

No I didn't say we will reserve space for ISO only. First of all the only endpoint that get closed and reopened is only ISO. It is unspoken truth that for all the ISO endpoints, its default interface (alternate = 0) must has no endpoint (closed ISO). Therefore ISO will likely be the last endpoints got opened. All other endpoints are opened when...

#
hathach
[hathach/tinyusb] New branch created: fix\-idf\-latest
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #521: Uac2

Ah now the picture gets clearer. Actually a smart thought! Your are right, the interfaces which need to be activated by SET_INTERFACE will use what is left from the other EPs. I always have this highly complicated picture in mind, where the end user may has multiple multi-interface USB applications running (similar to audio). I guess this comes from reading too many USB specifications ^^. They always suggest you may close interfaces currently not needed in order to allow a bigger interfac...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #521: Uac2

Ah now the picture gets clearer. Actually a smart thought! Your are right, the interfaces which need to be activated by SET_INTERFACE will use what is left from the other EPs. I always have this highly complicated picture in mind, where the end user may has multiple multi-interface USB applications running (similar to audio). I guess this comes from reading too many USB specifications ^^. They always suggest you may close interfaces currently not needed in order to allow a bigger interf...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #521: Uac2

Actually, your implementation still need to handle this case of SET_INTERFACE request for changing the endpoint size as well...

Thats acutally not correct, my implementation would recognize ATL 3 and reserve the required 300 in the first place. It determines the worst case i.e. the biggest required FIFO size for every EP ever needed and sets up the FIFO this way. Thus the FIFO never needs to be reconfigured even in case of open/close EPs and it does not need any management.

Regarding ...

fallow birchBOT
#
kasjer
[hathach/tinyusb] New review comment on pull request #521: Uac2

Both microphone and speaker in real life require code that is capable of handling sound.
This is very hardware dependent and I don't think we can have out of the box code that will work on more then one platform.
For microphone we can have some sort of noise generator that will produce stream that host can see.
For speaker it is a little more difficult, audio data has to go somewhere.

For my part I'm using I2S microphone and I2S speaker that works with STM32F4 MCUs.
Speaker also works ...

fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #531 mimxrt1010\_evk: double stack size to allow net\_lwip\_webserver to run

#289 reported an issue with net_lwip_webserver with the 'NXP Transdimension (18 / 43 / iMX RT)' target.

I had access to a MIMXRT1010_EVK, and the issue was nothing more than a too restrictive stack size in NXP's default stack size value in the linker script. A minor tweak to the BSP board.mk by adding LDFLAGS to override the value remedies this.

I suspect the same change will remedy others (most notably the MIMXRT1015_EVK, which should be nearly identical to the MIMXRT1010_EVK), but I'...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #521: Uac2

Thats acutally not correct, my implementation would recognize ATL 3 and reserve the required 300 in the first place. It determines the worst case i.e. the biggest required FIFO size for every EP ever needed and sets up the FIFO this way. Thus the FIFO never needs to be reconfigured even in case of open/close EPs and it does not need any management.

Yeah, I mean I know you reserve the largest space for ISO. But we still need to resize the ep when SET_INTERFACE with different ep size is re...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #528: Adds files for the open source D5035\-01 hardware

thanks, I think this is mostly the symbol difference because of the startup asm code. SAMD51 used the modified/unified version from adafruit https://github.com/adafruit/samd-peripherals . By now, I just realized adafruit just adding same5 support to the repo. But that should be no problems, the tinyusb is a neutral library, application is free to pick any other driver/libraries they like :)

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #521: Uac2

Yeah, I mean I know you reserve the largest space for ISO. But we still need to resize the ep when SET_INTERFACE with different ep size is received. For stm32, maybe we can leave it with max fifo size and should be no issues, other mcus may need different approach. I kind of mixed-up some thought along the way across MCUs approach.

That is correct, the EP needs to know its current size but the FIFO size is fixed to maximum required size so there will never occur any issues once everythin...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zlittell
[hathach/tinyusb] New comment on pull request #524: Feature multiple hid interfaces

I was going to do another push to update some of the items mentioned but then realized I would be pushing a commit that just made the 2nd descripter const and then reduced the example buffer size to 8. Figured those two housekeeping items could be done when n api and combining the helpers is done. I didn't do much, but I am glad I could contribute. I have asked a ton of questions and bugged a few people, so I feel better about myself a little now haha.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #524: Feature multiple hid interfaces

I was going to do another push to update some of the items mentioned but then realized I would be pushing a commit that just made the 2nd descripter const and then reduced the example buffer size to 8. Figured those two housekeeping items could be done when n api and combining the helpers is done. I didn't do much, but I am glad I could contribute. I have asked a ton of questions and bugged a few people, so I feel better about myself a little now haha.

You are doing great, the PR add v...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #524: Feature multiple hid interfaces

The reason I needed the multi interface is that I have a generic HID interface that exchanges bytes and a keyboard interface. If they are the same interface I cannot capture the generic interface in my application because windows won't let you open a keyboard interface. Not sure if the same in other OS.

Windows does a good job to prevent keylogger software :D . I am sure others will have a strict limit toward keyboard as well :)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #289: check usbnet example with all ports

@majbthrd i just pull-out the rt1020-evk and rt1060-evk to test with

  • both 1020 & 1060 work (page loaded) with default stack size of 0x400 on Windows VM
  • both failed to load page with default/increased stack size on Linux

Would you mind testing it with Linux machine, since Linux use ECM and Windows use RNDIS, maybe there is a bit of issue somewhere. I am short on time to troubleshoot this for now, but if you could confirm the issue, I will update the 1st post that will make it easier t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: house\-keeping
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #521: Uac2

@PanRe do you have time to revert the dcd synopsys changes ? I would like to merge it this weekend to try to see if I could do further testing with audio this weekend. If you don't have time, I could merge it as it is and do the revert my self afterward (basically overwrite it with the current one) :D. Nice thing is we will have these modification in git log whenever we want to pull it up in the future :D

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #520: STM32F3 IRQ remap option and some minor improvements

@salkinium sorry for late response, this is great idea to solve the shared CAN/USB. I like your last suggestion by checking the actual remap bit. The overhead is too small ( a couple of cycle for bit test) and this aren't call at any fast rate either. Would you mind changing it to dynamic check. Also since it only available to selected chips, it should be wrapped with SYSCFG_CFGR1_USB_IT_RMP e.g

#ifdef SYSCFG_CFGR1_USB_IT_RMP
if ( remapped )
{
 use RMP IRQ
}else
#endif
{
  us...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #521: Uac2

@PanRe do you have time to revert the dcd synopsys changes ? I hope to merge it this and try to see if I could do further testing with audio this weekend. If you don't have time, I could merge it as it is and do the revert my self afterward (basically overwrite it with the current one) :D. Nice thing is we will have these modification in git log whenever we want to pull it up in the future :D

Done! I had to keep some changes @kasjer introduces for ISO EPs. I also extended the exa...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #521: Uac2

thank you very much and also @kasjer for this brilliant PR. This will be a very interesting & exciting feature for the stack. I cannot say thank enough to you two.

You are very welcome. There is still much to do yet! But i am happy that the driver finally made it into the stack! :)

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #521: Uac2

thank you very much and also @kasjer for this brilliant PR. This will be a very interesting & exciting feature for the stack. I cannot say thank enough to you two.

You are very welcome. There is still much to do yet! But i am happy that the driver finally made it into the stack! :)

Yeah, lots left to be done, especially audio normally involved dsp work. But it is a great milestone 👍

#
hathach
[hathach/tinyusb] New comment on issue #504: Convert EP buffers to ring buffers \(at least for ISO EPs\)

@PanRe I think this issue could be closed by now since it is implemented by #516

Frankly we are not yet done here ^^. The idea was to convert the EP buffers at least for ISO EPs to FIFOs. The merged unmasked pointer FIFOs are now perfectly suited for this task but it still needs to be implemented (if desired).

Yeah, I think it is is best to be implemented in class driver e.g audio or video. Once it is mature enough we can spin it off like what I plan to do with...

fallow birchBOT
#
majbthrd
[hathach/tinyusb] New comment on issue #289: check usbnet example with all ports

@hathach, I think the stack size change that I suggested was unnecessary. I measured peak stack usage at 684 bytes, and that is below the original, default of 1024 bytes. (In turns out my initial problems with running TinyUSB on the IMXRT1010-EVK had a lot more to do with the flaky built-in DAP on the evaluation board.)

I tested the IMXRT1010-EVK using net_lwip_webserver with the original stack size of 0x400 with Windows, Linux, and MacOS. I saw no issue.

@hathach, your mention of EC...

fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #533 net\_lwip\_webserver: tweak main\.c comments with smartphone suggestions

The goal of net_lwip_webserver is example code that works on as many different platforms as possible. Operation under Windows, Linux, and macOS has been tested, but smartphones seem to be under-developed and artificially picky (if not buggy). Given the sheer cornucopia of phone out there, it is probably a losing battle, but I've added comments in main.c with a couple of suggestion on things to try.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #289: check usbnet example with all ports

@hathach, I think the stack size change that I suggested was unnecessary. I measured peak stack usage at 684 bytes, and that is below the original, default of 1024 bytes. (In turns out my initial problems with running TinyUSB on the IMXRT1010-EVK had a lot more to do with the flaky built-in DAP on the evaluation board.)

Ah right, daplink is bit slow partly since it is external qspi flash, I have updated the flash-pyocd target, it should be easier to flash.

I tested the IMXRT1010-EVK...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-microchip\-driver
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-async\-control
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #289: check usbnet example with all ports

Ooops, I will try to do more test, maybe it is some OS setting, btw which Linux distro you are testing with, I am on ubuntu 20.04

I'm testing against: Ubuntu 18.04, Ubuntu 14.04, Windows 7, Windows 10, macOS High Sierra 10.13.16

I'm compiling with: gcc 9.2.1 (ARM 2019-q4)

Thanks for all your hard work, @hathach !

thanks for your os info. I have updated the 1st post, I will test it out later on. Have to switch on other works. But I think it is probably something min...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #538 audio: Add headset example

Describe the PR
This example code creates USB Audio 2.0 headset device.
Device has two audio interfaces first stereo speaker
with 48kHz stereo stream.
Second interface for microphone with 48kHz mono stream.

This example can be used to start working on audio device.
It can be also used to verify ISO endpoints for boards.

Speaker adaptive clock (bound to SOF).
Microphone for now has asynchronous clock.

Volume and mute control while present are not used for data stream
modifi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #538: audio: Add headset example

Describe the PR
This example code creates USB Audio 2.0 headset device.
Device has two audio interfaces first stereo speaker
with 48kHz stereo stream.
Second interface for microphone with 48kHz mono stream.

This example can be used to start working on audio device.
It can be also used to verify ISO endpoints for boards.

Speaker adaptive clock (bound to SOF).
Microphone for now has asynchronous clock.

Volume and mute control while present are not us...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #538: audio: Add headset example

@hathach I will leave fixing FIFO issue for synopsys to you. I'm sure you have better overall vision on how it should be done.
It is not part of the headset code anyway so separate PR addressing this will have chance for better review.

yeah, that makes lots of sense, I will merge this and make an issue for this. Will try to find time this weekend for a better fix.

#
hathach
[hathach/tinyusb] Pull request review submitted: #538 audio: Add headset example

Thank you very much for this incredible PR. This is really a great working base for us to add more work on UAC2. I really need further reading the UAC2 and more hand-on testing audio class.

The current audio API is a bit technical that needs lots of reading to get it work. I am hoping to simplify it more to make it easier for user. That is for sure more complicate and need a series of following-up PRs.

#
hathach
[hathach/tinyusb] Issue opened: #540 Better dcd synopsys fifo allocation for ISO

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

current synopsys EP FIFO allocation scheme does not support high ISO packet size e.g 192 in #538 . It assumes all FS endpoints packet only has up to 64 bytes. However FS ISO can have up to 1023 bytes.
https://github.com/hathach/tinyusb/blob/master/src/portable/st/synopsys/dcd_synopsys.c#L216

We need a better scheme not only resolve this FIFO OUT, but also open/close/re-open ISO endpoints with different packet size e.g...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

In fact we completely forgot this point last time we discussed about the reverted FIFO allocation in dcd_synopsis! We only had IN EPs or the TX part in mind...

I do not want to be annoying but IMHO you need to know upfront the required size of the RX FIFO since you can not change it easily once USB transfers are in progress. Either you fix it statically as you proposed above or you parse through the descriptors and find out how much you need. For the latter option we already have tested co...

fallow birchBOT
#
j4cbo
[hathach/tinyusb] Pull request opened: #541 Allow use of internal FS PHY on OTG\_HS interface

Describe the PR
Allow use of internal FS PHY on OTG_HS interface

Additional context
Some ST parts (like STM32F74xxx / STM32F75xxx, maybe others) allow the USB_OTG_FS core to be used with either an external ULPI PHY or an internal full-speed-only (12mbps) PHY. Currently the code assumes than an ULPI PHY is used unless the chip has an internal high-speed PHY (#if defined(USB_HS_PHYC)), with no provision to use the internal FS PHY.

I'm not sure an #ifdef is the right way to do ...

fallow birchBOT
#
ottobonn
[hathach/tinyusb] Issue opened: #542 Host mode on Adafruit Feather nRF52840 Express

Hi there! I am diving in to TinyUSB because I am interested in using an Adafruit Feather nRF52840 as a USB host for a keyboard.

I have been playing around with modifying the Adafruit clone of the TinyUSB files to enable host mode, but in switching the CFG_TUSB_RHPORT0_MODE to OP_MODE_HOST it looks like I will lose the USB serial device for console logs.

I am trying to figure out what configurations this hardware supports and wonder if it's possible to have a USB host on it at all, ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

@PanRe yeah, actually we don't forgot it, we just don't have time to work on it just yet (as well as bunch of other issues :smiley: ).

  • We shift the parsing of the descriptors from dcd_synobsis into usbd.c (put get_ep_size_report() into usbd.c)
  • We change dcd_alloc_mem_for_conf() to be called with the generated EP size report i.e. dcd_alloc_mem_for_conf(uint8_t rhport, ep_sz_tt_report_t rep)

Thank you for your suggestion, I will definitely need it when looking at the issue late...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #543 net\_device: re\-factor code so as to not be specific to lwIP

When the net class driver was originally added to tinyusb, @hathach put in a "TODO should not include external files" comment in ./src/class/net/net_device.h

This PR re-factors the code to remove the dependency on these include files. It also has the benefit of making the net class driver not specific to lwIP, making it more agnostic as to which network stack is chosen by the user.

It does this by putting the lwIP-dependent portion of the code in ./examples/device/net_lwip_webserver/s...

fallow birchBOT
fallow birchBOT
hollow gust
#

I'm using tinyusb with an Adafruit SAMD core... I'd like to implement a yield function - as my own code needs to be sure to do something periodically..... But when USE_TINYUSB is defined, main.cpp defines yield() and there is no further hook.

#

Is there a known approach for doing something during "yield-time" when using tinyusb?

robust walrus
#

@hollow gust are you using tinyusb with arduino? tinyusb itself lets you control when it runs because you have to call into it

hollow gust
#

@robust walrus I'm using it with an Adafruit Feather M0 Express - so the Adafruit SAMD core. The issue is that main.cpp in that core has:

#if defined(USE_TINYUSB)

// run TinyUSB background task when yield()
extern  "C" void yield(void)
{
  tud_task();
  tud_cdc_write_flush();
}

#endif
#

So now there is no way to define your own yield function -- cause it is there.

robust walrus
#

by core you mean arduino right?

hollow gust
#

I mean the "core files"

#

but, yes

robust walrus
#

can you just comment that out and supply your own? I don't know arduino

#

tud_task() is what needs to be called regularly

hollow gust
#

well - yes... but that's hacking code that is part of an external library - and will get overwritten when updating...

#

Just thought perhaps tud_task had a hook or there was some magic way I wasn't hip to

robust walrus
#

you may have better luck asking in arduino

#

tud_task doesn't have any hooks that I know of

hollow gust
#

thanks

hollow gust
#

On Arduino, tinyusb functions can't be called from interrupt routines - right? Specifically I'd like to send and receive MIDI from a timer routine - but it seems to me that the FIFOs in midi_device.c aren't going to be safe.

#

Is that right?

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: use\-stm\-driver\-repo
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: use\-same51\-from\-asf4
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: cdc\-auto\-write\-flush
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

Hi @duempel. Thank you for working on this. I suspect that this is what I'm looking for. However, currently there are conflicts with the master branch. I've tried to resolve the conflicts myself because I also need patches from the master branch. Probably I did something wrong because I'm getting the following error with the latest version of ESP-IDF:

  0 panic'ed (IntegerDivideByZero). Exception was unhandled.

Core  0 register dump:
0x4008b01b: dcd_edpt_xfer at /home/dragon/esp/e...
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

Hello @dobairoland , thank you for your interest in this feature. Since TinyUSB's master branch has received a lot of updates in the last months, there are currently conflicts with this PR.

I will try to merge the current master into my branch tomorrow to update the PR draft quickly. The further changes to create the final PR will be done in the following days.

If you want to test the changes, I would be very happy. Keeping you updated.

fallow birchBOT
#
dobairoland
[hathach/tinyusb] Issue opened: #549 MSC device cannot be unmounted on Windows

Set up

  • PC OS : Windows 10 & Arch Linux
  • Board : Custom board based on ESP32-S2
  • Firmware: Slightly modified version of examples/device/cdc_msc

Describe the bug

Linux can unmount the disc without any issue. The device cannot be "ejected" using the same firmware on Windows. (The same computer is used)

To reproduce

Linux:

  1. tud_msc_write10_cb() invoked, lba=2, offset=0 - write root directory
  2. tud_msc_write10_cb() invoked, lba=0, offset=0...
fallow birchBOT
fallow birchBOT
#
tannewt
[hathach/tinyusb] New comment on issue #549: MSC device cannot be unmounted on Windows

I don't think this is up to tinyusb to do. In order to not appear again you need to track the eject and change the readiness of the drive.

The example doesn't do this because the drive is in RAM and always available. Relevant code is here: https://github.com/hathach/tinyusb/blob/master/examples/device/cdc_msc/src/msc_disk.c#L156

Here is how we do it in CircuitPython: https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/usb/usb_msc_flash.c#L210

fallow birchBOT
#
j4cbo
[hathach/tinyusb] Pull request opened: #550 Add CDC NCM implementation

Describe the PR
Add implementation of CDC NCM networking interface

Additional context
CDC-NCM is the newest USB class for Ethernet over USB, available here: https://www.usb.org/document-library/network-control-model-devices-specification-v10-and-errata-and-adopters-agreement

It has two main advantages over the earler CDC-ECM:

  • Instead of a direct mapping of one control transfer per datagram, NCM packs multiple datagrams into a transfer
    buffer ("NTB"), allowing for better ef...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@duempel Thank you for resolving the conflicts. Unfortunately, I'm getting the same error as before.

There is no device connected in the beginning when it fails on the first call of tud_cdc_write() for the reason of division by zero here.

I don't have this issue with 075334af80303488a8c874255d725cb4ca15a7de.

I believe that it can work on other platforms because the exception occurs ...

#
dhalbert
[hathach/tinyusb] New comment on issue #549: MSC device cannot be unmounted on Windows

We actually use the non-disappearance in CircuitPython so that we can use "Eject" to flush any remaining writes to the disk, but then not have to unplug and plug it back in. There is no other simple way to flush writes. This is particularly important because Windows in the past has not flushed writes to FAT12 drives for up to 90 seconds. Supposedly this has been fixed in newer versions of Windows 10, but I haven't had a chance to test it yet.

I'd like this to have a compile-time switch to ...

fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@dobairoland thanks for your feedback. It's not easy to spot the cause of this issue now. As far as I understand you are using your own user application. Have you tried to run the cdc_msc_freertos example on your esp?

My first thoughts were: It seems that an endpoint transfer (dcd_edpt_xfer) is called before the endpoint was opened correctly. This could happen for example if you write and flush data before calling tusb_init (due to task priority or other reasons). This could also e...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach based on the explained behaviour from my last comment I think it is useful to provide more stability and block application mistakes. In this PR I deleted the tud_cdc_n_connected() check within the tud_cdc_n_write_flush(). What do you think about adding a tud_ready() call or introducing a ready variable for every cdc interface to check before usbd_edpt_xfer calls?

fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

Thank you @duempel for the ideas.

I see in my logs that everything has been initialized.

USBD init
CDC init
MSC init
VENDOR init

It is not possible for my application to write before initialization because TASK A calls tusb_init and after that it starts TASK B which in the end starts TASK C which writes to CDC.

I will try the cdc_msc_freertos example to modify and report back on the results.

fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

The issue can be reproduced with the cdc_msc_freertos example as well by not checking tud_cdc_available() before attempting to read:

Rebooting...
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4002330d
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe6100,len:0x8
load:0x3ffe6108,len:0x1814
load:0x4004c000,len:0x9d0
load:0x40050000,len:0x2e30
entry 0x4004c1ec
I (48) boot: ESP-IDF v4.3-dev-1728-g2fc1d7f544-dir...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Wow, thank you very much for this great PR, this NCM is definitely new to me. This looks really good at quick look, though since it is pretty big addition, It will take time for decent review, I will try to review as much as I could. Meanwhile since it is still WIP, I will mark it as draft PR, feel free to mark it as ready when you think it work reliably.

@majbthrd is probably also interested in this PR as well.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.7\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

My first thoughts were: It seems that an endpoint transfer (dcd_edpt_xfer) is called before the endpoint was opened correctly. This could happen for example if you write and flush data before calling tusb_init (due to task priority or other reasons). This could also explain why it's working with use of tud_cdc_available() or tud_cdc_connected(). The use could delay your endpoint access calls until it's fully initialized.

All other API must be called after tusb_init(), applica...

fallow birchBOT
#
majbthrd
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Speaking personally, the things that I'd like to see are:

  1. either move NCM class driver files into ./src/class/net or we move existing ./src/class/net/ into ./src/class/cdc; having some CDC network implementations be more CDC than others doesn't make sense; thoughts from @hathach ?

  2. Share a single ./src/class/net/net_device.h with the same "Application API" and two sets of "INTERNAL USBD-CLASS DRIVER API": one for ECM/RNDIS and one for NCM.

  3. MOST IMPORTANTLY: adopt the exac...

#
hathach
[hathach/tinyusb] New branch created: initial\-same7x
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@dobairoland sorry for my late reply. The initialization process you described with task A,B and C seems to be good. But even in this scenario task C should not directly write to a cdc interface. The init call only prepares memory for cdc to work. But it is not opening an endpoint. This is done by the usb host when setting a configuration. You can see when a configuration is set within the log:

USBD Setup Received 00 09 01 00 00 00 00 00 
  Set Configuration
  Open EP 81 with Size = 8...
fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

Did you only remove the tud_cdc_available() check from the example and did not change anything else?

Yes, that was the only change:

diff --git a/examples/device/cdc_msc_freertos/src/main.c b/examples/device/cdc_msc_freertos/src/main.c
index 71225588..8cf013fe 100644
--- a/examples/device/cdc_msc_freertos/src/main.c
+++ b/examples/device/cdc_msc_freertos/src/main.c
@@ -169,7 +169,7 @@ void cdc_task(void* params)
   while ( 1 )
   {
     // is data available to read from...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
mmalex
[hathach/tinyusb] Issue opened: #555 What is the status of the STM32L4 port?

A few questions and then details about where I'm coming from

  • whats the status of the STM32L4 port?
  • do I need to edit the descriptors in the miditest example to make a windows PC recognise it?
  • if integrating into a project using ST's HAL libraries, should I configure the USB peripheral first using their routines, or not?
  • if not, is the hang in dcd_synopsys.c known about? is there a workaround?
  • how is the tinyusb interrupt handler hooked up? I can't see anything in the tinyusb co...
fallow birchBOT
fallow birchBOT
#
mmalex
[hathach/tinyusb] New comment on issue #555: What is the status of the STM32L4 port?

hello! I was able to make a bit of progress, so I can close this now but in case anyone finds this and wonders the same things as me:

  • the STM32L4 port seems to work for midi!
  • I discovered that I hadnt copied the hw/bsp/ folder over to my project, and so when searching for the interrupt handler's caller, I failed to find stm32l476disco.c; from that file I learned that it was simply a case of declaring this function in your code, this is weak linked by default to a stub:
    `void OTG_FS_IRQ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach I finally got some minutes to make the changes you suggested within your review. I kept this PR as draft, because I just add some changes to cdc example code, which I don't know if you like them. But we can make this to merge very soon. 😉

The updated cdc example uses tud_cdc_rx_cb callback to recognize if there is a connected terminal. If we receive character here we can be pretty sure that a connection is set up. Within the callback we then check the line state and can print in...

fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@dobairoland it's very difficult to help you debugging because I do not have the ESP here. But you could check if the error still occurs if you do the following changes:

  • Add TU_VERIFY( p_cdc->ep_out, ); at the beginning of _prep_out_transaction in cdc_device.c #L85

  • Add TU_VERIFY( p_cdc->ep_in, 0 ); at the beginng of tud_cdc_n_write_flush in cdc_device.c [#L180](...

fallow birchBOT
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

I'm getting a different behavior with the new commits in this PR.

USBD Xfer Complete on EP 03 with 31 bytes
  MSC xfer callback
  SCSI Command: Test Unit Ready
  Queue EP 83 with 13 bytes ... OK
USBD Xfer Complete on EP 83 with 13 bytes
  MSC xfer callback
  SCSI Status: 0
  Queue EP 03 with 31 bytes ... OK
USBD Xfer Complete on EP 03 with 31 bytes
  MSC xfer callback
  SCSI Command: Test Unit Ready
  Queue EP 83 with 13 bytes ... OK
USBD Xfer Complete on EP 83 with 13 bytes...
#
dobairoland
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

Here are the logs with the requested changes:

USBD Xfer Complete on EP 83 with 13 bytes
  MSC xfer callback
  SCSI Status: 0
  Queue EP 03 with 31 bytes ... OK

USBD Setup Received 21 22 03 00 00 00 00 00 
  CDC control request
  Set Control Line State: DTR = 1, RTS = 1
  Queue EP 80 with zlp Status
USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received 21 20 00 00 00 00 07 00 
  CDC control request
  Set Line Coding
  Queue EP 00 with 7 bytes
USBD Xfer Complete on...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rework\-class\-driver\-control
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #557 Rework class driver control transfer

Describe the PR
Current class driver hooks for control transfer is only control_request (setup stage) and control_complete(data stage). There is a need to introduce control_ack_complete() that invoked when the zlp of ack stage is complete. However, 3 callbacks with the same signature is a bit too much,. This PR merge 3 of them into control_xfer_cb(rhport, stage, request)

Note: the reason to add callback for status complete is for request such as CDC tud_cdc_line_state_cb, hand...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

thanks @duempel sorry for being late on response, I am on the run with other issue. And don't worry too much about the ESP if you don't have the mcu to test with. Just focus on what you think and could best test for the PR, I will do the test on esp32s2 and fix it if needed later on. This PR will be probably used very often by esp32s2 user. @dobairoland would you mind moving the log on a gist or something, the long log make pr discussion more difficult to follow.

fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on pull request #557: Rework class driver control transfer

However, 3 callbacks with the same signature is a bit too much,.

It's your code; I'm just a contributor :P. But I don't agree with this.

From skimming your changes, putting all the callbacks into one function creates a rather large control_xfer_cb function. You can trim control_xfer_cb by calling into the real inlined callbacks in each branch of the if/else chain. But isn't that inlining equivalent to what you're already doing before this change :P? This seems like more w...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #557: Rework class driver control transfer

However, 3 callbacks with the same signature is a bit too much,.

It's your code; I'm just a contributor :P. But I don't agree with this.

From skimming your changes, putting all the callbacks into one function creates a rather large control_xfer_cb function. You can trim control_xfer_cb by calling into the real inlined callbacks in each branch of the if/else chain. But isn't that inlining equivalent to what you're already doing before this change :P? This seems li...

fallow birchBOT
fallow birchBOT
#
charkster
[hathach/tinyusb] Issue opened: #558 USBTMC example not working on SAMD21

Setup
Setup 1:
PC OS: Windows 10
Board: Seeeduino Xiao (samd21),
Firmware: examples/device/usbtmc

Setup 2:
PC OS: Raspberry Pi OS (using pyvisa 1.11.1, pyvisa-py 0.4.1)
Board: Seeeduino Xiao (samd21),
Firmware: examples/device/usbtmc

Describe the bug
On Windows 10 pyvisa (using NI VISA backend) will not report the device.
On Raspberry Pi pyvisa reports the device, but the resource manager is unable to connect.

To reproduce
Steps to reproduce the behavior:

  1. ...
fallow birchBOT
#
RomaVis
[hathach/tinyusb] Issue opened: #559 tusb\_init\(\) returns incorrect value

Affected versions
At least 0.7.0 and latest master (589dfdb)

Describe the bug
It's a simple coding bug in tusb_init() implementation:

bool tusb_init(void)
{
  // skip if already initialized
  if (_initialized) return true;

#if TUSB_OPT_HOST_ENABLED
  TU_ASSERT( tuh_init() ); // init host stack
#endif

#if TUSB_OPT_DEVICE_ENABLED
  TU_ASSERT ( tud_init() ); // init device stack
#endif

  _initialized = true;

  return TUSB_ERROR_NONE;
}

The functio...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #559: tusb\_init\(\) returns incorrect value

I don't fully understand the idea behind returning error code / status from this function if it uses TU_ASSERT to handle errors... Even if we fix it to return true on correct initialization, it will never be able to return false because of those assertions...

Ah right, thank you for openning the issue, this is left over from legacy code. will fix it right away.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-559
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach thanks for merging your latest changes in here. If you want to test out the functionallity I could recommend HTerm to you. Usually I use this terminal on windows, but it's also available for linux. HTerm has the ability to manually control DTR and RTS bits with buttons.

Since it has been going for a while, I will merge it now and do a follow up with tud_ready() check

Alright, I feel good with this. Thanks for your help and I'm happy we finally get this to master.

#
hathach
[hathach/tinyusb] New comment on pull request #506: CDC without DTR being set

@hathach thanks for merging your latest changes in here. If you want to test out the functionallity I could recommend HTerm to you. Usually I use this terminal on windows, but it's also available for linux. HTerm has the ability to manually control DTR and RTS bits with buttons.

Since it has been going for a while, I will merge it now and do a follow up with tud_ready() check

Alright, I feel good with this. Thanks for your help and I'm happy we finally get this to master.

...

fallow birchBOT
fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21

I did notice this in DMESG on the raspberry pi:

[ 2.214996] usb 1-1.4: new full-speed USB device number 4 using xhci_hcd
[ 2.354164] usb 1-1.4: New USB device found, idVendor=cafe, idProduct=4000, bcdDevice= 1.00
[ 2.354184] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.354202] usb 1-1.4: Product: TinyUSB Device
[ 2.354218] usb 1-1.4: Manufacturer: TinyUSB
[ 2.354234] usb 1-1.4: SerialNumber: 123456
**[ 2.359368] usb 1-1.4: can't set con...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-tud\-connected
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: correctly\-invoke\-scsi\-callback
#
hathach
[hathach/tinyusb] Pull request opened: #562 msc only invoke scsi complete callback after status transaction is complete

Describe the PR
There has been some race condition between host software and device handling with scsi complete callback. E.g windows complain when reboot from bootloader to application since status is not yet sent to host. This fix #375

@dhalbert may want to give it a try with issue on internal flash file system on nrf52840, or maybe pointing the user with the issue to test with this.

fallow birchBOT
fallow birchBOT
pseudo sinew
#

What gdb server do people use for tinyusb dev?

odd swan
#

@pseudo sinew I’ve seen some comments mention using openocd

#

Well, OpenOCD running GDB Server

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-esp32s2\-suspend\-wakeup