It's always stream on the "new" dma controller (unless it's channel....)
Fix a couple of inconsistent prototypes that had carried over from f1
originally. Reported by vampi on irc.
the 2014q3 or later toolchains are now readily available, and we should
now just consider this a user problem. This gets us out of trying to
parse compiler help output and chasing our own tail.
Fixes https://github.com/libopencm3/libopencm3/issues/965
Much as we had to pull in the individual target's include files
manually, because they're useful without necessarily having .c files
using them, the cortex core headers also need to be included. This also
pulls in the doc-cm3.h file that setup nice groupings.
They were originally used to make sure that the doxygen was generated
correctly, but that style is no longer necessary.
There may be more peripherals that can be "cleaned" like this, but let's
do them one step at a time, as we work on that area.
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.
See https://github.com/libopencm3/libopencm3/issues/873
Commentary describing this patch originally by zyp:
```
After looking further into it, I've concluded that my preliminary
analysis looks correct. The problem is that setting CNAK before
the SETUP complete event is received causes a race condition. The
SETUP callback is called when the SETUP packet event is received,
which means that setting CNAK from the callback is too early.
Originally the problem was that CNAK was set by ep_read() which is
called by the callback. #672 solved this by moving CNAK out of
ep_read() and calling it after the SETUP complete event is received
instead.
The regression by #785 is caused by the introduction of flow control
calls into the SETUP callback. They also set CNAK.
To solve this properly, I propose changing the event handling code
to only call the SETUP callback after the SETUP complete event is
received. Unfortunately, this implies that the callback can't call
ep_read() itself anymore, because the packet has to be read out of
the FIFO before the SETUP complete event arrives. This implies a
change of the API between the hardware drivers and _usbd_control_setup().
```
L1 (st_usbfs) works and passes tests as before change
F4 (dwc_otg_fs) works and now passes tests. (yay)
LM4f still compiles, and has had the same style of implementation as
st_usbfs, however has not been tested on any hardware.
usb_disconnect() is board/platform specific for chips that don't have
built-in handling for this. Allow the application to provide its own
version of usb_disconnect() to handle this.
See https://github.com/libopencm3/libopencm3/pull/924
Fixes https://github.com/libopencm3/libopencm3/issues/476
Sets USB_COUNTn_RX reg fields : bits <14:10> are NUM_BLOCK; bit 15 is BL_SIZE.
- When (size <= 62), BL_SIZE must be 0 and NUM_BLOCK set to (size / 2).
- When (size > 62), BL_SIZE must be 1 and NUM_BLOCK=((size / 32) - 1).
Previous code improperly set NUM_BLOCK and assumed the requested size was set.
Now, we use the next largest legal buffer size. Examples:
size BL_SIZE NUM_BLOCK => Actual bufsize
0 0 0 ??? (illegal !)
1 0 1 2
63 1 1 64
Algo is valid for F102, F103 and F0 devices (USB_FS peripheral).
In addition, the new usb_set_ep_rx_bufsize() function returns the actual
size set.
Tested-by: Karl Palsson <karlp@tweak.net.au>
The loopback functionality was never implemented, not for regular bulk
endpoints. By adding it, and adding pairs of endpoints, we can easily
catch buffer management problems. These tests currently fail on
st_usbfs devices.
This did require renumbering the endpoints, as dwc_otg_fs only offers
three endpoints in each direction, and they can't be arbitrary numbers,
unlike on st_usbfs.
See https://github.com/libopencm3/libopencm3/pull/880 and related tickets.
I2C3 is on many parts, but wasn't properly supported with the register
definitions. Declare them centrally, just depending on the memorymap
defining them. On some parts, the rcc bits were defined, but not the
base registers.
Fixes: https://github.com/libopencm3/libopencm3/issues/820
If $(OPENCM3_DIR)/lib/libopencm3_*.a exists, it will be linked in.
If we do that, we should also add it to the deps.
That way a newer *.a will result in a relink.
To use this, you should add a dependency to $(LIBDEPS) where you are
using $(LDFLAGS) and $(LDLIBS) now.
eg, old (wouldn't relink if the library changed)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
new (will relink when the library changes)
$(PROJECT).elf: $(OBJS) $(LDSCRIPT) $(LIBDEPS)
@printf " LD\t$@\n"
$(Q)$(LD) $(TGT_LDFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@
Tested-by: Karl Palsson <karlp@tweak.net.au>
Originally tracked via: https://github.com/libopencm3/libopencm3/pull/887
LPUART1 needs BRR to be 256 times the normal value.
Doing this with 64 bit math would work, but that pulls in quite a lot of
code for every platform, even if they don't have LPUART.
A little bit of maths, thanks to zyp on irc, lets us keep it in 32bit,
provided people don't try and use > 16MBaud on LPUARTs
Originally tracked via https://github.com/libopencm3/libopencm3/pull/888
