WinAVR 20050414 Released WinAVR (pronounced "whenever") is a suite of executable, open source software development tools for the Atmel AVR series of RISC microprocessors hosted on the Windows platform. It includes the GNU GCC compiler for C and C++. WinAVR can be found at http://sourceforge.net/projects/winavr/ with this release being at http://sourceforge.net/project/showfiles.php?group_id=3D68108&package_id=3D= 66543&release_id=3D305042 Below is just a sample of what's new. - README: The WinAVR README file has now become the WinAVR User Manual and is available in HTML. - GCC: New version, 3.4.3. - avr-libc: New version, 1.2.3. Many bugs fixed. - avrdude: Built from CVS after 4.4.0. New safe mode added. Will attempt to save the state of the fuses from accidental change. - uisp: New version, 20050207. - avarice: New version, 2.3. - SRecord New version: 1.21 (Special Thanks to J=F6rg Wunsch for building this at the last minute!) - Programmers Notepad New version, 2.0.5.48. - avrdude-gui: New package! This is a GUI fronted to the avrdude downloader software. WARNING: avrdude-gui is in an *alpha* stage and is included as a preview. Use at your own risk! - dwarfdump 20041122: New package! This utility can display lots of information about your ELF file that contains DWARF2 debugging information. - GNU Make: New version, 3.80. Now a native Win32 executable. - avr-mem script New addition. This is used by the Makefile Template to report memory usage. - Makefile Template Integrate the new avr-mem script to report memory usage. New dependency generation flags. New rule to generate preprocessed output for GCC bug reports. New experimental rule to start debugging: make debug. New macro to define a CPU frequency for all source code files. DWARF2 is now the default debugging information. - Installer: The uninstaller is now smarter, it installs a log of the files that are included and it only removes the files from the log. A registry key was put back in giving the location of the installation. Look in HKLM\SOFTWARE\WinAVR. It is now optional to install Programmers Notepad. For more information including tutorials you can check out the WinAVR homepage at http://winavr.sourceforge.net -Eric Weddington and Colin O'Flynn
WinAVR 20050414 Released
Started by ●February 15, 2005
Reply by ●February 15, 20052005-02-15
On 15 Feb 2005 13:31:09 -0800, "c_oflynn" <c_oflynn@yahoo.com> wrote:>WinAVR 20050414 Released... two months early! Probably used an open source implementation of http://science.slashdot.org/article.pl?sid=05/02/12/2344224&tid=126&tid=14 '-) -- Rich Webb Norfolk, VA
Reply by ●February 16, 20052005-02-16
"c_oflynn" <c_oflynn@yahoo.com> wrote in message news:1108503069.611053.87340@o13g2000cwo.googlegroups.com... WinAVR 20050414 Released>WinAVR (pronounced "whenever") is a suite of executable, open source >software development tools for the Atmel AVR series of RISC >microprocessors hosted on the Windows platform. It includes the GNU GCC >compiler for C and C++.Are the inb() and outb() functions still supported? The documentation is still there but I am having difficulty building.
Reply by ●February 16, 20052005-02-16
"Geek" <who@nowhere.com> wrote in message news:mVLQd.114758$K7.89421@fe2.news.blueyonder.co.uk...> > "c_oflynn" <c_oflynn@yahoo.com> wrote in message > news:1108503069.611053.87340@o13g2000cwo.googlegroups.com... > WinAVR 20050414 Released > > >WinAVR (pronounced "whenever") is a suite of executable, open source > >software development tools for the Atmel AVR series of RISC > >microprocessors hosted on the Windows platform. It includes the GNU GCC > >compiler for C and C++. > > Are the inb() and outb() functions still supported? The documentation is > still there but I am having difficulty building. > >I made same discovery. I haven't updated for a while and my code needed some work -sbi, cbi macros disappeared... -macro to access flash (near) disappeared... -inp/outp disappeared...some old stuff had even these -.. Well it took me very little time to "fix" my CURRENT project. The older ones are another issue... Is this something to expect in future as well? Does this happen often or has there been some clean-up to get rid of some "old stuff"?? Pygmi
Reply by ●February 16, 20052005-02-16
On Wed, 16 Feb 2005 19:40:18 GMT, "Pygmi" <bronco_castor@hotmail.com> wrote:> >"Geek" <who@nowhere.com> wrote in message >news:mVLQd.114758$K7.89421@fe2.news.blueyonder.co.uk... >> >> "c_oflynn" <c_oflynn@yahoo.com> wrote in message >> news:1108503069.611053.87340@o13g2000cwo.googlegroups.com... >> WinAVR 20050414 Released[...]>> Are the inb() and outb() functions still supported? The documentation is >> still there but I am having difficulty building.[...]>-sbi, cbi macros disappeared... >-macro to access flash (near) disappeared... >-inp/outp disappeared...some old stuff had even these >-.. > >Well it took me very little time to "fix" my CURRENT project. >The older ones are another issue... > >Is this something to expect in future as well? >Does this happen often or has there been some clean-up to get rid of >some "old stuff"??There was a discussion a while back on the avr-gcc mailing list. Some "old stuff" has been purged. Some people are not happy about it. But the purged macros were non-standard, had confusing syntax and unclear semantics, and had been deprecated for over two years, so (IMHO) the maintainers were justified in purging them. The quick fix for legacy code is to create a new header (e.g. "legacy.h") that defines the purged macros for you. E.g., #define sbi(p,b) (p) |= (1<<(b)) #define cbi(p,b) (p) &= ~(1<<(b)) etc. Then #include "legacy.h" in legacy code as a stopgap measure to get that code to compile with the new compiler. And be sure to _NOT_ #include "legacy.h" in new code. Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●February 17, 20052005-02-17
On Wed, 16 Feb 2005 19:40:18 +0000, Pygmi wrote:> > "Geek" <who@nowhere.com> wrote in message > news:mVLQd.114758$K7.89421@fe2.news.blueyonder.co.uk... >> >> "c_oflynn" <c_oflynn@yahoo.com> wrote in message >> news:1108503069.611053.87340@o13g2000cwo.googlegroups.com... >> WinAVR 20050414 Released >> >> >WinAVR (pronounced "whenever") is a suite of executable, open source >> >software development tools for the Atmel AVR series of RISC >> >microprocessors hosted on the Windows platform. It includes the GNU GCC >> >compiler for C and C++. >> >> Are the inb() and outb() functions still supported? The documentation is >> still there but I am having difficulty building. >> >> > I made same discovery. I haven't updated for a while and my code > needed some work > -sbi, cbi macros disappeared... > -macro to access flash (near) disappeared... > -inp/outp disappeared...some old stuff had even these > -.. >The inp/outp/sbi/cbi macros have been deprecated for years - I would be surprised if more than around 5% of the current avrgcc users started using the compiler before the documentation clearly stated that they were not for use in new projects. They have finally been removed in recent versions of the library. Basically, the trouble is that these macros are non-standard (even in the context of embedded systems programming), less flexible than the standard methods of bit manipulation, and don't do what they appear to say (i.e., they do not correspond directly to assembly instructions of the same name). For those that want to continue using them, it is easy enough to make your own macros (for older code that you don't want to change), move to more standard conventions, or invent your own.> Well it took me very little time to "fix" my CURRENT project.Good.> The older ones are another issue... >Maintaining older projects means maintaining older versions of your tools as well. One of the great things about software like gcc is that you can happily have as many old versions of the compiler and libraries as you want. In this case, "fixing" older code is just a matter of adding a couple of macros, but in general, you should think twice before changing tools in a working project. It comes as something of a surprise to me, and perhaps to the avr-libc maintainers, just how many people have been caught out by this change. If you are doing embedded programming, it makes sense to read the documentation for your tools, and it certainly makes sense to read the change lists and news lists for new versions before blindly upgrading and hoping that all is well.> Is this something to expect in future as well? > Does this happen often or has there been some clean-up to get rid of > some "old stuff"?? >It's rare that clean-ups make such a difference to existing code, but fair warning was given for those that read the documentation or followed the mailing list. Such changes are not made without due consideration - with a few command-line switches, you can make avr-gcc compile code written in a style that went out of date 25 years ago. But sometimes changes are necessary. Another change you can expect in the near future is a name change for the INTERRUPT macro. You should be either thinking "it's about time", or "I never use INTERRUPT anyway - SIGNAL is more appropriate", or you should go back and read the documentation again. David> Pygmi
Reply by ●February 17, 20052005-02-17
"David" <david.nospam@westcontrol.removethis.com> wrote in message news:pan.2005.02.17.08.24.00.322000@westcontrol.removethis.com...> On Wed, 16 Feb 2005 19:40:18 +0000, Pygmi wrote: > > > > > "Geek" <who@nowhere.com> wrote in message > > news:mVLQd.114758$K7.89421@fe2.news.blueyonder.co.uk... > >> > >> "c_oflynn" <c_oflynn@yahoo.com> wrote in message > >> news:1108503069.611053.87340@o13g2000cwo.googlegroups.com... > >> WinAVR 20050414 Released > >> > >> >WinAVR (pronounced "whenever") is a suite of executable, open source > >> >software development tools for the Atmel AVR series of RISC > >> >microprocessors hosted on the Windows platform. It includes the GNUGCC> >> >compiler for C and C++. > >> > >> Are the inb() and outb() functions still supported? The documentationis> >> still there but I am having difficulty building. > >> > >> > > I made same discovery. I haven't updated for a while and my code > > needed some work > > -sbi, cbi macros disappeared... > > -macro to access flash (near) disappeared... > > -inp/outp disappeared...some old stuff had even these > > -.. > > > > The inp/outp/sbi/cbi macros have been deprecated for years - I would be > surprised if more than around 5% of the current avrgcc users started using > the compiler before the documentation clearly stated that they were not > for use in new projects. They have finally been removed in recent > versions of the library. > > Basically, the trouble is that these macros are non-standard (even in the > context of embedded systems programming), less flexible than the standard > methods of bit manipulation, and don't do what they appear to say (i.e., > they do not correspond directly to assembly instructions of the samename).> > For those that want to continue using them, it is easy enough to make your > own macros (for older code that you don't want to change), move to more > standard conventions, or invent your own. >Yes it is.> > Well it took me very little time to "fix" my CURRENT project. > > Good. > > > The older ones are another issue... > > > > Maintaining older projects means maintaining older versions of your tools > as well. One of the great things about software like gcc is that you can > happily have as many old versions of the compiler and libraries as you > want. In this case, "fixing" older code is just a matter of adding a > couple of macros, but in general, you should think twice before changing > tools in a working project.I agree..partially. But, when writing lot of re-usable code, I have pretty much always old and new code mixed even in new projects as well.> It comes as something of a surprise to me, and perhaps to > the avr-libc maintainers, just how many people have been caught out by > this change. If you are doing embedded programming, it makes sense to > read the documentation for your tools, and it certainly makes sense to > read the change lists and news lists for new versions before blindly > upgrading and hoping that all is well.That is so true. If there was just time enough to do everything as it should be done.> > Is this something to expect in future as well? > > Does this happen often or has there been some clean-up to get rid of > > some "old stuff"?? > > > > It's rare that clean-ups make such a difference to existing code, but fair > warning was given for those that read the documentation or followed the > mailing list. Such changes are not made without due consideration - with > a few command-line switches, you can make avr-gcc compile code written in > a style that went out of date 25 years ago. But sometimes changes are > necessary. > > Another change you can expect in the near future is a name > change for the INTERRUPT macro. You should be either thinking "it's about > time", or "I never use INTERRUPT anyway - SIGNAL is more appropriate", or > you should go back and read the documentation again. > > David > > > > Pygmi >
Reply by ●February 17, 20052005-02-17
On Thu, 17 Feb 2005 19:02:55 GMT, "Pygmi" <bronco_castor@hotmail.com> wrote: [...]> >That is so true. If there was just time enough to do everything as it >should be done.If you don't have the time to do it right, where are you going to find the time to do it over? Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●February 18, 20052005-02-18
> > [...] > > > >That is so true. If there was just time enough to do everything as it > >should be done. > > If you don't have the time to do it right, where are you going to find > the time to do it over? > > Regards,Tell that to Motorola/Freescale which put a 16 bit bus on the MC68000 (which was the right thing to do) instead of an 8 bit bus, which could have won them the IBM PC deal. Intel has had plenty of time to put things right afterwards. Sometimes time to market is more important than other things. I know of an application where they used a $50 PowerPC cluster to control a fan. (4 MB Flash , 16 MB SDRAM external ADC etc. Now when they have the orders, it is beeing redesigned with $1-2 micros. It is painful to see the things beeing done in the wrong way to win a smaller customer and this kills the time to market for a larger customer. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by ●February 18, 20052005-02-18
On Sat, 19 Feb 2005 00:04:08 +0100, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:>> >> [...] >> > >> >That is so true. If there was just time enough to do everything as it >> >should be done. >> >> If you don't have the time to do it right, where are you going to find >> the time to do it over? >> >> Regards, > > >Tell that to Motorola/Freescale which put a 16 bit bus on >the MC68000 (which was the right thing to do) instead >of an 8 bit bus, which could have won them the IBM PC deal. >Intel has had plenty of time to put things right afterwards.My understanding is that it was the peripheral support for the 8088 (e.g., 8259, 8250, 8255), rather than simply the 8-bit bus, that tipped the scales in Intel's favor. If the 8080 and 8008 had a 16-bit external bus, IBM might have gone with the 8086 instead of the 8088. I'm not sure when Moto came up with the 68008, but it was probably too late.> >Sometimes time to market is more important than other things. > >I know of an application where they used a $50 PowerPC cluster >to control a fan. (4 MB Flash , 16 MB SDRAM external ADC etc. >Now when they have the orders, it is beeing redesigned with $1-2 micros.We're doing similar things with our prototypes, though not on such a grand scale. Our general purpose prototyping micro is the ATmega16. The final applications will generally be in the .5 to 8k program memory range. Not sure what chips production will use. Probably not AVR. :-( One customer wants us to pick from an "approved micros" list which does not include AVR, and another application has a 125 C temperature requirement. It's not my decision in any case (though I did have input on the prototype micro. ;-)> >It is painful to see the things beeing done in the wrong way >to win a smaller customer and this kills the time to market for >a larger customer.Having extra resources for prototyping _is_ the right way. In our market, anyway, we sell the capability with the prototype, then go to production with hardware that more closely matches requirements (especially now that we know much better what those requirements actually _are_). Regards, -=Dave -- Change is inevitable, progress is not.
