Zwei displays mit Atmega 16

Anhang fehlt.

Gruss
Jadeclaw

...und nicht iom16.h includen! Es wird grundsätzlich nur io.h 
eingebunden. Die Information über den verwendeten Controller gehört ins 
Makefile. Dann wird auch automatisch die richtige Device-spezifische 
ioXXX.h eingebunden.

> #include "LCD.C"
> #include "A2D.C"
Und das macht man auch nicht. .c-Dateien werden im Makefile dem Compiler 
als Sourcen bekanntgegeben. Zu jeder .c-Datei wird eine .h-Datei 
angelegt, die die Variablen- und Funktionsdeklarationen enthält (als 
extern-Deklarationen). Diese .h-Dateien werden dann mit #include in die 
.c-Dateien eingebunden, in denen sie benötigt werden.

Außerdem solltest Du sicherstellen, dass die Dateinamen auch tatsächlich 
in Großbuchstaben geschrieben werden (das gilt auch für die 
Dateierweiterung, die ist nämlich bei C-Sourcen üblicherweise ein 
kleines c).

Du wirst um eine Modifikation der LCD Software nicht umhinkommen.
Woher soll denn beispielsweise ein Aufruf von lcd_putc sonst
wissen auf welches Display er die Ausgabe machen soll?

Ergo wirst du wohl sinnvollerweise den Initialisierungs
und Ausgabefunktionen einen zusätzlichen Parameter
spendieren müssen, der genau das angibt. zb.

  lcd_putc( 0, 'a' );

"Gib das Zeichen a am Display 0 aus"

  lcd_putc( 1, 'a' );

"Gib das Zeichen a am Display 1 aus"

Innerhalb der Funktionen, musst du dann zusätzliche Logik
unterbringen, die je nach erstem Argument, entweder die
eine Enable Leitung oder die andere Enable Leitung bedient.

Und ja, sinnvollerweise wirst du dir dann die #define etwas
abändern:

1

#define LCD_E0_PORT       LCD_PORT  /**< port for Enable line for display 0 */

2

#define LCD_E0_PIN        6         /**< pin  for Enable line for display 0 */

3

#define LCD_E1_PORT       LCD_PORT  /**< port for Enable line for display 1 */

4

#define LCD_E1_PIN        7         /**< pin  for Enable line for display 1 */

Wenn du das so machst, sagt dir dann auch der Compiler mittels
Fehlermeldungen, wo du in den LCD Funktionen modifizieren musst
und eine Auswertung der Displaynummer einführen musst :-)

Was spricht eigentlich dagegen, beide Displays als ein Display mit zwei 
Controllern anzusteuern? So wie ein 4x27 oder 4x40? Man muss ja die 
nicht vorhandenen Ausgabepositionen nicht unbedingt ansprechen. Obwohl 
das auch kein Beinbruch wäre, denn der zugehörige DD-RAM ist ja im 
Controller vorhanden.

...

Hannes Lux wrote:
> Was spricht eigentlich dagegen, beide Displays als ein Display mit zwei
> Controllern anzusteuern? So wie ein 4x27 oder 4x40? Man muss ja die
> nicht vorhandenen Ausgabepositionen nicht unbedingt ansprechen. Obwohl
> das auch kein Beinbruch wäre, denn der zugehörige DD-RAM ist ja im
> Controller vorhanden.
>
> ...

Viele Wege führen nach Rom :-)
Klar, ist auch eine Möglichkeit.
Persönlich finde ich die Variante mit expliziter Display-Angabe
klarer, da man dann beim Aufrufer weniger aufpassen muss, wo
denn nun der gedachte Cursor steht.
Ist einfach nur eine Frage dessen was mir lieber ist: Habe
ich beim Aufruf eine explizit angeführte Information (welches
Display ist gemeint) oder ergibt sich das implizit durch die
Vorgeschichte im Programm (wohin habe ich den Cursor gesetzt).

Du müsstest an den Makros lcd_e_high(), lcd_e_low() und lcd_e_toggle() 
ansetzen. Diese werden von sämtlichen andere Funktionen aufgerufen. Du 
ersetzt die Makros durch eine Funktion, die anhand einer globalen 
Variable dann die entsprechende Enable-Leitung steuert. Dürfte sich 
ziemlich schnell machen lassen...

Uwe ... wrote:
> Du müsstest an den Makros lcd_e_high(), lcd_e_low() und lcd_e_toggle()
> ansetzen. Diese werden von sämtlichen andere Funktionen aufgerufen. Du
> ersetzt die Makros durch eine Funktion, die anhand einer globalen
> Variable dann die entsprechende Enable-Leitung steuert. Dürfte sich
> ziemlich schnell machen lassen...

Seh ich auch so.
Allerdings würde ich keine globalen Variablen dafür hernehmen,
sondern sauber den Funktionen ein Display Argument verpassen.
Alle anderen Modifikationen folgen dann automatisch daraus
und der Compiler überwacht die Modifikationen auch, weil ja
irgendwo die Parameter für den jeweiligen Aufruf herkommen müssen.
Das ist dann ziemlich narrensicher und es gibt kaum eine Möglichkeit,
dass sich bei der Modifikation ein Fehler einschleicht.