[ATSAM] Interupt handling from scratch

[Simon]

So having finally worked out how to address memory with pointers (thankyou to those that helped) I can now forgoe the manufacturers header files and use my own defines to just write/read the register memory locations.

So the next hurdle in this series is interupts. These too are address specific, so how do I get the compiler to put my interupt servicing routine at the right address?

[ataradov]

You do it in a linker script. Pretty minimal example here https://github.com/ataradov/mcu-starter-projects/tree/master/samc21, as usual. Actual functions can br located anywhere, but the vector table is fixed.

Also, not using manufacturer header files (or generated manually from SVD files) is a really bad idea.

[Simon]

OK, thank you but what is the linker and how did you create one?

[ataradov]

https://en.wikipedia.org/wiki/GNU_linker There is plenty of documentation on that stuff. You can start with the site mentioned in the article.

The linker script is here https://github.com/ataradov/mcu-starter-projects/blob/master/samc21/linker/samc21j18.ld Mine is derived from the stock one.

[Simon]

OK so what have you actually done as I see most of the files are as supplied. How are your examples different from a fresh project in AS. Basically I am trying to have a project were I can setup my own accesses to the registers (memory) without clasting with existing naming in the atmel files.

[ataradov]

Accessing registers and implementing interrupts are totally independent. Yes, I'm using vendor supplied header files for the code, because why would not I?

The vector stuff is located in the startup file and a linker script. Those files are created from scratch.

[Simon]

Yes so what I am trying to do is avoid the register definitions as I'm finding it easy enough to just err, address the registers by address. But I need to be able to do interrupts.

[ataradov]

So what is the actual problem? Pointers to the interrupt vectors are located in the table "void (* const vectors[])(void)". This table is placed at the beginning of the flash memory using a linker script (samc21j18.ld). None of this requires any header files.

You will need to re-implement functions NVIC_*() to actually work with the interrupt controller itself, if you don't want ARM core headers either.

[Simon]

How do you mean work with the interrupt controller itself? I just need to be able to handle the various interrupts.

[ataradov]

You need to first understand how interrupts work on ARM controllers. You have a vector table, which lists pointers to all the interrupt handler functions. They are simple C functions, nothing fancy. This table has to be located at the beginning of the flash memory. You can relocate it, but don't worry about that now, just assume that it has to be at the beginning.

The interrupt controller will fetch those vectors when it needs to execute an interrupt.

The interrupt controller itself looks just like any other peripheral (TC or SERCOM, for example). You can work with it using functions you normally use to access registers.

[Simon]

Well all the data sheet does is list the interrupt line numbers and there is only one per periphery so how different events on the same periphery trigger a different interrupt is a mystery to me.

[ataradov]

Yes, there is only one handler per peripheral. It is up to the application to read the interrupt status register and figure out what specific event caused the interrupt. That's what INTFLAG register is for.

[Simon]

So either way I do it I would always have to check the status register and execute whatever code is relevant?

[ataradov]

If you only enable one interrupt source (via INTENSET), then you don't have to check it, you will know that only one thing would have caused the interrupt. But generally, yes, you need to look at all possibly enabled flags and see if one (or multiple) of them are active.

[Simon]

OK, so basically it's just a case of getting the compiler to put the code for each handler in the right address. What is NVIC_*() ? Can't I just copy out the interrupt handling stuff?

[ataradov]

No, the actual code can go anywhere you or compiler likes. All the pointers to the handlers are collected in one table.

NVIC_*() are standard functions for working with NVIC. You can look at what they do and copy that code, of course. Again, you are going against industry best practices, but ultimately it is up to you.

[Simon]

Well what is the magic code for accessing registers. These are not published and the headers are double Dutch to me as there are so many levels.

[ataradov]

It is the same code we discussed in the other thread in great detail.

There is no magic, they are memory mapped registers, you access them the same way as you do now for the peripherals.

NVIC registers are published and documented in the core documentation. They are a part of the core.

But you will be better off learning how to work with header files.

[Simon]

The AVR mega 0 series use struct variables that loosely follow the data sheet. "Peripheral name""instance number"."register name".

The SAMC does not follow this logic. Indeed, it takes a massive debate to work out what has been done and given that I suspect that the headers are for ASF and not human consumption they all have very long-winded and non memorable names. If they have really done that then I'd prefer my own names that I can at least remember. But yes it would be nice to be able to just use the headers. 1.5 days trying to figure out what they have done. 0.5 days to figure out pointer memory addressing and get pins toggling. Here and now with what Atmel/Microchip offer I can't even figure out how to toggle a pin!

[ataradov]

We may be talking about different things or you are looking at some other header files.

Atmel header files are best in the industry, IMO.

And they follow the same general structure as for AVRs.

No idea why you are having so many problems with them.

[Simon]

well PORTA.DIR  would work on AVR mega 0 series. It does not on SAMC, that's all I am saying.

[ataradov]

You are fixating on ports too much. They are described differently. It is not a big deal.

But we are going in circles.

[SiliconWizard]

Maybe you should try Forth instead...

[Simon]

You are fixating on ports too much. They are described differently. It is not a big deal.

But we are going in circles.

Well Ports is where anyone would start. The easiest way af knowing if I have got the chip working at the most basic level is to toggle a pin. So where as on AVR all the registers follow the same format the SAMC ones have two style? so how are the ports refered to?

[ataradov]

Again, did not we discuss them to death already?

I offered you to use my macros for working with ports. The way those macros are implemented show you how to use ports. It is syntactically different, but basically the same as with any other MCU. It will be hard to do anything if you are that picky about small details like that.

Also, you came up with your own macros. What happened to them? Why is this an issue again?

Don't like how header files describe ports? Don't use that part. But use them for other peripherals that are more traditional. Including NVIC itself.