This has failing tests, and doesn't implement (yet) the delay routines,
so it won't even compile without disabling that functionality in the
core gadget0 code. However, it passes most tests, and it demonstrates
that the changes made to the setup handling earlier haven't broken USB
on this platform.
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)
As with F103 generic, there's no readily available L1 board with USB device
A custom LED is used to track boot process, but otherwise this should be
portable to any L1 board, except for the openocd configuration file.
Tests pass straight away, which is good, as it uses the existing f103 usb
driver.
There's no F1 discovery style board with usb device, so this is for a "generic"
device. The USB portion should be safe, but there's a led used for bootup that
is board specific, and of course the clock source is board specific.
Related, the openocd config file is rather custom to my own setup, but shows
what you need to customize for your test environment.
Further, as the F1 usb core doesn't include support for soft disconnect, use
the very hacky method of dragging the pin low to force reenumeration on reset.
Very very useful for development purposes!
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.
-ggdb3 make slightly bigger .elf files, but allows gdb to understand
macros, which libopenocm3 uses somewhat extensively. Make this the
default, and pull it up to the common base makefile, so it can be easily
substituted.
On linux, the output of CP rule was try to write to / which is - of course, forbidden for write.
This solution adds to each part of lib correct pointer to the root of lib where the libs should be written.
Bug found by Kuldeep Singh Dhaka.
We currently default to "-mfloat-abi=hard -mfpu=fpv4-sp-d16" for M4F cores, and
and variations of "-mfloat-abi=soft" for the others. Keep the M4F default, and
move others to no FP flags for consistency, but allow overriding these flags
via the FP_FLAGS environment variable.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
previously, only stm32 chips passed the information about which chip to
build on into the compiler. this information is essential to dispatch,
thus defining LPC13XX, LPC17XX, LPC43XX and LM3S in analogy to
STM32F1..4.
vector.o, nvic.o, scb.o and assert.o are available on every platform,
but at least some of them differ between the implementations. they
already got built explicityly on some platforms; now adding them to the
common Makefile.include.
Adds libopencm3/cm3/assert.h header that provides assertion check macros
similar to those provided by the standard C library.
Thanks to Nicolas Schodet for help.
- The library files are now being built into the lib subdirectory of the
source.
- The linker files for each library are being copied into the lib source
subdirectory.
Motivation: The relative locations of files in the source directory after make
are now the same as after make install now. This makes it easier to
reuse examples with their makefiles outside of the libopencm3
sourcecode directory.
Karl Palsson
Karl Palsson
Felix Held
Frantisek Burian
Alexandru Gagniuc
Gareth McMullin
Gareth McMullin
Piotr Esden-Tempski
chrysn
Tomaz Solc
Taylor Vesely