AVR - Strings direkt aus Flash lesen

[Timm Thaler]

Ich hab das für mich jetzt anders gelöst: Ich nehm Ada.

Da sich bei FPC mit dem Read vom Progmem keine Lösung abzeichnet und auch im englischen Forum das Interesse eher gering scheint, hab ich mit mal AVR-Ada angesehen. Der erzeugte Code sieht sehr gut aus. Die Lady zickt zwar wegen jedem überflüssigen Leerzeichen rum, aber das Konzept an sich gefällt mir, kommt Pascal auch sehr nah. Inline-Assembler ist etwas umständlicher einzubauen.

Für mich ist der Zugriff auf den Flash essentiell: Displaystrings, Sensorkennlinien, Dimmerkennlinien, sowas wird immer direkt aus dem Flash geholt. Ein Workaround wäre noch, dass ich das im Inline-Assembler mache, aber ich bekomme die Adresse eines Strings im Flash nicht heraus, und damit kann ich den nicht ansprechen.

Schade, dass ich Ada nicht eher entdeckt habe, das klang immer so exotisch und nur für Spezialprojekte und sehr kompliziert, aber das schreibt sich genauso schnell runter wie Pascal und das Compilat ist durchaus sehenswert, nicht so ein Heckmeck wie bei C.

[kupferstecher]

Ich hab das für mich jetzt anders gelöst: Ich nehm Ada.

Hm, schade...
Es geht natuerlich nur weiter, wenns auch Nutzer gibt. Aber ich kann dich schon verstehen, man hat nicht das Gefuehl, als ob Target AVR ueberhaupt weiterentwickelt wird.

Hast du im englischen Forum mal ein Thema zum Flash-Daten Lesen gestartet?

Vielleicht funktioniert es mit Ressourcen?

[Mathias]

Es geht natuerlich nur weiter, wenns auch Nutzer gibt. Aber ich kann dich schon verstehen, man hat nicht das Gefuehl, als ob Target AVR ueberhaupt weiterentwickelt wird.

Aber immerhin kann man jetzt mit fpcupdelux relativ einfach den Cross-Compiler erzeugen, dies ist schon mal recht viel Wert.

Es geht natuerlich nur weiter, wenns auch Nutzer gibt

Wie soll es da viele Nutzer geben, wen Lazarus für Desktop-Apps schon sher wenig genutzt wird.
Hier im deutschen Forum hat es nicht mal 10 Nutzer, welche sich aktiv mit Lazarus beschäftigen.

[Timm Thaler]

Es geht natuerlich nur weiter, wenns auch Nutzer gibt. Aber ich kann dich schon verstehen, man hat nicht das Gefuehl, als ob Target AVR ueberhaupt weiterentwickelt wird.

Ich hab jahrelang ASM programmiert, was einerseits effizient den Controller nutzt und man kann jedes Bit einzeln begrüßen. Andererseits ist es sehr zeitaufwendig und fehlerträchtig, man kann stundenlang nach einem Fehler suchen und dann hat man nur ein ldi statt eines lds geschrieben...

Ich starte gerade eine neue Projektserie und hab die mit C angefangen. Damit werde ich gar nicht glücklich, die Syntax ist grauenhaft und das Compilat sieht mitunter dermaßen bescheiden aus. Wenn aus einem shl erstmal ein mpy gemacht wird...

Daher war ich ganz froh zu entdecken, dass Lazarus auch AVR embedded kann. Leider fehlen hier grundlegende Funktionen und meine bisherigen Versuche Infos zu bekommen, wie ich meine eigenen Kenntnisse mit AVRs und ASM einbringen kann verliefen auch im Sande. Ich hab einfach keine Lust hier ein größeres Projekt anzufangen und dann nach einem halben Jahr zu merken, dass ich ein totes Pferd reite.

AVR-Ada ist anscheinend auch eine One-Man-Show, aber da gibt es einen gut abgehangenen Standard und der Compiler ist zumindest für die bisherigen ATmegas anscheinend ausgereift. Und wie das mit neuen AVRs wird steht eh in den Sternen.

[kupferstecher]

Wie soll es da viele Nutzer geben, wen Lazarus für Desktop-Apps schon sher wenig genutzt wird.
Hier im deutschen Forum hat es nicht mal 10 Nutzer, welche sich aktiv mit Lazarus beschäftigen.

Lazarusnutzer gibt es schon viele, im Forum aktiv zu sein ist ja nochmal was anderes. Dazu kommt noch, dass das englische Forum gewissermassen eine Konkurrenz darstellt, anfangs habe ich nur dort gepostet.

Lazarus/Freepascal waere auf Mikrocontrollern eigentlich das ideale Konkurrenzprodukt zu C, es kommt nur noch nicht richtig in die Puschen...

[kupferstecher]

Ich hab einfach keine Lust hier ein größeres Projekt anzufangen und dann nach einem halben Jahr zu merken, dass ich ein totes Pferd reite.

