ATMega88 Umwandlung IAR -> GCC

[Jan (Gast)]

Hallo zusammen

Ich würde gerne das Programm zur Brushless-DC Motoransteuerung von der 
Atmel-Seite auf meinen Mega88 laden. (Datei AVR447 
http://www.atmel.com/products/AVR/mc/)

Allerdings hänge ich gerade bei der Umwandlung der IAR-Befehle in 
gcc-Befehle.

Wie müsste die folgende Zeile für den GCC aussehen?

__flash const uint8_t sineTable[SINE_TABLE_LENGTH * 3] = {
.
.(hier stehen die Tabellendaten)
.
.

Wenn ich die zu

uint8_t sineTable[SINE_TABLE_LENGTH * 3] PROGMEM = {

umforme, erscheint die Fehlermeldung

error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'

Wie müsste der Code richtig aussehen?

Ich arbeite mit AVR Studio 4.13 und der aktuellsten WinAVR (müsste 
Januar07 sein)

[Jan P. (fire)]

Der Beitrag ist von mir, hatte vergessen mich einzuloggen.

[Karl H. (kbuchegg)]

Du hast den

#include <avr/pgmspace.h>

vergessen

[Jan P. (fire)]

Danke, das hat soweit geklappt

Nun hab ich noch eine Stelle gefunden, für die ich einfach keinen 
entsprechenden gcc-Befehl finde

__io volatile PMSMflags_t fastFlags @0x1e;

Wie müss ich das "umbauen"?

[Karl H. (kbuchegg)]

was das __io da vorne macht, weiss ich nicht.
Das @ könnte man so erreichen:

volatile PMSMflags_t* const fastFlags = (volatile PMSMflags_t*)0x1e;

und dann die Zugriffe anstatt

   fastFlags = 5;

ändern in

   *fastFlags = 5;

Auf Deutsch: anstatt den Compiler zu veranlassen, dass er
eine Variable auf eine bestimmte Speicheradresse legt, einen
Pointer vereinbaren, der die Adresse enthält und alle
Zugriffe über diesen Pointer führen.

Wird der Pointer selbst const gemacht, stehen die Chancen
gut, dass der Compiler die Pointervariable bei der
Optimierung los wird und der Code auch nicht schlechter
als beim Original ist.

Allerdings würde ich mir mal ganz genau ansehen, was da
eigentlich mit diesem ominösen 'fastFlags' gemacht wird,
bzw. welchem AVR Register das 0x1E entspricht und entweder
* nach einem Workaround mit 'offiziellen' gcc Register-Bezeichnungen
  suchen
* den Code umschreiben, so dass das fastFlags nicht mehr gebraucht
  wird. Dazu muesste man allerdings zunächst mal ergründen
  was denn fastFlags macht, erst dann kann man entscheiden
  ob man das umschreiben kann.

[Jan P. (fire)]

PSMflags ist ein selbst erstellter Datentyp

00253 typedef struct PMSMflags
00254 {
00255   uint8_t motorStopped : 1;     
00256   uint8_t motorSynchronized: 1; 
00257   uint8_t actualDirection : 2;  
00258   uint8_t desiredDirection : 1; 
00259   uint8_t driveWaveform : 2;    
00260 } PMSMflags_t;

fastflags ist nur eine Variable vom Typ PSMflags.

PSMflags beinhaltet den aktuellen Zustand des Motors.

(Motor gestoppt ja/nein, welche Drehrichtung usw.)

Hier ist die Beschreibung zur __io- Zeile

/*! \brief Motor control flags placed in I/O space for fast access.
 *
 *  This variable contains all the flags used for motor control.
 *  It is placed in GPIOR0 register, which allows usage of several
 *  fast bit manipulation/branch instructions.

[Joerg X. (Gast)]

an der Adresse 0x1e befindet sich bei den Atmegax8 das GPIO0, also 
eine,als I/O-Register "getarnte" Speicherzelle. Um nicht zuviel zu 
verändern müßte man den Zugriff darauf nach "PMSMFlags" casten, oder?
hth. -Jörg

[Karl H. (kbuchegg)]

Joerg X. wrote:
> an der Adresse 0x1e befindet sich bei den Atmegax8 das GPIO0, also
> eine,als I/O-Register "getarnte" Speicherzelle. Um nicht zuviel zu
> verändern müßte man den Zugriff darauf nach "PMSMFlags" casten, oder?
> hth. -Jörg

Ah. Das wusste ich nicht.

Na dann würde ich das doch glatt so machen:

#define  fastFlags  (*((volatile PMSMflags_t*)(&GPIO0)))

das müsste auf dasselbe hinauslaufen.

[Joerg X. (Gast)]

Ich hab 0x1e auch bloß im Datasheet nachgeschaut (hab den mega48 hier)
hmm, Ich seh gerade, dass das eine I/O Adresse ist (deshalb vermutlich 
das _IO im code oben), keine RAM-Adresse (das wäre ZL bzw. R30 :( ), 
also vermutlich besser 0x1e + 0x20 = 0x3e beim GCC benutzen, sorry falls 
ich verwirrung gestiftet haben sollte

-hth, Jörg

[Jan P. (fire)]

Das 0x1e Register wurde ja extra gewählt, da dort wohl ein schnellerer 
Zugriff drauf möglich ist. (Siehe verlinktes Atmel-Dokument im ersten 
Post)