I am trying to troubleshoot a project containing 2 targets which communicate over a CAN bus on Si Labs' C8051F04x CPUs with Keil's uVision3 environment. When running in edit mode, I can always see which target is active by looking at the selection line in the Build toolbar. But when I switch to debug mode, the toolbar disappears and I have found no way to tell which target is active. I have already loaded code into the wrong board once, and worry how well I will be able to keep track of it when I may have to switch among 5 targets. Has anyone figured out a way to tell them apart (other than switching to Edit mode & back again)? Thanks. ============================================================ Gary Lynch | To send mail, change no$pam in lynchg@no$pam.com | my domain name to stacoenergy
How about something like
#if defined( DEBUG ) char signature[]="DEBUG "; #elif defined( RELEASE ) char signature[]="RELEASE"; #else #error "Must be Release or Debug!" #endif
On 2/20/06 16:20:35; A.W. Neil wrote: > > How about something like > #if defined( DEBUG ) > char signature[]="DEBUG "; > #elif defined( RELEASE ) > char signature[]="RELEASE"; > #else > #error "Must be Release or Debug!" > #endif > and keep a Watch set on the signature string? > I hadn't thought of that. I will probabably have to put something in like that in there for production reasons anyway. I'll interpret this to mean there is nothing in uVision 3 to tip me off. > > PS Why do you always put your whole post in "code" mode? > When I started posting (over 10 years ago: on UseNet), all communication was in plain ASCII and there were conventions for most formatting types that I grew quickly comfortable with. In addition I could create tables with aligned columns using the space bar, insert ASCII art, much as I did in block comments in my code; e.g.: > > /* + + + + + + + + + + + + + + + + + + + + + + + + + + + */ > /* Because of the CAN engine's */ > /* auto-increment feature, we 0xD8 0xD9 */ > /* must take care when READING +----------+----------+ */ > /* the 16-bit CAN0DAT_1 | CAN0DATL | CAN0DATH | */ > /* register. It looks like an +----------+----------+ */ > /* SFR16, stored in little \ / */ > /* Endian format; but the Keil \ / */ > /* guarantee to always access \/ */ > /* the low byte last only /\ */ > /* applies to WRITE operations / \ */ > /* to SFR16's. The read order is |/_ _\| */ > /* unpredictable. +----------+----------+ */ > /* | regData | */ > /* Keil's native format for +----------+----------+ */ > /* unsigned int's is big Endian, 0x15 0x16 */ > /* which may make this transfer */ > /* look confusing. */ > /* + + + + + + + + + + + + + + + + + + + + + + + + + + + */ > (I cut & pasted that straight out of a source file.) I now post on several of these web forums, each of which implements a unique subset of something resembling HTML, and I don't want to keep track of which group I am in, or what part of my message needs which markups, so I put the whole thing between those tags, it looks just like ASCII, and works everywhere. Thanks for the insight. ============================================================ Gary Lynch | To send mail, change no$pam in lynchg@no$pam.com | my domain name to stacoenergy
tags, it looks just like ASCII, and works everywhere. Thanks for the insight. ============================================================ Gary Lynch | To send mail, change no$pam in lynchg@no$pam.com | my domain name to stacoenergy