Hallo Experten, ich dachte, bevor ich lange herum probiere und mir einen Wolf suche, frage ich die, die es wissen müssen. Ich habe eine Applikation bei der ein Kreuzsupport (Tisch in zwei Achsen verfahrbar) hochpräzise gesteuert werden muss. Ich muss ausserdem (das ist das wichtigste!) eine sehr hohe Wiederholgenauigkeit haben. Die Geschwindigkeit ist nahezu unwichtig. Wir reden hier von einem tausendstel Millimeter. Tisch und Antriebselemente sind soweit fertig. z.Info: Grosser Verfahrweg ist 180mm (präzision mind. +/- 0,01mm) kleiner Verfahrweg 45mm +/- 0,001mm !!!! Das System nimmt (mit einem anderen Rechner) in Echtzeit Videodaten auf und wertet diese aus. Ich werde also mit grossen Untersetzungen fahren müssen. Die Genauigkeit muss auch nur von einer Anfahrseite erreicht werden, sodass ich keine Hampeleien mit Getriebespiel etc habe. Ich kann also beim Positionieren immer zurückfahren und den Sollpunkt dann neu ansteuern. Jetzt endlich meine Frage: Ich habe mir das USC008, ISP und Kabelsatz von EmbedIt gekauft und muss nun ans Programmieren. Welche Compiler und ICP Tools sind am schnellsten und stabilsten ..... da ich bei M$ Ausschlag bekomme, bitte Unix und/oder Linux tools. Nach Möglichkeit in C, ASM ist aber auch ok. Gibt es Tools, die ich mir auf meine Unix-Plattform selbst portieren kann? BTW: Ich mag die Kommandozeile sehr! Stepper oder DC? Encoder ? Vorab schon mal herzlichen Dank für Eure Unterstützung.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.