example interfacing a STM32F4 with libusb

[Mathias]

Tectu,
you have to compile the test program and run it.

Code: Select all

$ gcc -lusb-1.0 -o test test.c
$ sudo ./test

You need the sudo, because it needs write access to the device. If you install the udev rule I provided, you don't need sudo. In order to install it, copy the "50-USB-test.rules" to /etc/udev/rules.d/ or similar and reload the rules (I forgot how, either google or restart the computer).
If you have problems, hit the reset button on the Discovery, then run "$ dmesg | tail" and see if a "ChibiOS/Custom Hardware" comes up.

[Badger]

copy the "50-USB-test.rules" to /etc/udev/rules.d/ or similar and reload the rules (I forgot how, either google or restart the computer)

restart udev (may not be necessary), and re-insert the USB device and it should run the new rules

[Mathias]

You have to either restart udev or at least tell it to reload the rules. "sudo service udev restart" may do the job, depending on what distribution you use. There is also a udevadm command that doesn't need you to restart udev...

On a sidenote, I pushed a new version that only inits the transfers after the USB_EVENT_CONFIGURED occured. That should fix the "connect cable after device startup" problem, there is still a problem where disconnecting the cable should reset the states.
*edit*
I think device reconnection now works. This is probably the first version that has no major flaws on my system. Although I still don't know if I completely obey the specs (which I kinda doubt).

[Tectu]

Thanks for the explanation. I'll try it out as soon as I am back home the next time.


~ Tectu

[kjellhar]

Not too difficult once you figure out what to do.

once you figure out what to do ...

Yeah-yeah, I know that was kind of a stupid statement . What I should have said was that it was that the code involved was not too difficult to understand once you figured out what to do. The USB part of the AVR32 framework was a complete mess, but after cleaning up and removing about 90% of the code, it was not too bad.

The Chibios driver looks much better, and I have no doubts that I will get it to run before long, but I also hope there will be some more documentation available soon.

Also, I know all of the major OS' hare handling USB slightly different, or at least they used to, which makes life hard for us implementing devices.

[kjellhar]

On a sidenote, I pushed a new version that only inits the transfers after the USB_EVENT_CONFIGURED occured. That should fix the "connect cable after device startup" problem, there is still a problem where disconnecting the cable should reset the states.
*edit*
I think device reconnection now works. This is probably the first version that has no major flaws on my system. Although I still don't know if I completely obey the specs (which I kinda doubt).

You new version worked on my Mac. I was suspecting that you was starting the transfer too soon, because the uC got an exception before I was even close to running the "test" program on my Mac. I'm surprised it actually worked on Linux.

I wouldn't worry too much about "completely obeying the USB spec" considering the complexity of it. As long as you can connect the device to all the major platforms without causing freezes or instant restarts, I would consider it a success. Not unlike the saying in aviation: A good landing is one you walk away from.

Again Mathias, thanks for your work. You just saved me many hours (or days) of work. I was just about to start this project with the exact same goal as you when I saw this thread. I will continue to work on you code. If you need to confirm some functionality on the Mac platform, don't hesitate to ask

Cheers,
Kjell

[kjellhar]

Oh Mathias, in your test.c code

Code: Select all

/*
 * on SIGINT: close USB interface
 * This still leads to a segfault on my system...
 */
static void sighandler(int signum)

This also failed on my Mac. Try to disable the debug options. I just commented out this line in main

Code: Select all

  //libusb_set_debug(ctx, 3);

and it worked.

[Mathias]

I think the chThdSleepMilliseconds(1000) after the usbConnectBus helped Linux recognize the device. Nice to see this version works on all major platforms now. If nobody has any problems using the device, thats enough for me. I realized, the ST-Link on the device aswer to the 0xEE String descriptor with a malformed packet too. So either its not specified what should happen on an out of index String or its not spec compliant either...

The sighandler wasn't really that helpfull anyways. What exactly fails on your mac? Didn't it compile or did it crash on runtime? Finding a proper solution shutting down the program is still on my todo list.

And I'd say the same thing about this project. Its not hard to understand what I'm doing there, but since this is my first coding on any uC and the first time I do anything with USB, it was quite a learning curve for me. But I can say, I learned a lot about it.

Another thing I wanted to share, since I'm usually quite lazy, I wrote a small python script to generate those String descriptors for me:
http://pastebin.com/thji78Wa
I'm pretty sure someone has done that before, but I searched quite a while for an Descriptor Generator and didn't find any... I don't think I will finish the whole descriptor generator though.
If someones google foo is better then mine: Drop a note.
Also if anyone has tips to improve the speed...

[kjellhar]

Just one question.

Why isn't it necessary to run "usbObjectInit". I noticed that in the SerialUSB example, the presumably equivalent function, "sduObjectInit" is called before anything else in the serial USB system.

[Mathias]

Because:

Code: Select all

/* ... This function is implicitly invoked by @p halInit(), ...*/
void usbInit(void) {
  usb_lld_init();
}

Code: Select all

void usb_lld_init(void) {
  /* Driver initialization.*/
  usbObjectInit(&USBD1);
}

On the other hand, sduObjectInit inits two queues and some flags...