Hi Karl and all who replied both on-list and off-list.
In the end, I did manage to get it working. (thanks to tools like jtag debuggers, openocd and gdb :-) ), at least for an application that just sends data. One of the things I notice it that, when using "usbd_ep_write_packet", you may not send "print" to fast or else you can "choke" it and lost print-commands. It's better to use this: while (usbd_ep_write_packet(usbd_dev, 0x81, buf, sizeof(buf)) == 0); (or even better add some "timeout" mechanism) Concerning your comments below (user callbacks running in the interrupt context), can you explain how USB really works? I have been reading-up on USB and -as far as I understand it-, it works like this: - USB is a master-slave protocol, with the master (aka "host") being the PC and the STM acting as slave (AKA "device") - All transactions on the USB-bus are initiated by the messages from the host (every ms) - There are several types of messages, but for us, two types are important: user data packets and control-packets - For both types of messages, there is a seperated link-layer connection. Therefor there are always at least two "endpoints": one for control and at least one for a data-path) - there is a hardware auto-sence mechanism (based on pulling one of the datalines high) which tells the USB host that a USB device has been added. But I guess this is all handled by the USB controller on the STM32F103. So, from a software point of view, - you first initiatlise a number of datastructures, for the USB protocol itself, for the endpoints, etc. - you define a number of callback functions - you do "usbd_init" Once that is done, you need to continuesly call "usbd_poll". If I understand it correctly, usbd_poll checks if there is data to be processed by the USB lbrary (based on the actual state of the USB controller), and call the callback functions if needed. Hence, if you call usbd_poll from inside a ISR, all resulting actions will also be done in the interrupt context) Is this correct? BTW. When exactly is the USB ISR called? What exactly triggers this interrupt? What is -for me- not clear is if -as there are multiple end-points- calling usbd_poll once is enough to process all data that might be waiting-for-processing in the USB controller, or if you need to call for every packet that comes in or needs to be send. (so, do you need to call usbd_poll for every packet you send out or receive, or just once) One of the things I did notice is that -once you call usbd_init- you may not wait to long to call usbd_poll, or else the device is not recognised by the USB host. My guess is that calling usbd_init triggers a protocol transaction between the host and the device, which all end up on the "control-endpoint", and therefor you need to call usbd_poll enough to process these packets. Is this correct? I guess this means that -calling usbd_poll from the ISR- is a good practice for "control"-packets as it garantees that the traffic will be processed fast enough by the USB library and keep the USB protocols up and running-. However, for user-data traffic, it would be better to call it from outside the ISR. So what would be best here? And how would one implement this? (I am sorry for all the questions. I just like to understand how it all fits together). Cheerio! Kr. Bonne. On 04-03-17 21:48, Karl Palsson wrote: > It's worth mentioning that it's not really recommended to try > calling usbd_poll from the irq handler, as it ends up with all > the user callbacks running in interrupt context. > > > Dave Hylands <dhyla...@gmail.com> wrote: >> I did a version for the STM32F4 which you can find here: >> https://github.com/dhylands/libopencm3-usb-serial/blob/master/usb-serial.c >> >> I set things up to call usbd_poll from the isr handler: >> https://github.com/dhylands/libopencm3-usb-serial/blob/master/usb.c#L290-L295 >> >> and then uses the SOF handler to transfer bytes into a circular >> buffer. >> >> >> On Thu, Mar 2, 2017 at 3:00 PM, kristoff <krist...@skypro.be> >> wrote: >> >>> Hi, >>> >>> >>> Can somebody explain how to really use the CDC ACM (serial over usb) on >>> a STM32F1? >>> >>> >>> In libopencm3-examples, there is an example on using cdc acm >>> (serial-over-usb), however I cannot modify the example to do something >>> usefull. >>> >>> The example only sets up the cdcacm-device and then does two things: >>> - there is an endless loop that just does usbd_poll >>> - inside the callback function, there is some code that echoes the >>> characters it received back to the usb-device. >>> >>> >>> But how do you write an application that actually does something usefull? >>> When I modify the "usbd_poll" loop to actually does something (like just >>> print out a line "count = ...", this results in errors when I boot the >>> device (i.e. "Device not responding to setup address."). >>> >>> So it looks like you really need to have this continues-cycle of the >>> usbd_poll running. >>> >>> >>> So how I you actually make an application that uses that cdcacm >>> interface and make it actually do something usefull? >>> >>> >>> >>> Cheerio! Kr. Bonne. >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> libopencm3-devel mailing list >>> libopencm3-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! >> http://sdm.link/slashdot_______________________________________________ >> libopencm3-devel mailing list >> libopencm3-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
