If you are using the SDK Interrupt Dispatcher with a "Normal" or a
"Fast" interrupt, you can free up a lot of the CPU resources if you use a "Super Fast" interrupt instead. This is one that completely bypasses the SDK Interrupt Dispatcher. We use "Super Fast" interrupts in a system that has four 115200 baud serial ports (2 on-chip and 2 off-chip), which create an interrupt every 86.8us on each port. Even at this rate, the interrupts use up less than 5% of the total CPU time, when all ports are active simultaneously. The "Super Fast" interrupts are described quite well in the Motorola on-line documentation, but here's a quick description of what is involved. The most important thing to remember is that all registers used by the interrupt must be saved on the stack and restored at the end of the interrupt. Also, if you want use R0 and R1 as general-purpose memory pointers and M01 has been set for Modulo Arithmetic, you will have to save M01 on the stack, set it to 0xFFFF for the duration of the interrupt, and restore its value at the end of the interrupt. Here's how we use a "Super Fast" interrupt for one of the on-chip serial ports: In the file "appconfig.h": // Definitions for the SCI #0 Transmitter Ready interrupt, // which is vector number 51, and the SCI #0 Receiver // Full interrupt, which is vector number 53. // // These definitions are required so the interrupt vector // and priority are set by the standard files "vector.c", // "config.c", and "const.c" // #include "sci0_task.h" // To get function prototypes #define GPR_INT_PRIORITY_53 6 #define INTERRUPT_VECTOR_ADDR_53 Sci0_Task_Rx_Interrupt #define GPR_INT_PRIORITY_51 5 #define INTERRUPT_VECTOR_ADDR_51 Sci0_Task_Tx_Interrupt In the file "sci0_task.h": void Sci0_Task_Rx_Interrupt(void); void Sci0_Task_Tx_Interrupt(void); In the file "sci0_task.c": void Sci0_Task_Rx_Interrupt(void) { // Save the registers that are used asm (lea (sp)+ ); asm (move x0,x:(sp)+ ); asm (move y0,x:(sp)+ ); asm (move r2,x:(sp)+ ); asm (move r3,x:(sp) ); . . (process the interrupt) . // Restore the registers that are used asm (pop r3 ); asm (pop r2 ); asm (pop y0 ); asm (pop x0 ); asm (rti ); } void Sci0_Task_Tx_Interrupt(void) { // Save the registers that are used asm (lea (sp)+ ); asm (move x0,x:(sp)+ ); asm (move y0,x:(sp)+ ); asm (move r2,x:(sp)+ ); asm (move r3,x:(sp) ); . . (process the interrupt) . // Restore the registers that are used asm (pop r3 ); asm (pop r2 ); asm (pop y0 ); asm (pop x0 ); asm (rti ); } I hope this information is useful for you. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com -----Original Message----- From: Christian Brauchli [mailto:] Sent: Monday, September 30, 2002 10:02 AM To: Art Johnson; Subject: RE: [motoroladsp] Compiler efficiency article Hi, I can also confirm what Art is talking about. The compiler is quite inefficient. While doing the prototying of a motion Control Application we used C-Programming language. Our Interrupt service routine which has been called each 33us used about 30us(C-Code)(just about 3us or 10% for doing other things) . So the processor 56807 was at the limit. While translating the C-Code into Assembly (manually) we could reduce the 30us runtime down to 14us(so we have now more than 57% of available ressources). So the Code made by hand was at least twice as fast as the C-Code. We started using this processor in March 2001 and we have a lot of experience with the processor and Code-Warrier IDE. There are many bugs in the compiler. Usually if the C-Code is not running we check for the assembly code and implement a work-arround. rgds Chris Brauchli Head of Software Development Dep. __________________________________ BRAUCHLI NETSOLUTION BERG Bahnhofstrasse 7 CH- 8572 Berg Switzerland Tel. +41/ 71 / 638 00 45 Fax. +41/ 71 / 638 00 46 Mob. +41/ 78 / 616 22 14 email. www.brauchli-netsolution.ch __________________________________ -----Original Message----- From: Art Johnson [mailto:] Sent: Montag, 30. September 2002 16:04 To: Subject: [motoroladsp] Compiler efficiency article Hi, I thought you might be interested in reading this article about the efficiency of modern compilers, especially when they're used with DSP chips. As you know, in my opinion the CodeWarrior 56800 compiler is extremely inefficient at generating object code, compared to the best that can be done manually. I reported this to Metrowerks (SR Number: 1-13810245 -- Suggested improvement in the compiler), and they say that the 56800E compiler has this fixed already, but they're not sure when it will be fixed in the 56800 tools. Please follow this link: http://www.electronicstimes.com/story/OEG20020516S0032 Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |