Problem with multiple targets in CW 6.0

[tombo]

Hi! I'm trying to set up my CW project to have 2 targets for the EL32 processor.

1 target will be for the initila development hardware (EL32 demo board and off board hardware) and the other target will be for the production hardware. The main differences are the ports used to drive the external hardware.

If I try and create a new target with CW 6.0, the selection is greyed out but it can be selected in the previous version (4.6 ??). Is this a bug or is something else interfering?

Is the workaround to develop in the previous version??

Thanks,

Tom

[mke_et]

While it works, I'm wondering if that's really how you want to do things.

I had a project where the first pass was just that, first pass. We learned a few things, and then ran a second pass of 50 boards for production.

One of things we learned was double-check your layout. The first prototypes were concepts. When we went to production, the layout guy 'assumed' we made a mistake, and renumbered LEDs that were important status indicators. Since the cases were already made and labeled, we were in trouble.

The easy solution was to create a board revision file that described port usage. That way the prototypes could still be used for testing and development even with bit and port changes made to the code. There is a variable I named BdRev and I originally used that to just change bit definitions on one port.

Then after the 50 boards, the design was enhanced. The next 100 boards changed again, moving some bits between ports, swapping some ports, and even adding new capability not in the original design. (The ports were swapped to be able to take advantage of port interrupts for a new feature.) Now my BdRev variable was enhanced to select more than just a bit to turn on and off. It now was used to select which procedures to build, and even which source files to selectively include at build time.

By changing the data in the board revision file, even the latest code updates could be created for and operate correctly on the original prototype. Up to a point, of course. If the new features aren't there, they just aren't there.

It does mean keeping 'clean' on your code, and making sure every routine uses the definitions and parameters you set up in your board definition file. It may also mean that in a few cases you have to write different routines that select which source to assemble/compile in a few cases. In my case, I even wrote the 'enhanced' code for the new features all in one 'include tree' so that the include for the source file was inside a conditional.

I don't think I would use the 'target' for things like a port definition change.

[tombo]

Interesting ... actually I think I'm approaching it from a similar point of view.

I have a HWDefs.h file where I define my I/O for the different hardware and use #ifdef / #endif in the code and headers to conditionally compile. In the different targets, I use -DStandard=1 or -DProduction=1 to do the conditional compile.

I can then use my (trusted, working) prototype h/w to develop and when the hardware designer gives me new h/w I can test on it but not screw up my working target s/w while still debugging the new h/w.

As you say, I probably will determing that this is a non-sustainable path to be on but for now it seems to work.

Could you show an example of the board rev. file?? That may convince me.

Thanks for the help,

Tom

[mke_et]

OK, I define my BdRev variable in a huge text file that just describes all the hardware changes. Then I have a file called 'ports.inc' that defines what bits and port do whatever. There I do this:

In the code you have to be very careful and have conditional code as well in some cases. For example, a bit may move from one port to another, and there may be interactions with routines that do other things on one of the ports. In cases like that, you may be able to keep from code change with some of the bit set/reset commands, but what if multiple bits moved to multiple places? For example 2 bits that are tied to something. In one case they are on a single port, but in another case they are split between two ports. In that case, you need to have conditional code.

