Hi All,
I am in the process of converting the AVR port to work with the XMEGA. There isn't a lot to change (in fact I have tasks executing, and the serial driver ported) but I have several questions:
1) In AVR port_switch (AVR/chchore.c) I noticed that not all registers are saved. Why is this? Shouldn't r0-r31 be saved on the stack?
2) I also noticed that in the port_switch routine the status register is not saved on the stack. Shouldn't this also be saved?
3) Why does PORT_IRQ_PROLOGUE mark r18-r27, r30-r31 as clobbered? Shouldn't the compiler take care of saving the appropriate registers? I can see that according to http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage those are the call-saved registered but I don't see why they would be marked as clobbered in an ISR.
The Xmega has the ability to nest interrupts. What sort of precautions do I need to take when writing the port? It is obvious to me that I need to implement port_lock_from_isr() and port_unlock_from_isr() as they are blank in the AVR port. Is there anything else I need to watch out for?
All I have really done so far is add support for 3 byte program counters. I still need to save the RAMP[D,X-Z] and EIND registers (on devices that have those)
Here is my repository for this interested. I yanked out a lot of the unused ports to keep the repo small. https://github.com/swinchen/ChibiOS_XMEGA
Thanks for the help!
Porting to Atmel XMEGA
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Porting to Atmel XMEGA
Hi,
ChibiOS saves all registers but at different times in order to make context switch efficient.
The function port_switch() only needs to save registers that functions are supposed to preserve, the caller expects the other registers to be changed so there is no need to save them.
The ISRs save the other registers and have to save all of them because when task switch happens all registers have to be saved in the extctx structure.
About interrupts nesting, see the ARM ports, your assumption is correct, the only problem is that you have to reserve enough stack to serve all the nested interrupts in each thread and that takes a lot of RAM.
Alternatively you have to simulate an IRQ stack in the ISR proloque and epilogue, this saves RAM but increases complexity and IRQ response time. Not worth the effort on an 8bit IMO but feasible.
Giovanni
ChibiOS saves all registers but at different times in order to make context switch efficient.
The function port_switch() only needs to save registers that functions are supposed to preserve, the caller expects the other registers to be changed so there is no need to save them.
The ISRs save the other registers and have to save all of them because when task switch happens all registers have to be saved in the extctx structure.
About interrupts nesting, see the ARM ports, your assumption is correct, the only problem is that you have to reserve enough stack to serve all the nested interrupts in each thread and that takes a lot of RAM.
Alternatively you have to simulate an IRQ stack in the ISR proloque and epilogue, this saves RAM but increases complexity and IRQ response time. Not worth the effort on an 8bit IMO but feasible.
Giovanni
Re: Porting to Atmel XMEGA
Ok.. hmmm.
So from ATmega128 datasheet (doc2467.pdf, p. 15): "Note that the Status Register is not automatically stored when entering an interrupt routine, nor
restored when returning from an interrupt routine. This must be handled by software." I don't see any code in the AVR port that saves the status register but I do see a "sr" register in extctx. Is this something that gcc saves for us? If so do you know where to find the documentation that explains what gcc does during function calls and interrupts on the AVR?
I don't see where extctx is used other than calculating the size of the stack. This may be the only time this is needed if all the registers are saved for us by the compiler. I feel like there is there is some fundamental ChibiOS design that I don't quite understand.
Sorry for the "newbie" question but this is my first low-level OS type project. Thanks for your patience, I am sure I will "get it" soon.
Sam
So from ATmega128 datasheet (doc2467.pdf, p. 15): "Note that the Status Register is not automatically stored when entering an interrupt routine, nor
restored when returning from an interrupt routine. This must be handled by software." I don't see any code in the AVR port that saves the status register but I do see a "sr" register in extctx. Is this something that gcc saves for us? If so do you know where to find the documentation that explains what gcc does during function calls and interrupts on the AVR?
I don't see where extctx is used other than calculating the size of the stack. This may be the only time this is needed if all the registers are saved for us by the compiler. I feel like there is there is some fundamental ChibiOS design that I don't quite understand.
Sorry for the "newbie" question but this is my first low-level OS type project. Thanks for your patience, I am sure I will "get it" soon.
Sam
Re: Porting to Atmel XMEGA
I may have answered my own question. I just de-compiled a simple application with an interrupt handler and it looks like either gcc or avr-libc injects code to save the status register.
Man, I would love to find some documentation that explains what happens during function calls and ISRs. It seems like setting up the stack and context switching based on de-compilation would be much more prone to error than good, solid documentation.
Maybe I should just stick with the MSP430
Man, I would love to find some documentation that explains what happens during function calls and ISRs. It seems like setting up the stack and context switching based on de-compilation would be much more prone to error than good, solid documentation.
Maybe I should just stick with the MSP430
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Porting to Atmel XMEGA
I like the MSP430 more than the AVR, it is a more elegant architecture, the generated code is much much smaller on the MSP.
Anyway you are correct, GCC inserts a prologue and an epilogue to ISRs automatically and that is represented in extctx structure. This behavior is not clearly described in the documentation but it is stated that code is inserted.
In general, when doing a port, it is a good idea to look closely at the generated asm.
Giovanni
Anyway you are correct, GCC inserts a prologue and an epilogue to ISRs automatically and that is represented in extctx structure. This behavior is not clearly described in the documentation but it is stated that code is inserted.
In general, when doing a port, it is a good idea to look closely at the generated asm.
Giovanni
Re: Porting to Atmel XMEGA
How goes the XMEGA port? I've just completed two boards using two different XMEGAs (an A3U and D4), and I really love the promise of these new AVRs. I have a robot competition in 12 days, so I probably should skip trying to use ChibiOS, unless I can get it up and running in a day. I only need support for task scheduling, events/messaging, and serial ports. I also need to drive a stepper motor, but I don't think I need HAL support for that.
-
- Posts: 276
- Joined: Mon Sep 24, 2012 3:52 pm
- Location: Donetsk
- Been thanked: 32 times
- Contact:
Re: Porting to Atmel XMEGA
Hi,
I made port for xMega and IAR compiler. Also I ported SERIAL driver.
http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=797&start=20
Now I adapting my existing project to work with the ChibiOS. In the process of work there were some unpleasant moments, which I have not solved yet. In general, everything works. Using and porting the drivers I am not going to, as the project is very large and everything is already written to work directly with the hard and some piece of code is written in assembler, because the speed playing a crucial role.
I made port for xMega and IAR compiler. Also I ported SERIAL driver.
http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=797&start=20
Now I adapting my existing project to work with the ChibiOS. In the process of work there were some unpleasant moments, which I have not solved yet. In general, everything works. Using and porting the drivers I am not going to, as the project is very large and everything is already written to work directly with the hard and some piece of code is written in assembler, because the speed playing a crucial role.
Who is online
Users browsing this forum: No registered users and 7 guests