Forum: Mikrocontroller und Digitale Elektronik Übertragungsprobleme mit I2C und eDIP240


von Daniel S. (daniel-r-s)


Angehängte Dateien:

Lesenswert?

Hallo zusammen.

Ich Arbeite gerade an einem Techniker Abschlussprojekt. und brüchte 
zwecks immer näher rückendem Abgabetermin dringend Hilfe.

Da der Support von ea auch nach mehrmaligen versuchen nicht reagiert 
wende ich mich an alle Wissenden hier.

Ich verwende als Prozessor einen Infinion XE164F.

Ich versuche eine Verbindung zwischen meinem Master (XE164) und dem 
slave
eDIP240 mit I²C zu realisieren.

Prinzipiell kann ich mit dem eDIP per I²C kommunizieren allerdings mehr 
schlecht als recht. Versucht habe ich 2 varianten. Einmal mit aktiven 
smallprotokoll und einmal ohne.

Problembeschreibung:

Ohne Smallprotokoll.

Löschen des Displays funtioniert einwandfrei, auch des zeichnen einer 
Linie wie in der beschreibung angegeben. wenn ich aber werte aus einem 
array übertragen möchte gibt es probleme. Wenn ich beispielsweise den 
Text"test" senden möchte, werden immer wieder unterschiedliche sachen 
angezeigt. Bsp. teZL oder ZLxt und vor allem springt das bei jedem 
senden hin und her.

mit Smallprotokoll.

Tja. das ist so ne Sache. Das löschen funktionierte sporadisch. Linien 
zeichnen oder Textausgabe überhaupt nicht. obwohl ich nichts am 
Programmcode geändert habe funktioniert inzwischen auch das senden nicht 
mehr.

In beiden fällen mache ich keine ACK abfrage da es sobald ich die 
anfrage mit reinnehme überhaupt nicht mehr funtioniert.

Ich stelle mal den Code in C für beide Varianten im anhang rein

von cskulkw (Gast)


Lesenswert?

Hallo Daniel,

wenn ich es richtig verstanden habe, dann gibt Du ständig den Wert 0xDE 
zu Beginn aus. Warum tust Du das? Das erste Byte muß aber entweder 11 
hex (Befehle senden) oder 12 hex (Displaysendepuffer anfordern) sein. 
Dann folgt die Nutzdatenlänge ohne bcc und 1. Kommandobyte. Versuche 
doch einmal das DE weg zu lassen.

Was macht Dein Signaltiming? Hast Du Dir das mal auf dem Scope 
angeschaut?
Das eDIPxxx ist ja echt mächtig aber leider auch grottenlangsam. Ich 
stelle CAN-Botschaften auf dem Display dar. Aber wenn die schneller als 
10ms eintreffen, dann schaffe ich es nicht die Daten schnell genug in 
das Display zu übertragen.

Ich denke, dass Du Gas geben mußt, weil Dein Termin bald abläuft, oder? 
Ich würde Dir vorschlagen, dass Du Dir einen Plan aufstellst, welche 
Inhalte Dein Display anzeigen soll. Es gibt bei EA diesen eDIP-Compiler 
kostenfrei zum downloaden. Mit diesem kannst Du vom PC aus sogenannte 
Makros programmieren, kompilieren, übertragen und diese mit kurzen 
schnellen Makrosteuerbefehlen vom Mikrocontroler aus aufrufen und 
ausführen lassen.
Der Vorteil liegt darin, dass Du Dir um die BCC und 
Datenlängenberechnung für diese Inhalte keine Gedanken machen mußt. Du 
brauchst nur einen MAX232 für den Anschluß an den PC bauen. (Steht im 
Datenblatt Seite 19 vom edip240-7)

Damit ließe sich der Aufwand erheblich reduzieren, den Du für die "das 
Auge ansprechende Grafik" aufwenden müßtest. Du kannst Bitmaps und viele 
andere Dinge bereits vom internen Makro zeichnen lassen. Über Deinen 
Mikrocontroler forderst Du dann nur die Ausführung Makro x 
(n=0,1,...)an. Bzw. gibst dann Deinen Text an der Stelle aus, der dann 
situationsabhängig ständig aktualisiert werden muß.

