WinAVR and AVRStudio...

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

I'm not sure where to post this so, here it goes anyway.

It's the slow time of year at work and I'm getting to write a lot of test procedures. But those have been completed now, for the most part.

So, it's on to developing some test fixtures to speed up test time. In short, I'm thinking of ways to build a flexible test fixture, where I can simply dump an assembly specific test routine into the host controller board and start testing a given assembly. There will probably be a couple of dedicated host controllers to specific assemblies, as well.

Well, I don't want to carry my ImageCraft ICCAVR USB security key back and forth between home, work, and back home. In that light, I was looking at using WinAVR, as it seems to be a plug-in intended for use in AVR Studio.

So a couple questions, having never used WinAVR.

Other then working within the AVRStudio GUI, what might be any other advantages over my current C compiler, ImageCraft ICCAVR V7.14?

Is WinAVR GCC and GCC++, or is it some other flavor of C compiler. I know that GCC is a popular C compiler, but I haven't really looked into WinAVR, or even CodeVision, for that matter.

Having only ever used the ImageCraft ICCAVR C compiler, I have no idea as to WinAVR's underlying substance.

Any input and/or advice that you might offer is appreciated.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

WinAVR is just a build of the standard GCC toolchain for AVR (often with some of the most up to date patches applied)

As it's GCC it's the most heavily developed compiler engine in the world (which is why a lot of us like using it). It's true that there's a difference between the "front end" (which is standard for all architectures) and the "back end" (which holds the bits specific to AVR). Clearly the former is far more heavily developed and robust than the latter which is why there are AVR specific bugs found from time to time but I don't think it's any better/worse than any other compiler.

There is also a bit of an issue that because of the architecture split there are apects of the compiler that are possibly better targeted to 32 bit Von Neumann architectures than 8 bit Harvard architecture of AVRs which is why the handling of the multiple address spaces (code, SRAM, EEPROM) are a bit more "clunky" than in some of the other AVR specific compilers.

Cliff

PS Welcome to the Darkside of the force! :lol:

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

Thanks Cliff.

I was looking at one of the stickies above and there was a lot of mention of Linux. Is that necessary, or am I good to go with Windows XP. I'm afraid that if I had to learn Linux too, I'd be wasting my employers time. At least with GCC, I think I can manage to get past some of the basics, like the differences in data-type syntax, for instance. I also know that there are a lot of library oddities that I'll have to delve into, like the '_' as in _delay() and _BV() and such. But I think I can manage to get past those things without wasting too much of my employers time and money.

Thanks for the feedback...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

WinAVR is a pre-built AVR toolchain that runs on Windows. No Linux involved, or necessary. (That's what the "Win" part is for. ;) )

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

You mentioned the use of AVR Studio as a GUI; well, I have never used AVR Studio as a GUI for writing or compiling C code.

Just install latest WinAVR package in Windows, fire up your favourite code (and makefile) editor (I use notepad++ or dev-cpp), and keep avr-libc docs (local installed by winavr or online website) and AVR datasheet open when writing code. I compile in command prompt by typing "make", but no unix/linux skills is really necessary.

- Jani

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

Thanks guys!

I'm going to give it a try, here at home first - then maybe I'll be a bit more effective (like I really all that good of a programmer anyway) at work.

Who knows? Maybe you'll convert me. :wink:

Won't John Samperi be upset if that happens!!! :lol:

Oh! Wait a minute... I rarely ever program the AVR in assembly, so why would John even care??? :roll:

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Actually I think there's a lot of merit in starting out using Studio as it hides you from the complexity of Makefiles which is often a barrier to using GCC as you effectively end up learning two languages - both the C/Asm and the Makefile language. You can postpone learning the latter by using the Studio IDE.

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

clawson wrote:
Actually I think there's a lot of merit in starting out using Studio as it hides you from the complexity of Makefiles which is often a barrier to using GCC as you effectively end up learning two languages - both the C/Asm and the Makefile language. You can postpone learning the latter by using the Studio IDE.

That's the reason why I like the ImageCraft C compiler so much. I don't have to know anything about "Make " files, and can just get right to work on the intended goal - getting my project working.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:
Any input and/or advice that you might offer is appreciated.
Get work to buy another ImageCraft C compiler? After all it is for their benefit, just like a soldering iron.
Quote:
I don't have to know anything about "Make " files
Don't need to know, fortunately, just use the "configuration options", just put the processor type (dropdown menu" and the clock frequency. The makefile will be generated by Studio.

So easy even I can use it. :) ...if I were to use C that is...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Bad "dial up day" in Wisconsin it seems ... :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

