USB Composite library question

Working libraries, libraries being ported and related hardware
Posts: 1322
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB Composite library question

Post by ag123 » Tue Aug 28, 2018 8:14 pm

on a different note, this usb composite library is a volunteered effort, hence, i really thank apruss for investing effort in this and sharing this

i think separating the use cases / device classes has a rather strong merit, that would make usb-serial on its own, usb-hid on its own, usb-storage on its own etc. within usb-hid i think there could be even finer sub-division of the 'use cases' i'm finding that usb-hid is literally 'pretty big'. if one make say a keyboard + joystick + mouse + sensor feedbacks (e.g. temperature, pressure, etc) i think hid could literally cater for it.

making a usb-composite device would then take a little more effort, perhaps a little bigger or if one needs to fork it and create a 'custom' usb-composite version that is size optimised for the multiple purposes.

the notion of developing distinct use cases / device classes on their own is that there are a large multitude of usb device classes / use cases

this being a volunteer effort, others could then chip in and develop other device classes e.g. usb-audio, usb-imaging, usb-ethernet, usb-irda in a similar framework and extend this library.
that would make the BP/MM live up to what it really is: a generic usb device, its role dependent on how one makes the sketch and this library that runs on it and perhaps any additional adjacent peripherals

Posts: 26
Joined: Tue Aug 21, 2018 5:30 pm

Re: USB Composite library question

Post by Janus » Tue Aug 28, 2018 8:39 pm


Most inhouse projects start small, for one job, then someone starts just adding things at random.
When I have had to restructure existing code for customers, I always use the same basic structure.
Device driver, usb_base.h as an example, I am not very original at naming things.
Then do something with it, usb_hid.h to follow the theme here.
Expand that with usb_keyb.h, usb_mouse.h, usb_gamepad.h, or more of the like, each of which could #include
I am not a real C/C++ programmer, so excuse me if I get some of the syntax less than perfect.

That leaves usb_raw.h if you want the bare packets for some reason.
usb_temp.h for a temperature sensor.
usb_bt.h for bluetooth, which a bluetooth responsive program could include.
usb_???.h for something no one here has thought of yet.

Chain them backwards via includes, and only the pieces needed are ever included.
Thus usb_hid.h just sends and receives hid packets, but nothing else.
Jut as each layer only does its job, nothing else.
You don't need to plan for every possible value, just what you will be using.

This is what I had planned on doing with usb, once I actually managed to figured out anything about it.
This library will save me a lot of time, and anything I can improve about it, I will post back here so if it helps others, they can use it as well.


Posts: 1322
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB Composite library question

Post by ag123 » Wed Aug 29, 2018 6:31 am

one thing to note that writing a usb device class driver (e.g. hid) library is pretty much the app / sketch itself. the main arduino loop() does 'nothing'
hence, i'd encourage 'observers' to try it out and possibly extend it, i.e. write new usb device class cases which could be added to the 'library'.
this 'library' is literally a collection of apps / sketches. it isn't really simply a 'library'

Posts: 282
Joined: Sat Sep 30, 2017 3:34 am

Re: USB Composite library question

Post by arpruss » Fri Aug 31, 2018 12:32 pm

Before people write implementations of new usb classes, I would prefer to refactor the code. It currently has one major limit: a composite device can only have one instance of each plugin (e.g., only one serial).

Posts: 26
Joined: Tue Aug 21, 2018 5:30 pm

Re: USB Composite library question

Post by Janus » Fri Aug 31, 2018 3:20 pm

For my part, I am not even starting until I finish getting F107 board support working.
So far, that is lots of fun already.

I am going to wait until someone makes sense on how the packets are received or transmitted before I do anything.
Right now, usb is a mess, and I fail to understand the flow logic.
Thus I will wait until I manage to find a demo or program that uses usb otg, then disassemble the result to analyze on the assembly level.

I know people will say to just read the sourcecode, but I am not a real C/C++ programmer.
What I do is match existing patterns until I can see under them.
The logic level is where I work, and C/C++ is tedious at best in my eyes.

I don't really like the arduino ide much, but it so much easier to use than the alternatives that it is worth the hassle.


Post Reply