ATmega8 und servo bzw. Positionierappl.. Guten Rat gebraucht

Nun, ich verstehe zwar nix von dem was du vor hast, allerdings kann ich
was zum Toolchain sagen:

AVR-GCC + AVR-LIBC

http://www.nongnu.org/avr-libc/
http://www.avrfreaks.net/AVRGCC/


hätte man allerdigs auch googeln können....

Man findet auch RPMs, die sich problemlos installieren lassen
(rpmssek.com ist dein Freund).

Das ganze funktioniert echt super bis auf eine Kleinigkeit: Der
Simulator, den der ist wirklich ziemlich.. naja, sagen wir mal die
ENtwickler könnten dringend Unterstützung gebrauchen. Dafür kann man im
AVRStudio gut simulieren (gibbet bei Atmel). Das ist alleridng WIndows.
Keine Ahnung ob man das mit WINE ans laufen bekommt

MfG

Sebastian

Nein, AVR Studio läuft nicht unter Wine.  VMLAB läuft dagegen unter
Wine, ist aber payware.  (Dafür ist dessen IO-Simulation aber echt
Spitze.)

Lieber Sebastian, lieber Jörg
vielen Dank für Eure Hilfe. Was ich vor habe?
Nun, es geht darum einen zweiachsigen Tisch (300x200mm) zu verfahren.
Der Tisch (zwei Marmor-Platten) trägt optische Messgeräte die auf einer
optischen Achse verfahren werden müssen. Die Verfahrwege stehen im
direkten Zusammenhang mit der Qualität der Messung und müssen daher
eine sehr hohe Reproduzierbarkeit haben. Ein tausendstel mm ist dabei
nur der Anfang, leider machen mir thermische Probleme einen Strich
durch die Rechnung und es wird wohl bei dieser Genauigkeit bleiben
müssen. Ich muss nun einen Controller haben, der die beiden Platten via
Servo positioniert. Die Motoren sind über ein Getriebe (1400:1) mit
einer Spindel verbunden und erzeugen auf diese Weise den Vorschub. Ich
möchte die Getriebespiele herausrechnen indem ich nur von immer der
selben Seite an die Zielposition heranfahre.

Mein Problem ist, dass ich kein Linux verwende (jedenfalls nicht
hierfür), da ich in Realtime arbeiten muss und deshalb QNX/Neutrino
verwende. Ich muss also die Werkzeuge auf dieser Plattform verfügbar
haben und das heisst: Selbst compilieren! Ich habe mir den gcc 3.4.0
schon mal zur Brust genommen und werde es auf diesem Wege versuchen.
Ob ich die c-lib für den AVR 'durch bekomme' weiss ich noch nicht.
Mit den Simulatoren sehe ich eher schwarz. Das ist ein grosser Aufwand,
denn erfahrungsgemäss sind die nicht POSIX konform und eher ein
Klumpatsch Sourcecode.
Wenn alle Stricke reissen, werde ich dann eben den AVR auf den Müll
schmeissen und das ganze via I/O-Board auf meine Realtimebox ziehen.
Währe nur schade, da ich dann auch noch die Rechenlast der PWM's
abfangen muss.

PS: Was ist Wine?

Vielen Dank für Eure Pointer und für Eure Hilfe
Mal sehen......vielleicht gibt es bald gcc3.4.0-avr unter Neutrino :-)
Oder ich beisse in den sauren Apfel und installiere mir auf 'ner alten
Mühle nochmal Windoze.

> Ich muss also die Werkzeuge auf dieser Plattform verfügbar haben

Warum eigentlich?  Warum muß Deine Steuermaschine identisch mit Deiner
Entwicklungsmaschine sein?

Ganz davon abgesehen, was ich von QNX in seinen letzten Versionen
gehört und gelesen habe, sollte das ganz gut funktionieren.

> Ob ich die c-lib für den AVR 'durch bekomme' weiss ich noch nicht.

Warum denn nicht?  Die compiliert sich doch via avr-gcc und
avr-binutils.

Wenn Du mit irgendwas bei der Portierung nicht klarkommst, wende Dich
bitte an die avr-libc Entwickler Mailingliste.

> Mit den Simulatoren sehe ich eher schwarz. Das ist ein grosser
> Aufwand, denn erfahrungsgemäss sind die nicht POSIX konform und eher
> ein Klumpatsch Sourcecode.

Da tust Du Ted Roth unrecht.  simulavr sollte recht gut Posix-konform
sein (sofern Du eine socket-Implementierung hast, denn die braucht's
für die Verbindung zum GDB).

> PS: Was ist Wine?

Ein Windows-Emulator.

>Warum eigentlich?  Warum muß Deine Steuermaschine identisch mit Deiner
>Entwicklungsmaschine sein?
Weil wir field updates einspielen müssen und wir nicht zwei
Betriebssysteme pflegen wollen. Wir benutzen einfach kein Windoze.

>Ganz davon abgesehen, was ich von QNX in seinen letzten Versionen
>gehört und gelesen habe, sollte das ganz gut funktionieren.

Da kannst Du drauf wetten :-) Wir sind seit 18 Jahren QNX Consulter und
entsprechend 'gefärbt' ;-)
Es geht aber noch um mehr, wie manuelle Bedienung, Verdrahtungsaufwand
etc.

>Da tust Du Ted Roth unrecht.  simulavr sollte recht gut Posix-konform
>sein (sofern Du eine socket-Implementierung hast, denn die braucht's
>für die Verbindung zum GDB).
Um Gottes Willen! Nein! Ich wollte niemandem unterstellen das sein Code
nicht konform ist. Ich habe den Code ja noch nicht einmal gesehen. Es
war/ist eben nur meine bisherige Erfahrung gewesen. Wenn dem nicht so
ist, bin ich doch sehr froh.
Wir benutzen den GDB via Eclipse (heisst bei uns alles Momentics) mit
gcc 2.95.3 und 3.3.1 parallel für mehrere CPU-Plattformen. Ich muss den
avr-gcc beim Portieren eben sauber in diese Hirarchie einbetten um nicht
Gefahr zu laufen, falsche Header einzusaugen was man evtl. erst viel
später merkt! Hier gibt es eben 12 mal /usr/include und /usr/lib etc.
:-)
Ok, ich werde mich da schon durchhangeln und wenns interessiert hier
dann Bericht abliefern.
cheers
Peter