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
|