Wie gesagt, ich versteh das gut.
Mir gehts ja ingesamt aehnlich, mit ASM auf AVR angefangen, spaeter hab ich mich mit dem STM32 in C versucht, grauenhaft...
Da ich Lazarus auf dem Desktop verwende, hab ich mir auch Target AVR und ARM angeschaut, aber richtige Projekte hab ich seither auch nicht gemacht. Zumindest gibts die Targets der beiden Controllerfamilien, die ich bisher verwendet habe

Vielleicht kannst du dich ja motivieren neben deinen Hauptprojekten nebenher (in welcher Sprache auch immer), dich noch ein bisschen mit Freepascal auf AVR zu beschaeftigen~ So viel - glaube ich - fehlt naemlich nicht mehr.

[Mathias]

So viel - glaube ich - fehlt naemlich nicht mehr.

Bis auf das Problem mit averdude, bin ich mit Lazarus ein Stück weiter gekommen, wie oben schon beschrieben erzeugt Lazarus immerhin schon eine HEX.

Lazarus/Freepascal waere auf Mikrocontrollern eigentlich das ideale Konkurrenzprodukt zu C, es kommt nur noch nicht richtig in die Puschen...

Ich denke, wen sich das durchsetzen würde, gäbe es sicher eine Arduino Freunde mehr. C ist so eine Müll-Sprache.
Da kann man stundenlang Fehlersuchen, nur weil C nicht mal 2 Integer richtig mutiplizieren kann.

spaeter hab ich mich mit dem STM32 in C versucht, grauenhaft...

So ein ST32 liegt bei mir auch auf dem Tisch, aber ausprobiert habe ich ihn noch nicht, fehlender Treiber unter Linux.

[Socke]

Edit: es gibt bereits einen Bug-Eintrag dazu: https://bugs.freepascal.org/view.php?id=32074

Der Bug-Eintrag wurde in den letzten Tagen nochmals diskutiert.
Florian Klämpfl hatte folgende Syntax vorgeschlagen:

Code: Alles auswählen

const
  a : string = '';section '.eeprom';
  b : string = '';section '.text';

@Timm Thaler: kannst du das überprüfen? Ich kenne mich (noch) nicht so gut mit Assembler aus. Ggf. hat der Compilerswitch {$J+/-} hier auch einen Einfluss.

[Mathias]

Florian Klämpfl hatte folgende Syntax vorgeschlagen:

Dies könnte man stark mit einer Stringkonstante verwechseln.

Diese Lösung würde ich eleganter finden:

Code: Alles auswählen

const
  MenuStr1 = 'Button1'; progmem;
  MCU_ID = 101; eeprom;

Oder etwas in dieser Art:

Code: Alles auswählen

const
  a : string = 'Hello';section:eeprom;
  b : string = 'World';section:text;

[Socke]

Florian Klämpfl hatte folgende Syntax vorgeschlagen:

Dies könnte man stark mit einer Stringkonstante verwechseln.

Die Strings '.eeprom' und '.text' werden direkt an den Assembler übergeben und sind daher konstant. Du kannst hier alles angeben, was dein Assembler unterstützt - was in der Regel abhängig vom Assembler und der Architektur ist.

Die Frage ist nicht, ob der Compiler das frisst (das tut er), sondern was er daraus macht.

[Mathias]

Die Strings '.eeprom' und '.text' werden direkt an den Assembler übergeben und sind daher konstant.

Jetzt blicke ich mehr durch, man sagt dem Compiler, er sollte noch ein ".text" hinter die Stringkonstante setzen ?

[siro]

Ich hab mal (gaaanz früher zu MS DOS Zeiten) mit TurboLoc gearbeitet.
damit habe ich Turbo Pascal Programme für ein Embedded System mit einem NEC V25 Prozessor geschrieben.
Das funktionierte ausgezeichnet. Ich find das leider nach so vielen Jahren nicht mehr, aber da habe ich
auch einiges getrickst. Tabellenwerte und Texte waren da auch ein Thema.

Da hatte ich dann zum Beispiel Proceudren geschrieben, die gar keine waren, dort lagen dann nur Werte in ASM Code abgelegt.
Das sah dann in etwa so aus:

Procedure Text1;
asm db $5,'Hallo' { Längenbyte und der Text selbst }
end;

In der Procedure befand sich also kein ausführbarer Code, sondern die Bytes des entsprechenden Textes oder der Tabelle.
Der Compiler musste dies ja im Codesegment ablegen.....

Mit einem Zeiger konnte ich nun darauf zugreifen, ohne dass irgend etwas in den Ram kopiert wurde.
Ich weis natürlich nicht ob das in ähnlicher Form in deinem Falle gehen würde.

[Timm Thaler]

Mit einem Zeiger konnte ich nun darauf zugreifen, ohne dass irgend etwas in den Ram kopiert wurde.

