[ATSAM] Interupt handling from scratch

[Simon]

ideally I would like to understand how the atmel headers work but after over a day of looking i am still confused. The AVR had one header file that put all registers into periphery structs. There are dozens of header files and I'm struggling.

If i write my own macro's/headers I will unwitingly clash with something pre existing so I guess I am wasting my time writing my own stuff as I'd have to rewrite everything.

[ataradov]

There is one file per peripheral. This file describes the peripheral registers. Those pretty struts. They are independent of any addresses or locations.

Then there is one file for each instance of the peripheral. This one describes a particular instance, so it has addresses in it.

And then there is a file per device that pulls all of that together.

Seems pretty logical to me. I really don't understand why you are having so much trouble figuring that out.

And once you get used to that, you don't even nerd to read those files. Most of the names just match names from the datasheet.

[Simon]

Well As is probably obvious I'm not that skilled in programming but I won't become so by reading books about coding for x86 platforms.

So in the SAC wu have: REG_PORT_DIR0 sure, it's there and i can use it, it I remember it. The port is now 0 instead of A, i guess i can try and remember that. and it starts with REG, i can see why but I would not have bothered. The 0 is on the end of DIR, so that reads as the DIR "0" register intead of the DIR register of port "0".

But yea i can use those.

[ataradov]

Why do you need those REG_xxx definitions? I never used them in my life.

Just use structure format, and it will be much more readable and logical: "PORT->Group[0].DIR.reg". Yes, you need to remember that 0 is A. You can create your own defines for that, and the code will read "PORT->Group[PORTA].DIR.reg".

And PORT is really the only peripheral that is this "illogical".

[Simon]

Why do you need those REG_xxx definitions? I never used them in my life.

Well where do i find anything different?, I followed the links through form the SAMC21.h header file.

[ataradov]

Just so we are talking about the same stuff. Here is a set of files I'm talking about https://github.com/ataradov/mcu-starter-projects/tree/master/samc21/include

Here you see samc21.h, which includes one of the part-specific files. Each part specific file includes header files from "components" and "instance" directories.

And later you see it actually define all the peripherals. For example here is how PORT is defined:

Code: [Select]

#define PORT              ((Port     *)0x41000000UL)
Here you can see an address cast to "Port" type. The definition of that type is located in the "component/port.h" file included earlier.

There you can see that Port is a structure that contains an array of PortGroup members:

Code: [Select]

typedef struct {
       PortGroup                 Group[2];    /**< \brief Offset: 0x00 PortGroup groups [GROUPS] */
} Port;
. And you can follow that to see what PortGroup is. It is actually the structure that defines all the PORT registers.   

[techman-001]

Maybe you should try Forth instead...

I'm not aware of any decent Open Source Forth for ATSAM because the flash controller only supports 256-bytes-at-once writes. The designer of Mecrisp-Stellaris informed me of this last March when I asked if he had considered porting to ATSAM.

Note: Mecrisp-Stellaris internally uses individual 2 byte writes (=opcode size!) on STM32 Flash.

