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
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
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
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
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 ;-)
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
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:-(
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.