When changing the target MCU, but using the same source code, VM doesn't delete the already compiled library code, to cause a rebuild.

I do this frequently, where the same source code is compiled for
Teensy 3.0
Teensy 3.1
AVR mega32

If I forget to do a clean manually, it dutifully builds a .hex file that is invalid but will download!

VM+VS consistently does not clean and recompile library sources when I change CPU types from the list shown above.

Is it simply that the library source and .o dates match? But changing the MCU type means the .o is invalid.

I can't point the finger of blame at VM versus VS as I don't know the internals.

thanks for working with me on this.
I did enable the show build folders. I did clean on each MCU target and I do see the respective folders get purged. Then as I rebuild for each target, the two MCUs' folders get repopulated with object files. This all looks OK to me.

I have the build config set to build for debug not release. In the debug folder, there is another set of object files with today's date but older times. I see the .hex file there. 
Build-clean does not erase the files in this debug folder.

Here's something maybe noteworthy.
If I hit the F7 key, the objects in the MCU-specific build folder update. Nothing changes in the debug folder.
If I use the rebuild menu option, the files in the debug folder do update. Hitting F5 has the same effect.

Perhaps this means nothing.. since doing a clean and then build does make new object files in the build folder but not the debug folder. But hitting F5 does make new objects in the debug folder.

So I conclude none of this seems to show a problem or cause for the .hex that gets sent to be the  wrong one, which do see happen consistently.

Hi,

You might find that creating new configurations (Debug teensyX, Debug TeensyY) for each board then setting the #defines for the (Configuration) instead of the (Project) might be easier. This way you just need to switch the configuration when you switch board.

Another idea is to edit the teensy boards.txt and add your own entries with your own hardware flavours. Then when you switch board you would not have to set any defines at all and visual micro will cache per flavour.

By the way, where are you setting F_CPU? In the project properties I hope?

Tim@Visual Micro wrote on May 8^th, 2014 at 4:12pm:

I'm setting F_CPU in the project properties. To get to that I have to
1. Get the solution  explorer display up, which I now do routinely. As a newbie way back, it was very difficult to even do this.
2. click on the project. As a newbie back then, the difference between a project and a solution (Microsoft nonsense) was confusing.
3. Hit ALT-ENTER keys, to open the properties. As a newbie, this trick took a lot of time to find. The menus to do this didn't seem tow work correctly.
4. key in the F_CPU and some other standard defines (not mine). 

I now  have a shortcut. When I change to do an AVR build with the same source code, I put an "x" in front of the F_CPU so it is disabled for the AVR build. The AVR build gets F_CPU from somewhere else.


I looked at boards.txt - for AVR and teensy31. For the latter there are lower case f_cpu=nnn entries but I think they apply only to the Arduino IDE windows. 
I don't know what I'd add per your suggestion on adding F_CPU to the boards.txt file.

Thanks
Steve

I no longer need to do the "clean" when switching target board types. If I follow the same procedure each time. There is some situation with mistakes I have to avoid though, such as mistakenly directing the build to download to the wrong board type. But I'm OK if I follow the procedure.

Regarding using different build configs for using the same source code with different targets. Would you mind being a bit more detailed on this? I searched the menus but don't the the concept nor the menu choices/steps so I can move the defines out of the project properties. 

I don't "get it" with this instruction:
Quote:


Thanks
Steve

I'll give it a try.
Can't the F_CPU and so on that are board specific happen automatically for teensy 2 and teensy 3.x boards since all of these are among the choices in the drop-down list to the right of the Arudino version choice?

Yes as I said you earlier can edit the Teensy boards.txt and add your own custom hardware/boards by copying and renaming existing entry.

Or you can just hack the existing teensy3 entry by adding F_CPU to a fixed value ...

If you make changes to boards.txt then click "Tools>Visual Micro>reload Tool chains" or re-start the Ide


Boards.txt Info

The boards.txt format allows for multiple .option[n] entries like this one

teensy3.build.option1=-mthumb
teensy3.build.option2=-nostdlib
teensy3.build.option3=-D__MK20DX128__
 

You can probably just add the F_CPU= to a new option. You need to increment the option[n] (option1,option2,option3) so that it is the next highest of whatever already if defined

teensy3.build.option1=-mthumb
teensy3.build.option2=-nostdlib
teensy3.build.option3=-D__MK20DX128__
teensy3.build.option4=F_CPU=1000000000000000000000L :) 

The boards.txt is under teensyIDE/hardware/Teensy

