Platzsparende Byte-Konstanten definition in Strings

Äh... was ist das Problem?

Brauchst du sowas?

1

#define MY_CONST 0x42

2

#define CONST_2_STRING(a) "a"

3

4

int main ()

5

{

6

  const char * teststring = "0x42 is stored as " CONST_2_STRING(a) " END";

7

  printf("%s",teststring);

8

9

  return 0;

10

}

Genau so ist es- im Flash soll direkt eine "0x41" stehen - also ein 
einzelnes byte (innerhalb eines strings).
Genau dies meinte ich mit "im text wird dann ein "B" angezeigt - d.h. im 
Flash steht das Zeichen 0x41 = 65 = ASCII B)

Dieses "Byte" möchte ich vorher als Zahl definieren können (z.b. mit 
defines (1<<x> einzelne Flags setzen können usw...)
es wäre mit dem beschriebenen Makro kein Problem, die Zahl als 
"dezimalzahl" abzuspeichern und später auszuwerten, doch mir geht es 
wiegesagt um eine platzsparende (binäre) Variante.

Wozu ich dies brauche:
Ich möchte eine sehr platzsparende und ressourcen (RAM) schonende 
Alternative für eigene Projekte zum Textparsing entwickeln -  die sache 
funktioniert in etwa so, daß es im System eine definierte Liste von 
Variablen gibt, bereits per "formatstring" der index eines bestimmten 
Elements angegeben werden kann (inclusive Formatierung), sodaß der Wert 
dann geparsed werden kann.
Vorteil zu sscanf:  weniger Overhead beim Aufruf (ich übergebe meinem 
"parser" nur eine "anweisungsdatei" und er füllt selbstständig eine 
liste mit variablen, die ich vorher im System angelegt habe.

Zudem muß ich beispielsweise keine Gleitkommazahlen implementieren, da 
ich mit Festkomma arbeite usw.. (-> platzsparende Libary,  mehr Flash 
übrig für Programmcode :-) )


Soweit meine Idee - leider wäre sie ohne die Möglichkeit im Text mit 
"binären" Daten zu arbeiten ziemlich uneffizient.

Ich weiß das Thema ist nicht einfach - arbeite selbst seit ca 8 Jahren 
im Bereich embedded systems - und habe einige Jahre AVR Erfahrung 
sammeln dürfen. Daher hoffe ich sehr auf Hilfe irgendeines C-Gurus bzw. 
einfach eines ehrgeizigen Geistes, der sich dieses Problems mal annimmt.
In Assembler würde mir dies weniger Kopfzerbrechen bereiten, doch möchte 
ich die Strings gern effizient in "C" (C++) integrieren - und da klappen 
.BYTE Anweisungen halt nicht ;-)

Wiegesagt, ich revanchiere mich liebend gern für die aufgewendete Zeit- 
ob nun mit einem kleinen Prototypen oder einem Stück 
Sourcecode/Schaltung für ein Problem etc..  - meine Fantasie stelle ich 
gern zur Verfügung.
Kurzum - freue mich sehr über hilfreiche Ideen von eurer Seite.

Falls es noch Fragen oder unklarheiten zum oben geschilderten Thema 
gibt, bitte zögert nicht - ich versuche es so gut wie möglich zu 
erklären.

Vielen Dank im Voraus und euch allen ein paar beschaulich schöne Tage 
:-)
Dominik

Edit:  ASCII 65 ist natürlich auch bei meinem Rechner ein "A"   - nur um 
keine Verwirrung aufkommen zu lassen ;)

Karl Heinz, ich denke mit deiner Fantasie hast Du den Nagel ziemlich auf 
den Kopf getroffen :)

Ich dachte mir, es kann doch nicht so schwer sein, dieses \x41 mit 
"irgendeinem" Makro, Stringification oder zusammenführung irgendwie 
dahin zu überführen - in ASM geht es direkt per define/enum/equation

Hoffe sehr, daß irgendeiner, der es versteht besser als ich mit Makros 
zu spielen als ich, hier zufällig mal einen Blick drauf wirft und sich 
sagt, dies wäre 5 Minuten nachdenken wert... :)

Denn mit der Effizienz stirbt oder lebt ein solcher Parser - hier wollte 
ich die Infos gern Binär verpacken - ginge umständlich mit einem 
"Skriptumwandler"  (  der mir dann einen \x01 \x02  string erzeugt), 
aber wäre doch um so vieles schöner, wenn es direkt ginge..

