Keil C166, xhuge, huge

[clonephone82 (Gast)]

Hallo Zusammen,

Ich habe aktuell bei einem alten Projekt mit xc164 wieder ein TFR dummy 
Trap => Memory fault => ich vermute ein xhuge, huge Problem.

Ich muss zugeben das ich bei xhuge, huge und far nicht genau weis was 
ich da mache.

Die Erklärungen von Keil zu diesen Themen naja wann man dann aber 
welches braucht das ist für mich nicht klar.

Ist vielleicht noch jemand in diesem Forum, der sich noch mit dem alten 
Zeugs auskennt mir das vielleicht mal einfach erklären kann?

danke
mathias

[Sindelfingen (Gast)]

Wo ist das Programm?

Sonst, wie immer, Zeile 911.

[Peter D. (peda)]

Beschreibe doch erstmal das Problem.
Niemand kann in Deinen Kopf schauen.

Wo tritt der Fehler auf, beim Compilieren, Linken oder Ausführen?
Gibt es eine Fehlermeldung, dann copy&paste sie.
Enthält sie Filenamen, Zeilennummern, dann copy&paste die Zeilen in der 
Nähe.

clonephone82 schrieb:
> naja wann man dann aber
> welches braucht das ist für mich nicht klar.

Allgemein bedeutet huge, Dein Program enthält riesige Daten oder Code. 
Falls doch nicht, dann ist es Quatsch, das Huge Model zu verwenden oder 
Variablen als huge zu deklarieren.
Man nimmt immer das kleinste Model bzw. Datenformat, bei dem der 
Compiler/Linker noch keinen Fehler wirft.

[Steffen R. (steffen_rose)]

Peter Dannegger schrieb:
> Allgemein bedeutet huge, Dein Program enthält riesige Daten oder Code.

Wenn ich mich recht erinnere, benötigt man dies auch für Pointer, die 
außerhalb definierten 16k Pages zeigen.

[steht da doch so (Gast)]

Steffen Rose schrieb:
> Wenn ich mich recht erinnere

Falsch erinnert. ;-)

near: 16Bit mit 64k Adressbereich auf max. 16k Daten

far: 32Bit mit 256k Adressbereich auf max. 16k Daten

huge: 32Bit mit 16M Adressbereich auf max. 64k Daten

xhuge: 32Bit mit 16M Adressbereich auf max. 16M Daten

http://www.keil.com/support/man/docs/c166/c166_le_memtypes.htm

[Steffen R. (steffen_rose)]

far Datenpointer:
Wenn ich mich recht erinnere, wurde bei der Pointerarihtmetik nicht die 
Page erhöht. Genau dies sagt 'max. 16k Daten'.

Sollte im Normalfall nicht vorkommen, weil man ja auf definierte Daten 
zugreift. Und diese sind (bei far model) komplett innerhalb einer Page.


> Falsch erinnert. ;-)
Auch dies nur aus der Erinnerung und ggf. für eine ältere Version des 
C166 Compilers.

[steht da doch so (Gast)]

Steffen Rose schrieb:
> komplett innerhalb einer Page

Das ist das entscheidende bei far. Die referenzierten Daten dürfen 
nicht über eine Page-Grenze gehen.

aus http://www.keil.com/support/man/docs/c166/c166_le_far.htm
 "objects are limited to 16K and may not cross any n*(16K) page 
boundary, where n= {1,2,3,...)"

[clonephone82 (Gast)]

Hallo,

Vielen Dank euch allen.

@ Sindelfingen: Es geht nicht um einen Code es geht mir einfach 
allgemein darum es zu verstehen.

@steht da doch so
Das ist das entscheidende bei far. Die referenzierten Daten dürfen
nicht über eine Page-Grenze gehen.
=> ja ok und wie merk ich das ich habe das Gefühl das der Linker da 
überhaupt nicht meckert. Ich habe das schon alles gelesen aber eben 
lesen aber bei const daten habe ich halt Probleme denke ich und wie soll 
man das erkennen wenn der Linker einem nicht hilft? Hast du da ein Tipp?