This is the existing teensy3 entry ...

teensy3.name=Teensy 3.0
teensy3.upload.protocol=halfkay
teensy3.upload.maximum_size=131072
teensy3.upload.maximum_ram_size=16384
teensy3.upload.speed=12000000
teensy3.upload.disable_flushing=true
teensy3.bootloader.path=undefined
teensy3.serial.restart_cmd=true
teensy3.serial.safe_baud_rates_only=true
teensy3.upload.avrdude_wrapper=teensy_reboot
teensy3.build.mcu=mk20dx128
teensy3.build.cpu=cortex-m4
teensy3.build.option1=-mthumb
teensy3.build.option2=-nostdlib
teensy3.build.option3=-D__MK20DX128__
teensy3.build.cppoption1=-fno-rtti
teensy3.build.linkoption1=-mthumb
teensy3.build.additionalobject1=-larm_cortexM4l_math
teensy3.build.linkscript=mk20dx128.ld
teensy3.build.architecture=arm-none-eabi
teensy3.build.command.gcc=arm-none-eabi-gcc
teensy3.build.command.g++=arm-none-eabi-g++
teensy3.build.command.ar=arm-none-eabi-ar
teensy3.build.command.objcopy=arm-none-eabi-objcopy
teensy3.build.command.objdump=arm-none-eabi-objdump
teensy3.build.command.size=arm-none-eabi-size
teensy3.build.core=teensy3
teensy3.build.noarchive=true
teensy3.build.elide_constructors=true
teensy3.build.gnu0x=true
teensy3.build.dependency=true
teensy3.build.time_t=true
#teensy3.build.linker_relaxation=true
teensy3.build.post_compile_script=teensy_post_compile
#teensy3.build.serial_number=true 

This is how to copy and rename an existing entry. Note the additional "option4" and new name+description...

myteensy3_96.name=Teensy 3.0 at 96mhz
myteensy3_96.upload.protocol=halfkay
myteensy3_96.upload.maximum_size=131072
myteensy3_96.upload.maximum_ram_size=16384
myteensy3_96.upload.speed=12000000
myteensy3_96.upload.disable_flushing=true
myteensy3_96.bootloader.path=undefined
myteensy3_96.serial.restart_cmd=true
myteensy3_96.serial.safe_baud_rates_only=true
myteensy3_96.upload.avrdude_wrapper=teensy_reboot
myteensy3_96.build.mcu=mk20dx128
myteensy3_96.build.cpu=cortex-m4
myteensy3_96.build.option1=-mthumb
myteensy3_96.build.option2=-nostdlib
myteensy3_96.build.option3=-D__MK20DX128__
myteensy3_96.build.option4=F_CPU=96000000L
myteensy3_96.build.cppoption1=-fno-rtti
myteensy3_96.build.linkoption1=-mthumb
myteensy3_96.build.additionalobject1=-larm_cortexM4l_math
myteensy3_96.build.linkscript=mk20dx128.ld
myteensy3_96.build.architecture=arm-none-eabi
myteensy3_96.build.command.gcc=arm-none-eabi-gcc
myteensy3_96.build.command.g++=arm-none-eabi-g++
myteensy3_96.build.command.ar=arm-none-eabi-ar
myteensy3_96.build.command.objcopy=arm-none-eabi-objcopy
myteensy3_96.build.command.objdump=arm-none-eabi-objdump
myteensy3_96.build.command.size=arm-none-eabi-size
myteensy3_96.build.core=teensy3
myteensy3_96.build.noarchive=true
myteensy3_96.build.elide_constructors=true
myteensy3_96.build.gnu0x=true
myteensy3_96.build.dependency=true
myteensy3_96.build.time_t=true
#myteensy3_96.build.linker_relaxation=true
myteensy3_96.build.post_compile_script=teensy_post_compile
#myteensy3_96.build.serial_number=true 

NB: THE SPEED MIGHT BE WRONG IN OPTION4, HAS NOT BEEN VALIDATED

Yes sorry that was not clear. An unlimited number of option[n] are supported

So option5 is ok

Success! Using VisualMicro/VisualStudio for both AVR and Teensy 3 targets using same source code for both, a quick change to the boards.txt file allows just changing the target MCU to do a build. No longer do I have to setup a custom project or other special things. Just pick the target and COM port and compile/download. As it should be!

See post #5 at
http://forum.pjrc.com/threads/25757-Q-on-altering-boards-txt

How the boards.txt file is really used in Arduino is a great mystery.