RE: [motoroladsp] general SDK question

Very good observation, I was also surprised by the way the SDK is organized in that regard. I originally used the SDK as a learning tool, and then began re-writing specific areas of code that are time dependant. Right now, all but one of my ISR routines are in assembly language. I still use the SDK framework for the startup, and initialization of data. I have a large portion of C code that uses the periph.h functions directly rather than use the drivers (ioctl). However, for a few functions, (e.g. the quad timers) I still use the file interface for initialization, but have replaced the ISR handlers with my ASM versions. I am convinced that the SDK is a great aid to getting going. However, for all but the simplest application, it is a starting point only. Much of the supplied C code is still used, but not so much of the BSP package, which is geared for portability across platforms.

Jerry.

-----Original Message-----
From: cwolfatwork <c...@yahoo.com> [mailto:c...@yahoo.com]
Sent: Friday, January 24, 2003 12:19 PM
To: m...@yahoogroups.com
Subject: [motoroladsp] general SDK question

I'm new to using SDK/Code Warrior (working with 56852 and 56858);
however, I've done quite a bit of other embedded stuff. I was
initially impressed with the SDK, in that a lot of working (?) code
was provided. However, after trying to do some very simple stuff,
and tracing my way through the code, I'm much less impressed. As an
example, following the lead of the test code provided to blink the
LED's on the 56852 eval board, the function 'ioctl' is used. I
wanted to see exactly what this code did, so I followed the 'code
trail' to finally get to 'periphBitSet' (for LED_ON), in periph.h.
The code 'trail' includes, at least: io.h, leddrvIO.h, leddrv.h,
gpiodrv.h, and periph.h, and results in 3 lines of Assembly language
code that actually do something (read the state of the port, OR in
the desired bit to change, write the new data to the port). Which
brings me to my question: do experienced embedded people use the SDK
code only as examples of how to do (or not do) things, or would
they 'buy into' the SDK framework and tailor their project around
it? To rephrase the question, do you 'roll your own' code, using the
SDK code as a reference, or do you integrate the SDK code into your
project? There are advantages to both approaches. Comments??

Chuck Wolf

_____________________________________
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: m...@yahoogroups.com

To Post: m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3

" TARGET="_blank">http://docs.yahoo.com/info/terms/

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information visit http://www.messagelabs.com
________________________________________________________________________

In our case, we (I) simply used the SDK code as examples of how things could be done. We have developed our own library functions for the low-level drivers and interfaces for the DSP56F80x chips. This way, we get exactly what we need, without having to create any "work-arounds" to do things that were not envisioned or permitted in the code written by others. 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: cwolfatwork <> [mailto:] Sent: Friday, January 24, 2003 10:19 AM To: Subject: [motoroladsp] general SDK question I'm new to using SDK/Code Warrior (working with 56852 and 56858); however, I've done quite a bit of other embedded stuff. I was initially impressed with the SDK, in that a lot of working (?) code was provided. However, after trying to do some very simple stuff, and tracing my way through the code, I'm much less impressed. As an example, following the lead of the test code provided to blink the LED's on the 56852 eval board, the function 'ioctl' is used. I wanted to see exactly what this code did, so I followed the 'code trail' to finally get to 'periphBitSet' (for LED_ON), in periph.h. The code 'trail' includes, at least: io.h, leddrvIO.h, leddrv.h, gpiodrv.h, and periph.h, and results in 3 lines of Assembly language code that actually do something (read the state of the port, OR in the desired bit to change, write the new data to the port). Which brings me to my question: do experienced embedded people use the SDK code only as examples of how to do (or not do) things, or would they 'buy into' the SDK framework and tailor their project around it? To rephrase the question, do you 'roll your own' code, using the SDK code as a reference, or do you integrate the SDK code into your project? There are advantages to both approaches. Comments?? Chuck Wolf _____________________________________ 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/

I'm new to using SDK/Code Warrior (working with 56852 and 56858); however, I've done quite a bit of other embedded stuff. I was initially impressed with the SDK, in that a lot of working (?) code was provided. However, after trying to do some very simple stuff, and tracing my way through the code, I'm much less impressed. As an example, following the lead of the test code provided to blink the LED's on the 56852 eval board, the function 'ioctl' is used. I wanted to see exactly what this code did, so I followed the 'code trail' to finally get to 'periphBitSet' (for LED_ON), in periph.h. The code 'trail' includes, at least: io.h, leddrvIO.h, leddrv.h, gpiodrv.h, and periph.h, and results in 3 lines of Assembly language code that actually do something (read the state of the port, OR in the desired bit to change, write the new data to the port). Which brings me to my question: do experienced embedded people use the SDK code only as examples of how to do (or not do) things, or would they 'buy into' the SDK framework and tailor their project around it? To rephrase the question, do you 'roll your own' code, using the SDK code as a reference, or do you integrate the SDK code into your project? There are advantages to both approaches. Comments?? Chuck Wolf