Remember, this is a conditional that changes the BUILD, it is not something that changes program flow in operation. (Although I do that to in some cases. To do that, just put a variable in the code that is set to the bdrev value. Hey, if you have a routine that reports the board rev on command it's gotta know it, right? )

; The location of these functions are moved from port H to port M
; starting with rev 03.

if bdrev < 3
tree3 equ PTH ; Port H for rev 1 and rev 2
tree3ddr equ ddrh
insel equ PTP ; Port P is inbus select pins
inselddr equ ddrp ; Port P is inbus select pins
sel_6 equ $0BF ; Bit 6 for high ETs
endif

if bdrev > 2
tree3 equ PTM ; Port M is the new output register rev 3 and beyond
tree3ddr equ ddrm
insel equ PORTK ; Port K is inbus select pins
inselddr equ ddrk ; Port P is inbus select pins
sel_6 equ $07F ; Bit 7 for high ETs
endif

if bdrev = 1
; This is the original first pass proto board rev 01
LStat equ $01 ; Left Lane Status light
LFault equ $04 ; Left Fault Indicator
RStat equ $08 ; Right Lane Status light
RFault equ $40 ; Right Fault Indicator
endif

if bdrev > 1
; Left and right are reversed on rev 02 and later. Here's the new equates
RStat equ $01 ; Left Lane Status light
RFault equ $04 ; Left Fault Indicator
LStat equ $08 ; Right Lane Status light
LFault equ $40 ; Right Fault Indicator
endif

--
Alban Edit: updated code to be what user wanted.


Message Edited by Alban on 2007-09-17 01:09 PM

[tombo]

Ok, I assume from what you've shown that you work primarily in ASM. (not relevant I know I just thought it interesting that you haven't been forced down the C/C++ path. I use both)

Is the BdRev var set in the 'huge text file' or is it passed on the command line to the assembler? Personally I would prefer the latter but maybe that's my personal predjudice.

I use the second project to set my conditional compile variable (i.e. Standard project declares a command line var Standard=1 and Production project declares a command line var Production=1)

Then in my HWDefs.h
<snip>
/* define LIN_OUT_EN */
#ifdef Standard
/* Freescale demo board */
#define LIN_OUT PTBD_PTBD1
#define LIN_OUT_DDR PTBDD_PTBDD1
#define LIN_OUT_MASK PTBDD_PTBDD1_MASK

#endif

#ifdef Production
/* LINtenna hardware */
#define LIN_OUT PTBD_PTBD4
#define LIN_OUT_DDR PTBDD_PTBDD4
#define LIN_OUT_MASK PTBDD_PTBDD4_MASK

#endif
</snip>

In essence we are doing the same thing. In my case, I build the executables with different names so that I know what version the executable is for. I assume you do something similar (in a makefile perhaps?).

I just like having my CW IDE with the pulldown for the individual projects and clicking on the Debug icon and knowing that it'll build and debug correctly every time. I only have to worry about setting up the conditional compile sections in the code.

I think as well (have to verify), that if they decided to change the Production h/w to a different processor, I could change the Production project (theoretically) using Processor Expert with minimal (??) impact. (Actually, I would probably create a third project and clone the previous)

Thanks for sharing, I always enjoy seeing how others approach a problem and probably down the road I'll come up against a problem that your solution doesn't have and give myself a smack!!!

[alexod]

I have a related issue.

For speed of bring up I used Processor Expert, and it's all gone very well.  The use of "targets" has allowed me to have two builds of the project for differing applications.  One board has a subset of the functionality.

My problem came today when I tried to have a pin take on new meaning in one of the targets.

I have a pin which on one board is part of a serial interface to a latch, on the other board it is a ADC input.  It seems that Processor Expert works on a per project basis, and does not understand the per target.


I'm using CW for MCU's 6.1, Std Edn.  I see bean sharing is allowed in a better version.  Is this what I need?

I known, the answer for now is have two projects and share source code files.  The targets were just working so seamlessly.

Thanks for any ideas...

Alex

[mke_et]

Hmm, the forum software won't let me edit the message...

That first one should be 'less than', but it won't accept the character.

[CrasyCat · Accepted solution]

Hello

CodeWarrior for MCU V6.0 still allows you to define multiple build targets in a project.

In order to be able to create  a new Build target:

  - Open your project in the IDE

  - Switch to the Targets Tab in the .mcp window

  - Click inside of the .mcp window (to make sure it has the focus)

  - The entry Projects -> Create Target should be available now.

Note that the Build Target ComboBox allowing to easily switch to another target is not available in the default configuration of the V6.0 tool chain.

Please look at {Install}\Help\PDF\TN241.pdf Page 13 for information on how to add the combo box to the .mcp window tool bar.

CrasyCat

[tombo]

Whoa!

This morning it's working fine. I tried exactly what you said yesterday and it was no go but now it's good.

I was getting version control going at the same time so, who knows.

Thanks,

Tom