microcarl wrote:

That's the reason why I like the ImageCraft C compiler so much. I don't have to know anything about "Make " files, and can just get right to work on the intended goal - getting my project working.

Hi Carl,

Another option is to go with the WinVAR tool chain and link with the Eclipse IDE (with the AVR plugin). Eclipse is a java based 'defacto standard' IDE for many development platforms now and the plugin intergrates the options for compiling of multiple AVR chips / speeds / configurations along with the build / compile / upload functions via AVRDude.

http://sourceforge.net/projects/avr-eclipse/

I'm ex-UNIX / gcc / vi type guy - but the Eclipse platform has finally won me over. Also if you ever want to go Linux - the interface for your work will be identical.....

I also understand the the JTAG-Ice debugging etc can now be intergrated to this too - but that is more advance than I need at the moment.

HTH,

Carl

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

But surely if you use Eclipse rather than Studio you are then stuck with a simulator that's even more half baked than the one in Studio?

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

gcc does not require make.
It can be run directly from the command line or a one-line *.bat file.
Absent a dependency-checker, would need to do a
complete rebuild whenever one needed an executable.

Getting the same code to run with more than
one compiler provides some error-checking.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Honestly, I think the whole Makefile issue gets overblown. The Make program can do a lot, but that doesn't mean you have to use every single one of it's obscure features. WinAVR comes with a Makefile Template that has practically everything you need for a regular AVR application. All you have to do is to modify a few variables at the top of the Makefile Template for your application, and this is mostly to put in a list of C files for your application.

If you're not ready to edit this Makefile Template, WinAVR also comes with MFile, which is a very simple graphical Makefile generator. MFile uses the WinAVR Makefile Template as the basis for the Makefile that it generates. With MFile, you can graphically select the various options you want and it plugs it in the Makefile. The nice thing is that you can see how it does it for you.

A long time ago I used NMAKE on DOS systems to build applications. GNU Make is, of course, very similar but more powerful. Make is also more powerful and gives you more benefits than using batch files, or shell scripts. It's purpose is simple and that it describes how to build something, typically software. When I started out learning GNU Make, I went to the GNU Manuals Online (WinAVR has a link to this), and looked at the GNU Make User Manual. It is my opinion that anyone can easily get by with reading the first 5-6 chapters. I'm certainly not a Make expert and I was able to put together the WinAVR Makefile Template, based on earlier makefile fragments from different sources. Since then, other contributors (mostly from Joerg Wunsch) have added various capabilities to the Makefile Template.

I freely admit that there is one stupid thing about using Makefiles and GNU Make, and that is having to use a hardcoded TAB character in place of SPACE to indent the commands for a rule. But others see that that is stupid too and perhaps that will be changed in a future version of Make.

If you can program in assembly or C language, then learning Makefiles is not that difficult. But once you learn it, it can be a powerful tool to have.

Eric

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

Eric,

I think that more than anything the thing that makes people look at a Makefile and think WTF is:

http://sunsite.ualberta.ca/Docum...

Now admittedly that's not in the first 5..6 chapters but it is linked from them and a user reading the manual will almost certainly have to understand $@, $<, etc. to follow many existing rules (inluding many in the Makefile template)

I just think there's a lot folks look at something like:

%.lss: %.elf
	@echo
	@echo $(MSG_EXTENDED_LISTING) $@
	$(OBJDUMP) -h -S $< > $@

and think "totally incomprehesible" then "give me a nice cozy IDE any day"

Cliff

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

clawson wrote:
Eric,

I think that more than anything the thing that makes people look at a Makefile and think WTF is:

http://sunsite.ualberta.ca/Docum...

Now admittedly that's not in the first 5..6 chapters but it is linked from them and a user reading the manual will almost certainly have to understand $@, $<, etc. to follow many existing rules (inluding many in the Makefile template)

I just think there's a lot folks look at something like:

%.lss: %.elf
	@echo
	@echo $(MSG_EXTENDED_LISTING) $@
	$(OBJDUMP) -h -S $< > $@

and think "totally incomprehesible" then "give me a nice cozy IDE any day"


Franly said, if people shit their pants over some symbols they should stay out of the programming business.

The ironic thing is that the same complainers then often advocate XML. The same people who nearly get a heart attack because they have to type a simple, innocent TAB at the begin of each command and freak out because their peanut brains can't associate "<" with "goes in" and ">" with "goes out" then advocate 20 level deep nested XML junk and to model a scripting language in XML, like Java's horrible ant build tool.

HTML "programmers"? Give me a bucket!

Stealing Proteus doesn't make you an engineer.

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

Some folks refuse to use an electric saw favoring instead the venerable cross cut and the healthy workout it gives the user, not to mention saving the planet from global warming. What a bunch of wussies... real mean find flint rock and chip out their own axes before even attempting to cut wood.

A person who tries to invent easier ways to do things is called an engineer. This isn't about how long your technical penis is, it is about getting the job done with as little time and effort as possible.

Only a fool would disdain a simpler tool.

Smiley

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

You totally miss the point. If you shit your pants because of a few symbols you no longer can make an informed decision what would actually be the best tool for the job.

Stealing Proteus doesn't make you an engineer.

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

ArnoldB wrote:
You totally miss the point. If you shit your pants because of a few symbols you no longer can make an informed decision what would actually be the best tool for the job.

Oh, sorry. Have you tried Depends?

Smiley

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

... Ok guys, let's see if we can tone down the rhetoric, or at least elevate it out of the gutter for a few moments. :)

Yes, I agree and admit that having an IDE do everything for you is nice to have. I enjoy that too. AVR Studio does automatically generate a Makefile for the end-user and it works reasonably well, for simple AVR applications. Right now, more work needs to be done to have that makefile generation be smarter about things. As soon as the application becomes moderately complex the end user finds out that Studio's makefile generation is insufficient. The "escape valve" is that the user can provide their own Makefile. This gives the ultimate control back to the end user, which is another thing that I like.

Yes, the Makefile has symbols. Any decent programmer has to work with symbols in their programming language. So it becomes a matter of looking it up in a manual to see what something means. Honestly, how hard can that be?

Here's the GNU Make Manual, in 11 different formats:
http://www.gnu.org/software/make...

Looking at the Table of Contents (always a good place to start), we find "Appendix A Quick Reference". Going to that link:

http://www.gnu.org/software/make...

we find first a "Summary of Directives", then a "summary of the built-in functions", then a "summary of the automatic variables", in which we find the magic symbols that we're looking for as the first and third items:

$@
    The file name of the target.
...
$<
    The name of the first prerequisite. 

If one has read the first 5-6 chapters then they will have the language to understand what is meant by "target" and "prerequisite".

All of this is knowing how to do basic research in a book: table of contents, appendices, indices, etc., knowing how to sift through the material to find out just the information you need. First, there must be a willingness to try something new, and a willingness to understand from other people's perspectives without pre-judging whether something is good or bad. Laziness is only a virtue up to a point.

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

Eric,

But if the kind of "beginner" questions posted here (ie those from the typical users of Studio rather than users of real Makefiles) is anything to go by then these folks have difficulty enough learning any language let alone several (in fact that usually starts with English ;) ). Makefiles are effectively just another "programming language" - but if your goal is simply to get an LED flashing it's maybe a hurdle too far to learn the AVR architecture, the C language and the make "language". Ticking a few boxes in a GUI is often going to look easier.

Sure it may be a form of laziness but the hope will be that once they get their LED flashing, learn a bit more C, recognise the limitations of the build environment THEN they may be ready to tinker with their own Makefiles. I know that Mfile is an attempt to be an "easy in". But these same folks (initially) seem to be incacpable of spotting that Mfile exists.

Cliff

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

Certainly any simple AVR application like blinking an LED does not require the end user to learn how Makefiles work. AVR Studio can automatically build a project without one ever having to learn how that works. Same as many other IDEs. For advanced users, it is too constraining. The WinAVR Makefile Template and MFile were created to help people transition from one to the other, if they so desire.

