mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Konzeptphase für Hobbyprojekt


Autor: T3Knopap$T (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Für ein Hobbyprojekt bin ich gerade in der Konzeptphase für eine
Menüsteuerung (Taster + 2-zeiliges LC-Display) um sowol Parameter
darzustellen als auch zu verändern. Da ich auf einem ATmega32 arbeite 
steht
nur begrenzt RAM zur verfügung, weshalb ich nach einer RAM-Schonenden
Lösung suche;) Folgendes habe ich mir überlegt. Über eure
Meinungen/Anmerkungen/weiteren Ansätze bin ich euch jetzt schon dankbar
;)

Die Idee:

-->|---------|-->|---------|-->|---------|
   |DISP_n-1 |   | DISP_n  |   | DISP_n+1|
<--|---------|<--|---------|<--|---------|

                 |---------|
                 |Param_n_0|
                 |---------|

                 |---------|     |---------|
                 |Param_n_1|---->|ParamCH  |
                 |---------|     |---------|

                 |---------|
                 |Param_n_x|
                 |---------|

Also: Es soll 3 Zustände geben:

- Anzeige (DISP)        : Hier können Parametergruppen ausgewählt werden
- Parametergr. (PARAM)  : Hier kann jeweils ein Parameter der Gruppe
                          ausgewählt werden.
- ParamChange (PARAM_CH): Hier kann der Parameter (nach Anwahl) geändert
werden.

Das kleine ASCII-Bildchen dient nur der Veranschaulichung, hoffentlich
verwirrt es nicht mehr als das es hilft ;)
Meide Idee war das mit einer doppelt(bzw.dreifach) verketteten Liste zu
lösen in der Vorgänger u. Nachfolger bekannt sind. So könnte man per
Tastendruck bequem im Menü navigieren. Allerdings ist das sehr
RAM-intensiv bzw. ich weiß nicht genau wie ich das ganze möglichst
RAM-schonend umsetzen kann.

Das Menü wird nicht sehr dynamisch sein, es ist also nicht nötig zur
Laufzeit Anzeigelelemente anzufügen womit ein Großeil der Informationen
konstant und somit aus meiner Sicht in dem ROM abgelegt werden können.
Die einzige Information die zum Compilezeitpunkt nicht bekannt ist ist
der aktuelle Wert des jeweiligen Parameters. In Peusocode hätte ich das
jetzt mal so versucht ob das in C überhaupt möglich ist bin ich mir
nicht sicher ;) ??
//Parameter RAM-Variable
unsigned char Param_Drehzahl[LCD_NUM_OF_SYMBOLS];

//Displayobject Datentyp
typedef struct
{
  unsigned char Zeile1[LCD_NUM_OF_SYMBOLS];    //Beschreibung des angezeitgen Wertes
  unsigned char  *p_Zeile2[LCD_NUM_OF_SYMBOLS]; // Parameter
  struct display *p_next;                      
  struct display *p_last;
  struct display *p_firstParam;
} display;

//definiertes Displayobjekt im ROM
static const Drehzahl=
{
  Zeile1={'D','r','e','h','z','a','h','l'}
  Zeile2=&Param_Drehzahl
  p_next=&Temp
  p_last=&Druck
  p_firstParam=&Motordrehzahl
}
Mir wäre sehr geholfen wenn Ihr mir sagen könntet ob das totaler
Schwachsinn ist, oder ob die Idee umsetztbar ist. Gegenüber anderen
Lösungsansätzen bin ich natürlich offen.


Danke u. Gruß
T3Knopap$T

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Allerdings ist das sehr RAM-intensiv

