Why new folder for new project?

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?
.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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?

No this is a new feature of AS6 (inherited from VS 2010). The fact is that by default projects now have two build variants available (and you can add more if you can think why). These are "Debug" and "Release" with Debug selected by default. So if you switch to the Release variant and build that you'll find that your generated files are in ./Release/ instead.

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:

Quote:
The assert() macro may be removed at compile time by defining NDEBUG as a macro (e.g., by using the compiler option -DNDEBUG).

so it is a bit of shame if Atmel aren't doing this when switching between Debug and Release!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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. Thus, the .solution and project files are in separate folders.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But in the general case, a solution can consist of several projects all in their own sub-folders w.r.t. the solution folder.

That's often true in "big" .exe projects in VS2010 where you may develop several libs each as their own "project" all as part of an encompassing solution with one further project that is that actual .exe that links together the libs. But this is a level of complexity above what you normally do with AVRs so I think this Solution=multiple Projects thing in AS6 is just plain confusing for most users of AVR. Generally you have Solution=Single Project so why bother with both Solution and Project levels? I guess they presumably couldn't hide this with the VS2010 heritage involved? (or maybe it does make sense for UC3 and SAM3/4 ?).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nickkennedy wrote:
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
You should be able to remove the file Studio created, or any other file, from the project. Just right click on the file in the Solution Explorer window and click "Remove".

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.

.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

For UC3 it's a different story

Ay, there's the rub! So why are UC3/SAM3 paradigms imposed on AVR8 development?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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.)

Umm yes that would be the case *IF* selecting "Debug" also did a -D_DEBUUG and selecting Release did a -DNDEBUG. Then your code could, indeed do:

#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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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.

Quote:

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(I'm not sure if this is a conscious decision to avoid forcing you to use our convention, or if it's an oversight)

Clearly an oversight - see what VS2010 does by default for "Debug" and "Release" - many people using AS6 will also be familiar with VS 2xxx and may expect it to be operating in a similar way in this area.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've added enhancement request AVRSV-3917 for this, asking that -DDEBUG be added to the default Debug profile properties.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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" ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Isn't that dependent on the device fuses?


Does AS6 have an equivalent of this (picture below)?...

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.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
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:

You are no doubt right. But is that true for Xmegas? For Xmegas, I use this info from the iox....h file and it works.

#define BOOT_SECTION_START     (0x20000)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!