| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
Signed-off-by: RJ Ryan <rryan@mit.edu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A variety of USB descriptor structures have been manually
"unpacked". Instead of using the struct, their members were unpacked
into the struct they were nested in. Additionally sizeof()'s were
commented in favor of manual calculation of structure sizes.
After uncommenting these changes, the USB CDC peripheral stopped
correctly configuring with the host. The root problem with the
structures is that GCC is padding them. By applying
__attribute__((__packed__)), these problems are fixed. I removed all
the instances of the workaround I saw within the USB code.
Signed-off-by: RJ Ryan <rryan@mit.edu>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The STL in particular relies on abort() for entering an error
state. Without an abort() definition, the use of many STL primitives
results in a link error because the default implementation of abort()
uses _kill, _exit, and _getpid -- none of which are present. My
abort() implementation writes an error message to the error USART and
enters the throbbing-LED error state.
Signed-off-by: RJ Ryan <rryan@mit.edu>
|
|/
|
|
|
|
|
| |
default implementation. This allows the use of assert() from libc's
assert.h.
Signed-off-by: RJ Ryan <rryan@mit.edu>
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Michael Hope <michaelh@juju.net.nz>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's been tricky for users to start their own projects while still
using our build system. The current recommended practice to get this
done involves modifying the top-level Makefile to add their module
into LIBMAPLE_MODULES, and include their own rules.mk. Editing the
repository Makefile is stupid and shouldn't be a necessary step.
Instead of that, allow the environment to provide the initial value
for LIBMAPLE_MODULES. This allows users to specify it on the command
line.
Also add WIRISH_PATH to the initial set of "useful" paths.
|
| |
| |
| |
| | |
Oh, copy-to-ide. I long for your death.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add new common.inc, which is common_rom.inc with some
DEFINED(_FLASH_BUILD) usages thrown in to allow for RAM builds. It
also uses a new REGION_RODATA region alias for read-only data.
Move section .USER_FLASH to REGION_RODATA. This means it lives in RAM
under RAM builds. Although this might be surprising, not doing so
would make RAM builds useless.
Modify the individual board linker scripts to properly set
REGION_RODATA and _FLASH_BUILD before calling out to common.inc.
Delete common_rom.inc, common_ram.inc, common_header.inc, in favor of
common.inc. This should fix RAM builds on all boards.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Comment the Makefile more verbosely. It's been causing confusion on
the forums.
Add target-config.mk, this contains build configuration depending on
the BOARD and MEMORY_TARGET variables. Its contents were cluttering
up the Makefile and making it harder to read.
|
|/ |
|
|
|
|
|
|
| |
Stick FSMC_BCR_MTYP_SRAM among the bitfields assigned to the BCR
write. Technically not necessary (SRAM is the default after reset),
but good for readability and future-proofing.
|
|
|
|
|
|
| |
Rename HEAP_START/HEAP_END macros CONFIG_HEAP_START/CONFIG_HEAP_END,
to mark them as build-time configuration options. Wrap their
definitions with #ifndefs appropriately.
|
|
|
|
|
|
|
| |
nzmichaelh rightly argues that actual RX buffers should be
heap-allocated, to avoid wastage for unused devices. Deprecate the
field for 0.0.12, since that's coming out soon. This will let us get
rid of this field in master immediately after 0.0.12 gets shipped.
|
|
|
|
|
|
| |
Specify _lm_heap_start and _lm_heap_end in Maple Native's linker
scripts to point respectively to beginning and end of FSMC-mapped
external SRAM chip addresses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- common_header.inc: Declare EXTERN symbols _lm_heap_start and
_lm_heap_end.
- common_rom.inc: Check for _lm_heap_start and _lm_heap_end. If they
are defined, preserve their values. Otherwise, _lm_heap_start is
starts after .bss, and _lm_heap_end is the end of SRAM.
This allows existing linker scripts to continue using the old heap
scheme, but allows for customizability elsewhere.
- syscalls.c: Respect the addresses of _lm_heap_start and _lm_heap_end
as the boundaries of the heap in _sbrk().
|
|
|
|
| |
Explain what's going on so unfamiliar readers have more hope.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Use region aliases in common_ram.inc, common_rom.inc. These are
provided by the individual board scripts which include these. Note
that the aliases have horrible names. We'll need to fix that up.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix _sbrk() implementation so it properly rejects negative arguments
which would send the program break below the heap start. Fix
incorrect check against argument causing heap overflow. Also set
errno properly to ENOMEM when the call fails.
Beginning and end of the heap are now determined by HEAP_START and
HEAP_END macros. Their current values seem to work OK for heaps on
the internal SRAM, but they'll need to get generalized for Maple
Native.
|
| |
|
|
|
|
|
| |
stm32.h has been updated to prefix its definitions. Update the rest
of libmaple to take this into account.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove SRAM_SIZE define. This seems like a bad idea given that
bootloader builds drop user code at an offset from the SRAM start
address.
Prefix every #define with "STM32_" to avoid polluting the namespace.
Keep and deprecate the remaining ones (except for aforementioned
SRAM_SIZE), but define them to be the same as their prefixed variant.
Take a little extra care to break libmaple builds which specify PCLK1
and PCLK2 instead of the prefixed versions. Some libmaple forks make
use of these; they will break in mysterious ways if they don't handle
this change properly.
|
|
|
|
| |
Comment/whitespace changes only.
|
|
|
|
|
|
|
|
|
| |
uart_send() is not part of libmaple, and nm doesn't show it getting
linked in from anywhere else, so I don't believe it exists. Remove it.
Also remove some commented-out sections from getch(), putch(),
_write(), and fgets(). These either reference uart_send() or use old
libmaple APIs which no longer exist.
|
| |
|
|
|
|
|
|
|
| |
The linker scripts share an initial section. Factor this out into a
new file common_header.inc, and have the main linker scripts include
this file. Apart from eliminating a redundancy, this will make it
easier to add new linker scripts in the future.
|
|
|
|
|
|
|
|
|
|
|
| |
Remove doxygen from clean; no sense killing the docs just because you
want to change boards.
Add new "mrproper" target to nuke all autogenerated files; currently,
this is just the build/ and doxygen/ directories.
Make a note of BOARD env. variable and doxygen, mrproper targets from
help target.
|
|
|
|
|
| |
The tables are too long to read comfortably without additional
horizontal line breaks.
|
|
|
|
|
| |
Actually read a character each time we ask for one. Put pin 22 back
into OUTPUT mode when we're done.
|
|
|
|
|
| |
The headers just #define some numbers, so there's no need for them to
be including libmaple headers.
|
| |
|
|
|
|
|
| |
First in what is sure to be a long series of efforts in educating
people that you can have GPIOs 56--100 or the SRAM chip, but not both.
|
|
|
|
| |
SerialUSB.read() is already blocking, so no sense looping on available().
|
| |
|
| |
|
|
|
|
| |
Measure pins one at a time.
|
|
|
|
|
| |
Each call to measure_adc_noise() now does
N_ADC_NOISE_MEASUREMENTS (currently 40) samples, instead of just 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update measure_adc_noise() to actually use the Welford online
algorithm, instead of accumulating data in an array on the stack.
This allows us to increase the number of samples (to 1000).
Revised algorithm tested on host PC and compared (in Python) against
numpy with a list of 100 values in [0, 1) drawn using random.random().
Results (Python):
>>> r = [random.random() for i in xrange(100)]
>>> numpy.mean(r)
0.50073064742634854
>>> numpy.var(r)
0.083726090293309297
Results (C++, x86 host PC):
n: 100 mean: 0.500731 variance: 0.084572
So this algorithm for variance has some inaccuracies, but it appears
to be good to a couple of significant figures.
|
| |
|
| |
|
|
|
|
| |
Print input as if it were an ASCII character, not a number.
|
| |
|
| |
|