I get tired of of the religious arguments and the snap judgments that come with it: "Makefiles suck! Everything should be done by the IDE! Command line tools are in the dark ages!". From my point of view, I like both. I like having the GUI front-end and pressing the single button and have my application built properly in front of my eyes. It gives me time to think about the problem at hand. I also like having the ability to dig into the guts and do something completely custom if my application needs it. I don't want to be hamstrung by my tools.

My end goal is to make the tools easy for the beginner, yet make it easy enough for the advanced user to customize and to get into the guts if they want to. To cover the needs of the whole spectrum of users. Have we reached that goal? By my estimates, no. We have a lot more work to do. Is it usable today? Yes, very usable, and not overly difficult if one doesn't mind applying a little bit of brain power.

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

You're leaning against an open door here! I personally wouldn't think of not using a Makefile or of not building at a command prompt. But in part that's maybe because I'm a luddite.

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

Do any of you that think the GNU makefiles are easy have your source in multiple folders and the compiler output in yet another folder?

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

steve17 wrote:
Do any of you that think the GNU makefiles are easy have your source in multiple folders and the compiler output in yet another folder?

No...

Other then the compilers own use of its default include and library folders, all of my project files go the project folder that I specifically assign them to go.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

For me, an AVR application is so small that I would rather have the Makefile be simple and put all of the source code, object modules, and final output files all in a single directory. No hierarchies involved. I never really understood the reasoning to have all of the object code go into a separate directory, or the output files go into yet another directory. I respect the fact that other people have different opinions and so may want that feature. That's why it was added to the WinAVR Makefile Template.

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

EW wrote:
I never really understood the reasoning to have all of the object code go into a separate directory, or the output files go into yet another directory.

One time I used this feature was when I used the same algorithm (source) for a PC program and a AVR application. I wanted to have one source and the binary to be HW dependend. That was one time in a lot of years in SW development...

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

EW wrote:
For me, an AVR application is so small that I would rather have the Makefile be simple

My AVR spps don't seem that small to me, but I agree on one thing. I would rather the makefile be simple. :)

EW wrote:
I never really understood the reasoning to have all of the object code go into a separate directory, or the output files go into yet another directory.

I have apps for different AVRs, and even different brands of microcontroller that share some source files.

It's not a big deal but when I "diff" my source with my archive to see what needs to be put into the archive, If the .obj and .lst etc. files are in the source folder, I need to do a "make clean" before diffing or else the diff result is a big mess. Otherwise I'm always "unclean". :)

EW wrote:

That's why it was added to the WinAVR Makefile Template

The template I tried worked well for putting the compiler output into a separate folder. But only if all the source was in one folder. I never could get it to work with multiple source folders.

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

Steve what kind of code control archiving system do you use them? In most (VSS, CVS, SVN, etc.) the archive database will not "know" about any files that has not been deliberately introduced so it just won't "see" the .o's and .lst's anyway (or it'll be obvious they aren't part of the archived content)

Your use of the word "diff" there sounds like you maybe aren't using a formal code control system. In not take a look at SVN - it's very good.

Cliff

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

Quote:

I never really understood the reasoning to have all of the object code go into a separate directory

Eg. so that the version control system does not report them as "not versioned" every time you get a status listing for a directory with source code files in it.

Eg. to make backing up, but excluding generated/intermediate files, easy.

Eg. so that old projects with one file per function does not look so cluttered?

Most or all of the above knicked from a similar discussion in another thread...

EDIT: I am a huge friend of Subversion (SVN), but it's been a while. I am also a huge friend of the Windows SVN plugin called Tortoise.

I either mis-understand what Cliff writes above, or we are looking at different parts or versions of SVN.

If you look in a directory, all files not under version control will of-course still be shown. In some listings they will be explicitly marked with "not versioned" or some such.

For a small project that's fine. For a project with 10 aource files (eg. 4 .c's with .h's, 1 .c without .h, and 2 "free" .h's - nothing extreme) the list already starts to be somewhat cluttered.

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

Personally, I've never had any problems with diff tools, or revision control systems, or at least they never bothered me. But as I mentioned, I respect that other people have different opinions. I'm certainly not against it, I just never needed it personally.

Yes, the WinAVR Makefile Template can put the compiler output in subdirectories, but it doesn't deal with source code in multiple subdirectories. Doing that is probably application-specific and it would be difficult trying to make it generic and put it in a single makefile.

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