Wieso ? Du kannst die Menüstruktur doch aus dem Flash lesen. Und wenn du 
wie oben gesagt nicht viel dynamisch hast (also das sich das Menü zur 
Laufzeit ändert) ist es kein Problem. Dann brauchst du lediglich ein 
paar Bytes RAM (ein Byte um die Seite zu identifizieren in der du gerade 
stehst, bzw einen kleinen Stack von vllt 10 Bytes wenn du beim 
Rücksprung in das übergeordnete Menü an der richtigen (sprich zuletzt 
verwendeten) Stelle stehst.

Der Ansatz mit der doppelt verketteten Liste ist ok.
Von dem was ich mir durchgelesen habe müsste es funktionieren. Habs aber 
auch nur kurz durchgelesen.
Ich habe das in einer Menüstruktur ähnlich gemacht.
Ich habe mir Texte, Textlisten (mit den indizes der verwendeten Texte 
innerhalb der Liste), Objekte (die Texte oder Textlisten enthalten 
können), Seiten (die aus Objekten zusammengebaut sind) sowie 
Seitenlisten (die indirekt aus Textlisten bestehen) gemacht.
Die Verbindung zwischen Objekten und Variablen die sich ändern können 
habe ich ganz einfach über Zeiger gemacht. So hat jeder Parameter seinen 
eigenen Zeiger.
Funktioniert auch ganz gut. Ist nur ein wenig klobig geraten und nicht 
so schön zu erweitern (aufwändig).

Autor: Mobius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würd noch einen Funktionspointer in die Struktur einfügen. Damit 
erspart man sich den riesen switch-case um herauszufinden, was du 
eigentlich machen musst, wenn der Benutzer ne Taste drückt (ein wenig 
vergleichbar mit einem Action-Listener in Java).

Die einzelnen Menueinträge würde ich in ein Array legen. Dann kannst du 
dir die Pointer auf vor zurück und parameter auch sparen, indem du 
stattdessen den Index des betreffenden Eintrags abspeicherst (wenn dein 
Menu nicht mehr als 256 Elemente enthalten soll, reichen dir je ein 
uint8_t).

Bei meiner Menu-Struktur habe ich es so gelöst, dass ich immer den 
aktuellen Menu-Eintrag in den RAM abgelegt habe (da ich ab und zu die 
Texte dynamisch verändern musste). Kann man sich aber auch ersparen und 
nur die Index-Variable anspeichern.

grüße
Mobius

P.S.: const speichert nciht im ROM. Zum abspeichern in den Flash, schau 
dir avr/progmem.h an (natürlich nur, wenn du WinAVR verwendest ;) ).

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Generell nochmal gesagt :

Indizes sind m.M. nach Pointern vorzuziehen. Erstmal erleichtert es beim 
Debuggen (Abzählen von einträgen ist einfacher als die Kristallkugel 
nach 0xfe23 zu befragen). Und zweitens braucht man auch dadurch weniger 
Speicher.
Man erkauft sich das allerdings damit das bei jedem Zugriff der Zeiger 
neu berechnet werden muß.

Als ergänzung zu dem was Mobius geschrieben hat :
Funktionszeiger vllt in einer separaten Tabelle ablegen, dann kann man 
ebenfalls mit Indizes hantieren. In Verbindung mit Enums ist das dann 
wunderbar zu lesen und direkt verständlich.
Ich mache das meist auch per Index, wobei ich in der Zeigertabelle dann 
oft noch einen optionalen Integer Wert mit ablege. Wenn ich bei einem 
Aufruf über diese Tabelle den Integerwert an die aufzurufende Funktion 
mitgebe kann ich noch eine Fallunterscheidung machen. Beispiel :

Die Funktionszeigertabelle speichert mir Darstellungsfunktionen für das 
Display (z.b. signed/unsigned integer auf Display ausgeben). Mit dem 
Integer unterscheide ich ob ich signed/unsigned Darstellen möchte, und 
wieviele Stellen ich haben möchte. Dann kann ich mit einer einzigen 
Funktion alle Fälle erschlagen und bestimme mit dem Integer Parameter 
meine genaue Darstellung.
Der Index im Menü zeigt dann auf einen Eintrag indem meine Funktion und 
die dazugehörige Darstellung steht.
Es ist vllt ein bissl kompliziert erklärt, aber es ist im Prinzip ganz 
einfach. Ich habe das z.b. in einer Grafik-UI so gemacht. Da ist eine 
Funktion die einen Button Darstellen soll. Über den mitgegebenen Integer 
Wert wird das aussehen und Verhalten des Buttons bestimmt (3D/2D, 
Rastend/Nicht Rastend, Bitmap/Text, Rahmen/kein Rahmen, usw.). So kann 
ich mit einer Funktion 10 verschiedene Objekte implementieren ohne 10 
verschiedene Funktionen zu programmieren. Spart Zeit/Nerven/Bytes und 
ist einfach erweiterbar.

