|
A novice question: what am I missing in installing a normal ISR (not
fast), statically, not dynamically. I'm trying to use the IRQ Dispatcher, but not the whole driver. The symptom is that a compile notifies me of "undefined identifiers" FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an 'F' pre-pended. It is pramdata.c that can't find my functions. What is an "approved method" of registering my ISR function with the dispatcher when I'm not using the SDK *driver*? This would have to occur at compile time. I tried changing the order of compiling by dragging sections around in the 'Files' pane, and dragging my ISR file above appconfig.h in the 'link order list". This did not help. I tried compiling my ISR file seperating before building, no help. It is as if the linker just doesn't see my ISRs. I would be inclined to patch vector.c by changing 2 "configUnhandledInterruptISR" to by the names of my ISR functions (with or without an 'F'). I unlocked pramdata.c and pasted in my function prototypes - no change. Of course, my prototypes don;t have the "F" in them. Then I realized that I was just shooting in the dark and decided to ask those who know. I've re-read the 26 pages of Chapter 7 "Implementing Interrupts using the SDK" multiple times, and searched the Yahoo archive and looked through Exercise 3-c. So far, I've added this to the bottom of appconfig.h, in both the "external RAM" tree and the "FLASH" tree. This was all that I // *** set PLRs in GPR (page C-24 803 User Man.) #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE // *** the SDK vector table patch follows #define NORMAL_ISR_14 FISR_CAN_Transmit #define NORMAL_ISR_15 FISR_CAN_Receive My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a user .c file, not any SDK-defined file. I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c (because Chapter 7 said not to). Perhaps that documentation assumes that I am using a #define to include the whole driver, but I'm not. Thanks in advance. P.S. I just received an email virus with the subject "correct declaration in C style" from []. The virus was Exploit-MIME.gen.b or W32/Bugbear@MM. McAfee found it. Beware! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
|
|
install static NORMAL_ISR_XX in SDK
Started by ●October 10, 2002
Reply by ●October 10, 20022002-10-10
|
You have to do the following in the file "appconfig.h": 1) add the following function prototypes: void ISR_CAN_Transmit(void); void ISR_CAN_Receive(void); 2) add the following defines: // Definitions for the J1939 (CANbus) interrupts // #define GPR_INT_PRIORITY_14 3 #define NORMAL_ISR_14 ISR_CAN_Transmit #define GPR_INT_PRIORITY_15 3 #define NORMAL_ISR_15 ISR_CAN_Receive The above is an example of what we do here, you can change the priority values to be anywhere from 1 to 7 as required by your system. The reason you must do this is that the interrupt vector file "vector.c" has only the following includes: #include "port.h" #include "arch.h" #include "config.h" The file "config.h" includes the file "configdefines.h", which in turn includes your file "appconfig.h". So, the interrupt vector file "vector.c" only "knows" about the function prototypes that are explicitly inside your file "appconfig.h". This should solve your problem, but if it doesn't please let me know. 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: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 11:59 AM To: ' Subject: install static NORMAL_ISR_XX in SDK A novice question: what am I missing in installing a normal ISR (not fast), statically, not dynamically. I'm trying to use the IRQ Dispatcher, but not the whole driver. The symptom is that a compile notifies me of "undefined identifiers" FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an 'F' pre-pended. It is pramdata.c that can't find my functions. What is an "approved method" of registering my ISR function with the dispatcher when I'm not using the SDK *driver*? This would have to occur at compile time. I tried changing the order of compiling by dragging sections around in the 'Files' pane, and dragging my ISR file above appconfig.h in the 'link order list". This did not help. I tried compiling my ISR file seperating before building, no help. It is as if the linker just doesn't see my ISRs. I would be inclined to patch vector.c by changing 2 "configUnhandledInterruptISR" to by the names of my ISR functions (with or without an 'F'). I unlocked pramdata.c and pasted in my function prototypes - no change. Of course, my prototypes don;t have the "F" in them. Then I realized that I was just shooting in the dark and decided to ask those who know. I've re-read the 26 pages of Chapter 7 "Implementing Interrupts using the SDK" multiple times, and searched the Yahoo archive and looked through Exercise 3-c. So far, I've added this to the bottom of appconfig.h, in both the "external RAM" tree and the "FLASH" tree. This was all that I // *** set PLRs in GPR (page C-24 803 User Man.) #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE // *** the SDK vector table patch follows #define NORMAL_ISR_14 FISR_CAN_Transmit #define NORMAL_ISR_15 FISR_CAN_Receive My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a user .c file, not any SDK-defined file. I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c (because Chapter 7 said not to). Perhaps that documentation assumes that I am using a #define to include the whole driver, but I'm not. Thanks in advance. P.S. I just received an email virus with the subject "correct declaration in C style" from []. The virus was Exploit-MIME.gen.b or W32/Bugbear@MM. McAfee found it. Beware! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
Reply by ●October 10, 20022002-10-10
|
You can try adding
something like the following to appconfig.h:
extern void ISR_CAN_Transmit(void);
#define INTERRUPT_VECTOR_ADDR_14 ISR_CAN_Transmit extern void ISR_CAN_Receive(void);
#define INTERRUPT_VECTOR_ADDR_15 ISR_CAN_Receive This overlays the default interrupt handler.
You should drop the leading
'F' in "C" files.
Jerry.
From: Corey, Rick [mailto:r...@dpconline.com] Sent: Thursday, October 10, 2002 1:59 PM To: 'm...@yahoogroups.com' Subject: [motoroladsp] install static NORMAL_ISR_XX in SDK A novice question: what am I missing in installing a normal ISR (not fast), |
Reply by ●October 10, 20022002-10-10
|
Thanks, Art! That works. I put my prototypes into both appconfigs, RAM and FLASH. Page 7-12 of the Programmer's Guide seemed to imply that I should have added: #define NORMAL_ISR_14 FISR_CAN_Transmit However, it only compiled after I got the "F" out. If you had a nickel for every time you saved someone days of frustration, you would already be a multi-millionaire. Thanks again. Rick Corey P.S. Daniel Malik promptly reproduced my "#pragma interrupt saveall warn RTS/RTI" bug and reported it to Metrowerks, so now maybe they will acknowledge it. After more thought and re-reading Chapter 7 of the Programmer's Guide a few more times, I think more strongly that the "inline" and "#pragma interrupt called" factors may be as relevant as the "auto-inline" and "deferred inline" checkboxes. -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 10, 2002 3:29 PM To: Corey, Rick; Subject: RE: install static NORMAL_ISR_XX in SDK You have to do the following in the file "appconfig.h": 1) add the following function prototypes: void ISR_CAN_Transmit(void); void ISR_CAN_Receive(void); 2) add the following defines: // Definitions for the J1939 (CANbus) interrupts // #define GPR_INT_PRIORITY_14 3 #define NORMAL_ISR_14 ISR_CAN_Transmit #define GPR_INT_PRIORITY_15 3 #define NORMAL_ISR_15 ISR_CAN_Receive The above is an example of what we do here, you can change the priority values to be anywhere from 1 to 7 as required by your system. The reason you must do this is that the interrupt vector file "vector.c" has only the following includes: #include "port.h" #include "arch.h" #include "config.h" The file "config.h" includes the file "configdefines.h", which in turn includes your file "appconfig.h". So, the interrupt vector file "vector.c" only "knows" about the function prototypes that are explicitly inside your file "appconfig.h". This should solve your problem, but if it doesn't please let me know. 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: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 11:59 AM To: ' Subject: install static NORMAL_ISR_XX in SDK A novice question: what am I missing in installing a normal ISR (not fast), statically, not dynamically. I'm trying to use the IRQ Dispatcher, but not the whole driver. The symptom is that a compile notifies me of "undefined identifiers" FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an 'F' pre-pended. It is pramdata.c that can't find my functions. What is an "approved method" of registering my ISR function with the dispatcher when I'm not using the SDK *driver*? This would have to occur at compile time. I tried changing the order of compiling by dragging sections around in the 'Files' pane, and dragging my ISR file above appconfig.h in the 'link order list". This did not help. I tried compiling my ISR file seperating before building, no help. It is as if the linker just doesn't see my ISRs. I would be inclined to patch vector.c by changing 2 "configUnhandledInterruptISR" to by the names of my ISR functions (with or without an 'F'). I unlocked pramdata.c and pasted in my function prototypes - no change. Of course, my prototypes don;t have the "F" in them. Then I realized that I was just shooting in the dark and decided to ask those who know. I've re-read the 26 pages of Chapter 7 "Implementing Interrupts using the SDK" multiple times, and searched the Yahoo archive and looked through Exercise 3-c. So far, I've added this to the bottom of appconfig.h, in both the "external RAM" tree and the "FLASH" tree. This was all that I // *** set PLRs in GPR (page C-24 803 User Man.) #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE // *** the SDK vector table patch follows #define NORMAL_ISR_14 FISR_CAN_Transmit #define NORMAL_ISR_15 FISR_CAN_Receive My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a user .c file, not any SDK-defined file. I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c (because Chapter 7 said not to). Perhaps that documentation assumes that I am using a #define to include the whole driver, but I'm not. Thanks in advance. P.S. I just received an email virus with the subject "correct declaration in C style" from []. The virus was Exploit-MIME.gen.b or W32/Bugbear@MM. McAfee found it. Beware! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
Reply by ●October 10, 20022002-10-10
|
Thanks
Jerry!
I
happened to read Art's reply first, but you also saved me from missing
another deadline.
I'm replying now to a reply from Metrowerks. They
still do not explicitly acknowledge reproducing my #pragma interrupt
problem! I'm telling Metrowerks of the erratum and omission that you
and Art identified.
Thank
you again!
I
particularly appreciate that folks on this list do not sneer at beginner
questions.
Rick
Corey
|
|
|
Reply by ●October 10, 20022002-10-10
|
Corey, Rick wrote: > I'm replying now to a reply from Metrowerks. They still do not explicitly > acknowledge reproducing my #pragma interrupt problem! I'm telling > Metrowerks of the erratum and omission that you and Art identified. We will look into it, there is a lot going on right now but that sounds like an excuse and I'm not making any excuses. Metrowerks needs to address many issues and I'm getting engineering and operations more involved. It is only by listening and reacting we will get better. Unfortunately things move much slower than one would want even when they are moving rapidly. > I particularly appreciate that folks on this list do not sneer at beginner > questions. As a non-engineer I appreciate it too. Ron -- Ron Liechty, Ombudsman for Metrowerks Corporation |
Reply by ●October 10, 20022002-10-10
|
Hi Rick, I'm always glad to be of help. When I started working with the DSP56800 family in May of last year, I had the same problems that you and other members of this group are having. I would ask questions and _sometimes_ I would get complete (and correct) answers, but also I would often get minimal answers, incorrect answers, or no answers at all (I didn't know about this group back then). So, I had to dig in and basically learn everything myself, often by trial and error, including things that did _not_ work according to the manuals, data sheets, and tech support people that I talked to. When I first joined this group near the end of July this year, I was basically passive, expecting that most questions asked by members would get prompt, complete, and detailed answers. When I saw this was not happening, I decided to do as much as I could to help. I just thought of all the grief and frustration I went through over many months, and how much I would have appreciated some truly helpful answers. <<< OK, OK, end of self-pity section! >>> On the subject of "beginner questions", I received an email that a young developer in India sent me directly, as he was too afraid to ask his questions on the group. Here's part of my answer to him: 'The only other thing I can suggest is to post a message to the motoroladsp yahoo group to see if any other members can help you. Don't be afraid just because you are a "newbie", every one of us was a newbie at one time.' <Please, no insult intended, I am NOT calling you a newbie!!!> On a brighter note, I do think the 56800 family is an excellent group of products, Metrowerks is working hard to fix the bugs in CodeWarrior, and here at PMC we're getting very close to finishing our work on several exciting new products using the 56F807 chip. It's also a beautiful, sunny fall day here in Vancouver, the weekend is close at hand, and I have a week's vacation next week to work (or actually play) in my garden. Does it get any better than that? <rhetorical question> Best regards, Art Johnson PS: The reason you got my answer so fast is that I cheated! As a Moderator of this group I get to see the members' messages before they are posted to the group, so I started my reply just after approving your message to go to the group. So, my answer was sent _before_ your message made it onto the group (there is some delay at Yahoo, most likely due to the huge number of messages they have to process). So, I have to admit it, I'm a cheater! :-) -----Original Message----- From: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 1:13 PM To: Art Johnson; Subject: RE: install static NORMAL_ISR_XX in SDK Thanks, Art! That works. I put my prototypes into both appconfigs, RAM and FLASH. Page 7-12 of the Programmer's Guide seemed to imply that I should have added: #define NORMAL_ISR_14 FISR_CAN_Transmit However, it only compiled after I got the "F" out. If you had a nickel for every time you saved someone days of frustration, you would already be a multi-millionaire. Thanks again. Rick Corey P.S. Daniel Malik promptly reproduced my "#pragma interrupt saveall warn RTS/RTI" bug and reported it to Metrowerks, so now maybe they will acknowledge it. After more thought and re-reading Chapter 7 of the Programmer's Guide a few more times, I think more strongly that the "inline" and "#pragma interrupt called" factors may be as relevant as the "auto-inline" and "deferred inline" checkboxes. -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 10, 2002 3:29 PM To: Corey, Rick; Subject: RE: install static NORMAL_ISR_XX in SDK You have to do the following in the file "appconfig.h": 1) add the following function prototypes: void ISR_CAN_Transmit(void); void ISR_CAN_Receive(void); 2) add the following defines: // Definitions for the J1939 (CANbus) interrupts // #define GPR_INT_PRIORITY_14 3 #define NORMAL_ISR_14 ISR_CAN_Transmit #define GPR_INT_PRIORITY_15 3 #define NORMAL_ISR_15 ISR_CAN_Receive The above is an example of what we do here, you can change the priority values to be anywhere from 1 to 7 as required by your system. The reason you must do this is that the interrupt vector file "vector.c" has only the following includes: #include "port.h" #include "arch.h" #include "config.h" The file "config.h" includes the file "configdefines.h", which in turn includes your file "appconfig.h". So, the interrupt vector file "vector.c" only "knows" about the function prototypes that are explicitly inside your file "appconfig.h". This should solve your problem, but if it doesn't please let me know. 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: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 11:59 AM To: ' Subject: install static NORMAL_ISR_XX in SDK A novice question: what am I missing in installing a normal ISR (not fast), statically, not dynamically. I'm trying to use the IRQ Dispatcher, but not the whole driver. The symptom is that a compile notifies me of "undefined identifiers" FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an 'F' pre-pended. It is pramdata.c that can't find my functions. What is an "approved method" of registering my ISR function with the dispatcher when I'm not using the SDK *driver*? This would have to occur at compile time. I tried changing the order of compiling by dragging sections around in the 'Files' pane, and dragging my ISR file above appconfig.h in the 'link order list". This did not help. I tried compiling my ISR file seperating before building, no help. It is as if the linker just doesn't see my ISRs. I would be inclined to patch vector.c by changing 2 "configUnhandledInterruptISR" to by the names of my ISR functions (with or without an 'F'). I unlocked pramdata.c and pasted in my function prototypes - no change. Of course, my prototypes don;t have the "F" in them. Then I realized that I was just shooting in the dark and decided to ask those who know. I've re-read the 26 pages of Chapter 7 "Implementing Interrupts using the SDK" multiple times, and searched the Yahoo archive and looked through Exercise 3-c. So far, I've added this to the bottom of appconfig.h, in both the "external RAM" tree and the "FLASH" tree. This was all that I // *** set PLRs in GPR (page C-24 803 User Man.) #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE // *** the SDK vector table patch follows #define NORMAL_ISR_14 FISR_CAN_Transmit #define NORMAL_ISR_15 FISR_CAN_Receive My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a user .c file, not any SDK-defined file. I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c (because Chapter 7 said not to). Perhaps that documentation assumes that I am using a #define to include the whole driver, but I'm not. Thanks in advance. P.S. I just received an email virus with the subject "correct declaration in C style" from []. The virus was Exploit-MIME.gen.b or W32/Bugbear@MM. McAfee found it. Beware! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
Reply by ●December 4, 20022002-12-04
|
Hi Wim, Yes, the 'do' bug is in CodeWarrior 5 with the 5.0.2 patch. Here is the complete text of my Bug Report. Best regards, Art ======================= The bug is that CodeWarrior is generating 'do' instructions, despite the fact that we have checked ONLY the following boxes in {Project}->Target Settings Panels->Code Generation->M56800 Processor: - Peephole Optimization - Instruction Scheduling - Compiler Emits 32-bit CMP - Compiler adjusts for delayed load of N register - Write constant data to .rodata section All other boxes are unchecked, including "Allow DO Instructions". For optimization, we have selected the following in Global Optimizations: - Optimize For Faster Execution Speed - Optimization Level 4 Please do not ask us to attempt things like changing any of the above settings, using external memory, or commenting out any of our code. This will not work for several reasons as I tried to explain (apparently without success) when we were dealing with SR Number 1-25899146. We are having program crashes caused by the Hardware Stack Overflow (Vector number 5, Address X:$000A). This is being caused by CodeWarrior placing 'do' instructions in the program, despite the fact that the "Allow DO Instructions" box is unchecked in {Project}->Target Settings Panels->Code Generation->M56800 Processor. Here is a section of my source code that is causing the 'do' instruction to be generated: // Make the data from the Control Heads p_rtu_data = g_sci0_master_rtu_data; p_data = &g_Modbus_CtrlHead_Data[ DCH_DCH_STATUS_1 ]; mask = MPC_D_DCH_CENTER_BRIDGE_BIT; for ( i = 0; i < MAX_NUM_DCH_UNITS; i++, p_rtu_data++, p_data += MPC_D_MODBUS_TABLE_CONTROL_HEAD_HSDATA_LENGTH, mask <<= 1 ) { . . (contents of the loop not shown) . } Here is the assembly code from the start of the loop: P:00003669: CC8F376A do #0xf,0x376a P:0000366B: B8FF move X:(SP-0x0001),R0 P:0000366C: E040 nop P:0000366D: F014 move X:(R0),X0 P:0000366E: 90FB move X0,X:(SP-0x0005) P:0000366F: BE38 tstw X:0x0038 P:00003670: C100 clr Y0 P:00003671: A201 bne Sic_Logic+0x22 (0x3673) ; 0x001b3a I am not sending you a test case, because I think this information should be enough for you to find the cause of this Bug. I also do not have the time available right now to develop a test case, as I am under extreme pressure to get software produced for several of our new products. Please let me know as soon as you have made some progress in fixing this Bug. Thank you. Sincerely, 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: Wim de Haan [mailto:] Sent: Tuesday, December 03, 2002 11:53 PM To: Art Johnson Subject: RE: install static NORMAL_ISR_XX in SDK Hi Art, In the Netherlands we have a manner of saying "shared distress is half distress (and shared joy is double joy)" I am glad that I am not alone with my frustations about Metrowerks (the shared distress). You mentioned the 'do' instruction bug. Is this bug present in Codewarrior 4 and 5? Do you have a more detailed description of this bug? Thanks in advance! Kind regards, Wim de Haan Exendis B.V. W.J. de Haan P.O.box 56, 6710 BB Ede Keesomstraat 4, 6716 AB Ede The Netherlands. Tel: +31-(0)318 - 676305 Fax: +31-(0)318 - 676319 mailto: URL: http://www.exendis.com -----Original Message----- From: Art Johnson [mailto:] Sent: vrijdag 11 oktober 2002 15:40 To: Corey, Rick Subject: RE: install static NORMAL_ISR_XX in SDK Hi Rick, It's a pleasure for me as well, to have these discussions. I don't think it would be helpful to share details of the relative priorities of the bugs that need to be fixed. As you say, everyone would have a different opinion and so it could actually slow down progress on the bug fixes. I do think that it should be obvious to Metrowerks, that bugs causing total program crashes should be put above all other bug fixes. This is just common sense. In this regard, the 'do' instruction bug that I found recently is in this category. I tried to show Metrowerks the seriousness of this in 3 paragraphs of my bug report: ============================ "This Bug is a real "Show Stopper" for us. Since it is responsible for total system crashes and is likely to happen at any time in any of our products, we cannot ship anything until we receive a fix or work around for this Bug. Obviously, this Bug can cause the same failures in any other company's software as well. The DSP56800 family of devices are often used in critical safety or control systems, where a program crash could be responsible for property damage, personal injury, or even death. I feel very strongly that this Bug should be addressed immediately, and it should be given a higher priority than any other Bug or feature enhancement that Metrowerks is currently working on. If it is necessary for you to go higher up the chain of command at Metrowerks to raise the priority of this Bug, please do so." ============================ This did not have the desired effect, so my manager here started going through "other channels". This DID have the desired effect! We were visited yesterday afternoon by our local Motorola rep who brought along John R. Deck, the Western US Regional Sales Manager at Metrowerks. We went over all the problems we are having (basically everything that's been said on the discussion group), and I summed up my feelings about CodeWarrior as follows: "I have been developing software for more than 26 years, and in that time I have used hundreds of software products. In my opinion, if there was a race to find the WORST software product in the whole universe, CodeWarrior would be in first place, by a huge margin. It would be so far ahead of whoever's in second place that you couldn't see them with the Hubble Space Telescope!!! - using the best far-field lens - and a month-long exposure - with all of NASA's, JPL's, NSA's, and DOD's supercomputers running image enhancement software" I have no doubt he clearly understood our message. He promised that things will be moving ahead briskly and efficiently with this critical Bug Report. Anyway, I have to get back to work now, so have a great weekend (even though you have to work)! Best regards, Art -----Original Message----- From: Corey, Rick [mailto:] Sent: Friday, October 11, 2002 5:29 AM To: Art Johnson Subject: RE: install static NORMAL_ISR_XX in SDK Hi Art, What a pleasure to read your email! The perspective was very helpful, and I do agree: how *could* it get any better? I happen to have heavy rain and two days of code-work this weekend, but still, if the tools are working well enough to make progress, and our cute little boards still haven't smoked, and more and more of my code is working, I am whistling while I work. (Our managers seem almost frightened to see the most-nerdy developers cheerful and finally upbeat, when they only see a deadline missed and more slippage in our future. However, we know that progress comes from pain, and that we may even be past the worst of the pain!) Ron at Metrowerks has sent me several very thoughtful and reasonable Emails explaining their constraints and intentions, and I feel better about them, too. Perhaps the only true underlying difference is what constitutes "fast enough", and what can be done to appease the ravening pack of wolves (my phrase) while total perfection of the toolset is pursued as fast as resources permit. What do you think: would sharing details of what order they hope to address issues help or hurt? I thought that many folks who saw their own pet peeve below the top 10% might become even more indignant. Also, I would dread the response (or even my own response) of someone who saw his claim of a compiler bug relegated to the status of "*perceived* compiler bug". I'm just glad not to be in the position of a Metrowerks manager facing 450 demanding developers on a daily basis! Have a great few days in your garden! The field of corn next door to me is all brown and withered, and we just figured out what that huge patch of weeds is. Nightshade! I'm glad I didn't nibble on the flowers. It's been great getting to know you. And feel free to call me a newbie! There is always so much to learn that we are *all* perennial newbies in this industry. All is relative. Rick Corey -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 10, 2002 6:35 PM To: Corey, Rick; Subject: RE: install static NORMAL_ISR_XX in SDK Hi Rick, I'm always glad to be of help. When I started working with the DSP56800 family in May of last year, I had the same problems that you and other members of this group are having. I would ask questions and _sometimes_ I would get complete (and correct) answers, but also I would often get minimal answers, incorrect answers, or no answers at all (I didn't know about this group back then). So, I had to dig in and basically learn everything myself, often by trial and error, including things that did _not_ work according to the manuals, data sheets, and tech support people that I talked to. When I first joined this group near the end of July this year, I was basically passive, expecting that most questions asked by members would get prompt, complete, and detailed answers. When I saw this was not happening, I decided to do as much as I could to help. I just thought of all the grief and frustration I went through over many months, and how much I would have appreciated some truly helpful answers. <<< OK, OK, end of self-pity section! >>> On the subject of "beginner questions", I received an email that a young developer in India sent me directly, as he was too afraid to ask his questions on the group. Here's part of my answer to him: 'The only other thing I can suggest is to post a message to the motoroladsp yahoo group to see if any other members can help you. Don't be afraid just because you are a "newbie", every one of us was a newbie at one time.' <Please, no insult intended, I am NOT calling you a newbie!!!> On a brighter note, I do think the 56800 family is an excellent group of products, Metrowerks is working hard to fix the bugs in CodeWarrior, and here at PMC we're getting very close to finishing our work on several exciting new products using the 56F807 chip. It's also a beautiful, sunny fall day here in Vancouver, the weekend is close at hand, and I have a week's vacation next week to work (or actually play) in my garden. Does it get any better than that? <rhetorical question> Best regards, Art Johnson PS: The reason you got my answer so fast is that I cheated! As a Moderator of this group I get to see the members' messages before they are posted to the group, so I started my reply just after approving your message to go to the group. So, my answer was sent _before_ your message made it onto the group (there is some delay at Yahoo, most likely due to the huge number of messages they have to process). So, I have to admit it, I'm a cheater! :-) -----Original Message----- From: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 1:13 PM To: Art Johnson; Subject: RE: install static NORMAL_ISR_XX in SDK Thanks, Art! That works. I put my prototypes into both appconfigs, RAM and FLASH. Page 7-12 of the Programmer's Guide seemed to imply that I should have added: #define NORMAL_ISR_14 FISR_CAN_Transmit However, it only compiled after I got the "F" out. If you had a nickel for every time you saved someone days of frustration, you would already be a multi-millionaire. Thanks again. Rick Corey P.S. Daniel Malik promptly reproduced my "#pragma interrupt saveall warn RTS/RTI" bug and reported it to Metrowerks, so now maybe they will acknowledge it. After more thought and re-reading Chapter 7 of the Programmer's Guide a few more times, I think more strongly that the "inline" and "#pragma interrupt called" factors may be as relevant as the "auto-inline" and "deferred inline" checkboxes. -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 10, 2002 3:29 PM To: Corey, Rick; Subject: RE: install static NORMAL_ISR_XX in SDK You have to do the following in the file "appconfig.h": 1) add the following function prototypes: void ISR_CAN_Transmit(void); void ISR_CAN_Receive(void); 2) add the following defines: // Definitions for the J1939 (CANbus) interrupts // #define GPR_INT_PRIORITY_14 3 #define NORMAL_ISR_14 ISR_CAN_Transmit #define GPR_INT_PRIORITY_15 3 #define NORMAL_ISR_15 ISR_CAN_Receive The above is an example of what we do here, you can change the priority values to be anywhere from 1 to 7 as required by your system. The reason you must do this is that the interrupt vector file "vector.c" has only the following includes: #include "port.h" #include "arch.h" #include "config.h" The file "config.h" includes the file "configdefines.h", which in turn includes your file "appconfig.h". So, the interrupt vector file "vector.c" only "knows" about the function prototypes that are explicitly inside your file "appconfig.h". This should solve your problem, but if it doesn't please let me know. 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: Corey, Rick [mailto:] Sent: Thursday, October 10, 2002 11:59 AM To: ' Subject: install static NORMAL_ISR_XX in SDK A novice question: what am I missing in installing a normal ISR (not fast), statically, not dynamically. I'm trying to use the IRQ Dispatcher, but not the whole driver. The symptom is that a compile notifies me of "undefined identifiers" FISR_CAN_Transmit and FISR_CAN_Receive (my ISR function names with an 'F' pre-pended. It is pramdata.c that can't find my functions. What is an "approved method" of registering my ISR function with the dispatcher when I'm not using the SDK *driver*? This would have to occur at compile time. I tried changing the order of compiling by dragging sections around in the 'Files' pane, and dragging my ISR file above appconfig.h in the 'link order list". This did not help. I tried compiling my ISR file seperating before building, no help. It is as if the linker just doesn't see my ISRs. I would be inclined to patch vector.c by changing 2 "configUnhandledInterruptISR" to by the names of my ISR functions (with or without an 'F'). I unlocked pramdata.c and pasted in my function prototypes - no change. Of course, my prototypes don;t have the "F" in them. Then I realized that I was just shooting in the dark and decided to ask those who know. I've re-read the 26 pages of Chapter 7 "Implementing Interrupts using the SDK" multiple times, and searched the Yahoo archive and looked through Exercise 3-c. So far, I've added this to the bottom of appconfig.h, in both the "external RAM" tree and the "FLASH" tree. This was all that I // *** set PLRs in GPR (page C-24 803 User Man.) #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE // *** the SDK vector table patch follows #define NORMAL_ISR_14 FISR_CAN_Transmit #define NORMAL_ISR_15 FISR_CAN_Receive My ISRs are named ISR_CAN_Transmit & ISR_CAN_Receive. I put them into a user .c file, not any SDK-defined file. I have not yet patched archUserISRTable[ ] or archISRType[ ] or vector.c (because Chapter 7 said not to). Perhaps that documentation assumes that I am using a #define to include the whole driver, but I'm not. Thanks in advance. P.S. I just received an email virus with the subject "correct declaration in C style" from []. The virus was Exploit-MIME.gen.b or W32/Bugbear@MM. McAfee found it. Beware! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
|
|
Reply by ●December 4, 20022002-12-04
|
Art Johnson wrote: > Yes, the 'do' bug is in CodeWarrior 5 with the 5.0.2 patch. Here is the > complete text of my Bug Report. While this is not a "bug" since the project had "peephole optimizations" and "instruction scheduling" turned on and we do not support debugging when these options are enabled, it is fixed in the upcoming patch to behave as Art and others believe it should. Ron > ======================= > > The bug is that CodeWarrior is generating 'do' instructions, despite the fact > that we have checked ONLY the following boxes in {Project}->Target Settings > Panels->Code Generation->M56800 Processor: > - Peephole Optimization > - Instruction Scheduling > - Compiler Emits 32-bit CMP > - Compiler adjusts for delayed load of N register > - Write constant data to .rodata section > All other boxes are unchecked, including "Allow DO Instructions". > > For optimization, we have selected the following in Global Optimizations: > - Optimize For Faster Execution Speed > - Optimization Level 4 -- Can you really afford not to use CodeWarrior 8.3 ? Faster Compiles, Improved Code Generation, Updated IDE for OS X 10.2 http://www.metrowerks.com/MW/Support/Download/default.htm Ron Liechty - - http://www.metrowerks.com |
