Portierung IAR nach AVR-Studio 6

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).

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 
:-)

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.

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.

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)

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.

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.

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.

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.