Autor: T3Knopap$T (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

wow, bin positiv von der schnellen Reaktion des Forums überrascht ;)
Dafür erstmal Danke !!

@ Mobius /Rene : Das mit dem Funktionspointern kann ich mir noch nicht 
so richtig vorstellen. Könnte einer von euch vllt. ein kurzes C/pseudo 
code Beispiel zu Verdeutlichung zu erstellen?

Ich hatte ja vor für Jede Display-Seite ein "Stucktur-Objekt" in den Rom 
zu legen. Wenn ich jetzt anstatt der Zeiger für "vor" und "zurück" einen 
Funktionspeuter in die Stuktur einbaue der je nach Objekt ein anderen 
Index hat, dann hab ich doch in der Funktion trotzdem nen riesen switch 
case, oder verstehe ich jetzt grundsätzlich etwas nicht ;) ?


@ Mobius: Danke für den Tip mit dem Progmem ... öfter mal was neues ...


Gruß
T3Knopap$T

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Frank B. (frank501)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strukturiert und ohne unnötiges Zeigergewurschtel kann man es auch 
einfacher lösen, indem man sich eine Funktion bastelt, die einen 
beliebeigen Wert auf dem Display anzeigt, mit 2 Tasten verändert und den 
neuen Wert als Rückgabewert ausgibt. Als Eingabe braucht diese Funktion 
nur den anzuzeigenden Text und den Initialwert der Variabel.
In Pseudocode sähe das Ganze etwa so aus:

Funktion (texte, startwert [,maxwert, minwert]) = Ausgabevariable
Var X
{
 X = startwert;
 Ausgabe Text auf Display;
 Ausgabe X auf Display;
 Wenn nicht taste 3 wiederhole
 {
  Wenn taste 1 dann erhöhe X;
  Wenn taste 2 dann erniedrige X;
  Wenn X > max wert dann X = maxwert;
  Wenn X < min Wert dann X = minwert
  Ausgabe X auf Display;
 }
 Ausgabevariable = X;
}


Damit braucht man den Code für egal wie viele zu verändernde Werte nur 
einmal und braucht sich den Code durch Zeiger nicht zu versauen.
Das eigentliche Menü muß dann nur die (in einem Array) abgelegten Texte 
anzuzeigen und zu blättern und ruft die Funktion bei einem Druck auf 
eine Taste auf.
Der Rückgabewert wird dann einfach in der richtigen Variable 
gespeichert.

Frank

Autor: Mobius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank: Interessante Möglichkeit. Aber einen Pointer auf die zu 
verändernde Variable im Menu-Eintrag wird man brauchen. Dann noch 
min/max Werte und vllt. auch noch step-size (je nachdem wie "allround" 
die Funktion sein soll). Die müssen auch als Information in den 
einzelnen Menu Einträgen abgespeichert werden. Auch könnte es sein, dass 
nicht nummerische Einstellungen verändert werden sollen (mein, wenn man 
zB leise/laut, langsam/mittel/schnell, etc. ausgeben muss). Dafür 
bräuchte man dann eine weitere Anzeigefunktion und der Aufrufer muss 
dann entscheiden, was getan werden soll.

Will nicht sagen, dass die Idee schlecht ist, es hängt halt davon ab, 
was man mit dem Menu alles tun will. Sie hat Vorteile und Grenzen und um 
Zeiger wirst du auch bei dieser Lösung nicht drum herum kommen ;) (halt 
nur um Funktionszeiger ^^).


@T3Knopap$T: Nein, die Zeiger für vor und zurück nicht durch nen 
Funktionspointer ersetzten. Die kannst du so lassen, wenn du eine 
verkettete Liste aufbauen willst. Wenn du alle Einträge in ein Array 
gibts, kannst du die Zeiger durch index-Variable austauschen (und damit 
3 byte / Eintrag sparen, nicht viel summiert sich aber ;) )

