Hi, ich versuche verzweifelt ein Headerfile für den AT90can128 zu bekommen, welches ich in WinAVR bzw. mein Programm einbinden kann. Hat evtl. jemand so ein Headerfile oder weiß jemand wo man eines herbekommen kann ? Servus und vielen Dank für eure Hilfe. Christian Mayer
Du brauchst weit mehr als ein Headerfile: Compiler und Linker müssen den neuen -mmcu= ja auch verstehen lernen. Die Arbeit dafür wird gerade insgesamt erledigt. (Das Headerfile gibt's mittlerweile in der Tat bereits im CVS, aber s. o.: es wird Dir allein kaum was nützen.) So wie ich das verstanden habe, war es aber bisher weniger aufwendig, die komplette toolchain selbst neu zu compilieren, als an Muster dieser Gattung von Atmel heranzukommen. ;-)
Hätt ich vorher avrfreaks gelesen, hätte ich mir die Arbeit, eine Antwort zu schreiben, eigentlich auch sparen können. Du hast dort ja schon eine Antwort erhalten. Mehrfachpostings gelten als unhöflich, weil sie sinnlos Zeit bei den potentiellen Beantwortern binden -- das gilt bei einem derartigen Thema durchaus auch für mehrere verschiedene Foren, insbesondere da Du ja bereits eine recht erschöpfende Antwort (mit URL) bekommen hast.
Sorry Jörg! Kann ja nicht riechen, das es Leute gibt, die sich gleich in mehreren Foren aufhalten, drum habe ich in zwei Foren meine Frage versucht zu klären, um mehr Leute zu erreich. Nochmals sorry, und vielen Dank für Deine Antwort!!! Servus Christian!
Hi Jörg! Noch eine Frage, was meinst Du mit mmcu und CVS? Ich hätte vielleicht auch anmerken sollen, daß das mein erstes Projekt ist, und ich deshalb nicht wirklich viel Ahnung von der Materie habe. Servus Christian!
Nun, wenn Du Dich in mehreren Foren aufhälst, warum traust Du das nicht auch anderen zu? ;-)
Der ;-) von Dir beruhigt mich wieder etwas, es ist halt so, daß ich gerade Diplomarbeit schreibe und ich die Zeit im Nacken sitzen habe, drum hab ich halt in 2 Foren inseriert, bitte sag mir nun was mmcu und CVS sind ? Servus Christian !!!
Das solltest Du bei der Diplomarbeit aber langsam wissen, oder? ... -mmcu= ist die Compileroption, mit der man dem Compiler(-frontend) mitteilt, für welchen MCU-Type (microcontroller unit) man compiliert, also -mmcu=at90s8515 oder -mmcu=atmega128, oder eben -mmcu=at90can128. CVS ist das concurrent version system, das vermutlich meistverbreitetste Versionsverwaltungssystem. Damit werden u. a. auch die Quellen der avr-libc verwaltet. Ein Web-Frontend dafür findest Du hier: http://savannah.nongnu.org/cgi-bin/viewcvs/avr-libc/ Eine URL mit dem Bugreport für den Arbeitsstand der Implementierung hast Du ja bei AVRfreaks schon bekommen. Dort sollten sich auch Zeiger auf die Implementierungsdetails für GCC und Binutils befinden. Alles in allem wirst Du nicht umhin kommen, Dir diese Dinge selbst zu compilieren. Auf einem Unix dauert das keine Stunde. Auf Windows? Keine Ahnung. Keiner der aktiven Entwickler benutzt sowas...
Ich würde für ne Diplomarbeit nie einen so brandneuen Chip nehmen. Man weiß dann nie, ist es ein Hardware- oder Softwarefehler oder ist einfach nur der Chip buggy. Neue Chips werden heutzutage grundsätzlich nur als grüne Bananen ausgeliefert. Es finden sicher ja immer wieder genügend doofe Anwender, die brav ihre gefundenen Bugs zurückmelden. Wenn man also in Zeitdruck ist, ist ein brandneuer Chip das pure Gift für den Zeitplan. Zumindest solltest Du ihn nur bei max 8MHz betreiben, da manche Fehler erst bei hohen Frequenzen auftreten (siehe AVRFreaks: LPM-Bug). Peter
Vielen Dank Jörg ! Wenn Du mir jetzt noch sagst was ich wie und wo compilieren muß, dann bin ich zufrieden, denn wie schon oben angekratzt, das ist mein erstes Projekt, und ich war froh, als WinAVR überhaupt etwas gemacht hat, und nu soll ich irgendwas compilieren, ich hoffe Du kannst Dir vorstellen, daß ich da keinen Dunst habe was ich zu tun habe !!!! Servus Christian !!
Hi Peter! Danke für den Tip, leider ist der Chip (AT90Can128) ziemlich passend für meine Aufgabe, denn ich muß GPS Daten auf den CANbus schicken, ich hab auch ein Board von Microchip hier, jedoch habe ich da eine SPI Schnittstelle zusätzlich zwischen dem PIC16F876 (µController) und dem MCP2515 (CAN Controller). Servus Christian !!!
Nun, hast Du es denn schonmal mit RTFM probiert? Die avr-libc Doku solltest Du wenigstens mal gelesen haben -- die hat ein eigenes Kapitel darüber, wie man die Tools compiliert. Wie gesagt: auf Windows ist das alles entsprechend umständlicher, da Du Dir erstmal die Cygwin-Umgebung draufnageln mußt. Letztlich hast Du dann ein ,,Unix im Windows'', kannste auch gleich auf ein Unix gehen, das ist einfacher -- mit der Kommandozeile umgehen lernen mußt Du ohnehin, wenn Du den Kram compilieren willst. Das ist nicht alles ,,klickbar''. :-))
Sorry aber was ist RTFM? Und ich krieg hier nen Vogel, Peter hat da wohl was wares geschrieben, ich hau den Atmel kram bald in die Ecke und nehm das Microchip Board, da hacke ich dann meine Assemblercode rein und gut ist. Wie ist es eigentlich, wenn ich im AVRStudio 4.0X Assemblercode verwenden möchte (nur Assembler), da brauch ich doch auch eine AT90Can128.inc,oder sowas, gibt es sowas ? Servus Christian!!!
da gibt`s ne can128.def ist bei der aktuellen version von avr studio mit dabei. Trotzdem halte ich es für risikoreich mit einem chip zu entwickeln der noch nicht als serienprodukt verfügbar, und dessen liefertermin Q4/2004 bei atmel auch keiner verbindlich bestätigen möchte.
Aua Aua Aua Aua Aua Sag mal tut das auch beim Schreiben weh oder nur beim Lesen? Stefan
Ich kann mir nicht vorstellen, daß der AT90CAN128 sich grundsätzlich vom ATMega128 unterscheidet. Deshalb muß man doch nicht gleich den WINAVR neu compilieren Benenne doch einfach das iocan128.h in iom128.h um, damit die zusätzlichen Namen für die CAN-Register und die Interruptvektoren definiert sind und fertig. Peter P.S.: Ich verwende den T89C51CC01 als CAN-µC und bin sehr zufrieden damit. Ich programmiere mit einem älteren Keil C51 Compiler, der wußte auch noch nichts vom T89C51CC01. Ich hab dann nur das neue regcc01.h mit ins Include-Verzeichnis gestellt und fertig.
Er unterscheidet sich massiv :-( -- lies die iocan128.h im CVS einfach nach. RTFM -- Lies das Scheiß-Manual.
@Jörg, "Er unterscheidet sich massiv" ??? Also ich kann da keinerlei weitere Unterschiede erkennen. Für die Codeerzeugung (Instruction Set, Memory Map) sind sie 100% kompatibel. Man muß also nur die anderen IOs und Interrupts bekannt machen (s.o.). Ich hab das schon öfter so gemacht, daß ich, wenn der Compiler / Assembler den neuen Typ noch nicht kennt, einfach den nächst ähnlichen alten Namen nehme und hatte nie Probleme damit. Peter
wenn`s ja nur I/O und INT wären, dann wäre es ja recht einfach. Beim AT90CAN128 hat man aber gerade bei den Ports und Funktionsregistern eine Menge zwischen I/O-mapped und MEMORY-mapped verschoben. Um hier noch optimalen code zu generieren sind wohl noch einige veränderungen am compiler notwendig.
Nö, das kann der Compiler schon allein optimieren. Alle IO-Register werden erstmal als MMIO behandelt, der Optimizer kann dann ggf. ermitteln, ob der Zugriff via IO-Befehlen einfacher zu machen ist. Die Grenze, aber der MMIO Pflicht ist, kennt er ja. Meine Aussage mit ,,unterscheidet sich massiv'' bezog sich vielmehr darauf, daß der für den ATmega128 erzeugte Code aufgrund der vielen geänderten Register nicht binärkompatibel ist. Wenn man sowieso anfangen muß, an den Tools herumzuhacken, kann man's auch gleich richtig machen. Wir haben schließlich Opensource, /You/'ve got the source. Die Patches geistern im Internet herum. Man muß die Tools also wirklich nur mal schnell übersetzen. Das braucht keine halbe Stunde (zumal die avr-libc standardmäßig keine Doku baut -- die dafür benötigten Tools würden nochmal einen Rattenschwanz an abhängigen Werkzeugen mit sich bringen). Kann sein, daß das Aufsetzen eines Linux oder FreeBSD auf dem Rechner auch nochmal eine weitere Stunde dauert, aber danach hat man eine lauffähige Umgebung. (Wenn man unter Windows schon Cygwin drauf hat, sollte es dort aber auch nicht länger brauchen.)
"Man muß die Tools also wirklich nur mal schnell übersetzen." Wer, wie ich, ein komplett vorinstalliertes XP hat und daher dieses komplett löschen, neu partitionieren, neu installieren, alle Anwendungen neu installieren und einrichten und dazu Linux installieren und lernen müßte, für den dürftes dieses "nur mal schnell" schon gut einen Mann-Monat bedeuten. Da benenne ich doch viel lieber "nur mal schnell" um, solange bis das aktuelle WINAVR da ist. Aber ich sehe diese Gefahr noch lange nicht, da ich Chips erst dann nehme, wenn sie bereits einige Zeit in Produktionsstückzahlen gut verfügbar sind (aufgrund früherer schlechter Erfahrungen). Peter
Ich vermisse eine aktualisierte Version der EEPROM.H Bei der Migration vom mega128 auf den can128 muss ich mir jetzt für jeden Zugriff auf's EEprom Konstrukte drumherum basteln. Wann kommt eine neue WINAVR-Version?
> Ich vermisse eine aktualisierte Version der EEPROM.H Erstens eeprom.h (Kleinschreibung), zweitens suchst du wohl eher eine aktualisierte Fassung der entsprechenden Bibliothek, denn die ist dein eigentliches Problem. Du kannst dir nach Kai Klenovseks Anleitung (hat er hier schon gepostet) sofort und auf der Stelle eine avr-libc-1.2.5 compilieren und diese über die 1.2.3 von WinAVR drüberbügeln, wenn du willst. Mit dieser Version wurde das ,,EEPROM geht nicht auf einer Reihe von Controllern''-Problem repariert. > Wann kommt eine neue WINAVR-Version? Musst du Eric Weddington fragen. Aber besser nicht persönlich, da er dafür schon einen Thread aufgemacht hat: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=31546
>Wer, wie ich, ein komplett vorinstalliertes XP hat und daher dieses >komplett löschen, neu partitionieren, neu installieren, alle >Anwendungen neu installieren und einrichten und dazu Linux installieren >und lernen müßte, für den dürftes dieses "nur mal schnell" schon gut >einen Mann-Monat bedeuten. Warum klingest du nicht einfach beim netten Nachbarsjungen, der macht dir das in 1-2 Stunden, sofert du noch Platz auf der Festplatte hast. Man kann nämlich Windowspartitionen kleiner machen, dahinter Linux drauf (waren das jetzt 3 oder 5 Mausklicks? Weiss ich nicht mehr). Dann toolchain laut avr-libc Doku bauen (ca. 10-20 Minuten) und fertig ist es. Der Nachbarjunge erklärt dir dann noch die nötigsten Sachen und es kann schon losgehen. Für eine Windowsinstallation + Office + Mail einrichten brauch ich ungefähr gleichlang.
@Jörg Wunsch: Die Großschreibung hab ich zur Hervorhebung bewußt gewählt - ich versteh das schon richtig. Und ja, ich suche natürlich eine aktualisierte Bibliothek, denn am Header-File ändert sich bis auf die Warnings ja wohl nix.
Ich hab jetzt mal das inoffizielle Update über die alte Installation drüberkopiert. Nur nun wird allerdings gar kein at90can128 mehr als mcu akzeptiert und jegliches Kompilieren schlägt folglich fehl. Hab ich noch was vergessen? Was tun?
Zuerst pruefen, ob auf avr-gcc -dumpspecs | find "at90can128" etwas ausgegeben wird (...mcu=at90can128...). Wenn nicht, sind im "inoffiziellen Update" die gcc-Anpassungen fuer den CAN128 nicht enthalten.
Nöö, da kommt nix. Dann ist obiger Link leider kein wirkliches Update, schade. Auch mit dem Suchbegriff can kommt nix. Laut Ankündigung soll ja im Laufe des Monats ein neue Version des WINAVR rauskommen. Nun gut, dann werde ich da wohl selber einen Workaround schreiben.
Im letzten Update hat sich ein kleiner Fehler eingeschlichen der bei mir wegen MinGW und dem ganzen Geraffel nicht aufgefallen ist. Inoffizielle Updates für die "noch" aktuelle WinAVR Version werde ich aber nicht mehr machen, es sei denn es dauert noch mehr als ein Monat.
Hallo Kai, habe auch das Problem, daß ich die neue avr-libc 1.2.5 für das EEPROM des AT90CAN128 nutzen will. Jörg hat mir schon gesagt, daß du eine Anleitung zum Compilieren der LibSources hast, die ich dann über die alte 1.2.3 bügeln kann. Wo finde ich die? Dankeschön
Danke Kai, hab mir den Link angeschaut und kriege bei der Beschreibung (Unix-Welt und so...) ein ungutes Gefühl, ob das so easy geht. Eigentlich brauche ich momentan nur 3 Routinen "eeprom_read_block(), eeprom_write_block, eeprom_is_ready()". Es müßte doch klappen, die Sources aus der 1.2.5 zu nehmen und in die eigene Applikation zu packen. D.h. ich verwende keine fertigen Lib-Funktionen mehr und übersetze diese 3 kleinen Funktionen halt jedesmal mit - ok? Gibt's dabei noch was besonderes zu beachten, beim Aufruf, oder so? Wegen der neuen EE-Adressen 1F, 20 und 21? Vielleicht hat auch schon jemand eine übersetzte libc.a für diese 3 kleinen Funktionen, ich brauch ja nicht die ganze lib???? Danke Christian
> Eigentlich brauche ich momentan nur 3 Routinen "eeprom_read_block(), > eeprom_write_block, eeprom_is_ready()" Schreib dir die Funktionen doch erstmal selber. Müssen ja nur auf deiner Target MCU laufen und du kannst später wieder auf lib Funktionen umstellen, sobald die standardmäßig bei den avr-gcc Distris dabei sind.
> Es müßte doch klappen, die Sources aus der 1.2.5 zu nehmen und in > die eigene Applikation zu packen. Schlechter, als wenn du gleich die älteren Quellen (1.2.3 oder so) benutzt. Separat compilieren müsste eigentlich immer funktioniert haben, da ja dann die korrekten Definitionen für die EEPROM-IO-Register benutzt werden. Aber hatte Kai nicht auch 'ne Binärversion der 1.2.5 für Win32 auf seiner Webseite?
> hab mir den Link angeschaut und kriege bei der Beschreibung >(Unix-Welt > und so...) ein ungutes Gefühl, ob das so easy geht. Ein absolutes Hexenwerk ist das natürlich nicht, aber man sollte schon ein wenig Verständnis von Unix mit bringen dann sollte es in der Regel kein Problem sein. > Eigentlich brauche ich momentan nur 3 Routinen "eeprom_read_block(), > eeprom_write_block, eeprom_is_ready()". Es müßte doch klappen, die > Sources aus der 1.2.5 zu nehmen und in die eigene Applikation zu > packen. D.h. ich verwende keine fertigen Lib-Funktionen mehr und > übersetze diese 3 kleinen Funktionen halt jedesmal mit - ok? > Gibt's dabei noch was besonderes zu beachten, beim Aufruf, oder so? > Wegen der neuen EE-Adressen 1F, 20 und 21? So hab ich das persönlich noch nicht gemacht aber theoretisch sollte es kein Problem sein wenn Du die Assembler Files direkt in Deinen Code einbindest.
> Aber hatte Kai nicht auch 'ne Binärversion der 1.2.5 für Win32 auf > seiner Webseite? hab ich letzte Tage von der Seite runter genommen, da sich ein kleiner Bug eingeschlichen hat der bei mir mit MinGW auf der Platte nicht aufgefallen ist der beschränkt sich allerdings auf den AVR-GCC.
Danke Jungs, Jörg - meinst du mit den "älteren Quellen" die C-Sourcen der 1.2.3? War auch mein erster Gedanke, die alten Sourcen abzuändern aber die hab ich doch in meiner WinAVR-Distri gar nicht drin.
> Jörg - meinst du mit den "älteren Quellen" die C-Sourcen der 1.2.3? Ja. > War auch mein erster Gedanke, die alten Sourcen abzuändern aber die > hab ich doch in meiner WinAVR-Distri gar nicht drin. Du musst sie ja nicht einmal abändern, du musst sie nur mit dem richtigen -mmcu=at90can128 compilieren. Du kannst sie erstens bei avr-libc selbst bekommen und zweitens gab's wohl immer noch ein separates WinAVR-File mit allen Quellen (kann aber sein, dass das Eric beim letzten WinAVR dann nur noch durch die Hinweise auf die URLs der einzelnen Projekte ersetzt hat). Aber ansonsten ist das Selbstcompilieren einer avr-libc-1.2.5 auch nur eine Sache von wenigen Minuten. Am längsten wird es wohl dauern, bis du die nötigen MinGW/MSYS-Pakete auf deiner Kiste installiert bekommen hast.
> Du musst sie ja nicht einmal abändern, du musst sie nur mit dem
richtigen -mmcu=at90can128 compilieren.
Klingt gut, hab's aber noch nicht ganz gecheckt.
Sollen die entsprechenden eeprom.S,... Assemblerfiles mit dem Projekt
übersetzt werden?
Gib bitte nochmal 'nen Newbie-Tip...
> Sollen die entsprechenden eeprom.S,... Assemblerfiles mit dem > Projekt übersetzt werden? Ja.
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.