Nunja - ich hoffe mal meine Weihnachtswünsche werden noch irgendwie 
erhört.
Trotzdem möchte ich Dir sehr danken - du hast meine langen Ausführung 
wirklich bildhaft auf den Punkt gebracht.

Dir - und euch allen noch einen schönen zweiten Weihnachtsfeiertag
Viele Grüße,
Dominik

An sich wäre dies eine sehr gute Idee - doch leider sollte diese Info ja 
mit in den string (und dort eben möglichst wenig Platz wegnehmen)

Zumindest würde auf diese Weise die Verwendung z.B. eines Enums klappen 
- doch leider kann ich einen char/byte-string schlecht in eine Struktur 
kapseln, sodaß an den richtigen Stellen meine "Parse-Infos" stehen..

z.b.  "Beispieltext 40 von 0x420 "
geparsed mit "Beispieltext \x80\x01 von \x83\x02"
0x80 könnte bedeuten dez. uint8
0x81 = hex uint16
x01/x02 wäre ein Variablenindex in einer liste..

alle zeichen im parsestring die das 0x80-bit gesetzt haben, leiten einen 
Parsevorgang ein...

so einfach könnte der Parsetext aussehen - ein einfacher aufruf würde 
reichen: Parse(my_const_char_beispieltext_parsestring);
==> sehr geringer overhead => für kleine Applikationen viel geeigneter 
als das (oft zu) mächtige sscanf

den obigen beispieltext würde man idealerweise etwa in dieser form 
definieren können:

static const char * my_const_char_beispieltext_parsestring=
"Beispieltext " PARSEVALUE(FLAG_U8 | FLAG_DEZ, ENUM_VARLIST1) "von 
"PARSEVALUE(FLAG_U16 | FLAG_HEX, ENUM_VARLIST2)"

soweit die Idee..
Wer kennt jemanden der mir helfen kann? :-)  Mag keinen C-Code-Generator 
basteln müssen, da soetwas immer recht fehleranfällig und auf jeden fall 
umständlicher in ein Projekt-Makefile einzubinden ist (gerade in punkto 
dependencies, aktualisierung)

gibt es evtl von anderen ähnliche Bestrebungen in die richtung?
Vielleicht könnte man sich ja zusammentun..

Johann L. schrieb:
> Anstatt die Zahl in den String zu bauen, bau doch einfach den
> String/Char als konstande in den struct, z.B. 'B' anstatt 0x42 im
> Initializer der Struktur.

Dies geht leider nicht/schlecht, da 0x42 ja Ergebnis einer Berechnung 
sein soll (z.b. mehrere Flags gesetzt - raus kommt 0x42)
Im Code wäre es wesentlich besser lesbar etwas in der Art zu schreiben:
const char* tmp="start parsetext " PARSEHEX_u8_var1 " end parsetext";

statt z.B. "start parsetext \x81 end parsetext";

aber vermutlich gibts wirklich keine Variante..

ich habe es nicht hinbekommen, das \x vor eine Zahl "anzuhängen", sodaß 
sie korrekt ausgewertet wird

@Mark:
Strings parsen ist exotisch? :) Sobald man Daten verarbeiten /senden 
will, kommt man heute kaum drumrum - jedes Modem, die meisten 
GPS/WLAN/ISM Receiver nutzen textuelle Protokolle..

