C and C++ library for STM32 ARM Cortex-M3 development boards. https://git.suspectdevices.com/feurig/libmaplemidi-cma/atom?h=v0.0.12 2011-09-13T09:56:29+00:00 2011-09-13T09:56:29+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T09:56:29+00:00 urn:sha1:0ae1bcb110eec198e1efcbf3ddb8fe3e88b03fbe Oh, copy-to-ide. I long for your death. 2011-09-13T08:44:02+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T07:23:03+00:00 urn:sha1:ada25198f61a07281785be07f0586ee5151acda5 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. 2011-09-13T06:22:15+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T05:32:09+00:00 urn:sha1:c8223ee8ab5ec5a9a0b642ee729419d5eed7d6b0 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. 2011-09-13T05:24:37+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T05:23:36+00:00 urn:sha1:b28db99f6122ddc5ce0f34e08832e13d2ab54f2b 2011-09-13T01:29:50+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T01:29:50+00:00 urn:sha1:0697f5d0d61fd75c148df1ce91722608c789f0ac 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. 2011-09-13T00:59:12+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T00:59:12+00:00 urn:sha1:f711c740e011b4f0014e934720bf8c4d1ac8a109 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. 2011-09-13T00:11:59+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-13T00:11:59+00:00 urn:sha1:f4f819774559ce1cf84956b7e9b5cf4b5e4e5c0c 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. 2011-09-12T21:25:07+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-12T21:24:45+00:00 urn:sha1:9cc8168568e9ff652305feb36292762107d0eb20 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. 2011-09-12T21:25:01+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-12T20:24:43+00:00 urn:sha1:fc4bd8eb9ea6271ad1e3aa734657808e77ac1e2a - 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(). 2011-09-12T20:10:10+00:00 Marti Bolivar mbolivar@leaflabs.com 2011-09-12T20:10:10+00:00 urn:sha1:780381d160730486565eb9a16a191487127d6120 Explain what's going on so unfamiliar readers have more hope.