@Peter: ja genau das dachte ich ja eben auch. Ich habe das Projekt mal 
geerbt als ich in der Firma wo ich bin angefangen habe. Leider musste 
ich auch immer wieder neue Sachen dazu bauen etc. Irgendwann ging dann 
der Speicher aus und dann fing ich an dies genau zu analysieren und 
dabei habe ich dann auch vom XLARGE Model auf HLARGE gewechselt weil ich 
eben auch gedacht habe das ich das nicht brauche. Dennoch habe ich noch 
2-3 xhuge im Code ohne diesen läuft es nicht - aber wieso ich diese 
dennoch brauche sehe ich noch nicht.

Der XC164 hat ja

2K Bytes Dual-port RAM for Register Sets and System Stack,
4K Bytes Data RAM Controlled by DMU,
Internal Instruction Memory Block (IMB) Controlled by PMU,
128K Bytes Program Flash, 4K Bytes RAM,

Kann es sein, dass wenn ich zum Beispiel im Flash ganz oben eine const 
struct abgelegt habe und ich diese irgendwo im Code verwenden möchte das 
ich dann ein xhuge brauche weil es ein kann das ich über die 64k hinaus 
komme? bei 128k flash?

Beim RAM kann ich ja nie Probleme haben weil ich ja nie und nimmer 64k 
habe. :-)


danke euch.

[clonephone82 (Gast)]

Hallo,

Also aktuell hier mal ein Beispiel wo ich nicht ohne XHUGE auskomme, es 
aber nicht verstehe.

#define XHUGE xhuge

typedef struct
{
  uint16_t mode; /*!< system info mode */
  uint16_t reset; /*!< system info reset */
  uint16_t dload; /*!< system info dload */
  uint16_t can_baudrate;
  uint16_t error;
  crc16_t crc; /*!< system info crc */
  byte_t infobits1; /*!< bits that can be used in the app */
  byte_t infobits2; /*!< bits that can be used in the app */
}hwinfo_t ;

// durch prama renameclass wird die sysinfo an den Anfang des RAM´s gelegt
// USER CLASS HWINFO die am anfang von 0xC000 liegt
#ifdef _KEIL
#pragma renameclass(xdata=hwinfo)
#pragma NOINIT
static hwinfo_t XHUGE hwinfo;
#pragma INIT
#endif // #ifdef _KEIL

err_t hwinfo_get_dload(uint16_t *data)
{
  memcpy(data, &hwinfo.dload, sizeof(uint16_t));
  return(ERROR_OK);
}

Wenn ich jezt das xhuge oben weglasse dann bekomme ich beim aufruf von 
hwinfo_get_dload nichts richtiges in data zurück. Aber wieso ich jetzt 
ein xhuge brauche eben kann mir das jemand erklären?

danke
sg
mathias

[clonephone82 (Gast)]

Hallo,

Kann mir da vielleicht jemand helfen?

sg
mathias

[Peter D. (peda)]

Siemens war schon immer sehr speziell.
Und daß sie an OTP festgehalten haben, wo andere schon jahrelang 
Flash-MC produzierten, hat nicht gerade zur Verbreitung beigetragen.

Ich kann Dir da nicht helfen. Wir setzen nur Atmel und NXP ein.

Zu meinen Fragen hast Du auch nicht geantwortet:
Beitrag "Re: Keil C166, xhuge, huge"

[wo ist er? (Gast)]

Dann zeige den Code, der nicht funktioniert.

[Steffen R. (steffen_rose)]

clonephone82 schrieb:
> memcpy(data, &hwinfo.dload, sizeof(uint16_t));

memcpy() arbeitet meiner Erinnerung nach im aktuellen Memory Modell.
Kommt aber evtl. drauf an, was Du linkst.

Schau mal, ob Dir xmemcpy() weiterhilft.

[Lucifer (Gast)]

Jedes Speichermodell hat eine passende Lib. Und die wird vom Linker 
eingebunden.

Die Frage ist eher, wie hier der Speicher verteilt wird. Renameclass, da 
sollte man wissen, was man tut.