Gast
#176889
hi leute, seh ich das richtig das selbst das neuste winavr den mega88 nicht unterstützt? kann ich trotzdem diesen uC verwenden (und wenn ja was muss ich konfigurieren)? für jede antwort dankbar :)
Gast
#176890
Problem ist wohl eher, dass Atmel den mega88 nicht unterstützt. Oder hast Du schon Samples vom m88 in der Hand? Solange es keine Samples gibt, wird auch niemand ernsthaft den WinAVR daran anpassen wollen. Stefan
Gast
#176891
Meiner Erinnerung nach hat WinAVR sogar den herumfliegenden Patch integriert, mit dem m48/88 und CAN128 unterstützt werden. Sagt denn das README nix dazu?
Gast
#176892
@stefan ich hoff doch mal sehr, dass ich einen m88 kriege, schließlich studier ich ja direkt an der quelle @jörg also das readme sagt mir, dass du es teilweise geschrieben hast, sowie einige patches und das mfile....worin ich aber leider keinen m88 finde...für den dude gibts folgenden patch https://savannah.nongnu.org/patch/?func=detailitem&item_id=3135 kann damit aber auch nicht wirklich was anfangen ("anfänger"), aber ich knabber mal fleißig weiter an der sache. gruß, jens
Gast
#176893
Dann bleibt Dir wohl nur die Eigeninitiative: http://savannah.nongnu.org/patch/?func=detailitem&item_id=2923
Gast
#176894
hi, ja, da war ich auch schon. wenn ich die sache richtig durchschaut hab, muss ich diverse textzeilen in die angegebenen dateien einfügen....wenn ich die dateien hätt! und ich finde auch keine anleitung mit der ich meine inkompetenz ausgleichen könnt. ist der patch an ein bestimmtes betriebssystem gebunden? danke, jens
Wenn ich studieren würde, würde ich mir nicht noch unnütze Arbeit damit aufhalsen, indem ich schwer oder nicht beschaffbare Bauteile nehme. Was ist denn an dem Mega88 dran, daß es nicht auch der Mega8 tut ? Und gerade unter Zeitdruck ist es äußerst unklug, Samples zu nehmen. Du weiß nie, ist der Fehler in Deinem Programm oder ist es ein Bug im µC. Peter P.S.: O.k., eine Sache die man ja beim Studium lernen soll, ist die Zeit effektiv zu nutzen, d.h. sich auf das Wesentliche zu konzentrieren und möglichst beste Randbedingungen zu schaffen, damit man nicht unnütz Zeit mit Nebensächlichkeiten vergeudet.
Gast
#176896
Zum Applizieren dieser Patches in den Original-Sourcecode gibt's das Kommando "patch". Wo der Sourcecode im Einzelnen zu finden ist, sollte irgendwo in der WinAVR-Doku stehen. Wenn Du's wirklich nicht findest, kann ich Dir auch paar URLs posten. (http://www.openavr.org/ dürfte auch ein guter Anhaltspunkt sein, um alle Links zu finden.) Du brauchst die GNU binutils, den GCC und die avr-libc (drei verschiedene Pakete). Allerdings, Selbstcompilieren geht auf einem Unix (bzw. Linux) deutlich simpler als auf einem Windows, weil Du Dir auf letzterem erstmal die Umgebung dafür schaffen mußt. Auf einem Unix, das schon einen Compiler hat und einen einigermaßen aktuellen Prozessor, dauert die ganze Compiliererei wohl weniger als eine halbe Stunde (ohne Doku von avr-libc, diese braucht viele Abhängigkeiten, aber die wird standardmäßig nicht gebaut -- kannste auch im Netz lesen).
Gast
#176897
Was heisst denn "studiere direkt an der Quelle"? Hast Du direkt was mit den Atmel-Jungs zu tun? Meine letzte Info war - nicht zu bekommen, auch nicht in Musterstückzahlen. Stefan
Gast
#176898
@stefan das heisst ba-studium bei atmel
Gast
#176899
@Jens: Sag Bescheid, wenn du funktionierende Muster in die Finger bekommst - würde mich sehr interessieren. Im Augenblick benutze ich den mega16 per JTAG, für das Endprodukt wird dann das Programm auf den mega8 umgesetzt. Wäre prima, wenn der mega88 endlich verfügbar wäre. Stefan
Gast
#176900
Ich hab ein funktionierendes Muster... Aber leider schaffe ich nicht, den Controller zu programmieren. Ich scheitere trotz neuer WinAVR Version bereits am kompilieren. Der Makefilegenerator (mfile) kennt den Mega48 anscheinend nicht, also habe ich in der Makefile manuell MCU = atmega48 eingetragen. Doch beim Übersetzen kennt er die Registernamen nicht (UBRR1H, UBRR1L ...)
Gast
#176901
Es ist richtig, Mfile kennt die neuen AVRs noch nicht. Als Eric die aktuelle WinAVR-Version vorbereitet hat, hatte ich gerade noch die Zeit übrig, ihm ein aktuelles avr-libc-Release auszurollen, damit er von allen aktuellen Bugfixes ohne eigene Patches profitieren kann, aber für irgendwelche Arbeiten an Mfile hat meine Zeit nicht mehr gereicht. > Doch beim Übersetzen kennt er die Registernamen nicht (UBRR1H, > UBRR1L ...) Mein Datenblatt kennt diese allerdings auch nicht. Hast du wirklich einen ATmega88 im Sinn?
Gast
#176902
UBRR1H, UBRRnH, UBRRH, ... ich habe alles durchprobiert. Welche Dateien muss ich einbinden? Wann gibt es eine neue Version von Mfile? Der makefileeintrag MCU = atmega48 stimmt doch?
Gast
#176903
Datenblatt S. 325 (Register summary): UBRR0H/UBRR0L. Die ATmegax8 haben nur eine USART, die hat dann die Nummer 0. Die Beschreibung in den Datenlättern ist nur völlig generisch und benutzt statt der Kanalnummer die Metavariable `n'. Nein, eine neue Version von Mfile ist noch nicht ,,um die Ecke''. Ich muss halt erst die Zeit finden dafür. Es gibt noch paar andere Dinge, die da mit rein sollen, insbesondere C++-Support. Wenn es ein ATmega88 ist, dann sollte -mmcu= auch auf atmega88 stehen, der ATmega48 hat nur halb so viel Speicher.
Gast
#176904
Ich habe schon den richtigen ausgewält - Es ist nur so, das ich auch die 48er verwende. Das mit dem Usart compilieren funktioniert jetzt. Ich müsste das Prog aber noch übertragen. Ponyprog kennt den Chip allerdings nicht.
Gast
#176905
Dann nimm doch kein Ponyprog. ;-) Was spricht gegen avrdude?
Gast
#176906
Prinzipiell nix, ich habs nur noch nie verwendet. Mal schaun....
Gast
#176907
Ich habe mit einem atmega8 experimentiert. Als Programmieradapter werwende ich den seriellen von Ponyprog. Mit diesem Programm funktioniert auch alles wunderbar. Aber wenn ich nun avrdude verwende kommt eine Fehlermeldung: makefile:34 unrecognized character: "M" Das ist die Zeile in der MCU = atmega8 steht.
Gast
#176908
Errm, was versuchst du denn mit dem Makefile und avrdude? Willst du avrdude das Makefile füttern? Das geht wohl nicht... Aber sorry, der pseudo-serielle Adapter von Ponyprog (bit-bang via RS-232) ist nun gerade so ziemlich der einzige Adapter, den avrdude nicht unterstützt. (uisp unterstützt ihn, aber ob das so weit gepflegt worden ist, dass es die neueren Controller schon kennt, weiß ich nicht.)
Gast
#176909
Ich füttere avrdude NICHT mit dem Makefile, sondern klicke nur auf "make Program" im Programmers Notepad. Der Ponyprogadapter funktionierte bislang immer wunderbar! Aber ich lasse mir gerne einen guten Schaltplan für einen seriellen Adapter empfehlen (Ich habe leider keine parallele Schnittstelle)
Gast
#176910
Ein guter Schaltplan für einen seriellen Adapter? STK500 oder AVRisp. ;-) Oder halt USBisp, falls du nur USB hast. (Welche Rechner gibt's eigentlich, die zwar eine serielle aber keine parallele Schnittstelle haben?) Man könnte sicher auch den seriellen Pingpong-Adapter dem avrdude beibringen, aber da müsste sich halt ,,jemand'' hinsetzen. Bei diesem ,jemand' muss es sich notgedrungen um eine natürliche Person handeln... Wenn dein make derartige Fehler meldet, hast du wohl irgendwas am Makefile verhunzt...
Gast
#176911
AVRisp klingt gut. Das originale Teil möchte ich mir aber nicht kaufen. Zahlreiche Laptops haben nur eine serielle schnittstelle, aber keine Parallele. Ich habe im Web einige Schaltpläne zu "AVRisp compatible" Adapter gefunden. Welchen kan man empfehlen? Funktioniert das Teil eigendlich auch mit den neuen Controllern?
Gast
#176912
Na komm, das AVRisp ist doch nun alles andere als zu teuer (für ein STK500 würde ich das Argument eher einsehen). Allein die Hälfte des Preises dürftest du fast für die Platine bezahlen, wenn du das selbst machen willst (als Einzelstück). Ich weiß nicht, was die Nachbauten so kosten sollen. Außerdem brauchst du noch eine Firmware dafür. Ich kann ansonsten Matthias Weissers USBisp wirklich empfehlen. Wenn du was selbst bauen willst, nimm das. Spricht STK500-Protokoll, Firmware ist Opensource.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.