Der Funktionspointer ist dafür, dass du die Aktion, die bei einem 
Tastendruck ausgeführt werden soll (zB. Zeit einstellen, Motor starten, 
Variable hochzählen, Roman ausgeben, etc.) einem Menu-Eintrag zuordnest. 
Eigentlich genau wie bei 
http://www.mikrocontroller.net/articles/FAQ#Men.C3... 
^^.

Das Traversieren des Menus erfolgt dann mit einer Action-Funktion, die 
nichts anderes zu Tun hat, als den Zeiger/Index (je nachdem ob 
verkettete Liste oder Array) entsprechend einem Tastendruck zu 
modifizieren.
// Ein Zeiger/Index auf den aktuellen Eintrag, das angezeigt wird
IndexVar menu

function ActionFunc(button)
{
   wenn button = zurück
       menu = menu.last
   wenn button = vor
       menu = menu.next
   wenn button = hinauf
       vorigen Parameter anzeigen
   wenn button = hinunter
       nächsten Parameter anzeigen
}

// ein Menu Eintrag, wie aus dem obrigen Link
const ROM menu
{
   // Daten für die restliche Struktur
   ActionFunc;
}

// aufrufer der Funktion
Interrupt
{
   menu.ActionFunc(gedrückte Taste);
}

gruß
Mobius

Autor: gastt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe erst durch mein menügebastel funktionszeiger lieben gelernt ^^
man kann unglaubliche schweinereien damit anstellen und sogar sehr 
"objekt"basierend arbeiten


für solche menüs die diverse untermenüs haben können hatte ich eine 
lösung wo allein das array bestimmt wie das menü aussieht
in der struktur steckt dann nur eine variable die die aktuelle "ebene" 
darstellt

struct
{
  char *text;
  unsigned char ebene;
  void (*f_ptr)(void);
}menu_t;

menu_t menuarray[] PROGMEM ={
{"Hauptmenu"    , 0 , menu_vor},
    {"Einstellungen 1"    , 1 , menu_vor},
        {"Parameter 1.1"          , 2 , tuwas1},
        {"Parameter 1.2"          , 2 , tuwas2},
    {"Einstellungen 2"    , 1 , menu_vor},
        {"Parameter 2.1"          , 2 , tuwas3},
        {"Parameter 2.2"          , 2 , tuwas4},
    {"Version"            , 1 , tuwas5},
};


will man nun einen neuen menüpunkt eintragen setzt man diesen an die 
entsprechende position , schreibt die passende funktion der "action" 
dazu und fertig

soll es nur einen punkt weiter gehen oder zurück existiren menu_vor() 
und menu_zurueck()  funktionen die als "action"  eingetragen werden

das umsortieren der punkte oder löschen/ hinzufügen ist hier sehr 
einfach

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>man kann unglaubliche schweinereien damit anstellen und sogar sehr
>"objekt"basierend arbeiten

Hehe. Das ist wohl wahr. Es lassen sich eine Menge feiner Sachen damit 
umsetzen die sich sehr leicht erweitern lassen. Aber man muß echt 
aufpassen bei den Schweinerein. Hat man da nen Fehler drin kann man gut 
und gerne etliche Stunden Fehlersuche betreiben.
Daher halt der Hinweis mit den Indizes.
Je nachdem wie groß das ganze ist macht das zustäzliche Byte für einen 
Zeiger auch nicht viel aus bzw die Speicherersparnis wird durch die 
Inizes wieder zunichte gemacht.
Aber sehr schöner Ansatz den du zuletzt gepostet hast. Werd den bestimmt 
mal irgendwie verwursten :-))

Autor: gastt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in der endgültigen version hab ich anstelle des textes bzw den zeiger 
auch nur ein index auf ein textarray mit textzeigern ^^
weil sich dann verschiedene sprachen einstellen lassen mit einem 
pointeroffset

an der sache mit den indizes auf zeigerarray  stört mich bei 
funktionszeigern immer das man ja nicht vergessen darf die zeiger 
einzutragen , die indizes zu prüfen usw ..
viele bauen dann zusätzlichen code ein damit vorher alles überprüft 
wird..

man editiert sozusagen an 3 baustellen
ist eines vergessen worden haut alles nicht mehr hin
und da wollte ich irgendwie daran vorbei
( das stört mich beim text in mehreren sprachen schon immer ^^ )



