| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite existing IRQ handlers in terms of new functions
dispatch_single_exti() and dispatch_extis(). dispatch_single_exti()
handles EXTIs which have a dedicated IRQ line, and thus doesn't have
to check EXTI_PR; it is mostly equivalent to the (now removed)
handle_exti(). dispatch_extis() handles multiple EXTIs sharing an IRQ
line. Using dispatch_extis() instead of calling handle_exti()
multiple times avoids unnecessary I/O to the (volatile) EXTI_BASE->PR
register.
These changes are in the flavor of the timer IRQ optimizations
performed in f5016b15bef56bbdfd187f9b623177ef6dde7ace.
|
| |
|
|
|
|
|
| |
These functions incorrectly replicate functionality that is already
accomplished by manipulating EXTI_IMR directly.
|
| |
|
|
|
|
|
| |
Add new handle_exti() instead of calling clear_pending() and
dispatch_handler() each time.
|
| |
|
|
|
|
|
|
|
| |
Nonportable (Maple Mini only) test of external interrupt
functionality. When wired properly, this triggers various EXTI lines
simultaneously, keeping track of the number of times each handler is
invoked.
|
|
|
|
|
|
| |
Read TIMx_SR before grabbing a pointer to the user handlers instead of
after. This should shave a couple of cycles off of the time between
IRQ entry and SR read.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove dispatch_irq() and dispatch_cc_irqs().
For IRQs which handle exactly one timer interrupt, add new
dispatch_single_irq(). The mere fact that the IRQ has been called
suffices to prove that its interrupt enable bit (in TIMx_DIER) and
interrupt flag (in TIMx_SR) are set. These facts are combined in
dispatch_single_irq(), which only needs to check if the timer_dev
handler is non-null before calling it and clearing the SR flag.
For IRQs which serve multiple timer interrupts, replace the
composition of calls to dispatch_irq() and dispatch_cc_irqs() with
individualized routines. These eliminate unnecessary timer register
reads/writes, and, in the case of capture/compare interrupts, have a
loop unrolling performed.
|
|
|
|
|
| |
Modify them to check whether the relevant interrupts are enabled
before attempting to handle them.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The delay_us() implementation multiplies its specified delay target by
a fixed constant in order to turn it into a busy-loop. This magic
number doesn't work properly when the clock configuration isn't the
same as a stock LeafLabs board. Add DELAY_US_MULT to the MCU-specific
configuration in stm32.h in order to allow other chips to use delay_us().
|
| |
|
| |
|
| |
|
|
|
|
| |
bug prevented consecutive SerialUSB.read() calls from returning consecutive bytes
|
|
|
|
| |
Thanks to x893 for the suggestion.
|
|\ |
|
| |
| |
| |
| |
| | |
Don't modify the core FreeRTOS code; only change source that's
specific to libmaple.
|
| | |
|
| |
| |
| |
| | |
example blinky.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libmaple/dma.c defines DMA interrupts __irq_dma_channel[1-7],
consistent with what is specified by support/ld/names.inc. However,
names.inc is inconsistent with what support/ld/libcs3_stm32_src/
expects. Specifically, it contradicts the files
- support/ld/libcs3_stm32_src/stm32_isrs.S
- support/ld/libcs3_stm32_src/stm32_vector_table.S
Which use the names __irq_dma1_channel[1-7].
Change names.inc and dma.c to use the correct IRQ names.
The original names.inc/libcs3_stm32_src inconsistency was introduced
in 43d6921658cd29b8022af4424d340a90fbcb9a7f, but dma.c had the correct
names until ec3cf2903f4b03bc1dae5e159495c9e5ef0938ca, where they were
renamed for consistency with names.inc. At that point, DMA interrupts
stopped working. (This was documented in the commit message).
Thanks to forum user robodude666 for tracking this down.
|
|
|
|
|
|
| |
The Servo::write() implementation previously relied upon this value to
support an undocumented Arduino misfeature. The relevant behavior was
removed in 0.0.10, so we shouldn't still include this define.
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks to gbulmer for the clarifying remarks.
|
|
|
|
|
| |
This information has been folded into the board hardware documentation
for Maple.
|
| |
|
|
|
|
|
| |
Put the PCLK1 and PCLK2 within #ifndef guards. This assumption is
biased towards LeafLabs boards.
|
|
|
|
|
| |
This file is out of date. Fix it to be a useful starting point for
figuring out how libmaple ports across chips/boards.
|
|
|
|
| |
Its content was moved into the official docs a while ago.
|
|
|
|
|
| |
The README already references the bugracker, and the top level
directory is too cluttered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation covers topics not specifically relevant to libmaple,
so it doesn't make sense for it to be part of the libmaple source
distribution.
Delete the docs/ tree, and prepare libmaple for use with the new
leaflabs-docs repo, which will contain the docs from now on.
* README: update to reflect this change
* support/doxygen/Doxyfile: This is the old docs/Doxyfile
* Makefile: Add a doxygen target
* wirish/comm/HardwareSerial.h: fix reference to docs/. The comment
informing maintainers that the HardwareSerial interface is
documented by hand refers to the docs/ tree, which no longer exists.
Update it to refer to the separate leaflabs-docs repository.
* support/scripts/copy-to-ide: No longer build the documentation
|
| |
|
| |
|
| |
|
|
|
|
|
| |
ASSERT() was previously documented in language.rst. Move it to a new
lang/api/assert.rst.
|
|
|
|
|
|
| |
The FAQ entry which explains the throbbing LED behavior is
insufficiently general. Rewrite it so users can tell that throbbing
generally indicates a failed assertion or some other error.
|
|
|
|
|
|
| |
Fix examples where pin 13 was used explicitly instead of
BOARD_LED_PIN. Also change an AVR-specific example in
docs/lang/cpp/booleanvariables.rst to Maple conventions.
|