One of the nice things about having a separate build
directory is that if one makes a big enough mess,
one can clean up by nuking said build directory
without damaging any innocent bystanders.
Also, as I usually use -save-temps,
not using a separate build directory produces considerable
clutter that can be hard to wade through.

steve17 wrote:
Do any of you that think the GNU makefiles are easy have your source in multiple folders and the compiler output in yet another folder?
Usually I try for make files compatible with AVR Studio.
As I do not want my source files in a directory called default,
a script generates a small make file that "include"s a make
file in the source directory.

I used multiple source directories to compile code using Dean Camera's MyUSB.
In that case, my source directory didn't have much in it,
so I didn't bother with a separate build directory.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

I'm actually using an old version of Microsoft's SourceSafe for archiving. The new version is expensive so I can't necessarily recommend it for home use, but in my humble opinion it kicks butt.

It can diff the files in an archived "project" (think folder), with the working folder where I do the builds, with a couple of clicks. That tells me what files I've changed lately. I then re-examine these changed files, clean them up, re-test them, and put them in the archive.

The "diff" window allows me to select the changed files and click "check in". Job done.

It also shows the new files in the working folder that aren't yet in the archive. Same deal. I recheck them, clean them up, re-test them. Do another diff, select them, and click "add files".

SourceSafe is one of my most important development tools. I'd be lost without it.

I'm not meaning to start arguments. I don't know CVS. My last employer used something like "PVCS" or maybe it was "PCVS". It was the most horrible error prone piece of garbage I ever saw in my life. It was one of the reasons I quit my job. I simply refused to use it. Software tools should help reduce errors and make the programmer's life easier. That PVCS thing was a train wreck ready to happen.

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

For my sins I've been using VSS on about twenty 1,000+ file projects over the last 10 years or more and, believe me, it's not without error. As someone I know once said it's not a question of "if your archive ever corrupts but when"!

We've just made a corporate decision to switch to SVN and are slowly migrating all our projects (there are some nice migration tools for this)

But the point in VSS is that if you do a "show differences (recursive)" and ensure the the "show files only in the To: location" is unticked then it will not even show you the local .o's, .lst's and other detritus. In fact I usually clear all the ticks except the "show files that are different in both places" box.

Cliff

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

Quote:

I'm actually using an old version of Microsoft's SourceSafe for archiving. The new version is expensive so I can't necessarily recommend it for home use, but in my humble opinion it kicks butt. [...]

I was a SourceSafe user for ten years. It does checking out, checking in, diffing etc as most every (semi-)modern version control software does. We even did branching. Our experiments with merging branches showed horrible results. No, I have no details in memory anymore. IMO, if you can't branch a development track and merge it back to the trunk then the tool is for toy/hobby development only.

SourceSafe fits extremely bad for distributed projects (geographically, organizational, temporal) due to it's reserved check-out model.

Subversion has the very lovely property that revision numbers are for the complete repository rather than for each individual file. This means that you don't need to say things like "This build consists of trunk\main.c rev 123, trunk\sub1.c rev 456, trunk\sub1.h rev 465..." but rather "This build consists of trunk/ revision 12345".

I am currently using ClearCase Lite (or whatever the "snapshot only" variant is called) at work. Don't even get me started...

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]

Last Edited: Thu. Jun 5, 2008 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
SourceSafe fits extremely bad for distributed projects (geographically, organizational, temporal) due to it's reserved check-out model.

If you thought SourceSafe was bad you probably haven't been forced to use SourceOffSite (http://www.sourcegear.com/sos/) as a remote client to VSS! Now it could well be that these days it's far more robust but it used to be a nightmare. So much so that we took to calling it SourceOfShite :lol:

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

