Dear all,
a couple of years ago I remember that I used a feature in UV3 and now this feature does not work anymore in the latest release of uVision.
I defined two targets in the same project: target1 and target2 for two different micros, and it was possible to use different files in the two targets (the asm startup files for instance).
I did that using the "Project Components" dialog window. On current release of UV4 this window is available on the menu Project/Manage/Components ... .
Now I am trying to do the same, but the changes I do to the dialog window fall in every Project Target, so all my targets have the same files.
Does it happen to you also? Is it a removed feature or I am doing something wrong?
I thank you all in advance, Marco.
"But that's exactly what they have done - UV4 does convert UV3 project files to its new format!"
I haven't looked closer at the UV4 format, but you can make big changes to file formats and have 100% automatic conversion, as long as the relationships between different information in the file looks similar between the two formats.
What I dislike about (at least) the UV3 format is that the relationships are not well-suited for supporting different HW revisions or different, but similar, HW platforms.
And having the boot loader code in the same project file means that the bootloader target may have to deactivate hundreds of source files.
Well, don't do that then!
A boot loader's whole reason of existence is that it should not depend on any particular application, so it has no business sharing a project with one.
It can be quite practical to have the boot loader as a target in the same project.
And the boot loader and target may actually have a reason to share a couple of files.
The boot loader may define a number of variables that are stored at an absolute location in memory, allowing communication between boot loader and application.
The boot loader and target may also contain the same source for CRC-32, even if the boot loader has it's own copy of the compiled code for the function.
The thing people should avoid is thinking that the application and boot loader shares the same object files, linked to fixed locations. A tiny change to the compiler or linker or used options could break such a combo badly. And it will also fail when the compiler needs helper functions to perform 32-bit math, or the processor doesn't have a div instruction.
But the important thing here isn't what parts of code or header files that gets shared. The important thing is that I want project files to be self-contained, to make sure that all information stays together a long time into the future.
The concept of having multiple targets in the same project file is very advantageous, since it makes sure that related source code is kept together. Ten years later, you don't suddenly stand there with the application source and notices that you can't build it because it tries to include a couple of files from a different directory - a directory that isn't available on the CD you got, or from the subtree exported from a source code manager many years ago before a company splitted/merged and all the staff went all over the world.
I'm a very strong believer in keeping everything together. The project files for a database application should contain the tools to create a new database, or for upgrading the database schemes between different versions.
A web project should contain everything to be able to recreate any gradient background images used etc.
If this had been PC tools, I would probably have considered the Keil project files as a reason for switching IDE. In this case, I need it for the debugger + simulator, so it isn't practical to just drop the IDE and only keep the compiler/linker.
Yes, but sharing source files by no means implies that they need to live in the same project file.
... and it is the job of header files to carry that information from the boot loader to the application. If all else fails, you can always link the readily built boot loader image into the application.
Ultimately, if your line of reasoning were to hold water, you would have to keep all applications that ever were to use that boot loader in a single project. That's rather clearly ridiculous.
Ten years later, you don't suddenly stand there with the application source and notices that you can't build it because it tries to include a couple of files from a different directory
Now you're mistaking an IDE for a configuration management / source code control system. Using source files in a single project has absolutely no effect on how you manage (or not) to store all the necessary files correctly and keep them together. You can miss a file that is part of the project just as easily as you can miss one that isn't.