|
Is there a
loss in time response /generated machine code efficiency or otherwise using the
Motorla SDK for programming 56807 DSPs versus "raw" programming?
Specially usning CAN and RS 232?
Luis
Villa |
|
|
SDK more overhead?
Started by ●February 26, 2003
Reply by ●February 26, 20032003-02-26
|
The SDK device drivers will use a larger amount of code, and will be significantly slower, compared to doing "raw" programming. The only parts of the SDK we use here are the startup code and the Interrupt Dispatcher. We don't use any of the SDK device drivers, we wrote all of our own drivers for the on-chip peripherals. This way we get exactly what we need, without the overhead of something that is designed to handle all possible options. This is not to criticize the SDK code, I look at it as an excellent learning tool, but not something I would use for our own production code. For the CAN and RS 232 communication ports, it is necessary to use interrupts to get the required response time. What we do here in our DSP56F807 products, and it works perfectly in all of our applications, is this: 1) If it is NOT critical to have a very short execution time for the interrupt, we use the SDK Interrupt Dispatcher with a "Normal" interrupt. The SDK Interrupt Dispatcher saves and restores ALL registers for "Normal" interrupts. We use "Normal" interrupts for the CAN communication port ISRs. 2) If it IS critical to have a very short execution time for the interrupt, we use a "Super Fast" interrupt, which we always write in assembler. The interrupt vector points directly to your ISR function, so the SDK Interrupt Dispatcher is completely bypassed. You must also save and restore all registers explicitly in your code. We use "Super Fast" interrupts for all of the other serial communication port ISRs (SCI0 and SCI1). 3) I would NOT recommend using a "Fast" interrupt, as it does not save/restore all registers. The on-line documentation for the SDK Interrupt Dispatcher is really quite excellent, basically I just read it, tried it, and everything worked the first time. You can start the SDK on-line documentation as follows: Start Programs Motorola Embedded SDK 2.5 Help and Documentation In "Contents", go to: Motorola Embedded SDK Core Documentation SDK Programmer's Guide 7 Interrupts Section 7.2.1 explains the differences between the 3 types of ISRs. Section 7.2.6 describes the SDK Interrupt Dispatcher. Section 7.2.8.3 describes using "#pragma interrupt" with the SDK Interrupt Dispatcher. Also look at Section 7.5.1 "Using Pragma Interrupt". I hope this information is helpful to you, please let me know if you have any more questions. 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: LuisST [mailto:] Sent: Wednesday, February 26, 2003 8:36 AM To: Subject: [motoroladsp] SDK more overhead? Is there a loss in time response /generated machine code efficiency or otherwise using the Motorla SDK for programming 56807 DSPs versus "raw" programming? Specially usning CAN and RS 232? Luis Villa Product Manager Soluciones Tecnolicas, S.A. ph +52 (333) 615-3214 fax +52 (333) 615-1856 _____________________________________ 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 |
|
|
Reply by ●February 26, 20032003-02-26
|
Art, Thanks, this was very useful. I am moving from programming cards such as NI DAQ cards to programming DSPs and the learning curve has been a bit steep for me. Luis Villa -----Original Message----- From: [mailto:] Sent: Wednesday, February 26, 2003 11:13 AM To: LuisST; Subject: RE: [motoroladsp] SDK more overhead? The SDK device drivers will use a larger amount of code, and will be significantly slower, compared to doing "raw" programming. The only parts of the SDK we use here are the startup code and the Interrupt Dispatcher. We don't use any of the SDK device drivers, we wrote all of our own drivers for the on-chip peripherals. This way we get exactly what we need, without the overhead of something that is designed to handle all possible options. This is not to criticize the SDK code, I look at it as an excellent learning tool, but not something I would use for our own production code. For the CAN and RS 232 communication ports, it is necessary to use interrupts to get the required response time. What we do here in our DSP56F807 products, and it works perfectly in all of our applications, is this: 1) If it is NOT critical to have a very short execution time for the interrupt, we use the SDK Interrupt Dispatcher with a "Normal" interrupt. The SDK Interrupt Dispatcher saves and restores ALL registers for "Normal" interrupts. We use "Normal" interrupts for the CAN communication port ISRs. 2) If it IS critical to have a very short execution time for the interrupt, we use a "Super Fast" interrupt, which we always write in assembler. The interrupt vector points directly to your ISR function, so the SDK Interrupt Dispatcher is completely bypassed. You must also save and restore all registers explicitly in your code. We use "Super Fast" interrupts for all of the other serial communication port ISRs (SCI0 and SCI1). 3) I would NOT recommend using a "Fast" interrupt, as it does not save/restore all registers. The on-line documentation for the SDK Interrupt Dispatcher is really quite excellent, basically I just read it, tried it, and everything worked the first time. You can start the SDK on-line documentation as follows: Start Programs Motorola Embedded SDK 2.5 Help and Documentation In "Contents", go to: Motorola Embedded SDK Core Documentation SDK Programmer's Guide 7 Interrupts Section 7.2.1 explains the differences between the 3 types of ISRs. Section 7.2.6 describes the SDK Interrupt Dispatcher. Section 7.2.8.3 describes using "#pragma interrupt" with the SDK Interrupt Dispatcher. Also look at Section 7.5.1 "Using Pragma Interrupt". I hope this information is helpful to you, please let me know if you have any more questions. 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: LuisST [mailto:] Sent: Wednesday, February 26, 2003 8:36 AM To: Subject: [motoroladsp] SDK more overhead? Is there a loss in time response /generated machine code efficiency or otherwise using the Motorla SDK for programming 56807 DSPs versus "raw" programming? Specially usning CAN and RS 232? Luis Villa Product Manager Soluciones Tecnolicas, S.A. ph +52 (333) 615-3214 fax +52 (333) 615-1856 _____________________________________ 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 |
Reply by ●February 26, 20032003-02-26
|
Luis, You're welcome, I'm always glad to help. One thing we do use here (and which I very strongly recommend) is a RealTime Operating System (RTOS). This allows you to split up your software into completely independent "tasks", so it is very easy to make sure that there is no possibility of interaction between the different tasks in your program. On the subject of good RTOSs, our company has had extremely good success with DSPOS for the Motorola DSP56800 family. I personally have had almost 2 years experience with DSPOS for the 56800 family, and it has proven itself to have rock-solid stability and reliability. The very few problems we did have initially were resolved immediately, within days or sometimes even hours of when I reported the problem. I would give DSPOS my very highest recommendation for anyone looking for a high-quality yet reasonably-priced RTOS. It has been my experience that using an RTOS saves a tremendous amount of development time, compared to developing your own scheduling algorithm. Unless your project is very small, you will recover your investment in DSPOS in the very first project where it is used. DSPOS also addresses the needs of the embedded developer very well, as its task-switching and other functions have very fast execution times. Its ROM/RAM footprints (especially the RAM footprint for the DSP56800 family) are very small, which is highly important for the 56800 family, as the internal Data RAM size varies from 1K words (801 chip) to 4K words (807 chip). To put some perspective on my opinions, I have 31+ years hardware design experience, and over 26 years software development experience. Honestly, I would rate both the DSPOS RTOS, and the technical support I have received, as being among the top 2 or 3 software products I have ever seen. You can see the DSPOS website at: <http://www.dspos.com> Regards, Art -----Original Message----- From: LuisST [mailto:] Sent: Wednesday, February 26, 2003 9:17 AM To: Art Johnson; LuisST; Subject: RE: [motoroladsp] SDK more overhead? Art, Thanks, this was very useful. I am moving from programming cards such as NI DAQ cards to programming DSPs and the learning curve has been a bit steep for me. Luis Villa -----Original Message----- From: [mailto:] Sent: Wednesday, February 26, 2003 11:13 AM To: LuisST; Subject: RE: [motoroladsp] SDK more overhead? The SDK device drivers will use a larger amount of code, and will be significantly slower, compared to doing "raw" programming. The only parts of the SDK we use here are the startup code and the Interrupt Dispatcher. We don't use any of the SDK device drivers, we wrote all of our own drivers for the on-chip peripherals. This way we get exactly what we need, without the overhead of something that is designed to handle all possible options. This is not to criticize the SDK code, I look at it as an excellent learning tool, but not something I would use for our own production code. For the CAN and RS 232 communication ports, it is necessary to use interrupts to get the required response time. What we do here in our DSP56F807 products, and it works perfectly in all of our applications, is this: 1) If it is NOT critical to have a very short execution time for the interrupt, we use the SDK Interrupt Dispatcher with a "Normal" interrupt. The SDK Interrupt Dispatcher saves and restores ALL registers for "Normal" interrupts. We use "Normal" interrupts for the CAN communication port ISRs. 2) If it IS critical to have a very short execution time for the interrupt, we use a "Super Fast" interrupt, which we always write in assembler. The interrupt vector points directly to your ISR function, so the SDK Interrupt Dispatcher is completely bypassed. You must also save and restore all registers explicitly in your code. We use "Super Fast" interrupts for all of the other serial communication port ISRs (SCI0 and SCI1). 3) I would NOT recommend using a "Fast" interrupt, as it does not save/restore all registers. The on-line documentation for the SDK Interrupt Dispatcher is really quite excellent, basically I just read it, tried it, and everything worked the first time. You can start the SDK on-line documentation as follows: Start Programs Motorola Embedded SDK 2.5 Help and Documentation In "Contents", go to: Motorola Embedded SDK Core Documentation SDK Programmer's Guide 7 Interrupts Section 7.2.1 explains the differences between the 3 types of ISRs. Section 7.2.6 describes the SDK Interrupt Dispatcher. Section 7.2.8.3 describes using "#pragma interrupt" with the SDK Interrupt Dispatcher. Also look at Section 7.5.1 "Using Pragma Interrupt". I hope this information is helpful to you, please let me know if you have any more questions. 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: LuisST [mailto:] Sent: Wednesday, February 26, 2003 8:36 AM To: Subject: [motoroladsp] SDK more overhead? Is there a loss in time response /generated machine code efficiency or otherwise using the Motorla SDK for programming 56807 DSPs versus "raw" programming? Specially usning CAN and RS 232? Luis Villa Product Manager Soluciones Tecnolicas, S.A. ph +52 (333) 615-3214 fax +52 (333) 615-1856 _____________________________________ 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 |
Reply by ●February 27, 20032003-02-27
|
Luis - The SDK can be used at many different levels. The highest level uses high level interfaces that provide a great deal of flexibility and services but do have more overhead assocaited with them. But their are other levels to use it at that do not have significant overhead. Item such as the signal processing library are all optimized assembly code. Other items such as the Architecture services and bit manipulation services are for the most part optimized macros and do not have significant overhead. The same is tru for much of the memory management services. So their are many portions that can be helpful without adding significant code bloat. Also in many of the dirver functions are implemeted with macros which are executed without significant overhead. You might want to consider taking an approach of prototyping your system and using the components of the SDK you feel are appropriate. Then optimizing or removing elements that you find to have unaccpetable performance charateristics. We disucss this approach in an online guide you can find at http://e-www.motorola.com/collateral/SDK_UM.htm <http://e-www.motorola.com/collateral/SDK_UM.htm> . Also we have some good material on our training CD that can aid in speeding your development. This acn be ordered at http://e-www.motorola.com/collateral/56800_56800E_TRAINING_CD.htm <http://e-www.motorola.com/collateral/56800_56800E_TRAINING_CD.htm> . Finally I would reccomend that you can use the much of the driver code as examples to enable you to develop your own drivers if you determine that this is the most appropriate for you. Much of the underlying code I beleive is well written and works effectively, but has more features than you might find neccessary. Also remeber that you c! an! customize the drivers for your own particular application by doing things like replacing the ISR routines associated with the drivers. This is supported through the config file. Thannks. - Bill -----Original Message----- From: LuisST [mailto:] Sent: Wednesday, February 26, 2003 10:17 AM To: ; LuisST; Subject: RE: [motoroladsp] SDK more overhead? Art, Thanks, this was very useful. I am moving from programming cards such as NI DAQ cards to programming DSPs and the learning curve has been a bit steep for me. Luis Villa -----Original Message----- From: [mailto:] Sent: Wednesday, February 26, 2003 11:13 AM To: LuisST; Subject: RE: [motoroladsp] SDK more overhead? The SDK device drivers will use a larger amount of code, and will be significantly slower, compared to doing "raw" programming. The only parts of the SDK we use here are the startup code and the Interrupt Dispatcher. We don't use any of the SDK device drivers, we wrote all of our own drivers for the on-chip peripherals. This way we get exactly what we need, without the overhead of something that is designed to handle all possible options. This is not to criticize the SDK code, I look at it as an excellent learning tool, but not something I would use for our own production code. For the CAN and RS 232 communication ports, it is necessary to use interrupts to get the required response time. What we do here in our DSP56F807 products, and it works perfectly in all of our applications, is this: 1) If it is NOT critical to have a very short execution time for the interrupt, we use the SDK Interrupt Dispatcher with a "Normal" interrupt. The SDK Interrupt Dispatcher saves and restores ALL registers for "Normal" interrupts. We use "Normal" interrupts for the CAN communication port ISRs. 2) If it IS critical to have a very short execution time for the interrupt, we use a "Super Fast" interrupt, which we always write in assembler. The interrupt vector points directly to your ISR function, so the SDK Interrupt Dispatcher is completely bypassed. You must also save and restore all registers explicitly in your code. We use "Super Fast" interrupts for all of the other serial communication port ISRs (SCI0 and SCI1). 3) I would NOT recommend using a "Fast" interrupt, as it does not save/restore all registers. The on-line documentation for the SDK Interrupt Dispatcher is really quite excellent, basically I just read it, tried it, and everything worked the first time. You can start the SDK on-line documentation as follows: Start Programs Motorola Embedded SDK 2.5 Help and Documentation In "Contents", go to: Motorola Embedded SDK Core Documentation SDK Programmer's Guide 7 Interrupts Section 7.2.1 explains the differences between the 3 types of ISRs. Section 7.2.6 describes the SDK Interrupt Dispatcher. Section 7.2.8.3 describes using "#pragma interrupt" with the SDK Interrupt Dispatcher. Also look at Section 7.5.1 "Using Pragma Interrupt". I hope this information is helpful to you, please let me know if you have any more questions. 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 <http://www.pmc-controls.com -----Original Message----- From: LuisST [mailto:] Sent: Wednesday, February 26, 2003 8:36 AM To: Subject: [motoroladsp] SDK more overhead? Is there a loss in time response /generated machine code efficiency or otherwise using the Motorla SDK for programming 56807 DSPs versus "raw" programming? Specially usning CAN and RS 232? Luis Villa Product Manager Soluciones Tecnolicas, S.A. ph +52 (333) 615-3214 fax +52 (333) 615-1856 _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> . |
Reply by ●February 28, 20032003-02-28
|
--- In , "LuisST" <Luisst@c...> wrote: > Is there a loss in time response /generated machine code efficiency or > otherwise using the Motorla SDK for programming 56807 DSPs versus "raw" > programming? Specially usning CAN and RS 232? Exercise 3D provides some helpful hints on how to write custom drivers from within C (as C code or inline assembly) and assembly. You will find it at http://e-www.motorola.com/collateral/56800_EXERCISE_3D.zip > Luis Villa > Product Manager > Soluciones Tecnolicas, S.A. > lvilla@V... > ph +52 (333) 615-3214 > fax +52 (333) 615-1856 |
