[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] [ANN] WinAVR 20030115

From: E. Weddington
Subject: Re: [avr-gcc-list] [ANN] WinAVR 20030115
Date: Thu, 16 Jan 2003 10:07:49 -0700

On 16 Jan 2003 at 9:24, Marek Michalkiewicz wrote:

> Hi,
> > I currently work for a small company where we make RFID products
> > (transponders and reader units) for the pharmaceutical laboratory
> > market. We partner exclusively with another company that sells these
> > products.
> Similar situation here, different product - oil in water monitor
> (based on scattered IR light measurement), required on every ship by
> environment protection regulations, so that if the oil separator
> fails, water with >15ppm of oil is not dumped into the sea.  The
> project is based on AT90S8535, upgrading it to ATmega16 right now (no
> need to change the PCB as it's pin-compatible, just software).

That's a pretty cool application!

> > As to the naming of the project, WinAVR is the name of the "toolset"
> > 
> I appreciate your work - while I only use avr-gcc under Linux, two of
> my co-workers in my day job use WinAVR and like it.  One small request
> on their behalf: would it be possible for future WinAVR releases to
> include uisp, and the giveio.sys driver with installer (necessary for
> uisp to work with parallel port programmers under NT/W2K)?

Thanks, I'm glad they like it!

uisp... There's a story. Essentially I have two issues with uisp.

1. Building it. I have not been able to build the latest source on 
either MinGW or Cygwin.  There is a howto on building it with Cygwin 
but it doesn't work for me for the latest source OR the 20020626 
version. Harald Kipp of the Ethernut project has an uisp executable 
for Windows. He told me in email that he currently doesn't remember 
that changes that he had to make to build it on Cygwin, but he'll let 
me know the next time he gets to building it. Then there's the fact 
that it (supposedly) is built with Cygwin. This means that uisp will 
be linked with Cygwin dlls, and when that happens, technically I also 
need to provide the source for those Cygwin dlls because of licensing 
issues. I'd rather not bloat the source code download, it's big as it 
is. And I'm trying to keep the dlls to a minimum, preferrably none. 
(As it is, I ship 1 MSYS dll in the 20030115 release.)

2. Using it. For Windows it requires the giveio.sys drive as you 
mention. This driver has to be loaded with another program. AFAIK, 
there are 2 loaders available (sorry, I can't remember their names 
right now). One loader is a command-line tool, but it doesn't work 
for me. The other loader looks like it was written for Windows 3.1 
and to load giveio.sys, you *have* to do it through it's GUI. I would 
rather that the user does *not* have to do anything to get a driver 
loaded to use a program, that loading the driver can be automated. 
That's why I would have liked for the command-line loader to have 

No offense to you, Ted, or any of the other contributors of uisp but 
what would really help would be an open-source software front-end to 
device programmers that is *originally* designed to be cross-platform 
(Linux, Windows). Perhaps using a cross-platform HLL such as Perl or 
Python? I've seen serial port modules under Perl and Python and at 
least one parallel port module under Perl. Anybody interested in 
this? If this could be done and it truly works under Linux *and* 
Windows I would include it in a heartbeat.

> One more thing: you can save a little disk space and remove the old
> linker scripts (like avr4433.x - only used by old GCC versions) from
> the distribution, only avr/lib/ldscripts/avr[1-5].* are needed. The
> old linker scripts are in binutils for backwards compatibility, but
> it's not an issue when installing GCC+binutils as one package.

I've been wondering about this. Currently I package just what 
binutils and gcc puts out with make install. This also leaves an 
empty <installdir>/include directory as well. As to the old linker 
scripts, if they are truly not needed, then why have binutils install 
them in the first place? IMO, that would be the best place to correct 
that. I'm trying to keep the Windows build of these projects, mirror 
as much as possible the *nix build. And if the *nix build installs 
them then I think the Windows build should too.

But what I can do is at least write a note about it in the README.txt 
file that gets installed with it. Or maybe this could also be put 
into the avrlibc FAQ?


Thanks again Marek.


P.S. Marek, have you had any time to go over the boot.h inline 
assembly I sent you for avrlibc?

avr-gcc-list at http://avr1.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]