added prescaler for 16 bit pwm in LPC1347 target

Fork of mbed-dev by mbed official

Committer:
JojoS
Date:
Sat Sep 10 15:32:04 2016 +0000
Revision:
147:ba84b7dc41a7
Parent:
144:ef7eb2e8f9f7
added prescaler for 16 bit timers (solution as in LPC11xx), default prescaler 31 for max 28 ms period time

Who changed what in which revision?

UserRevisionLine numberNew contents of line
<> 144:ef7eb2e8f9f7 1 /* mbed Microcontroller Library
<> 144:ef7eb2e8f9f7 2 * CMSIS-style functionality to support dynamic vectors
<> 144:ef7eb2e8f9f7 3 *******************************************************************************
<> 144:ef7eb2e8f9f7 4 * Copyright (c) 2011 ARM Limited. All rights reserved.
<> 144:ef7eb2e8f9f7 5 * All rights reserved.
<> 144:ef7eb2e8f9f7 6 *
<> 144:ef7eb2e8f9f7 7 * Redistribution and use in source and binary forms, with or without
<> 144:ef7eb2e8f9f7 8 * modification, are permitted provided that the following conditions are met:
<> 144:ef7eb2e8f9f7 9 *
<> 144:ef7eb2e8f9f7 10 * 1. Redistributions of source code must retain the above copyright notice,
<> 144:ef7eb2e8f9f7 11 * this list of conditions and the following disclaimer.
<> 144:ef7eb2e8f9f7 12 * 2. Redistributions in binary form must reproduce the above copyright notice,
<> 144:ef7eb2e8f9f7 13 * this list of conditions and the following disclaimer in the documentation
<> 144:ef7eb2e8f9f7 14 * and/or other materials provided with the distribution.
<> 144:ef7eb2e8f9f7 15 * 3. Neither the name of ARM Limited nor the names of its contributors
<> 144:ef7eb2e8f9f7 16 * may be used to endorse or promote products derived from this software
<> 144:ef7eb2e8f9f7 17 * without specific prior written permission.
<> 144:ef7eb2e8f9f7 18 *
<> 144:ef7eb2e8f9f7 19 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
<> 144:ef7eb2e8f9f7 20 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
<> 144:ef7eb2e8f9f7 21 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
<> 144:ef7eb2e8f9f7 22 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
<> 144:ef7eb2e8f9f7 23 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
<> 144:ef7eb2e8f9f7 24 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
<> 144:ef7eb2e8f9f7 25 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
<> 144:ef7eb2e8f9f7 26 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
<> 144:ef7eb2e8f9f7 27 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
<> 144:ef7eb2e8f9f7 28 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<> 144:ef7eb2e8f9f7 29 *******************************************************************************
<> 144:ef7eb2e8f9f7 30 */
<> 144:ef7eb2e8f9f7 31 #include "cmsis_nvic.h"
<> 144:ef7eb2e8f9f7 32
<> 144:ef7eb2e8f9f7 33 /* In the M0, there is no VTOR. In the LPC range such as the LPC11U,
<> 144:ef7eb2e8f9f7 34 * whilst the vector table may only be something like 48 entries (192 bytes, 0xC0),
<> 144:ef7eb2e8f9f7 35 * the SYSMEMREMAP register actually remaps the memory from 0x10000000-0x100001FF
<> 144:ef7eb2e8f9f7 36 * to adress 0x0-0x1FF. In this case, RAM can be addressed at both 0x10000000 and 0x0
<> 144:ef7eb2e8f9f7 37 *
<> 144:ef7eb2e8f9f7 38 * If we just copy the vectors to RAM and switch the SYSMEMMAP, any accesses to FLASH
<> 144:ef7eb2e8f9f7 39 * above the vector table before 0x200 will actually go to RAM. So we need to provide
<> 144:ef7eb2e8f9f7 40 * a solution where the compiler gets the right results based on the memory map
<> 144:ef7eb2e8f9f7 41 *
<> 144:ef7eb2e8f9f7 42 * Option 1 - We allocate and copy 0x200 of RAM rather than just the table
<> 144:ef7eb2e8f9f7 43 * - const data and instructions before 0x200 will be copied to and fetched/exec from RAM
<> 144:ef7eb2e8f9f7 44 * - RAM overhead: 0x200 - 0xC0 = 320 bytes, FLASH overhead: 0
<> 144:ef7eb2e8f9f7 45 *
<> 144:ef7eb2e8f9f7 46 * Option 2 - We pad the flash to 0x200 to ensure the compiler doesn't allocate anything there
<> 144:ef7eb2e8f9f7 47 * - No flash accesses will go to ram, as there will be nothing there
<> 144:ef7eb2e8f9f7 48 * - RAM only needs to be allocated for the vectors, as all other ram addresses are normal
<> 144:ef7eb2e8f9f7 49 * - RAM overhead: 0, FLASH overhead: 320 bytes
<> 144:ef7eb2e8f9f7 50 *
<> 144:ef7eb2e8f9f7 51 * Option 2 is the one to go for, as RAM is the most valuable resource
<> 144:ef7eb2e8f9f7 52 */
<> 144:ef7eb2e8f9f7 53
<> 144:ef7eb2e8f9f7 54 #define NVIC_RAM_VECTOR_ADDRESS (0x10000000) // Vectors positioned at start of RAM
<> 144:ef7eb2e8f9f7 55
<> 144:ef7eb2e8f9f7 56 void NVIC_SetVector(IRQn_Type IRQn, uint32_t vector) {
<> 144:ef7eb2e8f9f7 57 int i;
<> 144:ef7eb2e8f9f7 58 // Space for dynamic vectors, initialised to allocate in R/W
<> 144:ef7eb2e8f9f7 59 static volatile uint32_t* vectors = (uint32_t*)NVIC_RAM_VECTOR_ADDRESS;
<> 144:ef7eb2e8f9f7 60
<> 144:ef7eb2e8f9f7 61 // Copy and switch to dynamic vectors if first time called
<> 144:ef7eb2e8f9f7 62 if((LPC_SYSCON->SYSMEMREMAP & 0x3) != 0x1) {
<> 144:ef7eb2e8f9f7 63 uint32_t *old_vectors = (uint32_t *)0; // FLASH vectors are at 0x0
<> 144:ef7eb2e8f9f7 64 for(i = 0; i < NVIC_NUM_VECTORS; i++) {
<> 144:ef7eb2e8f9f7 65 vectors[i] = old_vectors[i];
<> 144:ef7eb2e8f9f7 66 }
<> 144:ef7eb2e8f9f7 67 LPC_SYSCON->SYSMEMREMAP = 0x1; // Remaps 0x0-0x1FF FLASH block to RAM block
<> 144:ef7eb2e8f9f7 68 }
<> 144:ef7eb2e8f9f7 69
<> 144:ef7eb2e8f9f7 70 // Set the vector
<> 144:ef7eb2e8f9f7 71 vectors[IRQn + 16] = vector;
<> 144:ef7eb2e8f9f7 72 }
<> 144:ef7eb2e8f9f7 73
<> 144:ef7eb2e8f9f7 74 uint32_t NVIC_GetVector(IRQn_Type IRQn) {
<> 144:ef7eb2e8f9f7 75 // We can always read vectors at 0x0, as the addresses are remapped
<> 144:ef7eb2e8f9f7 76 uint32_t *vectors = (uint32_t*)0;
<> 144:ef7eb2e8f9f7 77
<> 144:ef7eb2e8f9f7 78 // Return the vector
<> 144:ef7eb2e8f9f7 79 return vectors[IRQn + 16];
<> 144:ef7eb2e8f9f7 80 }
<> 144:ef7eb2e8f9f7 81