one thing though: this thing started because I almost felt like I had 9600bps speeds (worse than serial)
but was it due to the implementation or some hidden flaw
(well, you used the blue pill built-in usb connector, that one only does usb 1.0)
(you should have made an external usb connector via the gpio pinouts)
if, for example, you set your EP to be of interrupt transfer type you could get a trickle of only 64b per milisecond :)
the mac assumes a 12mb/s speed
let me double check bmAttributes
0x02 = assuming this is bulk transfer because
Bits 0..1 Transfer Type
00 = Control
01 = Isochronous
10 = Bulk
11 = Interrupt
Bits 2..7 are reserved. If Isochronous endpoint,
Bits 3..2 = Synchronisation Type (Iso Mode)
00 = No Synchonisation
01 = Asynchronous
10 = Adaptive
11 = Synchronous
Bits 5..4 = Usage Type (Iso Mode)
00 = Data Endpoint
01 = Feedback Endpoint
10 = Explicit Feedback Data Endpoint
11 = Reserved
I'd check
lsusb -v on the host to be extra sure (that's a linux thing though)
that decodes bmAttributes among other things
but whatever 0b10 seems right
There is exist some tool to generate initialization code like CubeMX but for libopencm?
Hello
I'm trying to get usb cdcamc example (loopback) working on f413 board of my own design. The code works on f411 black pill but not on f413, anyone know of specific difference in usb implementations between these? I thought they were basically the same. Also worth mentioning is that dfu bootloader enumerates fine so I don't think its a problem with the board but when running my code it shows no activity whatsoever on usb data lines.
I'm trying to get usb cdcamc example (loopback) working on f413 board of my own design. The code works on f411 black pill but not on f413, anyone know of specific difference in usb implementations between these? I thought they were basically the same. Also worth mentioning is that dfu bootloader enumerates fine so I don't think its a problem with the board but when running my code it shows no activity whatsoever on usb data lines.
hello it was a while ago so dont remeber everything required but i got i2c-star going on the nucleo 413zh here is the code https://github.com/hackthedumpster/i2c-star-f413hz i bbelieve it required sum patching to libopencm3 the repo has its own libopencm3 with it. could try the firmware as is and if it works on your board copy the lopc3 over to your project. May wanna check if i disabled vbus sensing etc as well.
about halfway down in this issue is a list of pull requests for various usb fixes, most likely these (or some combination of them) is what i used to get the usb on the 413 going. libopencm3/libopencm3#1309 .The 413zh is interesting with newer features like being able to run code from spi flash, 10uart's, 6usb endpoints but clocked at a slower 100mhz. Anywho ive found those patches useful for a variety of my boards, i do believe the 413 among them.
So despite being outa my depths i decided to try and use my 2 usb3300's and my h7 portenta with ulpi onboard. And with the luck of Forrest Gump after adding a few defs and changing the f207 usb driver init all 3 enumerate and work! I imagine more hasta be done, i thought i needed to setup sum larger buffers based on amount/type of endpoints etc.So if anyone knows of more things i need to setup please let me know. But After they worked I moved on. I managed to get the 16mb of external ram on the portenta setup and going and this is my main question. The methods ive found thus far for integrating the ram as system mem in the ldscript requires edits to assembly written startup scripts. Not sure the best course of action. Best case is libopen has support for integrating external ram as system mem and i just need to supply it sum info..havent seen that yet but im hopeful.I guess hacking the vector file thats part of the linker script generation is doable but probly not the best solution.Any thoughts are appreciated. If it was ez enuff for me to do i caint imagine anyone else would need it but i can throw my usbhs/external ram code on github if anyone needed it, expect beginner level of code tho.