Der Knackpunkt ist halt herauszufinden, an welcher Speicherstelle der Compiler den Textstring ablegt. Auslesen kann man zur Not mit Inline-Assembler, aber man braucht die Speicheradresse.

Und dann muss man noch verhindern, dass der Compiler versucht den String in den Ram zu lesen, dieser ist sonst nämlich recht schnell voll.

[Socke]

Die Strings '.eeprom' und '.text' werden direkt an den Assembler übergeben und sind daher konstant.

Jetzt blicke ich mehr durch, man sagt dem Compiler, er sollte noch ein ".text" hinter die Stringkonstante setzen ?

Nein. Ein Programm wird in unterschiedliche Teile, sogenannte Sections, aufgeteilt.

• .text enthält die Prozessorbefehle (d.h. alle Prozeduren und Funktionen)
• .bss enthält uninitialisierte Variablen, deren benötigter Platz im Arbeitsspeicher reserviert wird
• .data enthält initialisierte Variablen, die im Flash abgelegt und bei Programmstart in den Arbeitsspeicher geladen werden
• .eeprom konstante Daten, die im Flash abgelegt, und erst bei Bedarf in den RAM geladen werden

Daneben gibt es noch weitere, spezielle Teile, siehe http://www.atmel.com/webdoc/avrlibcrefe ... tions.html

Aus dem Pascal-Code

Code: Alles auswählen

type
  TBuffer = array[0..16] of char;
const
  DEFAULT_BUFFER: TBuffer = 'MeinTextMeinText'; section '.eeprom';

Wird der - soweit ich das erkennen kann - korrekte Assembler-Code generiert

Code: Alles auswählen

# Begin asmlist al_typedconsts
.section .eeprom
TC_sPsPROJECT1_ss_DEFAULT_BUFFER:
	.byte	77
	.byte	101
	.byte	105
	.byte	110
	.byte	84
	.byte	101
	.byte	120
	.byte	116
	.byte	77
	.byte	101
	.byte	105
	.byte	110
	.byte	84
	.byte	101
	.byte	120
	.byte	116
	.byte	0
# [13] var
.Le11:
	.size	TC_sPsPROJECT1_ss_DEFAULT_BUFFER, .Le11 - TC_sPsPROJECT1_ss_DEFAULT_BUFFER
# End asmlist al_typedconsts

Aber im Programm wird wieder nur der Arbeitsspeicher ausgelesen.
Da ich - wie geschrieben - nicht so fest in Assembler bin, sollte hier nochmal jemand mit mehr Erfahrung einen Blick darauf werfen.

[siro]

Der Knackpunkt ist halt herauszufinden, an welcher Speicherstelle der Compiler den Textstring ablegt.

Code: Alles auswählen

procedure TextStr;
begin
  asm  db $5,'Hallo'   { Längenbyte und der Text selbst }
end;
 
procedure TForm1.FormCreate(Sender: TObject);
var p:^byte;
 
begin
  p:=pointer(@TextStr);
end;
 

An die Adresse der Procedure kommt man doch ran. Nur mit den Konstanten geht das wohl nicht.

Das "Begin" in der Pseudoprocedure konnte ich damals weglassen und gleich mit ASM beginnen, ansonsten wurde ein zusätzlicher Code
push bp
mov bp,sp
Code erzeugt. den muss man dann natürlich berücksichtigen.

-------------------------------------------
Ich hab das mit meinem PIC Assembler zum Beispiel so gemacht,
das sollte mit dem AVR auch möglich sein:

In dem Assemblerfile werden die Texte abgelegt:

Code: Alles auswählen

#define Product_Name	 "Mein Gerät"
#define Company_Name	 "Meine Firma, Berlin, Strasse"
#define	Software_Version "V1.03"
#define Software_Date	 "01.02.2017"
 
 
FLASH_CODE CODE_PACK   ; ist natürlich Assembler spezifisch beim AVR vermutlich [b].CESG[/b]
 
; ich hab die String hier mal 0 terminiert abgelegt
; das würde sicher auch mit length oder sizeOf und dem Längenbyte gehen
 
 
ProductName:
	db	Product_Name,0                 ; beim AVR[b] .db [/b] 
CompanyName:
	db	Company_Name,0
SoftwareVersion:
	db	Software_Version,0
SoftwareDate:
	db	Software_Date,0
DeviceIdentification:
 
; hier werden die Adressen nun veröffentlicht
; damit man später darauf zugreifen kann
; diese Konstanten müssen dann natürlich noch als "external" im Hauptprogramm definiert werden
 
  GLOBAL ProductName         ; beim AVR [b].GLOBAL[/b] ?
  GLOBAL CompanyName	
  GLOBAL SoftwareVersion
  GLOBAL SoftwareDate
 
  end
 
 

Nun kann man doch direkt auf die Namen bzw. dem Speicher zugreifen.