Einen Mikrocontroller mit genug speicher für ein einzelnes Gerät wäre 
100%ig günstiger -  jedoch für eine mögliche Serie würde man sich viel 
LeiterplattenPlatz/Geld verschenken, wenn die dahinterstehende Anwendung 
äußerst flexibel an verschiedenste Anwendungssfälle anpaßbar ein muß, 
das "low-end" Gerät jedoch nur wenig Speicher benötigt.
Hier wäre eine effiziente Programmierung die beste Lösung.
Einen solchen Algorithmus könnte man in zig anderen Anwendungen 
ebenfalls nutzen (nicht mal nur auf AVR-Harvard-Architekturen 
beschränkt, sondern durchaus auch von Neumann (ARM etc..) laufen lassen.

Der Aufwand wäre dann auch gerechtfertigt zumal ich ein ähnliches 
Konzept früher bereits realisiert hatte - hier waren die "parse-Befehle" 
im String allerdings textuell kodiert und daher speicheraufwändiger.

SScanf ist ist sehr sehr mächtig - ich benötige einige wenige 
String-Parse Funktionen, kann auf sehr viele identifier verzichten, 
benötige aber stattdessen u.U. applikationsspezifische Erweiterungen wie 
z.B. Bereichsüberprüfungen usw.. - hier wären binär-Flags sehr effizient 
nutzbar (in 95% der Fälle ist das Flag nicht gesetzt, der string bleibt 
kurz und bündig).
hier mal eine Gegenüberstellung: (AVR)

Sscanf
- Flash: 1,8KB mindestens
!-- String-Overhead von min. 3-4 Bytes pro geparster Variable
!-- hoher Stack(Aufruf-)Overhead wenn mehrere Variablen auf einmal 
geparsed werden müssen (und zwischendurch bedingungen ausgewertet werden 
müssen)
+ bereits fertig implementiert -> Zeitersparnis

"meine idee"
- Flash: <1KB für "einfache Parsefunktionen"
!++ geringer Overhead (1-2 Bytes pro geparster variablen)
!++ leicht erweiterbar (z.b. "x zeichen beim parsen überspringen / bis 
char X suchen", dann weiterparsen etc...
!++ nahezu kein Stack Overhead, da in eine indexliste geparsed wird
!++ bedingungen (wie z.b. bereichsprüfungen) können direkt in den 
Parsevorgang integriert werden --> eine zeile pro "komplexem string 
parsen"
-- Entwicklungsaufwand

=> meine variante spart hauptsächlich Flashspeicher in konstanten 
strings.
==> Ersparnis wird relevant bei textuellen Befehlen, Protokollen  mit 
vielen zu parsenden Variablen

Flash ist bei AVRs gerade das Bottleneck, da nicht durch ext.Flash 
erweiterbar.

Falls ich es nicht hinbekomme, würde ich jedoch auf eine textuelle 
Variante ausweichen und z.B. Parse-Strings und andere Konstanten in 
einen seriellen Flash speichern..


@Rolf
Vielen Dank für diese gute Idee - ich werde diesen Ansatz ein wenig 
verfeinern, er kommt dem, was ich realisieren möchte am nähesten :)

Dort wird es mit größeren Mikrocontrollern gelöst :-)  unschuldig guck

Zwingend vorgegeben ist der AVR natürlich nicht - nur habe ich ihn als 
einen der platzsparensten (code-effizientesten) controller 
kennengelernt.
Muß allerdings zugeben, daß ich zu dieser Zeit noch ausschließlich via 
Assembler unterwegs war - mit C fängt man sich doch einiges an Overhead 
ein wenn man ein gewisses Maß an Codekompatibilität erreichen möchte.

Mal eine Off-Topic Frage:
Einen preisgünstigen Mikrocontroller mit internem Flash,RAM EEPROM, 
(+auslese-schutz), der sich zudem noch relativ einfach via SPI oder 
notfalls JTAG programmieren und kostenlos debuggen (debugger for free) 
läßt, ansonsten ähnlich flexibel wie der AVR ist  - welcher Name würde 
Dir da einfallen?

Herzlichen Dank im Voraus,
Dominik

Dank Dir für den Tipp,

über Cortex habe ich bereits ausgiebig nachgedacht - einziger Grund sie 
nicht zu nehmen waren bisher die toch recht teuren tools.
Da ich zum Programmieren Eclipse nutze und begonnen habe, meine Projekte 
aus Kompatibilitätsgründen in C / C++ zu schreiben, war ich von den 
GNU-Tools bisher recht angetan, da sie sich nicht hinter Profi-Lösungen 
verstecken müssen und nahezu alles damit programmierbar ist. Für eine 
C++ Programmierumgebung inc. Debugger legt man jedoch einige tausend 
Euro auf den Tisch, welche ich zumindest derzeit noch nicht ausgeben 
möchte - bei AVR ist das einfach alles Gratis (Debugging geht zwar nicht 
oder nur über Umwege in Eclipse, doch man gewöhnt sich schnell daran, 
den Sourcecode in 2 Programmen parallel zu verwenden - schreiben in 
Eclipse, Debuggen im Studio)

Falls es eine vergleichbare Cortex-Alternative gäbe, wäre ich 
mittelfristig dabei, da die Preise tendenziell günstiger sind als bei 
den AVRs.

Gäbe es hier zumindest eine kostengünstige (unbeschränkte) 
Programmier-Variante?  - C/C++ Debugging wäre natürlich sehr hilfreich, 
geht aber notfalls auch mit "printf"-Style ,  womit ich gern zurück zum 
eigentlichen Thema überleiten möchte :)