WinAVR 20050414 Released

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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_id3D%68108&package_id3D%
66543&release_id3D%305042

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 JF6%rg 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


Re: WinAVR 20050414 Released

Quoted text here. Click to load it

... two months early!

Probably used an open source implementation of
http://science.slashdot.org/article.pl?sid05%/02/12/2344224&tid12%6&tid14 %

 '-)


--
Rich Webb   Norfolk, VA

Re: WinAVR 20050414 Released

WinAVR 20050414 Released

Quoted text here. Click to load it

Are the inb() and outb() functions still supported?  The documentation is
still there but I am having difficulty building.




Re: WinAVR 20050414 Released

Quoted text here. Click to load it
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



Re: WinAVR 20050414 Released

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

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.

Re: WinAVR 20050414 Released

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Good.


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.

Quoted text here. Click to load it

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


Quoted text here. Click to load it


Re: WinAVR 20050414 Released

Quoted text here. Click to load it
GCC
is
name).
Quoted text here. Click to load it
Yes it is.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

That is so true. If there was just time enough to do everything as it
should be done.

Quoted text here. Click to load it



Re: WinAVR 20050414 Released

[...]
Quoted text here. Click to load it

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.

Re: WinAVR 20050414 Released
Quoted text here. Click to load it


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
We've slightly trimmed the long signature. Click to see the full one.
Re: WinAVR 20050414 Released
On Sat, 19 Feb 2005 00:04:08 +0100, "Ulf Samuelsson"

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Re: M68k vs i8086+, was: WinAVR 20050414 Released
Quoted text here. Click to load it

There was another technical standpoint: the 80x86 code is shorter
than the equivalent 68k code. This is mostly due to the fact that
Intel decided to dedicate certain registers for certain uses
(cx for count, dx for I/O addresses, si and di for string ops etc).
Motorola stayed more fidel to the basic PDP-11 philosophy (where the
Motorola processors have their roots) using universal registers.
This needs more bits for the register addresses, and there are no
single byte opcodes in a 68k processor. The instructions
are definitely longer than the equivalent Intel instructions.
This is partially offset by the fact that there is less need for
shuffling the register contents around,

There is strong evidence that the initial PC designers were hard
pressed for memory: e.g. they used the interrupt vectors reserved
for Intel (0x00 to 0x1f) to keep the total interrupt table short.
The same reasoning seems to be behind the initial boot address
of 0x7c00 for nearly the top of a 32 kbyte RAM.

--

Tauno Voipio
tauno voipio (at) iki fi


Re: Doing it Right, was:M68k vs i8086+, was: WinAVR 20050414 Released
Quoted text here. Click to load it

This is also so true: "Work expands to fill the time allotted to it"
[Parkinson] ... plus 25%.

Quoted text here. Click to load it

Since you will never ever do it _right_, the best to be hoped for
is that _something_ is accomplished with the resources available.

If this something looks promising then more resources are laid on
the table and you try again.  And again, and again ...

Until:

The day it is perfected is the day it is obsolete.

Sic transit gloria mundi.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Doing it Right, was:M68k vs i8086+, was: WinAVR 20050414 Released

Quoted text here. Click to load it

Again, this is so true. Every now and then I just need to do
SOMETHING (i.e some kind of proto) AND DO IT FAST,
just to prove that the concept itself works. Then, if/when other
people feel confident, there just might be more time to do it
"properly". Unfortunately not probably the "absolute right" way,
bot closer to that....

I think that doing all things (like embedded SW) truly "right"
is possible only on your own/hobby projects, where hours
are not being counted...and timeschedule is the one you choose
and change as you wish.

Quoted text here. Click to load it

Pygmi



Re: Doing it Right, was:M68k vs i8086+, was: WinAVR 20050414 Released

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

We must do SOMETHING.  THIS is something.  Therefore, we must do THIS!

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: WinAVR 20050414 Released

Quoted text here. Click to load it

There are 125'C AVRs coming this year.
--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: WinAVR 20050414 Released
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Which is exactly what I wanted to do 30+ years ago for a killer PBX
system with a MicroData processor, but the penny-pinching president
insisted we get it working with the 8008 (which was all that was
available then).  We did, but the delays in recovery from noise
bursts etc. drove the customers away.  The customer will put up
with an occasional 1/2 second hole in transmission, but 5 to 15
seconds means they have hung up in disgust.

Later they redesigned for the 8080, which could handle it, but by
then I had left in disgust.  A similar area was the power
supplies.  Others could do those better than we could.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: WinAVR 20050414 Released
Quoted text here. Click to load it

Even better would have been to make the bus width selectable, like
they did on later chips, including the MC68HC001.

For the MC68000, this would have added only a small amount of additional
circuitry.  Since there weren't any extra package pins left over on the
64 pin DIP to use for dynamic bus sizing, they could have added a way to
tell the chip at reset time whether to use 8 or 16 bits, for instance,
by whether there was a pullup or pulldown on one of the signals.

Site Timeline