This decreases the retrieval time for a frame of 102 bytes from
660 us to 384 us, corresponding to a speed change from about
1.26 Mbps to 2.17 Mbps (102 bytes plus 2 bytes overhead).
queued_rx held a frame in the transceiver's receive buffer until we could
transfer it. This may cause frame loss if a new reception begins.
We now retrieve frames from the transceiver immediately and buffer them
in the MCU.
- mac.c (queued_tx_ack, rx_done, handle_irq): on TX completion, send a
a zero byte on EP 1
- mac.c (handle_irq): don't receive zero-sized frames (they're
malformed anyway), so that size zero can be used to signal TX
completion
This function set isn't really usable for real communication. Its main
purpose is to help with testing the firmware.
- tools/lib/driver.h (struct atrf_driver): added driver functions for
HardMAC access
- tools/include/atrf.h (atrf_rx_mode, atrf_rx, atrf_tx),
tools/lib/atrf.c: functions to enable/disable HardMAC mode and to
send/receive frames
At an interrupt barrier, the host must be able to ensure that no
interrupt generated before reaching the barrier is still pending and
will be delivered after crossing the barrier.
For this, we introduce the following concept:
- interrupts have a serial number. This number is sent to the host
on EP 1 (currently bulk) to signal the interrupt, instead of the
zero byte we used previously.
- the new request ATUSB_SPI_WRITE2_SYNC returns the interrupt
serial number from after the register write (the register write
itself is the interrupt barrier).
- the host can now check if the serial indicated from bulk and the
serial from ATUSB_SPI_WRITE2_SYNC are the same. If yes, interrupts
are synchronized. If not, it has to wait for the interrupt to be
signaled on EP 1.
We should also consider the case that the interrupt serial has gotten
ahead of ATUSB_SPI_WRITE2_SYNC. But that seems to happen rarely. In
any case, it's something for the host driver to worry about, not for
the firmware.
- board.h (irq_serial), board_app.c (irq_serial, INT0_vect): count
the interrupt serial number and return it when signaling the
interrupt
- include/atusb/ep0.h (ATUSB_SPI_WRITE2_SYNC), ep0.c (my_setup):
new request ATUSB_SPI_WRITE2_SYNC that does a register write, then
returns the interrupt serial
This reverts commit 39e3d4e61a.
The log isn't so useful in its present state because we may have to
unplug/replug to get out of a troublesome condition.
- usb/atu2.c (NUM_EPS), board.h (NUM_EPS): moved definition to
board.h
- board.h (NUM_EPS): use one EP for the boot loader, two for the
application
- usb/atu2.c (ep_init): initialize EP 1 only in an application build
- Makefile (USB_OBJS): moved into OBJS and BOOT_OBJS
- Makefile (OBJS): atu2.o is now app-atu2.o
- Makefile (BOOT_OBJS): atu2.o is now boot-atu2.o
- Makefile (MKDEP, %.o): moved dependency generation to macro $(MKDEP)
- Makefile (app-%.o): build from usb/%.c
- Makefile (boot -%.o): build from usb/%.c and set -DBOOT_LOADER
- board_app.c (INT0_vect): always read IRQ_STATUS, even if an
interrupt is already enqueued
- board_app.c (INT0_vect): if an interrupt is enqueued, accumulate
the interrupts signaled since
- board_app.c (irqs_more): when a pending transfer completes, send
interrupts accumulated since (if any)
- board.h (gpio_cleanup), board_app.c (gpio_cleanup): restore INT0
when done manipulating GPIOs
- board.c (gpio): updated comment explaining how to restore INT0
- include/atusb/ep0.h (enum atspi_requests), ep0.c
(ATUSB_GPIO_CLEANUP): new request to return to normal operation
after ATUSB_GPIO
Since GPIO manipulations may cause stray INT0 activity, we turn off
INT0 handing on ATUSB_GPIO. The MCU must be reset to restore access
to INT0.
There are still issues to resolve with the GPIO test. It may turn
out that there's a less invasive solution than just turning off
INT0 completely.
- board_app.c (gpio): mask INT0 before manipulating GPIOs
- board_app.c (board_app_init): make it clearer that EIMSK is a bit
mask