zeiger sind immer ein problemchen hier und da ... aber erleichtern einem 
vieles und sind gerade in C eine sehr starke waffe ^^

Autor: T3Knopap$T (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

danke für die vielen Anregungen ! Die  müssen jetzt erstmal verarbeitet 
werden ;)

Werde mich dann wieder melden wenn ich es, wie auch immer, umgesetzt 
habe!!

Oder, wenn ich auf die ersten Probleme stoße natürlich ;)


Gruß
T3Knopap$T

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@gastt

Das Problem mit den Zeigern die man immer nachpflegen muß hab ich ne 
(nicht ganz einfache, aber geniale) Lösung. Und zwar lassen sich ja mit 
dem Präprozessor schöne Schweinereien machen die die Verweise 
automatisch richtig setzen.

Z.B. mit folgendem Codeschnipsel

xxx.h :
-------

enum {
  #define TEXT(name,text) name,
    #include "xxx_cfg.h"
  #undef TEXT
  NUM_TEXT_INDEXES
};

  #define TEXT(name,text) char Text_Single_##name [] PROGMEM = { text } 
;
    #include "xxx_cfg.h"
  #undef TEXT

char * Text_Zeiger_Array Single_##name [] PROGMEM = {
  #define TEXT(name,text) Text_Single_##name,
    #include "xxx_cfg.h"
  #undef TEXT
};

xxx_cfg.h
---------

#ifdef TEXT
  TEXT (MAIN, "Hauprmenu")
  TEXT (ENTRY1, "Eintrag 1")
  TEXT (ENTRY2, "Eintrag 2")
  TEXT (ENTRY3, "Eintrag 3")
#endif



-------

Bei diesem kleinen Beispiel werden Texte angelegt und ein Array in dem 
die ganzen Zeiger auf die einzelnen Texte automatische generiert werden. 
Man muß sich dabei nicht mal mehr um die Zuordnung kümmern. Hat 
automatisch eine Konstante namens "NUM_TEXT_INDEXES" in der steht 
wieviele Texte bzw Indizes verwendet werden. Mit der Methode lassen sich 
auch sehr komplexe Strukturen automatisch richtig erzeugen.
Ist nicht ganz einfach zu verstehen aber wenn mans einmal verstanden hat 
ein echt mächtiges Werkzeug.

Autor: gastt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm  danke ^^
das is ma ne lösung :D

geht sogar mehrsprachig ohne dateisalat

#ifdef TEXT
  TEXT (MAIN, "Deutch1", "English1", "xxxxxxx1")
  TEXT (ENTRY1, "Deutch2", "English2", "xxxxxxx2")
  TEXT (ENTRY2, "Deutch3", "English3", "xxxxxxx3")
  TEXT (ENTRY3, "Deutch4", "English4", "xxxxxxx4")
.
.
.
.
#endif


witzige idee :)

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@gastt

Das ist doch noch gar nix :-)))))))
Mit der Methode kann man sich sehr viel arbeit ersparen und es kommt 
immer (sofern man die richtigen Datenstrukturen gewählt hat) die 
platzsparenste und zugleich wartungsfreieste Lösung bei raus.
In dem Beispiel habe ich ja nur 1 Ebene (Texte und Zeiger auf Texte) 
benutzt. Interessant wird das wenn man mit mehreren Ebenen (Zeiger und 
Indizes) "spielt".
Z.b. erstellt man sich (wie oben schon erwähnt) Objekt-Funktionen, 
Texte, Text-Listen und Seiten. Wenn man mit Indizes arbeitet hat man 
durch die automatische Enumeration auch immer einen sprechenden Namen 
den man durch die ganze Konfiguration hinweg benutzen kann.
In den Objekten kann ich Text-Indizes oder Listen-Indizes verwenden, und 
die Seiten-Infos beherbergen dann Objekt-Indizes. Alles mit sprechenden 
Namen, und kein abzählen mehr.
Ich verwende diese Technik für so ziemlich alles was im entferntesten 
nach Parametrierung riecht (ok, ich verwende nicht für jedes kleine 
bischen automatisch Listen, aber wenn z.b. Portpins variieren können 
bietet sich eine Konfiguration nach dem o.g. Muster an). Egal ob UART, 
Timer, Tasten, Analog-Eingänge, Funktionsaufrufe von einem Steuersystem, 
meinen hier veröffentlichten Kommando-Interpreter, und und und ...

