C Lauftschrift auf einem LCD 2 x 20

Aber wieso übergibt man nochmal die Adresse? Müsste die nicht bekannt sein Dank des Parameters vom Aufruf?

Irgendwie musst du dir ja die einzelnen Zeichen holen. Der String ist ein char Array, ich hole mir also die Adresse (&) von den einzelnen Elementen s[len] mit len = 0..
und übergebe diese pgm_read_byte
pgm_read_byte(&s[len])

Bei einem String im sram, hätte ich sofort mit
s[len]
die einzelnen Elemente.
Es würde dann so aussehen


CodeBox C
uint8_t len = 0;
while (s[len] != 0) len++;

Dafür gibt es aber auch strlen(s);
 
Könnte ich rein theoretisch mit & das Zeichen auch aus dem sram abholen? So wie jetzt halt nur aus dem sram?
 
Könnte ich rein theoretisch mit & das Zeichen auch aus dem sram abholen? So wie jetzt halt nur aus dem sram?

& ist der Address-of-operator, dadurch erhältst du die Adresse. pgm_read_byte erwartet als Argument eine Adresse, deswegen nutzt man es hier.
 
Das beantwortet seine Frage nicht, ich denke schon, daß er das so verstanden hat.

Genau genommen müßte "s[len]" genau dasselbe machen. Die AVR haben SRAM, also Static RAM. Jede Zelle hat 'ne fixe Adresse. Legst Du da einen String ab, landen die Zeichen ab irgendeiner Adresse beginnend im SRAM, die Variable (die's nur für den Compiler bzw Dich gibt) ist in Wirklichkeit die Startadresse. "s[len]" liefert Dir den Inhalt der Speicherzelle von Adresse (Start+len).

Ob's in C 'n Befehl gibt, der den Inhalt einer beliebigen SRAM-Zelle liefert, kann ich Dir nicht sagen (dann hätteste mit "&s(len)" die Adresse) - in Assembler wäre es "load" (entweder mit direkter Angabe einer konstanten Adresse: LDS (Load from Data Space), oder indirekt mit der Adresse in einem Doppelregister: LD (Load indirect from Data Space to Register using index XYZ)).

Nebenfrage an @Dirk : funktioniert "pgm_read_byte" auch auf TPI-Tinies (bzw auf Tinies die zwar LPM nicht kennen, aber den Flash wie SRAM lesen können (da der remapped ist))?

Als ASM-ler nutzt man einfach "ld", wie wäre das in C?
 
Das beantwortet seine Frage nicht, ich denke schon, daß er das so verstanden hat.

Ich weiß, dass es seine Frage nicht direkt beantwortet. Eigentlich wollte ich schreiben, dass ich es nicht verstehe, wobei ich die Frage ja verstehe. :confused:

Wenn man sofort auf den Inhalt der Variable zugreifen kann, man aber gerne erst mal die Adresse der Variablen herausfinden und dann wieder den Ihnalt der Adresse ermitteln möchte, kann man das sicherlich tun. Man wendet hier den Address-of-operator & und dereferenziert den Pointer durch *. Im Moment ein bisschen wie "Kann ich auch von der Beifahrerseite in mein Auto einsteigen und auf den Fahrersitz krabbeln und losfahren? Ich stehe zwar an der Fahrerseite, aber ich möchte es nur mal wissen!" Da weiß ich nicht genau, was ich antworten soll. :)

Hier mal bei den Grundlagen lesen, da wird erklärt, wie man auf den Inhalt einer beliebigen Adresse kommt.
http://www.c4learn.com/index/pointer-c-programming/

Ob's in C 'n Befehl gibt, der den Inhalt einer beliebigen SRAM-Zelle liefert, kann ich Dir nicht sagen (dann hätteste mit "&s(len)" die Adresse) - in Assembler wäre es "load" (entweder mit direkter Angabe einer konstanten Adresse: LDS (Load from Data Space), oder indirekt mit der Adresse in einem Doppelregister: LD (Load indirect from Data Space to Register using index XYZ)).

In C ist x, y, z Register oder LD, LDS ... Instruction erst man unwichtig. Der Compiler kümmert sich um alles, ich muss davon nichts wissen. Das was man ggf. bei Daten im Flash wissen sollte, ob die Daten im unteren Bereich oder im Oberen Bereich des Flash liegen. Im oberen Bereich wird mit long Adresse zugegriffen, hier gibts sowas wie pgm_read_byte_far (ELPM). Damit die Daten definiert abgelegt werden, kann man eine section erzeugen, die entweder unten oder oben liegt.

Nebenfrage an @Dirk : funktioniert "pgm_read_byte" auch auf TPI-Tinies (bzw auf Tinies die zwar LPM nicht kennen, aber den Flash wie SRAM lesen können (da der remapped ist))?

Als ASM-ler nutzt man einfach "ld", wie wäre das in C?

Hier bin ich im Moment überfragt. Ich kann das aber bei Gelegenheit mal nachschauen.

Dirk :ciao:
 
Mach Dir keine Umstände, das ist für MICH nur "'n Blick von der Rückbank aus", hab mich deswegen extra in den Kofferraum gesetzt.
Ich hätte übrigens was wie von hinten durch die Brust ins Auge geschrieben - aber ich will ja solche Sachen auch generell verstehen. Also ob irgendwas auch so gehen würde, auch wenns Quatsch ist...
 
:offtopic:
Nebenfrage an @Dirk : funktioniert "pgm_read_byte" auch auf TPI-Tinies (bzw auf Tinies die zwar LPM nicht kennen, aber den Flash wie SRAM lesen können (da der remapped ist))?

Als ASM-ler nutzt man einfach "ld", wie wäre das in C?

Ich habe einmal nachgeschaut. Der obere Code mit Flash Zugriff, sollte auch auf einem kleinen Tiny genauso laufen, der Compiler passt es der anderen Architektur an, man muss sich also nicht darum kümmern.

Dies macht der Compiler, wenn man pgm_read_byte beim Tiny nutzt (Inline Assembler)
ld mit z-Register zum indirekten Adressieren.


CodeBox C
#define pgm_read_byte(address_short)  pgm_read_byte_near(address_short)
// ...
#define pgm_read_byte_near(address_short) __LPM((uint16_t)(address_short))
// ...
#define __LPM(addr)  __LPM_tiny__(addr)
// ...
#define __LPM_tiny__(addr)  \
(__extension__({  \
  uint16_t __addr16 = (uint16_t)(addr) + __AVR_TINY_PM_BASE_ADDRESS__; \
  uint8_t __result;  \
  __asm__  \
  (  \
  "ld %0, z" "\n\t"  \
  : "=r" (__result)  \
  : "z" (__addr16)  \
  );  \
  __result;  \
}))
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)