Sample Forth interrupt handler code for Mecrisp-Stellaris on STM32F0
----------------------------------------------------------------------------------------------

 : tim6.int.handler
   do.stuff
 ;
 
 [']   tim6.int.handler   irq-tim6_dac   !        \ Tie the interrupt handler to the interrupt


STM32F051 interrupt list reference
------------------------------------------------
interrupt exti0_1
interrupt exti2_3
interrupt exti4_15
interrupt tsc
interrupt dma_ch1
interrupt dma_ch2_3
interrupt dma_ch4_5
interrupt adc
interrupt tim1_up
interrupt tim1_cc
interrupt tim2
interrupt tim3
interrupt tim6_dac
interrupt tim14
interrupt tim15
interrupt tim16
interrupt tim17
interrupt i2c1
interrupt i2c2
interrupt spi1
interrupt spi2
interrupt usart1
interrupt usart2
interrupt cec_can

[ataradov]

I'm not aware of any decent Open Source Forth for ATSAM because the flash controller only supports 256-bytes-at-once writes.

This is not true. It has to erase 256-byte row at once, but it can program any number of bytes. This is the same as with any other flash-based MCU.

There is a limit that only 8 writes can happen into a row before erase is necessary, but this can mostly be skipped for debugging. I don't know why Forth needs to write things into Flash, but hopefully it does not do that after application development is done.

[westfw]

Interrupts on a CortexM3 are "vectored" through a vector table at the beginning of memory.  It has a separate vector for each interrupt that can occur.The vector table is usually filled in by the startup file, startup_samc21.h, which will be included in builds automatically unless you take steps to prevent it.By default, the table is full of "weak" symbols to a dummy default interrupt function.

So far, this is pretty much exactly the way that the AVR interrupts work (they are also vectored, by a table in the startup code, to default functions.)
The difference is that on an AVR, you have to use the special ISR macro, because interrupt service routines need some extra code to save processor state.  On an ARM, it turns out that the hardware will save exactly the same state when an interrupt occurs as the function call ABI requires, so an ISR function is exactly the same as a normal function!
So all you have to do to create an ISR function on ATSAM is create a function with the correct name.  The compiler and linker will do the rest.
As for ENABLING an interrupt, there is an extra level that needs to be done.

• Enable interrupts at the CPU level.  Use the __enable_irq() function that is provided.  This is the same as sei() on the AVR.
• Enable the interrupts in the specific peripheral you're using.  Each peripheral has an INTENSET and INTENCLR register defined in those structures we've been trying to get you to use, or a REG_periph_INTENSET/etc symbol is the less desirable "instance/*.h files.  This is the same as setting the xxIEn bit in some peripheral status register on an AVR (except instead of a couple bits in a single status register, you probably have 3 separate registers that do nothing but manipulate or read the status of interrupt enables.)
• (this is the part that is new on the ARM) You must also enable the interrupt within the NVIC (Nested Vectored Interrupt Controller.)  The NVIC is part of the ARM definition of the CPU, so it won't appear in the Atmel include files, and probably not in the Atmel Documentation, either.  It has a bunch of 32bit registers, with each bit corrosponding to a particular vector, and some additional registers for setting priorities (which you can mostly ignore.)   The NVIC doesn't know about peripherals at all, only interrupt numbers.  So while the NVIC registers are defined in the ARM include files, the interrupt numbers are defined in the samc21xxx.h file (periperalname_IRQn)  There are also some standard functions for manipulating the NVIC.

An ATSAM chip really has WAY too many registers to define all their values manually.  You're looking at 61 register for the PORT (gpio), and some more to fiddle with the NVIC and clock for that port.  You really do need to figure out how to use the pre-defined symbols...

Which particular interrupt are you trying to configure?  pin change interrupts, since you were talking about gpio?

[techman-001]

I'm not aware of any decent Open Source Forth for ATSAM because the flash controller only supports 256-bytes-at-once writes.

This is not true. It has to erase 256-byte row at once, but it can program any number of bytes. This is the same as with any other flash-based MCU.

There is a limit that only 8 writes can happen into a row before erase is necessary, but this can mostly be skipped for debugging. I don't know why Forth needs to write things into Flash, but hopefully it does not do that after application development is done.

"This is not true. It has to erase 256-byte row at once, but it can program any number of bytes."
Thank you for the feedback Ataradov, I'll pass that along to the Mecrisp-Stellaris Forth author. Does this apply to all SAM versions and would you mind giving a Assembly example of a 2 byte write if you have the time ?

"I don't know why Forth needs to write things into Flash"
Mecrisp-Stellaris Forth compiles to Ram or to Flash as the programmer decides.

My workflow is to develop in Ram until I'm satisfied with the function I'm creating, then I'll 'compiletoflash' so that after a MCU reset I don't have to reload everything again. If a function I'm developing in Ram needs modification I just reset the MCU and upload again ... and again until it's right, then I put it in Flash.

This technique is very fast as the serial source uploads at 460800 Baud and uses hardware handshaking. Everything is orchestrated from my VIM editor make button.

There really is no such thing as a generic "Forth" because in embedded they are all different, even Mecrisp-Stellaris varies between different MCU's of the same manufacturer depending on hardware capabilities, particularly Flash.

The premier Open Source Forth for PIC (in my opinion), FlashForth can only compile to Ram for instance.

"hopefully it does not do that after application development is done: ?
It certainly can, that's up to the developer. Perhaps they may require data be saved in the Flash for some reason. Mecrisp-Stellaris can easily check the remaining Flash to see if there is adequate room before performing such a write to Flash. It does this normally anyway when the developer "compilestoflash".

[westfw]

I don't know why Forth needs to write things into Flash, but hopefully it does not do that after application development is done.

Remember that Forth is an interpreter.  You can define new words and things after the main part of your application development is done, and they'll be written to flash to save them.

for ATSAM [] the flash controller only supports 256-bytes-at-once writes.

This is not true. It has to erase 256-byte row at once, but it can program any number of bytes.

Are you sure?  I looked at the SAMC datasheet, and it's certainly possible to read it such that the 256byte-row-at-a-time, or at best 64byte-page-at-a-time writes are necessary.  It's not clear whether leaving bytes set to 0xFF when you write a page will permit those bytes to be written with non-FF values later (or exactly how you'd do that WRT "write page" command.)

[ataradov]

Yes, I'm 100% sure. You can write individual bytes or bits. Just write 0xff where you don't want things to be changed.

Otherwise the note about 8 writes into a row would not make any sense.

[techman-001]

Yes, I'm 100% sure. You can write individual bytes or bits. Just write 0xff where you don't want things to be changed.

Otherwise the note about 8 writes into a row would not make any sense.

I passed your feedback to the Mecrisp-Stellaris designer and he replied with the following questions:

Must the Flash always  be written in  ascending or descending order ?

Can it not be mixed by writing to random locations in Atmel SAME70 ?

I would be glad to know which Atmel SAM... chips may suffer from this limitations and which do not.

[ataradov]

You need to write 64 bytes for a write page command, but if you set bytes that you want to keep to 0xff, it will work.

SAM E70 is a bit different. It has ECC, so you must write in 64-bit chunks and with 64-bit alignment. But you can still do partial writes keeping in mind this limitation. This is explicitly described in the datasheet in the section about partial writes.

[techman-001]

You need to write 64 bytes for a write page command, but if you set bytes that you want to keep to 0xff, it will work.

SAM E70 is a bit different. It has ECC, so you must write in 64-bit chunks and with 64-bit alignment. But you can still do partial writes keeping in mind this limitation. This is explicitly described in the datasheet in the section about partial writes.

Thanks again, turns out that the SAM he was using to port his Forth to was a E70!

 He tells me that he may dig out some alternative SAMS and have another go, so there may yet be a Mecrisp-Stellaris Forth for SAM, just not the E70