Übrigens befindet sich das Display nach dem Einschalten im 
Kommandozeilenmodus. Test ausgeben funnktioniert wie beim guten alten 
Nadeldrucker mit Centronix-Schnittstelle.

Ich hoffe, dass Dir diese Tips schnell weiter helfen.

Viel Erfolg.

Carsten

von Peter D. (peda)


Lesenswert?

Du brauchst das Protokoll, sonst kannst Du die Empfangspuffergröße nicht 
auslesen.
Bevor Du was hinschickst, mußt Du solange warten, bis genügend 
Empfangspuffer verfügbar ist.

Wenn oben in der Ecke Zeichen erscheinen, ist das Kommando falsch oder 
der Puffer war zu klein und Bytes sind verloren gegangen.


Peter

von Daniel S. (daniel-r-s)


Lesenswert?

Hallo Carsten,
danke für die schnelle Antwort.

Da ich die Adressierung offen gelassen habe lautet ja auch das 
Adressierbyte laut doku 0xDE schreiben und 0xdf lesen. vorrausgesetzt 
ich habe das richtig verstanden.
Da die befehle bsp. zum löschen interruptgesteuert sind muss ich ja auch 
nach der startbedingung das Adressbyte senden. zumindest ist oder war 
das so bei allen I²C teilnehmern die ich sonst immer angesprochen hatte 
(z.b. A/D-D/A converter PCF8591 oder I/O erweiterung PCF8574)<--war ein 
anderes projekt.
Aber beim eDIP scheint ja einiges ein bisschen anderst zu laufen.

Die vermutung mit der übertragunszeit hatte ich auch schon. Hast du da 
10ms pause zwischen den bytes?

Hätte ich vieleicht dazuschreiben sollen. Der compiler ist vorhanden und 
die Programmierung des eDIP (und Prozessors)ist auch fertig(bis auf die 
datenverbindung). übertragen werden oder sollen div. Messwerte.

habe da noch ein nützliches programm bei LWS mess und labortechnik 
gekauft.
Das erleichtert massiv den aufbau eines Grundgerüstes des eDIP, habs 
aber erst gefunden als ich schon fertig war ^^



Hallo Peter,
danke auch an dich für die schnelle Antwort.
Wenn ich dich richtig verstanden habe dann benötigt das display zwingend 
das smallprotokoll.
Das mit dem eingangspuffer ist mir noch nicht ganz klar. Ich hatte das 
so verstanden das der Puffer eine max größe von 64byte hat. korreckt 
empfangene Daten werden per ACK quittirung bestätigt verarbeitet und der 
Puffer wieder frei gemacht.
Aber wie kann ich dann den empfangspuffer vor dem senden schon erfassen 
und evtl. leeren

von Daniel S. (daniel-r-s)


Lesenswert?

habe grade festgestellt das ich nen fehler in dem programm habe.
Der Kode bei "Text senden ohne Protokoll" ist eigentlich linie von oben 
links nach rechts unten zeichnen. mein fehler.
Das funktioniert auch. nur nicht mit eingeschaltetem protokoll und 
DC1+len+bcc

PS
Hey Peter
float superkomplizierte_wandlung_int_nach_float( int zahl )
{
  return zahl;
}
wo bleibt denn da noch der spaß an einer schönen funktion, wenn der 
aufruf vor lauter lachen schon kaum möglich ist ;-)

von cskulkw (Gast)


Lesenswert?

An Daniel noch einmal,

ja sorry, dass mit dem I2C-Bus ist bei mir schon sehr lange her. Darum 
fliegt mein SHT11-Feuchtigkeitssensor immer noch nicht...

Nein also das Diplay befeuere ich mit 115kBaud ohne Adresse. Nur wenn 
eine CAN-Nachricht mit 8 Batenbytes eintrifft und ich diese in einen 
ASCII-String umwandeln muß, dann werden aus 8 Bytes 16 Bytes + 7 
Leerstellen. Dann muß ich noch die Postion mitgeben und der DLC 
interessiert mich ja auch noch. Da kommen dann ca. 30 Bytes zusammen. Da 
sind dann schon 2,6 ms um,  bis die Nachricht im eDIP steckt.

