Suggest add attach/detach to all IRQ handler

LeafLabs Garden » Support » Maple Hardware Support

Suggest add attach/detach to all IRQ handler

(21 posts) (6 voices)

Started 4 years ago by x893
Latest reply from gbulmer

For beginners ability change IRQ handlers i suggest add attach/detach functionality to all IRQ handlers (as i understand weak not enough for this). So easy change handlers to custom. For shared IRQ handlers (for example USB/CAN) suggest attach function return false for originial processing or true for exit from original IRQ handler. Or tthis rules implement for all attach functions.

For example

Serial1.attach(custom_function)

struct usart_dev usart_dev_table[] = {
    [USART1] = {
        .base = (usart_port*)USART1_BASE,
        .rcc_dev_num = RCC_USART1,
        .nvic_dev_num = NVIC_USART1,
	.handler = NULL
    },
...
// Or uint8(*handler)(void)
void usart_attach(uint8 usart_num, void (*handler)(void))
{
	usart_dev_table[usart_num].handler = handler;
}
void usart_detach(uint8 usart_num)
{
	usart_dev_table[usart_num].handler = NULL;
}

static inline void usart_irq(int usart_num) {
	if (usart_dev_table[usart_num].handler != NULL)
	{
		(usart_dev_table[usart_num].handler)();
		if ((usart_dev_table[usart_num].handler)())
			return;
	}
#ifdef USART_SAFE_INSERT
	    /* Ignore old bytes if the user defines USART_SAFE_INSERT. */
		rb_safe_insert(&(usart_dev_table[usart_num].rb), (uint8)((usart_dev_table[usart_num].base)->DR));
#else
    /* By default, push bytes around in the ring buffer. */
		rb_push_insert(&(usart_dev_table[usart_num].rb), (uint8)((usart_dev_table[usart_num].base)->DR));
#endif
}

void USART1_IRQHandler(void) {
    usart_irq(USART1);
}

hope in some situation it's helpfull

Posted 4 years ago #

gbulmer
Moderator
I like the idea of making interrupts easier for beginners to use.

One of the secondary school students (16yo) I work with would like to write interrupt handlers (in his case for catching ADC conversion 'done').

Are the USART interrupts 'armed' by default? If not, that needs to be added too.

I think it might be good to wrap all the user-interrupts in one mechanism, then all interrupts use the same base mechanism.

Usually the attach handler mechanism returns the current value of the handler for that interupt so that you can implement interrupt service routine chaining (if you really want to) (but I'll ignore that for now in my example).

Folks could choose to wrap a general purpose mechanism, so for example,
```
void usart_attach(uint8 usart_num, void (*handler)(void))
{
	usart_dev_table[usart_num].handler = handler;
}
```
could become:
```
void usart_attach(uint8 usart_num, void (*handler)(void))
{

    switch (usart_num) {
    case 1: (void) attach_user_interrupt(IRQ_USART1, handler); // ignore previous handler
            break;
    case 2: (void) attach_user_interrupt(IRQ_USART2, handler);
            break;
    ...
    default: /* ignore it */
    }
}
```
Obviously there are lots of ways to write this.
WARNING: my code is uncompiled

attach_user_interrupt(...) just manages a table of user-interrupt handlers. The IRQ_'s, for example IRQ_USART1, are just constants indexing into that table.

I prefer this general approach to one which has special systems for each source of interrupts, e.g. one system for pin change on special pins, one for ADC, one for timers, etc.

The interrupt handler table could be 'the real one', or it could be indirect via an in RAM table.

In the case where it isn't the real interrupt table, calling the interrupt will be a little bit slower, but it gives extra flexibility. For example we might eventually choose to demultiplex, or even multiplex interrupts. For example we could invent three 'pseudo interrupts' for each USART. One might be for TX buffer empty, one for RX got a character, and one may be hardware handshaking. Or Timer 1 interrupts could be coalesced into one.

Initially I'd probably try to get as close to the real interrupts as possible to avoid writing extra documentation :-)
Posted 4 years ago #
x893
Member
Yes, but i add functionality to enable/disable native (libmaple) handlers. For example if i want use CAN - i need use libmaple USB handler if CAN disable and disable USB handler if CAN enable. So attached handlers must return true/false to original handler for enable/disable original handlers - it's only for shared irq handlers, but may be helpful for single source irq.

Something like this (only example)
```
void USB_IRQ_Handler(void)
{
  ... // Check if attached handler define and call it (not a void)
  if (attached_handler()) // Return true(1) if no need other processing
    return;

  // libmaple USB handler
  ...
}

uint8 attached_handler(void)
{
  if (CAN_Enable)
  {
     // Processing CAN
  }
  return CAN_Enable;
}
```
Posted 4 years ago #
mbolivar
LeafLabs

x893,

Interesting idea. Thanks to gbulmer for validating that the concept is not only of interest to advanced users.

I agree that the CAN/USB IRQ sharing issue seems to indicate that attaching an interrupt is a reasonable idea there. However, I wonder whether DMA isn't a better way of going about interrupting on USART byte receive/ADC conversion.

In any case, the new NVIC interface exposes a more convenient mechanism for relocating your vector table:

https://github.com/leaflabs/libmaple/blob/refactor/libmaple/nvic.c#L77

This should enable advanced users to make their own decisions for the time being (admittedly at a small penalty in having two tables around).

Once 0.0.10 gets out, let's play around with a few interfaces and see what suits our purposes best.

By the way, I've made a list of blocking changes to the 0.0.10 release here:

http://wiki.leaflabs.com/index.php?title=Blocking_Changes

I also keep this FAQ up to date:

http://static.leaflabs.com/mbolivar/libmaple_design/faq.html#how-long-is-this-going-to-take

I expect the USART refactor to be out by tomorrow.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - could you triage your 'blocking list' to make some 0.0.10 'betas'?

That way you might get some stuff out, and let the community test some of it before it is all 'baked'.

For example don't:
- refactor HardwareTimer & docs
- Restyle ... generated HTML documentation to be green
- Fix IDE so it removes build dirs on Windows
- Update documentation URL scheme to allow for future expansion.

I'm just picking these somewhat at random, to try to see if there is a useful subset that LeafLabs can focus on and ship as an 'early access' 0.0.10

(full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
mbolivar
LeafLabs

Ok, I've reordered the list by priority and specified when the beta will come out.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - Thank you! That is very helpful :-)

I am impressed & amazed that so much is included. Please don't feel that it has to be exactly that list; maybe add a small note to say that page is a 'living document and may change without notice' to give yourselves some 'wiggle room' :-)

Good luck
GB-)

Posted 4 years ago #
mbolivar
LeafLabs

gbulmer,

Thanks! We're excited about this release.

Posted 4 years ago #
mbolivar
LeafLabs

Update: added a bugtracker issue so I don't forget this.

http://code.google.com/p/leaflabs/issues/detail?id=62&can=3

Posted 4 years ago #
robodude666
Member
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 this 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:
```
void __irq_tim2(void)
{
#ifdef __IRQ_TIM2_HP_INTERUPT
	if(irq_tim2())
		return;
#endif

    dispatch_general(TIMER2);
}
```
If the user wishes to override the built in handlers, and the overhead incurred by them, they can define __IRQ_TIM2_HP_INTERUPT. It will then be their responsibility to create a irq_tim2 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 __irq_tim2 could be defined by the user if they wish and save a few more assembly commands per IRQ call.

-robodude666
Posted 4 years ago #
gbulmer
Moderator

I'm not sure how efficient you want this.

For zero overhead, replace the placeholder you've called __irq_tim2.

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):
http://embeddedfreak.wordpress.com/2009/08/07/cortex-m3-interrupt-vector-table/
http://dev.frozeneskimo.com/notes/getting_started_with_cortex_m3_cmsis_and_gnu_tools

So to replace a function defined as
void __irq_tim2(void);

would only need a user to write a function implementation for void __irq_tim2(void):
void __irq_tim2(void) { ... }
compile it, and have it linked before the library.

Assuming the interrupt table is initialised with the address of void __irq_tim2(void), 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:
SIGNAL(TIMER2_OVF_vect) { ... }
where TIMER2_OVF_vect is a predefined interrupt vector name.

But, I glanced at the gnu documentation:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
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 _fail() and it just loops forever, so straightforward :-)

So, the documentation of the interrupt handler names, and maybe a code fragment, would be enough.

Posted 4 years ago #
mbolivar
LeafLabs

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.

Posted 4 years ago #
jigajigajoo
Member

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. http://forums.leaflabs.com/topic.php?id=40

Posted 4 years ago #
mbolivar
LeafLabs

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 http://leaflabs.com/docs/hardware/maple.html#recommended-reading 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:

https://github.com/leaflabs/libmaple/blob/0.0.11/libmaple/usart.c#L233

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.

Posted 4 years ago #
konan
Member

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?

Posted 4 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.