Forum: Mikrocontroller und Digitale Elektronik Kommunikation zwischen EDIP-Display und ATmega8


von Matt (Gast)


Lesenswert?

Hallo liebe Forengemeinde,

Vorneweg sollte ich vielleicht erwähnen, dass ich nicht aus der 
Elektronikbranche komme und in der Programmiersprache C auch nicht 
besonders gut bewandert bin.

Mein Problem/Ziel:
Ich möchte ein EA EDIP160W-Display mit einem ATmega8 verbinden. Vom 
Display sollen Daten an den Mikrocontroller gesendet und gegebenenfalls 
verarbeitet werden. Ausserdem soll der ATmega8 natürlich Daten an das 
Display verschicken können.

Nach langem Probieren und Durchforsten von diversen Internetseiten habe 
ich eine UART-Verbindung erstellt und kann mittlerweile Befehle an eine 
Terminalanwendung des PC's senden sowie Befehle vom ATmega an das 
Display senden. Die Kommunikation mit dem Display erfolgt mit der Hilfe 
des smallprotokoll (Seite 10 im Datenblatt: 
http://www.lcd-module.com/fileadmin/pdf/grafik/edip160-7.pdf )

Mein Problem ist nun, dass ich nicht weiter komme und vom Display keine 
Daten abholen kann.
Wenn ich das richtig verstehe sollte folgendes Makro im Display 
programmiert einen String zum Senden bereitstellen: #SB "HELLO".

Laut Datenblatt entleer die Befehlsfolge <DC2>, 1, S, bcc den
Sendepuffer des Displays. Das Display antwortet zuerst mit der 
Quittierung <ACK> und beginnt dann alle gesammelten Daten wie z.B. 
Touchtastendrücke zu senden.

Allerdings funktioniert bei mir scheinbar gar nichts. Ich muss dazu aber 
auch sagen, dass ich nicht weiss wie ich die Kommunikation zwischen den 
beiden belauschen kann um so Rückschlüsse auf Programmierfehler 
meinerseits zu machen.

Gibt es eine Möglichkeit die Kommunikation der beiden zu belauschen?

Oder kann mir jemand helfen einen Codeschnippsel zu erstellen, der den 
gesendeten String in ein Array auf dem Mikrocontroller schreibt?

Ich habe da in etwa an folgendes gedacht:
1
uint8_t edip_receive(void)
2
{
3
  uint8_t cksum;
4
  size_t len;
5
  char result;
6
  size_t i;
7
  
8
  uart_send(EDIP_DC2);
9
  cksum = EDIP_DC2;
10
  
11
  uart_send(EDIP_1);
12
  cksum = cksum + EDIP_1;
13
  
14
  uart_send(EDIP_S);
15
  cksum = cksum + EDIP_S;
16
  
17
  uart_send(cksum);
18
19
  result = uart_receive();
20
21
  if (result == EDIP_ACK)
22
  {  
23
    cksum = EDIP_DC1;
24
    len = uart_receive();
25
    cksum = cksum + len;
26
    len = len + 1;
27
    char received_string[len];
28
    for (i = 0; i < len; i++)
29
    {
30
    received_string[i] = uart_receive();
31
    }
32
33
    edip_print("#ZC80,5,");
34
    edip_print(received_string);
35
    return 0;
36
  }
37
  if (result == EDIP_NAK)
38
  {
39
    return 1;
40
  }
41
  else
42
  {
43
    return 2;
44
  }
45
}

Ich hoffe man kann zumindest meinen Gedankengängen folgen und sehen was 
meine Absicht eigentlich wäre. Mit einer LED habe ich herausgefunden, 
dass das Programm in der for-Schleife hängen bleibt.

Ich bin euch für jede Hilfe dankbar ;)

Freundliche Grüsse,
Matt

von Karl H. (kbuchegg)


Lesenswert?

Matt schrieb:

> Mit einer LED habe ich herausgefunden,
> dass das Programm in der for-Schleife hängen bleibt.

Hmm.
Das könnte ein Hinweis sein.
1
    len = uart_receive();
2
    cksum = cksum + len;
3
    len = len + 1;
4
    char received_string[len];
5
    for (i = 0; i < len; i++)
6
    {
7
    received_string[i] = uart_receive();
8
    }

Wenn dir das LCD mitteilt, dass es zb 5 Zeichen schicken wird, dann 
wartest du hier auf 6 Zeichen, weil du len um 1 erhöhst.

Das kann jetzt natürlich auch richtig sein, je nachem ob in der 
Längenzählung eine eventuelle Checksumm mit enthalten ist oder nicht. 
Daher: bitte noch mal checken, ob das so richtig ist.

von Matthias (Gast)


Lesenswert?

Hallo und vielen Dank für deine rasche Antwort.
In meinen Augen sollte da eine Prüfsumme auch noch übertragen werden. 
Die überprüfung habe ich noch weggelassen, da der Empfang noch nicht mal 
funtioniert.
Ich habe die Schleife auch schon ohne das +1 programmiert, das ging dann 
auch nicht.
Ich werde noch versuchen die Schleife nur einmal durchlaufen zu lassen, 
dann finde ich vielleicht heraus welche Zeichen gesendet werden.

von Karl H. (kbuchegg)


Lesenswert?

So wie ich das sehe hast du doch das Display über UART angebunden? 
Richtig?

Was ich in solchen Fällen gerne mache:
Ich verkable das Ganze erst mal an den PC und probier zb mit HTerm da 
mal ein wenig rum - was muss ich dem Gerät schicken - wie reagiert es - 
was kriege ich zurück - wie deckt sich das mit den Angaben im Datenblatt 
- etc.

So sammle ich erst mal mit dem Gerät ein wenig Erfahrung und dank HTerm 
kann ich gezielt Bytes schicken bzw. sehe auf Bytebene was zurückkommt. 
Und erst dann, wenn ich denke alles korrekt verstanden zu haben und mit 
dem Datenblatt in Übereinstimmung gebracht habe, erst dann fange ich an 
das Programm zu schreiben.

Das Schlimmste ist immer das 'Stochern im Nebel'. Dadurch dass ich im 
HTerm sehe was ich schicke und auch sehe, was das Gerät antwortet, 
vermeide ich diesen Punkt automatisch erst mal.

von Matt (Gast)


Lesenswert?

Hallo Karl Heinz,

Vielen Dank für deinen Tipp! Ich habe für diesen Zweck gar nicht an 
HTerm gedacht, da mit diesem Protokoll ja immer "komische" Zeichen 
ankommen und ich nicht senden konnte. Dass ich damit ja auch HEX senden 
kann habe ich gar nicht realisiert.
Ich bin gerade dabei zu testen und sehe, dass als Antwort auf "DC2 | 1 | 
S | Prüfsumme" erst das ACK ankommt, dann "DC1 | Len | String | 
Prüfsumme"!
Steht auch so im Datenblatt, aber ich hab das anders interpretiert :)

Damit kann ich erst mal weiter arbeiten und komme hoffentlich an mein 
Ziel :)

Vielen Dank schon mal für die Hilfe!

Ich melde mich wieder, wenns läuft oder ich trotzdem nicht mehr weiter 
komme.

Bis dann,
Matt

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.