[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
worked.
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?
Ideas?
Thanks again Marek.
Eric
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
Re: [avr-gcc-list] [ANN] WinAVR 20030115, E. Weddington, 2003/01/18
Re: [avr-gcc-list] [ANN] WinAVR 20030115, E. Weddington, 2003/01/18
Re: [avr-gcc-list] [ANN] WinAVR 20030115, E. Weddington, 2003/01/18
Re: [avr-gcc-list] [ANN] WinAVR 20030115, E. Weddington, 2003/01/18
RE: [avr-gcc-list] [ANN] WinAVR 20030115, Ebert, Rolf, 2003/01/18