> Gibt es jetzt noch eine Möglichkeit, den Reset-Pin nach dem
> Programieren auf 1 zu legen.
Normalerweise sollte das die `exit specification' (Option -E) machen
können, also z.B. -E noreset. Allerdings glaube ich mich daran zu
erinnern gehört zu haben :), dass diese im Moment nicht funktionieren
würde. Wenn dem so ist => bitte einen Bugreport schreiben (auf
http://savannah.nongnu.org gibt's da ein Web-Interface dafür).
> Ich habe einige fertige RPM-Dateien für mein System gefunden.
Aua. ,,habe ... gefunden'' :-) Unterm Abstreicher? ;-)
Windows-Nutzer wären da wohl etwas vorsichtiger...
Die avr-libc-Doku enthält eine Selbstcompilier-Anweisung, mit der du
selbst unbedarft innerhalb von maximal 1 Stunde zum Ziel kommen
solltest.
GCC 4.0x ist für AVR überhaupt nicht empfehlenswert, da er einige
bekannte Bugs hatte. Wenn es schon ein 4.x sein muss, dann einen
aktuellen Snapshot nehmen, ansonsten bei der stabilen Version 3.4.4
bleiben.
RPMs für Linux werden nur saumäßig gepflegt, wie's scheint. Beklag
dich bei den Distributoren, die RPM-basierte Linuxe zusammennageln.
Offensichtlich ist es bei denen nicht so einfach, stabil irgendeine
derartige Software mit unterzubekommen, die nun vielleicht nicht
gerade 30 oder mehr Prozent ihrer Benutzer nehmen würden. Bei FreeBSD
weiß ich selbst, wie einfach es ist, etwas in die ports collection
aufzunehmen, das dann mit jedem FreeBSD mit verteilt wird, und sowohl
GenToo als auch Debian Linux scheinen einigermaßen agile Leute zu
haben, die im Rahmen von deren Paketsystemen die AVR-Toolchain
pflegen.
> Wie bekomme ich die paralele Schnittstelle für einen normalen user
> freigegeben?
Die Permissions auf /dev/parportX entsprechend setzen (X dürfte in den
allermeisten Fällen eine 0 sein). Die Unix-Variante des Parallelport-
Zugriffs geht einen relativ sauberen Weg (Linux und FreeBSD), bei dem
der Parallelport mit einem eigenständigen Treiber unterstützt wird.
Das ist zwar nicht die allerschnellste Variante, aber sie ist
ordentlich gegen andere konkurrierende Zugriffe verriegelt und sie
benötigt kein großräumiges Sicherheitsloch, da man den Zugriff sauber
über die /dev/*-Permissions regeln kann. Für Windows gibt's keinen
derartigen Treiber, sodass dort nur das Standard-Sicherheitsloch übrig
bleibt, alle IO-Ports für Anwenderprogramme zu öffnen.