Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:28
    slorquet commented #1466
  • 15:19
    karlp closed #1466
  • 15:19
    karlp commented #1466
  • 14:50
    slorquet opened #1466
  • 14:49
    slorquet closed #1465
  • 14:34
    slorquet opened #1465
  • 14:23
    karlp closed #1464
  • 14:23

    karlp on master

    stm32h7:usart: add common file … (compare)

  • 14:21
    karlp commented #1464
  • 13:22
    slorquet closed #1452
  • 13:22
    slorquet commented #1452
  • 13:21
    slorquet opened #1464
  • 12:29
    karlp labeled #1452
  • 10:55
    slorquet commented #1452
  • 10:48
    slorquet commented #1452
  • 10:43
    slorquet commented #1456
  • 10:37
    slorquet commented #1456
  • 02:54
    neoxic commented #1458
  • 02:50
    neoxic synchronize #1458
  • 02:43
    neoxic synchronize #1458
dxld
@dxld:it-syndik.at
[m]
(assuming you don't pass in len=0)
Yusuf Celik
@YusufCelik
yeah, I could look into that
dxld
@dxld:it-syndik.at
[m]
that shouldn't happen if you just got an IN callback tough
Yusuf Celik
@YusufCelik
I still wonder whether you and I are on the right track with regards to our assumptions
we thought we could just simply keep pushing data via the callback
but was that how libopencm intended to support usb transfers
dxld
@dxld:it-syndik.at
[m]
I mean I implemented a working production usb device using this code and I got the code right here :)
Yusuf Celik
@YusufCelik
I also found thi
there is a part that is interrupt based and has a similar idea to ours:

```static void bulk_tx_cb(usbd_device * usbd_dev, uint8_t ep)
{
char buf[64] attribute ((aligned(4)));

(void)ep;

/* Keep sending packets */
usbd_ep_write_packet(usbd_dev, 0x82, buf, 64);

}```

"keep sending packets" <<< evidenced by this
dxld
@dxld:it-syndik.at
[m]
and I read the ST peripheral register docs multiple times over, though I guess mine was _v2 on a STM32F0 instead of _v1 hmm
Yusuf Celik
@YusufCelik
wish I had the host code for this
dxld
@dxld:it-syndik.at
[m]
did you have a look at the gadget0 test/example code?
that has a host side thing too you can play with
Yusuf Celik
@YusufCelik
hopefully they do not say "look example for bulk transfers" let's just write 64bytes!!!!
haha
dxld
@dxld:it-syndik.at
[m]
perhaps, not sure :)
Yusuf Celik
@YusufCelik
(facepalm; but I can already do that. I just need an example that exceeds that number and performs at speed)
one thing though: this thing started because I almost felt like I had 9600bps speeds (worse than serial)
dxld
@dxld:it-syndik.at
[m]
it's still worth a look I think
it runs a bunch of different tests
Yusuf Celik
@YusufCelik
initially, when I used my HOST -> request -< MCU send data loop (4096) to send 256kb
4096 times of 64bytes was abysmally slow
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)
dxld
@dxld:it-syndik.at
[m]
I guess it's also possible your descriptors are just wrong
if, for example, you set your EP to be of interrupt transfer type you could get a trickle of only 64b per milisecond :)
Yusuf Celik
@YusufCelik
Screen Shot 2022-06-19 at 10.40.54 AM.png
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
dxld
@dxld:it-syndik.at
[m]
I'd check lsusb -v on the host to be extra sure (that's a linux thing though)
Yusuf Celik
@YusufCelik
lsusb Speed: Up to 12 Mb/s
dxld
@dxld:it-syndik.at
[m]
-v would give you a Device Descriptor: readout
that decodes bmAttributes among other things
but whatever 0b10 seems right
Alexander Voronov
@crvux
Hello!
There is exist some tool to generate initialization code like CubeMX but for libopencm?
hazardousfirmware
@hazardousfirmware
Hello! is there an example to set up the RTC on stm32f1 to count while using VBAT?
Currently using rtc_auto_awake(RCC_LSE, 0x7fff); it saves the count register but doesn't increment. thanks
Achintya-Chaware
@Achintya-Chaware
Hi! I am just getting started. I wanted to know how to use libopencm3 with STM32 Cube IDE. Any resource available?
karl
@karlhh
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.
Ben Maddocks
@bm16ton
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.
karl
@karlhh
Thank you Ben! I will look into it tomorrow, time to go to bed now.
karl
@karlhh
@bm16ton I love you man! Just switched to your version of libopencm3 and it works! I'm going to look closer into the difference in /lib/usb/ and see if I can pinpoint what made it work.