WinAVR 20050414 Released

... two months early!

Probably used an open source implementation of

'-)

--
Rich Webb   Norfolk, VA

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

[...] [...]

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

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.

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.

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

GCC

is

name).

Yes it is.

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.

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.

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

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.

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

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.

... snip ...

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 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

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.

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

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

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.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

There are 125'C AVRs coming this year.

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

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.

Pygmi

[...]

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

Regards,

-=Dave

--
Change is inevitable, progress is not.