Z.B. für Tasten :

#ifdef KEYDEF
//KEYDEF (name,      PIN_X, Bit
  KEYDEF (CURSOR_UP, PINA, BIT0)
  KEYDEF (CURSOR_DN, PINA, BIT1)
  KEYDEF (CURSOR_LF, PINA, BIT2)
  KEYDEF (CURSOR_RT, PINB, BIT4)
#endif

oder für Analoge Eingänge

#ifdef BOARD_UI_AINP
//BOARD_UI_AINP (name,     ch,    mux
  BOARD_UI_AINP (VOLUME,    0,    0)
  BOARD_UI_AINP (BASS  ,    1,    0)
  BOARD_UI_AINP (TREBLE,    0,    1)
  BOARD_UI_AINP (BALANCE,   1,    2)
#endif

Das schöne ist das man dadurch die eigentliche Header und Code-Datei nur 
anpacken muß wenn was wirklich neues implementiert werden soll. 
Ansonsten nimmt man einfach die xxx.c, xxx.h für ein anderes Projekt und 
passt lediglich die xxx_cfg.h an und schon (sollte) es laufen.

Es gibt noch einiges zu dem Thema zu sagen. Vllt werde ich noch einen 
Artikel darüber schreiben. Aber wenn man die generelle Vorgehensweise 
erstmal verstanden hat eröffnen sich einem enorme Möglichkeiten.
Die ganze Vorgehensweise mutet erstmal etwas umständlich und schwer 
verständlich an, aber der Aufwand lohnt sich. Allein dadurch das wenn 
man Datenstrukturen und Enums entsprechend immer konsistent hat (bei 5 
Einträgen gehts ja noch, aber ab 20 wirds dann umständlich "mal eben" 
einen neuen Eintrag irgendwo in der Mitte reinzufummeln, und wenn dann 
noch Kreuzverweise konsistent gehalten werden müssen ...

So genug geschwafelt und gewschwärmt :-)
Bin mal gespannt ob ich jemandem mit dem Post hier genug anregung 
gegeben habe mal damit was auf die Beine zu stellen.

Autor: gastt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab grad angefangen ein paar sachen so umzuheben ^^
ich find das witzig

Autor: brott (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene Böllhoff schrieb:
> Vllt werde ich noch einen
> Artikel darüber schreiben.

Ich währe dir sehr verbunden! Das klingt alles sehr spannen und sinnvoll 
was du schreibst. Ein Artikel zur Strukturierten programmierung währe 
sehr fein.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite auch lieber mit Indizes anstatt mit Pointern.
Indizes lassen sich einfacher vor und zurück zählen und auf 
Bereichsgrenzen prüfen "if( index < 0 || index >= sizeof(menu))".

Außerdem ist es fehlertoleranter.
Ein falscher Index zeigt nur einen falschen Menüpunkt an.
Ein falscher Pointer läßt das komplette Menü in den Wald laufen und es 
ist dann schwer den Schuldigen zu ermitteln.


Peter

Autor: Rene B. (themason) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mal ein paar Konfigurationsdateien wie ich sie in meinem Audio-Projekt 
verwende. Die sind mittlerweile schon ganz ordentlich umfangreich 
geworden.

DAP_MOD_CFG.H :
  Konfigurationsdatei für den Kern meines modularen Audio-Systems.
    Da werden Module deklariert, und die verschaltung der Module zu 
Setups, sowie grundlegende Konfiguration des Systems (Preset-Größe, 
Anzahl Steuerwerte und und und)

GLCD_UI_CFG.H :
  Konfigurationsdatei für die grafische GUI. Hier werden Texte, Objekte 
und Seiten definiert.

PARSER_CFG.H :
  Konfigurationsdatei für meinen Kommandointerpreter mit automatischer 
Hilfegenerierung, Kommandolisten (damit lässt sich viiieeeel machen), 
Verarbeitungscodecs usw ...

Ich möchte diese Technik mittlerweile nicht mehr missen, wenn man sich 
überlegt was man damit alles anstellen kann. :-))

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.