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.
I never really worked with uv2 (I started with uv3) so I don't know if it worked in the past, but what you describe is indeed the grim reality.
This is the way it has always worked in UV2 & UV3.
:-(
What you need to is to clear the 'Include in build' option for the "unwanted" file in each target.
So both files appear under both targets, but only one is actually built in each target.
What you need to is to clear the 'Include in build' option for the "unwanted" file in each target.<i/>
well yes, but the indication whether a file is to be compiled with the selected target is almost the same as the indication if any other setting (except the presence of a vertical arrow) deviates from the project defaults. this in conjunction with the fact that all files are display can create confusion.
You are right,
thanks Andy.
Marco.
"the indication whether a file is to be compiled with the selected target is almost the same as the indication if any other setting (except the presence of a vertical arrow) deviates from the project defaults"
No - it is the little arrow that indicates whether the file is to be built or not!
See: http://www.keil.com/support/man/docs/uv4/uv4_ca_filegrp_att.htm
The text is a bit misleading where it says "excluded from the linkage" - it does include "not translated"
OK, bad choice of word. I meant that exactly.
Keil's implementation of the project organization and different targets is, in my opinion, just stupid. I am extremely annoyed that they can't be bothered to make this right, as it should be a simple fix.
I've posted about a similar problem before:
http://www.keil.com/forum/docs/thread15532.asp
..but Keil developers doesn't seem to recognize this blatant design flaw.
Regards -Øyvind
It's probably called critical mass. They have a lot of customers, with project files designed according to their original - and rather broken - design. They may tweak the file format slightly, but the project files continues to have a similar approach.
Switching to a project configuration that works well for other IDE, they will have to make a file format conversion that makes it very hard to auto-migrate customer files to the newer format. Most probably Keil has decided that it is better to get a constant amount of low-volume complaints than to really fix the problem but risk a large part of their customer stock to get really annoyed because of project file breakage when upgrading.
I guess you are right, but in that case I really don't understand why they bothered to change their file format for uv4.
I've been thinking about converting to a make-based system (which would be way better when having multiple hardware targets using a mix of sources), but that makes using the debugger a hassle, since it requires me to have a project file, which more or less defeats the purpose.
Creating an application that can generate uv4 project files from make would solve that, but it really feels like crossing the river to fetch a pail of water...
Regards -Oyvind
I agree!
Another fundamental flaw is that there is no way to manage options that are common to multiple targets!
"Keil developers doesn't seem to recognize this blatant design flaw"
I must admit that I haven't looked in detail at whether UV4 is any better in this respect...
"They have a lot of customers, with project files designed according to their original - and rather broken - design"
And yet they have removed the UV3 documentation from the website!
The old CARM documentation is still there - marked "discontineud" - so why can't they do the same for UV3?
The only conclusion, surely, is that they really don't care about this large numbe of customers who need to maintain existing UV3 projects!
"Switching to a project configuration that works well for other IDE, they will have to make a file format conversion that makes it very hard to auto-migrate customer files to the newer format."
But that's exactly what they have done - UV4 does convert UV3 project files to its new format!
"
"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.