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

[Marek Michalkiewicz]

Hi,

> 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 

I see.  Can't help much here, but perhaps you could try to contact
Dean Ferreyra <address@hidden> who did the original Cygwin port.

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

Ahh, licensing issues...  If nothing else from your distribution
needs Cygwin DLLs, perhaps uisp could be built without Cygwin too,
but again I can't help much here (as I almost don't use Windows).

> 2. Using it. For Windows it requires the giveio.sys drive as you 
> mention. This driver has to be loaded with another program. AFAIK, 

Only NT/2000 (not 9x/ME, no clue about XP) and then only when using
parallel port programmers (not stk500 or avr910/pavr).

> 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 

Someone just told me they managed to compile giveio-install.cpp
(part of http://www.amelek.gda.pl/avr/uisp/giveio-src.tar.gz,
originally written for g++, I don't remember where I got that from)
with a M$ compiler with just a few changes, and it works.  The source
looks like a command line tool to me, perhaps you could try it...

Better not automate the installation of such a driver too much, for
security reasons - in theory, any application can then access I/O
ports, crash the machine, bypass file permissions by accessing the
disk controller directly, etc.  Of course, Windows security is
almost non-existent anyway, but it is still better for the user to
know what they are doing...

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

As far as I know, Windows lacks a clean low level parallel port API
(like Linux ppdev or FreeBSD ppi).  So we are probably stuck with
direct I/O port access and a driver like giveio.sys for NT/2000 anyway.
Atmel's own AVR ISP shipped with the STK200 doesn't work on NT either.

One nice thing about ppdev is that parallel port support is not limited
to the well known 0x378/278/3bc ports - should work with PCI parallel
ports too, which are quite cheap these days, and a nice way to reduce
risk of frying the motherboard if something goes wrong with the target.

Of course, I agree that uisp is not the most cleanly written program
ever, due to its long history (and, I admit, my lack of experience
with C++ which was chosen by the original author).

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

In the *nix world, binutils and GCC are separate packages, which
don't have to be upgraded at the same time.  You could have the
latest binutils, and two different versions of GCC installed at
the same time (and both will work).  These old linker scripts can
probably be removed from binutils after the 2.14 release, when
very few people can reasonably be expected to still use GCC 3.0.

You have both binutils and GCC as one big package, so there are
no problems with version compatibility.  That's why it is not
necessary for you to ship the old linker scripts - simply delete
them after "make install" and before packing the distribution.

BTW, is there any way to unpack that self-extracting .exe file
under Linux, other than running it under Wine?  unzip and unrar
don't handle it, so it must be something else...

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

Sorry for the long delay, and thanks for reminding me - I forgot
about it completely :(.  Just a few comments:

#define BOOTLOADER_SECTION    __attribute__ ((section (".bootloader")))

Another way to handle this is to use the standard linker scripts,
link the boot loader as a separate application and specify the
start address with the -Wl,-Ttext,0x3800 (or whatever) option.

        __asm__ __volatile__                         \
        (                                            \
            "movw  r0, %3\n\t"                       \
            "movw r30, %2\n\t"                       \
            "sts %0, %1\n\t"                         \
            "spm\n\t"                                \
            "clr  r1\n\t"                            \
            : "=m" (SPMCR)                           \
            : "r" ((unsigned char)BOOT_PAGE_FILL),   \
              "r" ((unsigned short)address),         \
              "r" ((unsigned short)data)             \
            : "r0", "r30", "r31"                     \
        );                                           \

I've never used the "=m" constraint - since the address for "sts"
must be constant anyway (it won't work with any possible memory
operand), I'd suggest to change this to "i" (_SFR_MEM_ADDR(SPMCR))
(constant, input operand).  See <avr/pgmspace.h> for some examples
(how the RAMPZ address is passed to the asm).

Some old devices (ATmega161/163/323) require ".word 0xffff" and
"nop" after "spm", probably as a workaround for some chip bugs.

On smaller devices (all except ATmega64/128), SPMCR is in the I/O
space, accessible with the shorter "in" and "out" instructions -
since the boot loader has a limited size, this could be an
important optimization.

Atmel has renamed SPMCR to SPMCSR in ATmega169.  Perhaps boot.h
should use the new name consistently, and all <avr/io*.h> files
should be updated to define both.

Other than a few suggestions above, your boot.h looks OK to me -
please go ahead and submit it.  Again, sorry for the long delay...

Thanks,
Marek

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