Hallo Experten, ich versuche gerade einen bestehenden Quellcode von einem Mega88 vom IAR-Compiler zum AVR-Studio 6 zu portieren dabei komme ich nicht wirklich weiter. ist die Portierung so korrekt? #define __no_operation() #asm("nop") #define __enable_interrupt() #asm("sei") #define __disable_interrrupt() #asm("cli") #define __watchdog_reset() #asm("wdr") wie ist es bei dem Flashbefehl : __flash const unsigned char ucTastenKombi[ANZAHL_TASTEN_KOMBI] = { TASTE_GERICHTET, TASTE_PLUS, TASTE_MINUS, TASTE_POLFILTER, TASTE_AUS, TASTE_AUS|TASTE_GERICHTET|TASTE_MINUS, TASTE_AUS, TASTE_AUS|TASTE_POLFILTER|TASTE_PLUS }; geändert für Atmel studio in: const unsigned char ucTastenKombi[ANZAHL_TASTEN_KOMBI] PROGMEM= { TASTE_GERICHTET, TASTE_PLUS, TASTE_MINUS, TASTE_POLFILTER, TASTE_AUS, TASTE_AUS|TASTE_GERICHTET|TASTE_MINUS, TASTE_AUS, TASTE_AUS|TASTE_POLFILTER|TASTE_PLUS }; zudem kann ich hiermit gar nichts anfangen es wird ein interrupt für die ganze Fuktion angelegt? #pragma vector = TIMER2_COMPA_vect // Interruptvektor für Timer0 __interrupt void isr_timer ( void ){ ist die Portierung si korrekt: #pragma vector = TIM2_COMPA// Interruptvektor für Timer0 __interrupt void isr_timer ( void ){ was mach ich mit __interrupt? wäre schön wenn mir ein Experte vom AVR-Studio ein Tipp gibt. Gibt es irgendwo in der Doku vom AVR-Studio eine Liste mit den Key-Befehlen? Bin gespannt auf euere Antworten!!
Texas schrieb: > #define __no_operation() #asm("nop") #asm --> _asm_ __volatile > wie ist es bei dem Flashbefehl : > > __flash const unsigned char ucTastenKombi[ANZAHL_TASTEN_KOMBI] = { __flash kann bleiben, es wird von allen aktuellen Versionen (4.7+) von avr-gcc verstanden. > geändert für Atmel studio in: > > const unsigned char ucTastenKombi[ANZAHL_TASTEN_KOMBI] PROGMEM= { PROGMEM regelt nur die Ablage aber im Gegensatz zu __flash nicht den Zugriff --> mit PROGMEM sind pgm_read-Funktionen oder memcopy_P zum Zugreifen erforderlich. > #pragma vector = TIMER2_COMPA_vect // Interruptvektor für Timer0 > __interrupt void isr_timer ( void ){ --> ISR (TIMER2_COMPA_vect) { /* code */ } > wäre schön wenn mir ein Experte vom AVR-Studio ein Tipp gibt. Hat mit AVR-Studio nix zu tun sondern nur mit den AVR-Tools (avr-gcc, Binutils und AVR-LibC).
Hey Johann L., danke für die schnelle Antwort ! Warum muss ich den Inline-Assambler mit volatile versehen wird es sonst weg optimiert von dem compiler? mit dem __flash befehl bekomme ich folgende Fehlermeldung Error 1 expected '=', ',', ';', 'asm' or '__attribute__' before 'const' TIMER2 ist komischer weise nicht bekannt habe den Interrupt_vector auf ISR (TIM2_COMPA_vect){ ... } geändert. Hast du noch ne Idee=? Gibt es eine Liste mit Keywörtern für AVR?
Texas schrieb: > Warum muss ich den Inline-Assambler mit volatile versehen wird es sonst > weg optimiert von dem compiler? Wenn das asm argumente hat, ja. Bei argumentloasen asm ist das volatile implizit > mit dem __flash befehl bekomme ich folgende Fehlermeldung Die Compilerversion muss stimmen wie gesagt, ansonsten brauchst du das alte PROGMEM + pgm_read. "avr-gcc --version" zeigt die Version an. Außerdem brauchst du GNU-C99, d.h. Option -std=gnu99. > TIMER2 ist komischer weise nicht bekannt habe den Interrupt_vector auf > > ISR (TIM2_COMPA_vect){ > ... > } > > geändert. > > Hast du noch ne Idee=? > > Gibt es eine Liste mit Keywörtern für AVR? Die AVR-LibC ist da manchmal etwas eigen, da hilft in die Header zu schauen. Mit -H sieht du, welche includiert werden und ein grep _vect *.h fischt die bekannten ISR-Namen raus. Ist hausbacken aber erprobt :-)
Johann L. schrieb: > Texas schrieb: > > > Die Compilerversion muss stimmen wie gesagt, ansonsten brauchst du das > alte PROGMEM + pgm_read. "avr-gcc --version" zeigt die Version an. > Außerdem brauchst du GNU-C99, d.h. Option -std=gnu99. >>jetzt eine doofe Frage wo geb ich die befehle ein im command window gehts nicht ? > ###ich habe die alle neueste version von AVR-Studio 6 da muss doch auch der Compiler aktuell sein oder? ich habe einen weg gefunden wie ich __flash deklariere __flash; meckert zumindest nicht mehr beim compilieren aber funktioniert es auch so ?####
Wenn du es selbst machen willst ist das eine schöne Übung ;) Wenn du das Rad nicht neu erfinden willst gib mal bei google "avr compiler ext:h" ohne Anführungszeichen ein und such dir das schönste aus.
Johann L. schrieb: > Die AVR-LibC ist da manchmal etwas eigen Sie orientiert sich (relativ strikt, da automatisch generiert) an den Namen, wie sie im Datenblatt stehen. Leider sind die verschiedenen AVRs da untereinander nicht konsistent. Was bei einem AVR ein TIMER1_OVF_vect ist, kann bei einem anderen schon mal TMR1_OVF_vect sein.
wie ist es nun korrekt definiert so #define __no_operation() asm volatile("nop"::) oder doch #define __no_operation() _asm_ volatile("nop") so? und noch mal zu dem __flash befehl ist es korrekt den mit ; abzuschließen? __flash; __flash; const unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI]= { 20, 20, 20, 20, 20, 2000, 2000, 2000 };
nein ist nicht korrekt. __flash ist ein Qualifier, so wie const oder volatile Die komplette Variablendefinition lauten in einem Stück zum Beispiel
1 | const __flash uint8_t xyz = 5; |
Schau halt im AVR-GCC-Tutorial nach. Da gibt es einen Abschnitt darüber, wie man auf den Flash Speicher zugreift und welche Möglichkeiten es da gibt.
Texas schrieb: > #define __no_operation() asm volatile("nop"::) > oder doch #define __no_operation() asm volatile("nop") so? Das hängt von deinen Compilereinstellungen ab. "asm" ist ein Bezeichner, der normalerweise zum /application namespace/ gehört, d. h. den darfst du eigentlich in deinem Code als Namen bspw. für eine Variable benutzen. Wenn du den Compiler auf strikte Standard-Kompatibilität stellst (-std=c89 oder -std=c99), dann geht das auch. Folglich wird es in diesen Einstellungen nicht als Schlüsselwort erkannt. Damit man trotzdem den inline-Assembler unabhängig von den Compilereinstellungen benutzen kann, kann man derartige Schlüsselwörter in ein Paar doppelter Unterstriche einfassen, also
1 | __asm__
|
Dann werden sie immer in ihrer Sonderbedeutung erkannt, denn ein solcher Name gehört zum implementation namespace, d. h. der Compiler (oder die Standardbibliothek) sind frei, ihn für eine Sonderbedeutung zu benutzen.
muss ich irgendeine Bibliothek zusätzlich einbinden für __flash? hab es jetzt so eingebunden im AVR-Studio 6 aber erlegt es nicht im Flash speicher ab... const __flash; unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI] = { 20, 20, 20, 20, 20, 2000, 2000, 2000 };
Texas schrieb: > const __flash; unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI] = { wenn du es wirklich so stehen hast dann sind das 2 Anweisungen const __flash; unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI] = {}; damit ist klar das es nicht imi flash landen kann.
wie müsste es denn richtig heißen so ? const __flash unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI] = { 20, 20, 20, 20, 20, 2000, 2000, 2000 };
Texas schrieb: > wie müsste es denn richtig heißen so ? Das ist richtig. Wenn dein Compiler das nicht mag, dann liegt das daran, dass wie Johann weiter oben schon gesagt hat, bzw. es auch im Tutorial steht, dein Compiler zu alt ist, bzw. die GNU-C99 Option nicht gesetzt ist (-std=gnu99)
es ist aber c99 konform gesetzt oder gibs eine andere funktion beim Avr-studio 6 wo ich das setzen muss?
Texas schrieb: > es ist aber c99 konform gesetzt Schau dir deinen Screenshot nochmals genau an, Buchstabe für Buchstabe... Oliver
Texas schrieb: > ich habe die alle neueste version von AVR-Studio 6 da muss doch auch der > Compiler aktuell sein oder? Warum muss da was aktuell sein? Hängt alles davon ab, was Atmel da gerade fertig hatte dafür. Solange du nicht einmal den Compiler mit der Option -v von Hand gestartet hast, ist einfach nicht sicher, ob er neu genug ist dafür. Meiner Erinnerung nach sind die bei Atmel Studio mitgelieferten Toolchains erst ab Version 6.1 (ist die noch Beta oder nicht?) beim GCC 4.7.x angekommen.
ich hab jetzt die "redseligkeit" vom compiler verändert siehe screenshot trozdem folgende Fehlermeldung: Fehler 1 expected '=', ',', ';', 'asm' or '__attribute__' before 'unsigned' const __flash unsigned int uiTastenTimer[ANZAHL_TASTEN_KOMBI] = { 20, 20, 20, 20, 20, 2000, 2000, 2000 }; kann doch nicht so schwer sein den Befehl __flash zu portieren... gibs da noch ne möglichkeit?
Texas schrieb: > ich hab jetzt die "redseligkeit" vom compiler verändert siehe screenshot und was plappert der über seine Compilerversion aus? Wenns 4.7+ ist, kennt der flash, siehe oben und in der gcc-Doku. Wenn es kein 4.7er ist, hast du Pech. Dann geht es nur über PROGMEN und Umbau aller Zugriffe auf die flash-Ausleseroutinen. Allerdings gibt es ja inzwischen auch ein AtmelStudio 6.1 mit aktuellerem Compiler. Oliver
Texas schrieb: > Fehler 1 expected '=', ',', ';', 'asm' or '__attribute__' before > 'unsigned' Deutliches Zeichen, dass __flash nicht implementiert ist. > kann doch nicht so schwer sein den Befehl __flash zu portieren... gibs > da noch ne möglichkeit? „nicht so schwer“ ist da relativ … Du tust dich ja schon schwer, dir einen Compiler mit passender Version zu installieren, da solltest du mit derartigen Aussagen wohl ein wenig vorsichtiger sein.
Erstmal sorry für den aufgewärmten Thread, aber ich denke mein Problem passt hier sehr gut aus Ergänzung. Gibt es eine Möglichkeit __eeprom von IAR nach AtmelStudio zu portieren? __flash klappt ja wunderbar.
Meines Wissens: nein. Zumindest ist nichts vorgesehen. Man könnte sich natürlich mit entsprechenden Sections was bauen, aber lohnt das wirklich? Soviele EEPROM Zugriffe hat man ja normalerweise nicht im Code und wenn doch, dann konzentriert man die eben in ein paar wenigen Funktionen. Und dann denn im http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial beschriebeenen EEMEM Mechanismus verwenden.
Schade, wäre ja auch zu einfach gewesen. Karl Heinz schrieb: > Soviele EEPROM Zugriffe hat man ja normalerweise nicht im Code Suche nach "__eeprom" in meinem Projekt ergab 183 Treffer :( Das wird spassig alles händisch mit dem EEMEM Mechanismus zu versehen... Gibt es evtl. einen anderen Weg, der schneller zum Ziel führt?
ggast schrieb: > Suche nach "__eeprom" in meinem Projekt ergab 183 Treffer :( Das muss noch nichts heißen. > Das wird spassig alles händisch mit dem EEMEM Mechanismus zu versehen... Ist doch eh immer nach dem gleichen Muster aufgebaut. Ausserdem ist mit 183 mal __eeprom im Code noch lange nicht gesagt, dass da auch entsprechend viele Zugriffe damit verbunden sind.
Bitte 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.