On Mon, 10 Jan 2005 21:20:05 -0500, mc wrote:> > P.S. How about installing in C:\Program Files? Or do you have components > that don't like long filenames? In general, I'm pretty picky about wanting > all my application software to follow Windows conventions. So far, I'mJust because "Program Files" is a convention, doesn't mean it is a good idea. In fact, it is an apallingly bad idea, and the microsoftie who thought of it should be strung up beside the even bigger halfwit who thought up the "my documents" scheme. Most useful development tools are, at heart, command line based (even if they have a pretty face on top), and life is vastly easier if paths are shorter and preferably don't have spaces. Just make yourself a "c:\progs" directory and put useful development stuff in there, leaving "program files" for your open office, firefox, the gimp, and other useful windowed programs.> pleased to see that you haven't made any of the common big blunders (the > most common of which is wanting to write in the install directory at run > time; on a secure machine, ordinary users don't have permission to write > there). Keep up the good work!
AVR compilers
Started by ●January 9, 2005
Reply by ●January 11, 20052005-01-11
Reply by ●January 11, 20052005-01-11
On Mon, 10 Jan 2005 23:38:09 +0000, Rich Webb wrote:>>>> >>>>>gcc for AVR >>>> >>>> >>>> GPL, which may or may not be an issue. Active user community. >>> >>> The GPL-ness of GCC is not an issue, and never has been. Support, or rather >>> someone to talk to when you get lonely, might be one. >>> >> >>It is for some people, either because they don't understand the gcc >>licensing and mistakenly think it means their own code must be gpl'ed, or >>because they *do* understand the licensing and know that this provides the >>user with a guarentee of availability, flexibility, and reliability that >>can't be achieved any other way. > > I'm with you all the way and I understand that the GPL is not "viral" > (as some large software empires might like people to believe) but that's > not the only issue. >Absolutely - and a good point to bring up.> Which license is used for the libraries that the AVR gcc port links > with, GLP or the LGPL? (Asking because I genuinely don't know; I'm a > happy ICC-AVR user.) >There are two areas where the licenses are important for the run-time system. There are the gcc libraries (which cover things like the code generated by multiplication operators, or snippets used for interrupt prologue and epilogues - i.e., routines that are generated by the compiler rather than added by the linker), and the C support library (avr-libc). Another poster has already quoted the gcc library license, which is GPL with an exception to use it unrestricted at run-time. The avr-libc is a modified BSD-style license, starting: The contents of avr-libc are licensed with a Modified BSD License. All of this is supposed to be Free Software, Open Source, DFSG-free, GPL-compatible, and OK to use in both free and proprietary applications.> To paraphrase RMS's explanation of this: using the LGPL ("Lesser" or > (older usage) "Library" GPL) permits using the libraries in proprietary > programs; using the ordinary GPL for a library makes it available only > for free programs. >This sort of attitude is the difference between "open source" advocates (who would of preference license a library under the LGPL, giving people the freedom to choose their own license for their own code) and "free software" advocates (who would of preference license a library under the GPL, forcing users to make more code free). It doesn't make much of a difference to users of embedded compilers like avr-gcc - LGPL'ed code can be dynamically linked to non-(L)gpl'ed code but not staticly linked. The idea is that if you sell a closed-source binary which uses an LGPL'ed library, the end user can update their library and still use it with the binary. That makes a lot of sense on big systems (i.e., desktops or bigger), and means binaries can take advantage of security fixes or improvements in libraries. But you may not staticly link LGPL'ed code to non-(L)gpl'ed code without at least providing unlinked object files (or source code) to the end user as well as the binary. This is far from ideal for most embedded systems outside the hobby and accademic arenas, so in general you must avoid LGPL'ed libraries as well as GPL'ed code. Of course, the above applies only to target libraries (i.e., the bits running on the avr). Host libraries (as used by gcc itself, for example), are an entirely different matter, and most users will either not care about the particulars of the license, or see the GPL or LGPL as an advantage.> For many embedded systems the distinction might be moot, regardless of > which license is used, as the cost to the customer may be only "for the > hardware" but the firmware is "free."You'll think differently if you use GPL'ed code in your embedded software and your competitor, having bought one of your boards, has the legal right to your source code. The GPL is a two-edged sword.
Reply by ●January 11, 20052005-01-11
mc wrote:>"Richard M." <richard@imagecraft.com> wrote in message >news:41E335E9.3030308@imagecraft.com... > > > >>Can you be more specific with the "problem?" Double check the >>Project->Options->Path to make sure the paths match where you install. I >>just got the bright idea (ha ha) that I should modify the driver to always >>look at <install root>\include for headers and <install root>\lib instead >>of relying just on the settings in those boxes. >> >> > >I corresponded with support today - some of the example projects apparently >aren't right. The paths were correct. But I think your bright idea is a >good one. > > >Hi Michael, you actually did catch a bug also - in the old days, due to historical reasons, we shipped header files with names like avr.h avrclassic.h <-- really ancient, like 1999 :-) io8515.h ioM103.h etc. io????v.h <-- latest The last set, with the "v" suffix, has a consistent naming scheme for the interrupt vector, so for example, you can write something like #pragma interrupt_handler uart:UART_ISR .... and by changing the initial #include from one header to another, you do not need to manually adjust the vector # (one nitpick with the AVR si that sometimes the vector moves between CPUs....) Anyway, for V7, I figure we will get rid of the old and only supply the io???v.h files and forgot to update all the examples projects. Oops.>>As for the "code location 0 already contains a value," I thought I fixed >>that. Anyway, go to Project->Options->Target->Device and you probably have >>"Custom" set up, which has text address as 0. I thought I changed that to >>2 :-) Anyway, location 0 already has the reset vector in the startup code >>and hence you get that msg. >> >> > >That was exactly it. I thought Application Builder would set the device >type in project options; it doesn't. > > >Not everyone uses the AppBuilder and some people use the AppBuilder to "check out" the capability of the other CPUs, so there is no direct tie-in in that sense. It goes the other way though, the AppBuilder will pick up whatever you set in the Project option for the device target.>I need to get better at reading this assembly language. It's very nice to >be able to see the output of the compiler. > > >Yes, I think we have one of the more readable interspersed C and asm listing around. I like the feature a lot when I was coding embedded systems so it's a feature very important for me to get right.>Thanks for responding! > >Michael > > >P.S. How about installing in C:\Program Files? Or do you have components >that don't like long filenames? In general, I'm pretty picky about wanting >all my application software to follow Windows conventions. So far, I'm >pleased to see that you haven't made any of the common big blunders (the >most common of which is wanting to write in the install directory at run >time; on a secure machine, ordinary users don't have permission to write >there). Keep up the good work! > > >Shouldn't be any problems with spaces or long file names (well, not any more anyway :-) ) The V6 licensing is a bit more PITA in that it does want to write here and there and who knows where, which is one major reason we are junking it on V7. Thanks for your interests. -- // richard http://www.imagecraft.com
Reply by ●January 11, 20052005-01-11
larwe@larwe.com writes:> You can integrate avrgcc with any programming text editor. uisp - the > most common companion ISP program - also supports the STK500 > comprehensively, as well as numerous other programming interfaces.Plus the nice added bonus of being able to specify the programming cable pinout (at least avrdude allows this). I do use the same cable for two types of CPLDs (with a slightly modified Altera JAM player), ARM ISP functions (with armtool) and AVRs (with avrdude). Making arrangements like this with commercial tools is often impossible. The quality of the code generated by avr-gcc is not always optimal. However, the overhead is rather slight, and the general optimization capabilities of gcc are good. Also, the quality of the code has improved with new versions of gcc. It would be nice to see comparisons between different compilers with real-life applications. The unfortunate thing is that the source code optimized for compiler A may be pessimized for compiler B, so making such comparisons is difficult. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●January 11, 20052005-01-11
Ville Voipio wrote:>... snip ...> > It would be nice to see comparisons between different compilers > with real-life applications. The unfortunate thing is that > the source code optimized for compiler A may be pessimized > for compiler B, so making such comparisons is difficult.However source code should be optimized for readability and maintainability, and optimization left to the code generator. The results should be quite viable for compiler comparisons. This does not preclude algorithmic improvement. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●January 11, 20052005-01-11
"David" <david.nospam@westcontrol.removethis.com> wrote in message news:pan.2005.01.11.07.52.30.616000@westcontrol.removethis.com...> On Mon, 10 Jan 2005 21:20:05 -0500, mc wrote: > >> >> P.S. How about installing in C:\Program Files? Or do you have components >> that don't like long filenames? In general, I'm pretty picky about >> wanting >> all my application software to follow Windows conventions. So far, I'm > > Just because "Program Files" is a convention, doesn't mean it is a good > idea. In fact, it is an apallingly bad idea, and the microsoftie who > thought of it should be strung up beside the even bigger halfwit who > thought up the "my documents" scheme.I think naming it "Program Files" was a mistake. It should have been "progs" for complete compatibility with software that doesn't recognize long filenames, and for quicker typing. Likewise "Documents and Settings" should have been "usr". Apart from that, I think it was a good idea. "My documents" was a good idea too. A lot of people don't seem to realize that this isn't 1988 and Windows isn't DOS. Windows is a multi-user operating system and the location of "My Documents" depends on how you're set up. For instance, in our lab, it's on a shared disk on the network. Also, ordinary users (non-administrators) don't have permission to write in Program Files. All of this should be familiar in UNIX, where ~ points to your home directory wherever it is, and ordinary users don't write in /usr/local/bin. But some Windows software developers don't seem to understand these concepts. They get it into their head that the program *has* to be in some particular place and the user *has* to be able to write in the install directory. Many Windows developers are also unaware that Windows has a command line and that useful things can be done there. To see it all done right, try Microsoft Visual Studio. To read a brief but technically detailed rant on the subject, see www.covingtoninnovations.com/michael/blog/0404/index.html#040401. I hasten to add that ImageCraft C DOES NOT HAVE THESE FAULTS as far as I can tell. Once I figured out that it doesn't select any processor by default, I got it going just fine.
Reply by ●January 11, 20052005-01-11
"Richard M." <richard@imagecraft.com> wrote in message news:10u76rdap8mlm6c@corp.supernews.com...>>That was exactly it. I thought Application Builder would set the device >>type in project options; it doesn't. >> > Not everyone uses the AppBuilder and some people use the AppBuilder to > "check out" the capability of the other CPUs, so there is no direct tie-in > in that sense. It goes the other way though, the AppBuilder will pick up > whatever you set in the Project option for the device target.Ah! Now I know which order to run them in. Thanks! (You're giving great support for a product I haven't paid a cent for! :)
Reply by ●January 12, 20052005-01-12
David wrote:> On Mon, 10 Jan 2005 23:38:09 +0000, Rich Webb wrote: > >[...]> It doesn't make much of a difference to users of embedded compilers like > avr-gcc - LGPL'ed code can be dynamically linked to non-(L)gpl'ed code but > not staticly linked. The idea is that if you sell a closed-source binary > which uses an LGPL'ed library, the end user can update their library and > still use it with the binary. That makes a lot of sense on big systems > (i.e., desktops or bigger), and means binaries can take advantage > of security fixes or improvements in libraries. But you may not staticly > link LGPL'ed code to non-(L)gpl'ed code without at least providing > unlinked object files (or source code) to the end user as well as the > binary. This is far from ideal for most embedded systems outside the > hobby and accademic arenas, so in general you must avoid LGPL'ed libraries > as well as GPL'ed code. >What you have said here is new and foreign to me. It's late, and I can't think, but I wanted to post a big HUH? as a bookmark for later processing.> Of course, the above applies only to target libraries (i.e., the bits > running on the avr). Host libraries (as used by gcc itself, for example), > are an entirely different matter, and most users will either not care > about the particulars of the license, or see the GPL or LGPL as an > advantage. > > >>For many embedded systems the distinction might be moot, regardless of >>which license is used, as the cost to the customer may be only "for the >>hardware" but the firmware is "free." > > > You'll think differently if you use GPL'ed code in your embedded software > and your competitor, having bought one of your boards, has the legal right > to your source code. The GPL is a two-edged sword. > > >
Reply by ●January 12, 20052005-01-12
"mc" <mc_no_spam@uga.edu> wrote in message news:41e402ad@mustang.speedfactory.net...> I think naming it "Program Files" was a mistake. It should have been > "progs" for complete compatibility with software that doesn't recognizelong> filenames, and for quicker typing. Likewise "Documents and Settings"should> have been "usr". Apart from that, I think it was a good idea. > > "My documents" was a good idea too.They're all bad ideas for another reason: they are different in the different language versions of windows. Also, windows itself uses both the long names as the short ones in the registry at different places. A real mess. I once bought an application that was in Dutch. It also contained a registry patch, which pointed to the German version of "Program Files"..... geez...... No need to mention that it absolutely would not install properly on an english Windows 2000......> I hasten to add that ImageCraft C DOES NOT HAVE THESE FAULTS as far as I > can tell. Once I figured out that it doesn't select any processor by > default, I got it going just fine.Imagecraft is just perfect. It doesn't even use pathnames in it's project files, so you can just copy them to a different directory and recompile. A big hand for Richard! Meindert
Reply by ●January 12, 20052005-01-12
"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message news:10uapio154h6t29@corp.supernews.com...> "mc" <mc_no_spam@uga.edu> wrote in message > news:41e402ad@mustang.speedfactory.net... >> I think naming it "Program Files" was a mistake. It should have been >> "progs" for complete compatibility with software that doesn't recognize > long >> filenames, and for quicker typing.> They're all bad ideas for another reason: they are different in the > different language versions of windows.That's bad, but there is a Windows system call to find out the actual name and location. (Program Files need not reside on C:.) People should use these system calls or environment variables rather than hard-coding the name.
