Why must Studio create a new folder when I create a new project?
Visual Studio doesn't insist on creating a new folder.
If I have an existing folder that I want to use, can I rename it, allow Studio to create a new one, and then copy the contents of the old folder to tne new one?
.
I don't have an answer but have a similar question or perhaps it's the same.
Trying to create a new project that's a variation on an existing one. I create a new folder, copy source files of interest to it and modify them as needed. Next I want to make a new project of this folder & file collection.
Going through the "new project" wizard, I'm sure to uncheck the "create new folder option" and to point to my folder. The result is that it creates a new folder anyway beneath the one I pointed to, plus a new source file that I didn't need, named the same as the project.
I guess there are back door ways around this, but is there a direct way?
Thanks,
Nick
Yes. I can understand having a separate solution/project/release and solution/project/debug directory for the object files (and any other build results)
I would expect an associated solution/project/src directory too. However you may prefer the source files to live directly in solution/project directory.
Personally, I prefer the sources to live far away.
I presume the reason for this geography is to ease the bulk copy of an ASF project from the internet.
As far as I can see, you start a Solution and then add Projects to it. The wizard creates a dummy project/main.c that you immediately delete. Then add all your real source files as 'Links'.
David.
Well, that didn't work. I let Studio 6 create the new folder and new source file. Then moved my real source files into the folder and deleted the superfluous one. The next step was to be to use "ASF Explorer" to add the necessary files to the project. Unfortunately, no directory is shown and all options are "grayed out". The explorer window is visible but none of the typical options for adding files are available.
I would choose the 'nearest' ASF example and let AS6 create the new project.
Then you use "Add Files" to browse for your existing source code. Either Copy or Link depending on the extent of your death wish.
I don't think that ASF is designed to be a global resource like ARM Stellaris or STM32 Peripheral Libraries.
David.
I'm not sure what the ASF examples are. Maybe that's part of my problem(?).
I did finally get Studio 6 to accept my files. I closed the non-functional Solution Explorer and then opened it again and it started working normally. I did have to accept the blank .c file Studio 6 created. I just deleted all of the template source code it had created and pasted in my actual source code. Now it's more or less happy.
A new anomaly I have a question about - I had Studio 6 build the project, which it did, but it put the .hex file in a "debug" folder instead of the "default" folder such as it had created in the past. (It didn't create one for this project.) Should I be concerned about this? I tried creating the default folder myself and doing the build again, but it didn't take the bait.
Nick
A new anomaly I have a question about - I had Studio 6 build the project, which it did, but it put the .hex file in a "debug" folder instead of the "default" folder such as it had created in the past. (It didn't create one for this project.) Should I be concerned about this?
It never really made sense in AS4 to have the output in something called /default/ anyway so at least this is a step towards something more sensible.
Typically in PC projects with VS2010 you have things like stack checking, assert() and so on enabled in the Debug build but not included in the Release build. It also makes one .exe you build about 3-4 times the size of the other. The situation is not quite the same for AVR but you might still have assert() in Debug and not in Release.
One thing that does happen in VS2010 when you build Debug or Release is that there are pre-processor symbols _DEBUG and NDEBUG defined (respectively). Rather sadly AS6 does not seem to offer these by default so it's up to you to define them. If you read the GCC manual for assert.h:
http://www.nongnu.org/avr-libc/u...
it even says:
The assert() macro may be removed at compile time by defining NDEBUG as a macro (e.g., by using the compiler option -DNDEBUG).
You could produce debug and release folders in AS4 if you wanted. The 'default' configuration is called default and is basically a release configuration with debug info. Select "Edit Configurations" in your Project -> Edit Configuration Options to use a different Active Configuration.
Likewise, in AS6 you could create a 'default' configuration and the build files go to that directory.
You find 'Example ASF projects' from the AS6->New tab.
David.
Yeah the Debug folder is standard with Visual Studio (unless you change to Release). I like that actually. I don't want the compiler output to be dumped into the folder with the source. However I consider the .atsln and .proj to be part of the source. I want them to be put into the archive along with the source.
I can live with the separate folder for the .sln, but I'd rather not. I sometimes get the .sln in a separate folder with Visual Studio but that's my mistake. When I do it right, it goes in with the source.
If you fail to uncheck the "create new folder for the solution" box. You get two additional folders. One for the .sln and another for the .proj. That's really aggravating.
And yeah it is annoying that Atmel Studio creates a .cpp file with main() in it, when creating a new project, but that is easy to delete.
I didn't get an answer to my question so I guess I will try and see what happens. If I have a folder called ABC with source in it, I will rename it to ABCD. Then I will back up one level and have Studio create ABC with the .sln stuff in it. Then I will move the source from ABCD to ABC, add the files to the project, and see if it builds okay.
I can live with the separate folder for the .sln, but I'd rather not.
But in the general case, a solution can consist of several projects all in their own sub-folders w.r.t. the solution folder.
Cliff! My comment was only to explain the mechanism, and why it looks like it looks.
Re if this is good or not, it was not my intention in the above post to express any opinion.
But yes: In many cases this is at a complexity level not needed for straight forward small projects. Then again, there are the bigger stuff where you have a substantial amount of code that has enough cohesion of its own to warrant it to be a project in it's own right, and yet it is not enough to form a complete application.
Since I am currently looking at the lwMesh that Alex announced last week, that would be the obvious example for me right now. A complete app would be lwMesh and the app code proper. I would not want to have copies of lwMesh all over the place if I do several apps. So I'd like a way to organize a "super-project" that encompasses a "standard" project (lwMesh) and the specific app project. This is what the solution does.- (I know you know Cliff, but just in order to get everyone on the same wave-length here..) There could be other ways to accomplish this - e.g. building lwMesh as a library but then one would be in a situation similar to the one avrlibc is in (lwMesh depends on board defines etc, so there would have to be one library built for each board etc).
Yes, I am quite used to the solution/workspace metaphor from PC software projects, so it might be that this is why I see no big complication with "solutions" in AS6.
Actually, I'm in the process of looking into updating the ASF project templates to enable asserts in ASF when debug mode is specified. Currently ther require an __ENABLE_ASSERTS__ (IIRC) macro to be defined, which needs to be put into the debug template.
ASF doesn't use assert() but rather our own Assert() solution - this prevents the entire C library on UC3 and ARM products from being pulled into the binary if an assert is added, and allows us to redirect the output as needed (for example, some boards we redirect this over the virtual USB COM port). It's also redirected when we run build tests on real hardware on our unit test server.
For end-users, one advantage for debug/release is of course the ability to disable test code, but the other is compilation speed; with Release mode set, debug information is not placed into the output ELF files, which can greatly speed up compilation at the expense of being able to debug at the source level.
- Dean :twisted:
Do you have figures for exactly how much additional compilation time is involved in meddling DWARF2 then?
Part of the raison d'être for Debug/Release in the PC world is the code bloat for the debug support in the final binary but for AVR the final binaries are virtually identical, the debug stuff is left behind in the .elf.
I did have to accept the blank .c file Studio 6 created. I just deleted all of the template source code it had created and pasted in my actual source code. Nick
Studio 6 created a Blink_2_LED.cpp file in the attached project, but I removed it from the project. The file still existed though. I subsequently deleted the file from the folder. The project still builds.
.
Do you have figures for exactly how much additional compilation time is involved in meddling DWARF2 then?Part of the raison d'être for Debug/Release in the PC world is the code bloat for the debug support in the final binary but for AVR the final binaries are virtually identical, the debug stuff is left behind in the .elf.
The final binary (as loaded into the chip) will be identical between the two, baring any additional code you enable in the debug profile. The ELF file will be somewhat-to-much larger in debug mode, depending on your debug settings.
For AVR8/XMEGA, the compilation speed between -g0 (no debugging information) and -g2 (medium debugging information) isn't all that much. Moving to -g2 (maximum debug information) isn't all that useful yet since Studio ignores most of the additional information, but will slow down compilation a tiny bit (~10%-ish).
For UC3 it's a different story; the majority of the time for me is spent generating the debug information on -g3. Using the Widget Toolkit ASF examples, the different can be a minute with, and 20 seconds without debug information for a full rebuild.
- Dean :twisted:
For UC3 it's a different story
There's still a damned good reason to have both profiles - so you can conditionally turn on and off your own debug code within your application (test menu access, consoles, serial traces, etc.) which is applicable for all architectures. The slowness when generating the ELF debug data (different from the user application debug code) is architecture specific yes, but irrelevant for the feature's intended purpose.
- Dean :twisted:
There's still a damned good reason to have both profiles - so you can conditionally turn on and off your own debug code within your application (test menu access, consoles, serial traces, etc.)
#ifdef _DEBUG show_test_console(); #endif
but Atmel appear to have forgotten to make these vital default defines for the "Debug"/"Release" selections so how can the source know it is being built for one or the other?
If it's up to the user to add the -D's then what's the advantage of the two pre-made build variants? The user might as well just manually either -D_DEBUG or not when they want to switch.
Selecting one of the configurations in a drop-down is easier than going into the project props.
And the -DDDEBUG is a trivial minimal example. What if you'd like to have finer granularity and thus several defines that you'd like to switch on/off?
Now, for those who does actually does not need the functionality - how much of a nuisance is this really?
Now, for those who does actually does not need the functionality - how much of a nuisance is this really?
Somewhere between "bugger all" and "exactly zero". You can just leave the profile to "Debug" and never touch it to no detrimental effect.
but Atmel appear to have forgotten to make these vital default defines for the "Debug"/"Release" selections so how can the source know it is being built for one or the other?
You can add them to the debug profile. Right now we don't automatically define anything (I'm not sure if this is a conscious decision to avoid forcing you to use our convention, or if it's an oversight) but once you add your define to the Debug and/or Release profile, you can switch back and forth with the dropdown.
Another example for it: you could have one codebase that can build several versions of your product's firmware, and have different profiles for each.
- Dean :twisted:
(I'm not sure if this is a conscious decision to avoid forcing you to use our convention, or if it's an oversight)
I've added enhancement request AVRSV-3917 for this, asking that -DDEBUG be added to the default Debug profile properties.
- Dean :twisted:
Can you add "-DNDEBUG" for the "Release" one too. VS developers (well me) expect to be able to use either. What's more as noted yesterday:
http://www.nongnu.org/avr-libc/u...
says it is sensitive to "NDEBUG" not "_DEBUG" ;-)
If we are talking enhancements here, how about this one.
There should be somewhere in the project where you can specify the code goes into bootloader memory. You shouldn't have to specify the ".text=0xxxxxx". Studio knows what chip it is programming so should know where the bootloader starts.
This would make it easier and less error prone to configure a bootloader for a particular chip. Currently it is arguably easier to build a bootloader with a makefile, because instructions can be put there telling the user what needs to be done and where to find the information.
Studio knows what chip it is programming so should know where the bootloader starts.
Isn't that dependent on the device fuses?
- Dean :twisted:
Isn't that dependent on the device fuses?
That dialog in AS4 knows I'm using a mega16 and it knows the four BOOTSZ options. Presumably As6 (like CodeVision for example) could have a compiler option box that you ticked to say "building a bootloader" and a drop list with the four BOOTSZ options like this in AS4. Not only could it pass the necessary -Ttext when building but could let the simulator and other debuggers know that the reset address was ox1F00 or whatever rather than 0x0000.
I noticed in AS6 the other day that when I repositioned code with a -Ttext and later forgot and started to simulate that instead of it showing C it simply said "no source for this" and showed me a disassembly listing at 0x0000.
Quote:
Studio knows what chip it is programming so should know where the bootloader starts.
Isn't that dependent on the device fuses?
- Dean :twisted:
#define BOOT_SECTION_START (0x20000)
I should have added that when using Studio, not a makefile, I need to divide the number by 2 that is given in the iox....h file.
I've added enhancement request AVRSV-3917 for this, asking that -DDEBUG be added to the default Debug profile properties.- Dean :twisted:
This is now fixed in an internal build and will be available in a future release.
- Dean :twisted:
