LeafLabs Garden » User Favorites: jigajigajoo

LeafLabs Garden » User Favorites: jigajigajoo 3905 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:14:36 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-22993 Wed, 20 Mar 2013 21:52:28 +0000 gbulmer 22993@http://forums.leaflabs.com/ konan - "PS why vectors[256]? according to RM0008, the last vector offset is 0x12c, so there's only 75 vectors..." I believe that no Cortex-M3 has more than 256 vectors. So that is robust though wasteful :-) According to PM0056 rev4, <a href="http://www.st.com/web/en/resource/technical/document/programming_manual/CD00228163.pdf" rel="nofollow">http://www.st.com/web/en/resource/technical/document/programming_manual/CD00228163.pdf</a> there 81 interrupts, so I'd probably use that figure for copying. I apologise, I forgot about another complication; the vector table start address must be aligned to 128 bytes, i.e. the bottom 7 bits of the address must be 0, see PM0056 rev4, "4.4.4 Vector table offset register (SCB_VTOR)". konan on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-22990 Wed, 20 Mar 2013 14:34:53 +0000 konan 22990@http://forums.leaflabs.com/ Something strange. I tried to copy the VT to the RAM, and give new address to the NVIC, but Maple hangs at boot time. here's the code: #include "scb.h" #include "nvic.h" typedef void (*inthand)(void); inthand NVT[75]; // new vector table void setup() { inthand *fvt; // flash vector table fvt = (inthand*)SCB_BASE->VTOR; for (int i=0; i<75; i++) NVT[i] = *(fvt++); nvic_init((uint32)&NVT, 0); } void loop() { SerialUSB.println((uint32)NVT[55], HEX); delay(1000); } When I comment out the "nvic_init" line, everything works fine, the value printed to SerialUSB is identical to the value from flash (SCB_BASE->VTOR+0xDC). konan on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-22988 Wed, 20 Mar 2013 11:06:50 +0000 konan 22988@http://forums.leaflabs.com/ gbulmer, thanks again, I'll try this. By the way, about the topic of this thread - I think, copying and modifying the vector table in RAM is much easier way to change any vector we need. It may be done by creating the library, that at start will copy the vector table, and then change any vector(s). With the ability to call "old" irq handlers, using vectors from the original VT in flash. PS why vectors[256]? according to RM0008, the last vector offset is 0x12c, so there's only 75 vectors... gbulmer on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-22987 Wed, 20 Mar 2013 09:12:55 +0000 gbulmer 22987@http://forums.leaflabs.com/ konan - If I understood your needs, then you want to have both your interrupt handler, and the 'initial' interrupt handler able to run There are, at least, two ways to do this: 1. Save the initial, in Flash, vector table base address (VTOR), build a new interrupt vector table in RAM (copy the old one and change the entry you want to handle), set the NVIC base register (VTOR) to point to the in-RAM interrupt vector table. Then your interrupt handler does as you describe, using the initial interrupt vector table value when it needs it. 2. Implement x893's mechanism, described at the head of this thread, for the interrupts you want to override, with the added ability to save previous interrupt vector values when attaching. As you have found, VTOR is in the SCB block. According to the ARM document "ARM v7-M Architecture Reference Manual" DDI0403D_arm_architecture_v7m_reference_manual.pdf the NVIC vector base register is at 0xE000ED08, so you could grab that value ((unint32**)0xE000ED08) and print the existing vector table. It will have a bunch of values that point to the same interrupt handler. So you could allocate an array of uint32's (or void *): <code>uint32* vectors[256];</code> copy the flash table to RAM, <pre><code>uint32* flash_vectors = *((unint32**)0xE000ED08); int i; for (i=0; i<256; ++i) { vectors[i] = *flash_vectors; ++flash_vectors; }</code></pre> set the VTOR to point to the start of it, <code>*((unint32**)0xE000ED08) = &vectors[0];</code> and if you got it right, everything should continue to work!-) WARNING: THAT CODE IS UNTESTED, NOT EVEN COMPILED. konan on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-22983 Wed, 20 Mar 2013 01:59:28 +0000 konan 22983@http://forums.leaflabs.com/ gblumer - thanks for explanation and sorry for late reply :) I holded over that project, but returned to it now. As far as I understood, at boot time the vector table is allocated in flash memory, and the only way to change the single vector is to copy the entire table into RAM, and call nvic_set_vector_table? The original vector table can be found at address from SCB_BASE->VTOR, am I right? gbulmer on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720&page=2#post-6106 Sun, 28 Aug 2011 17:28:20 +0000 gbulmer 6106@http://forums.leaflabs.com/ konan - the mechanism we have described doesn't let you do what you describe directly. By providing an interrupt handler called, for example, __irq_adc(), there is no record of the previous interrupt handler; your definition of (in this example) __irq_adc() replaces it completely at link time. As many of the handlers are dummy 'do nothing' handlers, this isn't a bad problem. There are several ways, some quite involved, of getting an effect similar to the one you describe. One involves copying the entire interrupt vector table, at run time into RAM, filling in the address of your handler in the copy, and choosing which interrupt vector table to allow the interrupt hardware to use. What is it that you need to do? We might be able to suggest a way to get the result you need. konan on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-6073 Wed, 24 Aug 2011 14:10:36 +0000 konan 6073@http://forums.leaflabs.com/ Hi all. I have a bit more complex task, than just defining my own handler. Besides of this, in my handler I need to decide, either to use my own routine, or jump to the previously defined handler. So, in setup() function I need to save old handler, and put my handler's address in the vector table. I'm not very familiar with low-level C programming, can anybody give me simple example of how to access the vector table? mbolivar on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-5950 Tue, 09 Aug 2011 14:07:19 +0000 mbolivar 5950@http://forums.leaflabs.com/ Hi jigajigajoo, A good starting point for information on interrupts is the book "The Definitive Guide to the ARM Cortex M3". Chapters 7--9 and 11 treat interrupts and exceptions in loving detail. If you're looking for free documentation, you should probably check out ARM's Cortex M3 Technical Reference Manual, although that's not as easy a read. For the structure of a vector table on the STM32, you'll need to check ST's RM0008; see <a href="http://leaflabs.com/docs/hardware/maple.html#recommended-reading" rel="nofollow">http://leaflabs.com/docs/hardware/maple.html#recommended-reading</a> for links. The short story on how libmaple organizes things is that we use linker scripts to weakly define all the IRQ handlers. This lets you define an IRQ handler as regular function with one of the names given in names.inc (see the other thread you referenced for more info on that file); if you do, the linker picks up on this and uses its address as the corresponding entry in the NVIC. libmaple defines a variety of these, see e.g. usart.c for examples: <a href="https://github.com/leaflabs/libmaple/blob/0.0.11/libmaple/usart.c#L233" rel="nofollow">https://github.com/leaflabs/libmaple/blob/0.0.11/libmaple/usart.c#L233</a> If neither you nor libmaple provides a definition, the linker uses a default handler (which infinite loops) instead. As mentioned above, there's not currently a convenient way to override libmaple's definition, if one exists. However, luckily for you, adc.c does not define __irq_adc(), so you're free to use your own. mbolivar on "Doc Request - Coretex M3 - Vector Interupt Primer" http://forums.leaflabs.com/topic.php?id=40#post-5949 Tue, 09 Aug 2011 13:55:21 +0000 mbolivar 5949@http://forums.leaflabs.com/ <blockquote> Is the procedure to setup interrupts on the Maple still valid? I tried to follow the steps... I was trying to get the interrupt from the ADC to work... basically every conversion, the ADC sends an interrupt out to signal a complete conversion. </blockquote> nope. libmaple has been refactored significantly since the time of those posts. the names of the weakly-defined IRQ handlers are still given in libmaple's /support/ld/names.inc, but the names have all changed: <a href="https://github.com/leaflabs/libmaple/blob/0.0.11/support/ld/names.inc" rel="nofollow">https://github.com/leaflabs/libmaple/blob/0.0.11/support/ld/names.inc</a> the IRQ handler for ADC1 and ADC2 isn't currently defined by libmaple, so just defining your own (and calling it "__irq_adc") should do the trick. jigajigajoo on "Doc Request - Coretex M3 - Vector Interupt Primer" http://forums.leaflabs.com/topic.php?id=40#post-5936 Mon, 08 Aug 2011 15:39:45 +0000 jigajigajoo 5936@http://forums.leaflabs.com/ Is the procedure to setup interrupts on the Maple still valid? I tried to follow the steps... I was trying to get the interrupt from the ADC to work... basically every conversion, the ADC sends an interrupt out to signal a complete conversion. I first initialized the ADC (initADC()). I then added an interrupt on the nvic, and the peripheral (in my case the ADC) (initInterrupts()), and then tried to overload the interrupt handlerADC_IRQHandler(). I didn't get it to work.... any input would be invaluable. The full code: <code> // START CONSTANTS const uint8 numMics = 6; volatile int tic = 0; // sampleRate = number of ADC cycles per read = ADC_SMPR_x + 12.5 = // samples per cycle at 14 MHz. For ADC_SMPR_1_5, total conversion time = 1 microsec. const adc_smp_rate sampleRate = ADC_SMPR_28_5; const int sampleRateInt = 28.5; // we're using raw adc channels via adcChans instead of micPins const int micPins[6] = {D15, D16, D17, D18, D19, D20}; // below refers to channels according to ADC docs, and not to pins on maple // 10-15 correspond to pins D15-D20 on maple // the order of adcChans decides the order in which the channels are read // (ie first one = chan0, etc) const uint8 adcChans[6] = {10, 11, 12, 13, 14, 15}; HardwareTimer timer(1); // END CONSTANTS // Analog input pin. You may need to change this number if your board // can't do analog input on pin 15. const int analogStartPin = 15; void setup() { // Set up board LED to blink, useful for debugging pinMode(BOARD_LED_PIN, OUTPUT); // Declare analogInputPin as INPUT_ANALOG: for(int i = 0; i < numMics; i++) { pinMode(micPins[i], INPUT_ANALOG); } initADC(); initInterrupts(); } void initADC() { // ADC register map adc_reg_map *regs = ADC1->regs; // below not needed, maplelib does it for us! //adc_init(ADC1); // if adc is on, turn it off so we can change settings if(regs->CR2 | ADC_CR2_ADON) { regs->CR2 ^= ADC_CR2_ADON; } adc_set_sample_rate(ADC1, sampleRate); // set number of channels to read adc_set_reg_seqlen(ADC1, numMics); // set channel read sequence order (from adcChans) uint32 channels = 0; for (int i = 0; i < numMics; i++) { channels |= (adcChans[i] << (i*4)); } regs->SQR3 = channels; // scan mode on regs->CR1 |= ADC_CR1_SCAN; // continuous mode on regs->CR2 |= ADC_CR2_CONT; // enable end_of_conversion interrupts regs->CR1 |= ADC_CR1_EOCIE; // calibrate ADC adc_calibrate(ADC1); // turn on ADC regs->CR2 |= ADC_CR2_ADON; // start adc read regs->CR2 |= ADC_CR2_SWSTART; } void initInterrupts() { // enable adc interrupt on the interrupt controller nvic_globalirq_enable(); nvic_irq_enable(NVIC_ADC_1_2); //enable adc interrupt on the adc } void ADC_IRQHandler(void) { SerialUSB.print('x'); tic++; if(tic == 60) { tic = 0; toggleLED(); } } void loop() { // use interrupts! } </code> jigajigajoo on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-5935 Mon, 08 Aug 2011 14:39:24 +0000 jigajigajoo 5935@http://forums.leaflabs.com/ I'm interested in learning how to use the ADC interrupts on the Maple, but I'm having a lot of trouble figuring out how to implement them, either in maplelib or higher level stuff. Obviously there's the api for external interrupts, but I'm wondering whether there's a way to hook that into the ADC's interrupt. More generally, how are interrupts implemented in the ARM architecture? I'm coming from an Arduino and I'm used to supersimple interrupt handling ie [code]SIGNAL(TIMER2_OVF_vect) { ... }[/code] Is there an equivalent using the maple, or do I have to do something weird with the nvic... Also, I found this on the forums, and tried to implement it, but it didn't work for some reason. <a href="http://forums.leaflabs.com/topic.php?id=40" rel="nofollow">http://forums.leaflabs.com/topic.php?id=40</a> mbolivar on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-5045 Tue, 07 Jun 2011 16:27:41 +0000 mbolivar 5045@http://forums.leaflabs.com/ robodude666, I had similar thoughts about speeding up timer interrupts in this way. I agree that allowing advanced users to override the default interrupt handlers is necessary and good. Thanks for the heads-up about ST's conventions. gbulmer, Thanks for the links and ideas; that gives me a place to get started. It does seem more desirable to do this at link time. gbulmer on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-5044 Tue, 07 Jun 2011 15:25:01 +0000 gbulmer 5044@http://forums.leaflabs.com/ I'm not sure how efficient you want this. For zero overhead, replace the placeholder you've called <code>__irq_tim2</code>. I have not written code to check this works with the ARM gcc toolchain. A normal linker (ld) would pick up a users implementation of a function before linking in a library implementation. Here are two examples which explain how to do this in C on Cortex-M3 (no assembler required): <a href="http://embeddedfreak.wordpress.com/2009/08/07/cortex-m3-interrupt-vector-table/" rel="nofollow">http://embeddedfreak.wordpress.com/2009/08/07/cortex-m3-interrupt-vector-table/</a> <a href="http://dev.frozeneskimo.com/notes/getting_started_with_cortex_m3_cmsis_and_gnu_tools" rel="nofollow">http://dev.frozeneskimo.com/notes/getting_started_with_cortex_m3_cmsis_and_gnu_tools</a> So to replace a function defined as <code>void __irq_tim2(void);</code> would only need a user to write a function implementation for void __irq_tim2(void): <code>void __irq_tim2(void) { ... }</code> compile it, and have it linked before the library. Assuming the interrupt table is initialised with the address of <code>void __irq_tim2(void)</code>, and that table gets loaded by the bootloader, then it's done. In some versions of gcc, including the Atmel AVR one, it is very straightforward to define an interrupt handler, and have it 'wired in'. Define a function using the syntax: <code>SIGNAL(TIMER2_OVF_vect) { ... }</code> where <code>TIMER2_OVF_vect</code> is a predefined interrupt vector name. But, I glanced at the gnu documentation: <a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html" rel="nofollow">http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html</a> but that looks like a few generic interrupts only. I think they might be there to support old ARM7 processor states, which don't apply to Cortex-M3. This still leaves the problem of how to call a default implementation having just clobbered it by using its name. For a lot of the interrupts, the default is called something like <code>_fail()</code> and it just loops forever, so straightforward :-) So, the documentation of the interrupt handler names, and maybe a code fragment, would be enough. robodude666 on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-5041 Tue, 07 Jun 2011 12:35:42 +0000 robodude666 5041@http://forums.leaflabs.com/ I was browsing the Google Code issue tracker and ran across this ticket and feel what I have to say fits well with changes related to better interrupt APIs. In reference to <a href="http://forums.leaflabs.com/topic.php?id=834">this</a> thread where an overhead in the timers was brought up, I think it would be cool to see an ability to override the built in interrupt handlers with your own if you desire high-perofmrnace. I really like the way STMicro's Standard Library handles these handlers (no pun intended). They have a single file (stm32f10x_it.h) that contains all of the irq handlers. Something like that would be neat to see for advanced users, or users who require high-performance. Going with some of the ideas brought up in this thread I suggest something along the lines of this, taking TIM2's interrupt handler as an example: <pre><code>void __irq_tim2(void) { #ifdef __IRQ_TIM2_HP_INTERUPT if(irq_tim2()) return; #endif dispatch_general(TIMER2); }</code></pre> If the user wishes to override the built in handlers, and the overhead incurred by them, they can define <code>__IRQ_TIM2_HP_INTERUPT</code>. It will then be their responsibility to create a <code>irq_tim2</code> function in their program. The function will be able to return true (or any non-'false' value) to stop the interrupt from continuing to the built in handlers. I'm sure you guys can create better naming and APIs for this, but it's an idea. If the user doesn't want to mess around with the attachInterrupts, the array searching, and rest of the mess invovled with it, they can define a few configuration settings and have a function of a pre-defined name called when the interrupt handler is called. It would be even better if <code>__irq_tim2</code> could be defined by the user if they wish and save a few more assembly commands per IRQ call. -robodude666 mbolivar on "Suggest add attach/detach to all IRQ handler" http://forums.leaflabs.com/topic.php?id=720#post-4273 Mon, 11 Apr 2011 13:45:23 +0000 mbolivar 4273@http://forums.leaflabs.com/ Update: added a bugtracker issue so I don't forget this. <a href="http://code.google.com/p/leaflabs/issues/detail?id=62&can=3" rel="nofollow">http://code.google.com/p/leaflabs/issues/detail?id=62&can=3</a>