5 Commits

Author SHA1 Message Date
Karl Palsson
d97c1b0435 tests: gadget0: delay between calls to trigger races
Attempt to be more brutal by delaying more often, instead of always
promptly servicing the usb stack.

This is implemented via using timer6 to do a known number of
microseconds busy delay, and so only works on platforms that have
reached at least core timer functionality, and provide the
rcc_apb1_frequency variable.

NOTE! This will _fail_ on devices using the st_usbfs drivers at present,
but the code _should_ work, and the tests land to verify that the
library fix, fixes the problem. (see subsequent commit)
2017-06-08 23:01:45 +00:00
Karl Palsson
c9c5cb7c9c style: fix some of the easier style bugs
No real changes.
2017-03-30 21:48:07 +00:00
Karl Palsson
b81588da74 tests: gadget0: Update for namespace cleanups
Fixes: 3a7cbec776bc9b9b53eefc26d5bf365466977e5a
2016-01-05 18:00:00 +00:00
Piotr Esden-Tempski
b1049f9a6f [Style] Stylefix sweep over the whole codebase. 2015-12-14 22:57:15 +01:00
Karl Palsson
34f00a7d5a tests: usb: gadget0 compatible interface (stm32f4)
This introduces the first firmware setup specifically for automated testing.
Based heavily on the linux kernel project's "USB Gadget Zero" idea, and in
theory, this should be testable with <kernelsrc>/tools/usb/testusb.c but...
not yet.  It's tricky to set that up and poorly documented, so we've got our
own tests instead. Instead, we include a set of python unit tests using pyusb.

These currently only test a basic core subset of functionality, but have already been
very helpful in finding latent bugs.

In this first stage, we support only the stm32f4 disco board, (MB997) and
FullSpeed USB devices.  A generic "rules.mk" is introduced to support multi
platform builds. (See below)

Some basic performance tests are included, but as they take some time to run,
you must manually enable them. See the README for more information

NOTE! Only the source/sink functional interface is supported, loopback will require
some comparision with a real gadget zero to check exactly how it's working.

FOOTNOTES 1:

This introduces a rules.mk file that is arguably substantially simpler[1] for
re-use, and then uses this rules.mk file to support multiple target outputs
from the same shared source tree. Less path requirements are imposed, and less
variables need to be defined in each project's makefile.  A separate bin
directory is created for each project.

All useful settings and configurations imported from the original library rules
file.

cxx support untested, but lifted from the original library rules file.

[1] Than the file in the libopencm3-examples repo it is loosely based on.
2015-10-03 00:58:43 +00:00