www.mikrocontroller.net

Forum: Compiler & IDEs Compiler warning: cast from pointer to integer of different size


Autor: Alexxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte eine Peripherie- oder Speicheradresse den Xmega-DMA 
Adressregistern mit einer Funktion zuweisen:

void InitDmaChannel(DMA_CH_t channel, register8_t *source, register8_t 
*destination, register16_t BlockCnt, register8_t TrigSrc, bool forever)
{
...
  channel.SRCADDR0= (uint8_t)(((uint32_t)source)>>0);
  channel.SRCADDR1= (uint8_t)(((uint32_t)source)>>8);
  channel.SRCADDR2= (uint8_t)(((uint32_t)source)>>16);
...
}

ebenso...

Bsp:
DMA.CH0.SRCADDR0= (((uint32_t)(&Buffer))>>0*8) & 0xFF;
DMA.CH0.SRCADDR1= (((uint32_t)(&Buffer))>>1*8) & 0xFF;
DMA.CH0.SRCADDR2= (((uint32_t)(&Buffer))>>2*8) & 0xFF;

Aber auch mit dem gefundenen Beispiel (s.o.) gibt der Compiler die 
Warnung aus: "cast from pointer to integer of different size"

- Wie kann man das elegant schreiben, ohne dass Warnungen produziert 
werden?
- Das mit dem "& 0xFF" kann man doch besser mit einem cast uint8_t() 
machen?
- Sind nicht einige Klammern überflüssig?

Alexxx

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht uintptr_t statt uint32_t? Soweit ich das sehen kann, sind die 
Zeiger auf Xmega schließlich 24 und nicht 32 Bit breit. Die intptr_t und 
uintptr_t sind allerdings optional und deshalb nicht notwendigerweise 
definiert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unabhängig vom Problem kommt mir das komisch vor:
 DMA_CH_t channel
 channel.SRCADDR0= ...
denn damit modifizierst du einen struct Parameter, kein DMA-Register. 
Meinst du vielleicht
 DMA_CH_t *channel
 channel->SRCADDR0= ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Problem: Die Xmegas mögen wohl eine 24-Bit Datenadressierung 
beherrschen, aber ob das der GCC auch weiss? Ich vermute, dass der in 
alter AVR-Tradition auch bei den Xmegas Adressen nur 16-Bit breit 
versteht und ein Programmierer, der mehr als 64KB Datenadressen 
verwendet, ein Problem kriegt. Und daher vorsorglich darauf hingewiesen 
wird, dass ein Casten nach 32-Bit Integer einen Fehler enthalten könnte.

Autor: Alexxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die internen Adressen (und deshalb für mich) reichen wirklich 16-Bit 
aus.
Der Xmega kann aber 16MB externen RAM ansprechen!
wie wäre es mit einem far-pointer?

Alexx

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexxx schrieb:

> Der Xmega kann aber 16MB externen RAM ansprechen!
> wie wäre es mit einem far-pointer?

Soweit mir bekannt gibt es die im GCC nicht, d.h. nicht wirklich. GCC 
hat generell ziemliche Probleme, zwischen verschiedenen Sorten von 
Pointern (codespace, dataspace, short, near, far, ...) zu 
differenzieren.

Man kann daher mit Attributen zwar die Platzierung statischer Daten 
steuern, also riesige Arrays ins Flash oder einen erweiterten 
Datenadressraum legen, nicht aber Pointer so steuern, dass 
unterschiedlicher Code raus kommt. Siehe auch die Hacks und 
Laufzeitfunktionen statt Dereferenzierung für Daten im Flash.

Da landet man schlicht und einfach an den Grenzen des AVR-GCC.

Autor: Alexxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A. K.:
Du hast natürlich recht!

@ Alle
PS: die Fehlermeldung ist tatsächlich weg, wenn man...

  channel->SRCADDR0= (uint8_t)(((uint16_t)source)>>0);
  channel->SRCADDR1= (uint8_t)(((uint16_t)source)>>8);
  channel->SRCADDR2= 0;

schreibt.

Danke für eure Hilfe.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wie wäre es mit einem far-pointer?

Der gcc kennt nur eine Sorte Pointer. Ob die nun 16, 24, oder 32Bit 
gross sind das koennte man beim implementieren des Codegenerators 
festlegen.

Die einfachste Loesung ist nun immer einen moeglichst grossen Pointer zu 
nehmen. Leider blaeht das aber den Code deutlich auf und macht ihn 
langsamer. Das will man also auch nicht.

Beim M16C wird das geloest indem nur 16Bit Pointer genutzt werden, und 
fuer Spruenge auf Funktionen eine Tabelle angelegt wird die dann 
ueberrall hin springen kann. Natuerlich auch nicht die beste Loesung.

Da ist es wohl ein Nachteil das der gcc hauptsaechlich fuer dicke CPUs 
entwickelt wird und man Microcontoller nicht so wichtig nimmt.

Olaf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.