Jerry is absolutely correct, you are free to use as much or as little of the
SDK
as you want. And yes, you still have this ability with CW 5.02 and SDK 2.5,
we
have been using them since August 22 and have had no problems in this regard.
Basically, the SDK is structured so that it is very simple (in the file
"appconfig.h") to choose which SDK features you want to include in
your
software.
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: Johnson, Jerry [mailto:]
Sent: Wednesday, October 09, 2002 9:55 AM
To: 'Corey, Rick'; '
Subject: RE: [motoroladsp] RE: Interrupt/context problem?
I only feel as though I should comment on one point in your message, which is
the avoidance of the SDK to allow you to "not" use the MSCAN premium
code,
rather do your own thing with regard to CAN programming.
As far as I know, and I have been doing it with SDK 2.4 and Codewarrior 4.1,
is
that you can easily not include MSCAN support, write your own CAN code, and
still use all of the rest of the SDK.
Since I am starting the switch to CW 5.02 with SDK2.5, I am expecting to
still
do my own thing regarding CAN bus operation.
I hope my expectations are still valid, and my existing code will still
work???
Jerry.
-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Tuesday, October 08, 2002 5:26 PM
To: '
Subject: RE: [motoroladsp] RE: Interrupt/context problem?
warning: long post
If you have IRQ madness when using "#pragma interrupt" without the
SDK, go
to "mixed mode" or "disassemble" and look at your ISR
postambles - I have
often seen an RTS instead of an RTI at the end of my ISRs. Yes, push the
status register and never pop it.
I am _not_ using the SDK, just plain vanilla 56803 EABI stationary. I
have to avoid the MSCAN SDK and just use the Metrowerks compiler
"#pragma
interrupt saveall warn" for MSCAN Rx and Tx IRQs (to start with).
I'm not a complete novice at interrupt programming, but I am very new to
Code Warrior and Motorola chips. Take what I say with a grain of salt
unless you reproduce my observations.
If I go to P: memory after downloading to RAM, and manually patch the RTS
opcode to an RTI opcode ($EDD8 to EDD9, I think), I eliminate the stack
corruption and can run IRQs using just the C compiler.
This would seem to be a 5.0.2 compiler bug (in my relatively humble opinion
and that of one FAE to whom I showed the behavior in person).
I've reported it to Metrowerks and they say they are looking for it but
have
never had it reported before. I guess most people use the SDK.
I can sometimes make the behavior toggle by commenting or uncommenting a few
lines of code this innocuous:
int dummyFunction( int iParam )
{
return(0); // I never call this dummy function, but
eliminating code until "it works"
} // revealed "impossible" compiler behavior
The Motorola web site tech support ("Digital DNA") has been helpful,
due to
Daniel Malik. He felt my mcp might be corrupt since he could make the
(intermittent) behavior go away forever with a new project.
I've dragged my code into a half-dozen new projects, but if I turn on my
usual compiler options, I can 'break' the pragma behavior. (Thanks
in
advance for the suggestion: "Then don't _do_ that.")
I'm currently testing the possibility that some unidentified compiler
options make my project 'ISR-RTS-prone" and his not. Daniel Malik
uses
straight "new project defaults".
I used to enable most warnings as errors, and this and that. I followed
some manual which cautioned me to disable bool support and wchar-t support
and any C++ feature since they were not supported for the '803. I
strongly
want to use "extended error checking" and "implicit arithmetic
conversions"
and a few others like deferred inlining and auto-inlining.
Another possibility (in my very tentative opinion) is that some interaction
with "#pragma called" might matter. I've been stable since I went
to all
"new project defaults" and only using inline functions from an ISR,
never
"#pragma called" functions.
I'm not going for ultimate speed, just trying to avoid the constraints
of
the SDK MSCAN driver. Sure, seeing an RTS at the end of your (non-SDK) ISRs
is hard to believe, but I have seen it repeatedly though intermittently.
Art's code and suggestions (including the app note AN2283/D) have been
invaluable. Thank you, Art! I would not have poked the CANRFLG register
during SoftReset, or written 0 to the CANTCR during SoftReset, or ever
written 0 to the CANTFLG register at all. I tried it your way and my code
started working. I bet you hear that a lot.
I would follow Art's suggestion to use either the SDK or ASM, except that
I
would find ASM very difficult beyond a few lines, and just can't use the
$3,000 SDK MSCAN application / driver. (I have to change CAN ID's with
almost every packet, or else change our design from head to foot.)
For now, I'm turning on just a few compiler options at a time, and
debugging
for a full day each way, to see if the RTIs stay where they belong.
Metrowerks has not told me whether they can reproduce my behavior or not,
from my project. I will repost soonest if I find how to re-create this
oddity with something specific.
Thanks for the chance to post.
Rick Corey
P.S. If you see "madness" on an eval board, not all eval boards have
recent
silicon. We got one "Proto-A" chip, and some 0111 and 0115 date
codes.
Check the web site archives for silicon errata. Beware using a SPI
peripheral as a Slave on early silicon. Maybe "everyone" knows that
already.
_____________________________________
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
_____________________________________
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
|