successfully ported the tinyUSB stack to the STM32G0 core :-) :-) :-)

[Commotari]

I just ported the existing code from dcd_stm32_fsdev.c and dcd_stm32_fsdev_pvt_st.h to run on my STM32G0B1RE Nucleus board :-) :-)

How is the process of contributing to this repository?

Because the changes to the existing files are a bit more than nothing, i added new files with 'g0' added to the file name.
Also the header file needed some changes because there are a lot of inline functions inside that I changed.
So I decided to add new files and not trying to squeeze the changes into the existing files with tons of ifdef macros.

greetings,
Stefan from Linz, Austria (aka WhyLee).

[hathach]

It is great to hear you get tinyusb running on G0. Since G0 using the same fsdev driver, both the .c and .h should be updated accordingly with ifdef where needed. Adding new files is not necessary since it will cause more work than needed to maintaining the driver. Feel free to submit PR when you think it is ready, people will help to review and get it merged.

[Commotari]

i will try to fuse the files together

[Nikitarc]

Are you sure you must add G0 support to fsdev driver?
Why not to sysnopsys/dwc2 wich supports most recent STM32s?

[hathach]

I just double checked G0 manual, it is indeed using fsdev driver. ST use both dwc2 and fsdev. fsdev mostly use with cost-efficient line I guess.

[Commotari]

the fsdev driver is similar to the code that stm puts out with their cubeIDE. but the buffer memory is different.
it has a problem with 8 bit and 16 bit writes, the rest of the 32bit are getting filled out with the same value when using them.
so, i had to change the access in most functions to 32 bit registers to 32-bit read-modify-write access instead of 16 bit writes that have been used in the previous driver. the same applies to the buffer copy functions. and a lot of the bits in the registeres changed, but most of the time to similar functions/names.
the only problem I had was with activating the logging with higher debug levels. in my case it used my uart and that messed up the interrupt. after deactivating my debugging uart outputs, my elisys usb analyser and the usb command viewer from usb-org showed no problem anymore.
i would not consider myself to be a usb expert. but it looks good so far. i will need a few days to clean up the stuff before i am able to do a pull request.

[hathach]

take your time, there is no rush at all.

[Nikitarc]

I heard that fsdev is deprecated and will be removed from tinyusb...

[HiFiPhile]

No you have mixed dcd_synopsys with fsdev.

dcd_synopsys is deprecated by dwc2, fsdev is for low-end STM32 MCUs.

[MikeEmbedded]

Hi @Commotari

Can you share your port of the TinyUSB to the STM32G0?

[andrewleech]

Hi @Commotari, how did you go merging your changes into the existing driver? I'm interested in getting the g0 chip going myself so would be happy to help, even if you wanted to share your split off files I could help with combining it all?

[HubertD]

I didn't have time to wait for the OP to share the code, so I tried to help myself.
Was quite a bit of work and the result is somewhat ugly, but I created a RFC PR: #1942

Seems to work on my machine (tm)

@andrewleech @MikeEmbedded would be great if you could test on your hardware,
@hathach looking forward for some review & advice :)

[Commotari]

hello guys, in the archive are the two updated fsdev files that i modified for my STM32G0B1xx mcu. so far the device presents itself when plugging the stm32 device in my windows notebook and with some compatibility check software, all seemed working. (descriptor download works fine). now as i am starting to implement a HID device with an additional raw channel, i will see if everything will work stable longterm. will still take a few days to confirm. but as the descriptor exchange is always working fine, i assume that all the other things should work as well. Am Mi., 8. März 2023 um 12:55 Uhr schrieb Hubert Denkmair < ***@***.***>:

…

I didn't have time to wait for the OP to share the code, so I tried to help myself. Was quite a bit of work and the result is somewhat ugly, but I created a RFC PR: #1942 <#1942> Seems to work on my machine (tm) @andrewleech <https://github.com/andrewleech> @MikeEmbedded <https://github.com/MikeEmbedded> would be great if you could test on your hardware, @hathach <https://github.com/hathach> looking forward for some review & advice :) — Reply to this email directly, view it on GitHub <#1757 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZTPL4NEQYWXYHI3ZKVQP3DW3BXTBANCNFSM6AAAAAASKI2PRI> . You are receiving this because you were mentioned.Message ID: ***@***.***>