Bei I2C und SPI gibt es es diese Wartezeit von 100µs zw. 2 zusendenden 
Bytes. Wenn ich zwischen den gesendeten Byte immer 100µs warten muß, 
bringt es mir nichts, wenn ich das Datenbyte mit 400 khz (I2C) oder 3Mhz 
(SPI) versende. Wenn ich richtig rechne, ist die Performance bei 
Übertragengeschwindigkeiten größer 100 kHz schlechter als bei dieser 
Grenze. Naja, ich will nicht alles verstehen.

Aus diesem Grund würde ich mal messen, ob die Wartezeit Dir Probleme 
macht.
Ich habe mir so ein LOGICPORT von Intronix beschafft. Ja, war nicht der 
Schnapper. Aber Messtechnik muß sein. Diese Software hat einen 
Signalinterpreter für CAN,RS232,I2C und SPI. Dieses Teil ist so eine 
Zeitersparnis. Vielleicht kannst Du Dir so etwas ausleihen -> Dann 
fliegen die Fetzen...

Übrigens das Beispiel auf Seite 8 mit dem Strich zeichen und dem Löschen 
des Displays benutzt das Smallprotokoll. Daraufhin müßtest Du ein ACK 
vom Display lesen können. Probier doch das Auslesen einmal aus.

Ich weiß nicht wieviel Zeit Du noch hast. Aber meine Erfahrung ist, dass 
Du langfristig nicht um einen Automaten herumkommst. Oder willst DU 
wirklich Deine µC immer nur in sinnlosen Warteschleifen verharren 
lassen, nur weil das Display nicht aus dem Quark kommt?

Weiterhin viel Erfolg

Carsten

von Daniel S. (daniel-r-s)


Lesenswert?

Das mit dem logicport habe ich mir grade mal angesehen. mal schauen ob 
ich jemanden finde der sowas in der art zufällig hat und mir leihen 
kann. ansonsten sinds weiterbildungskosten die ich wiederum steuerlich 
absetzen kann. Habe jetzt mal so viel rausgefunden das mir der 
eingangspuffer nach einem befehl nicht mehr entleert. ACK wird ebenfalls 
nicht generiert(Protokoll aktiv). daher schmeist es mir die Bytes des 
gesendeten arrays durcheinander. mit eingeschaltetem smallprotokoll 
funktioniert im übrigen überhaupt nichts mehr.
soll verstehen wer will, habe am code nichts geändert.

werde jetzt wohl nicht mehr drumm rum kommen mir die signale mal 
anzuschauen.

Leider bin ich an den Prozessor gebunden.
Dadurch wird mir wohl nichts anderes übrig bleiben als unzähliche 
timeraufrufe vorzuhnemen. aber vieleicht fällt mir da ja noch ne lösung 
ein.

Zeit habe ich noch 2 monate. sollte eigentlich reichen. vorrausgesetzt 
ich bekomm das jetzt mal langsamm zum laufen:-(

von cskulkw (Gast)


Lesenswert?

Wo ist denn Dein Standort?

von Grü (Gast)


Lesenswert?

Ich kenne das eDIP320 oder wie das heisst. Ist aber auch schon sehr 
lange her. Ich habe sehr lange an meinen Problemen gesucht. An Deiner 
Stelle würde ich max. 1/s etwas senden. Klappt das die Zeit verkürzen. 
Ich musste bei mir feststellen, dass sich die Timings extrem vom 
Datenblatt unterscheiden.

Um ehrlich zu sein: Ich bin von diesen EA Displays geheilt und werde mir 
das nie mer freiwillig antun.

Greets

von Peter D. (peda)


Lesenswert?

Die Beschreibung ist etwas dürftig.
Also:

Ein DC1-Paket darfst Du erst senden, wenn genügend Empfangsbuffer frei 
ist.
Das ACK darauf bedeutet nur, das Paket ist empfangen worden. Es ist dann 
aber noch lange nicht ausgeführt worden.

Um festzustellen, ob wieder genügend Empfangspuffer frei ist, mußt Du 
ein DC2-Paket senden und die Antwort auswerten.
DC2-Pakete kann man beliebig oft versenden.


Peter

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.