clawson wrote:
We've just made a corporate decision to switch to SVN and are slowly migrating all our projects (there are some nice migration tools for this)
For Windoze users, there is TortoiseSVN (http://tortoisesvn.tigris.org/) which integrates all of the svn-isms into the Explorer window. I've been using it for a couple of years now with few problems. OTOH, I'm the only one in my project, so I've never dealt with sharing issues. And the Explorer integration is not without problems.

I'm also a heavy user of VSS -- I use it on my M$ code.

The one thing I miss from VSS is the nice integration into the IDE. Although, since I'm not "locking" source to keep others from using it, it's not an issue.

Source control, IDEs, editors, OSes, programming languages - these are all religious issues. We all feel strongly about them, about what's "right", and in the end, we're all right.

(I'm going to create a new programming language: Zen. Then I'll create another language to replace it: Tao. I can't wait to see the arguments: "That was Zen. This is Tao.")

Stu :P

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

For Windoze users, there is TortoiseSVN [...] OTOH, I'm the only one in my project, so I've never dealt with sharing issues.

As Tortiose is just a GUI shell for SVN it works just as well as SVN itself when it comes to sharing issues. IMO that is "it works brilliantly!".

Still, if you come from SourceSafe or ClearCase the thinking is quite different. I suppose you either like the SVN philosophy (non-locking, repository-wide revision numbering,...) or you really don't. I have experience with all three of those, and in my world SVN is the best. And it has unlimited value (or whatever formulation Lee uses :mrgreen: )

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:

And it has unlimited value (or whatever formulation Lee uses Mr. Green )

lol--yes, certainly I am lurking. I believe that you are thinking of "infinite value"-- value = worth / cost.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Yup, we're using Tortoise on top of SVN and in addition to that we're building a linked system using:

Coderstriker - instigate peer code reviews:
http://codestriker.sourceforge.net

ViewVC - generates HTML views of SVN repositories for use in Wiki etc.
http://www.viewvc.org/

Hudson - auto rebuilds projects at each SVN checkin
https://hudson.dev.java.net/

Trac - an SVN aware Wiki to tie everything together in a global interface
http://trac.edgewall.org/

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

clawson wrote:
For my sins I've been using VSS on about twenty 1,000+ file projects over the last 10 years or more and, believe me, it's not without error. As someone I know once said it's not a question of "if your archive ever corrupts but when"!
Cliff

I've heard of problems but I've never seen any. I've used it for 10 years without problems. You may be doing fancy things I've never done. We had some fairly big projects at work. When I archive the archive, or whatever you call it, I would get a .ssa file of 100 megabytes.

The thing I like most is it knows where the local working folder is for each "project". It's hard to make a mistake. That darned "PCVS" didn't know anything. Another thing I like is you can run the commands from the command line. I do SourceSafe diffs from my editor. Very nice.

I never integrate it with Visual Studio. When that's done Visual Studio tries to take over. That makes me nervous. Maybe that's where others have problems.

I do all the actual archiving with SourceSafe explorer.

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

Back to Makefile...

The fisrt annoying thing about Makefile is that it does not have a file extension, possibly the only file in the known universe without one.

It's like looking at someone's avatar and say "I don't like that person", don't know really why. (what has this got to do with anything...?)

So here is a :idea: :idea: :idea: why not make winAvr understand makefile with an extension, any extension maybe .m or even have a little box where one can customise the extension with the letter of one's choice. winAvr will only need to ignore anything past makefile.

Then all of those un-illuminated, windows using, luddite cavemen can simply associate, say .m, with their favourite text editor and get a little more aquainted with makefile instead of having to go thorugh windows' third degree interrogation in order to open the file lest one descends into the darkness of black screen command line mode.

Or is that already possible and I just haven't seen in the manual?

Why is it that it is always the poor (or stingy ) people that suffer with using free tools? Well off people that use other C compilers do not need to suffer with makefiles. :roll:

Do I allways have to come up with all the great gcc ideas? :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Back to Makefile...
...
Then all of those un-illuminated, windows using, luddite cavemen can simply associate, say .m, with their favourite text editor and get a little more aquainted with makefile instead of having to go thorugh windows' third degree interrogation in order to open the file lest one descends into the darkness of black screen command line mode.

Or is that already possible and I just haven't seen in the manual?

You can use the '-f' switch at the command line.

make -f makefile.txt
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You can use the '-f' switch at the command line.
I don't want to go to command line, just click on makefile and have notepad (or whatever, maybe wordpad) open the file.

Or are you saying that if I rename makefile to makefile.txt and put the -f option somewhere in the Configuration options > Custom options > All files it should all be well?

How would I stop Studio producing another makefile when it does not find one? (now that makefile as been called makefile.txt)

Or is there another option to tell it to produce/use makefile.txt instead of makefile?

Enquiring minds want to know..as the saying goes.. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

How would I stop Studio producing another makefile when it does not find one? (now that makefile as been called makefile.txt)

Or is there another option to tell it to produce/use makefile.txt instead of makefile?

Enquiring minds want to know..as the saying goes.. :)

Good question, but I'am not sure how to integrate it with Studio since I use Programmers Notepad.

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

js wrote:
Back to Makefile...

The fisrt annoying thing about Makefile is that it does not have a file extension, possibly the only file in the known universe without one.


heh, heh. I bet you aren't a big *nix user. There are a whole lot of files over there without extensions.

Sorry I can't help with the makefile.txt thing because I do use the command line stuff, not AVR Studio.

You can get notepad or wordpad (or the editor of your choice) to open a file by right clicking on it, then hover on "Send To". If neither notepad or wordpad appear in the list, there are ways of putting them there.

Some of us who are personal friends of Uncle Bill, get a more colorful command prompt window. They are easier to read than that stupid gray text on black background. If you are on your best behavior, I could arrange an introduction. Actually I prefer to use Cygwin's bash, but please don't tell Bill.

Attachment(s): 

Last Edited: Fri. Jun 6, 2008 - 07:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js, I let Avr Studio do the makefile, and I put any compiler/linker options in via the studio custom/memory options. When I want to take a peek at the makefile (not very often), I just drag and drop the makefile onto a text editor shortcut that I have on the desktop. There are registry settings you can create for files without extensions, so you can right click on them and 'open with' whatever choices you have set. A google search would probably turn up what I'm referring to.

Last Edited: Fri. Jun 6, 2008 - 06:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If neither notepad or wordpad appear in the list, there are ways of putting them there.
Neither of them are there. I usually just either double click of the file, one with an extension associated with a program, or use "Open" or "Open with" BUT, because there isn't an extension, you have to select a program from a list, which is not remembered as there is no extension to associated it with that program.

Ok, ok lame excuse for not liking makefile but it's the best I can come up with. :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Quote:
If neither notepad or wordpad appear in the list, there are ways of putting them there.
Neither of them are there.

You need to put a shortcut to wordpad or notepad, etc. in your SendTo folder.

Your SendTo folder is located here:
C:\Documents and Settings\\SendTo

I'm assuming your XP is installed on 'C'.

There are a lot of ways to get the shortcut there. Here's one.

With Windows Explorer (A.K.A. My Computer), navigate to the afore mentioned SendTo folder.

Click Start > All Programs > Accessories. Right click on Wordpad, or whatever. Click copy. Go to the SendTo folder in Windows Explorer. Right click on a blank spot in the window, then click paste. Job done.

If you have a shortcut to Wordpad etc. on your start menu, you could copy that instead.

If you want a shortcut to Wordpad on the start menu, go to the > Accessories folder, right click on Wordpad and click "Pin to Start Menu".

Some of this stuff may require XP's default desktop. If you are a real Luddite with the classic desktop I guess the "Pin to Start Menu" doesn't work.

Last Edited: Fri. Jun 6, 2008 - 07:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to change the color of the command prompt window and make it easier to read (in my humble opinion), here's how.

Start a command prompt window. Right click on the title bar. Click Properties > Colors tab.

With the Screen background circle checked, click on the light blue, or light green or yellow. You can try others of course, but I think these are best. Then select the Screen Text circle at the top. Click on the black square. Click OK.

One last window will appear that allows you to make the change for command prompt windows you open in the future, or only affect the one window that you currently have open.

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

Quote:
You need to put a shortcut to wordpad or notepad, etc. in your SendTo folder.
OK done. :) ...now I have to make up another excuse....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
...now I have to make up another excuse....

You Aussies need excuses? I complain for pure enjoyment. :)

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

js wrote:

How would I stop Studio producing another makefile when it does not find one? (now that makefile as been called makefile.txt)

Or is there another option to tell it to produce/use makefile.txt instead of makefile?

It's part of configuration options.
It's labeled "Use external makefile" or something like that.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Quote:
"Use external makefile"
Which takes back to the start, NOT wanting to use "external makefile" but the "invisible" one generated by Studio. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly