Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Heribert, > > > ich habe jetz mal Andrès Rat befolgt und die Interrupt-Leitung der eDIPs angeschlossen. > > Mal sehen, event. hat es ja daran gelegen das das ständige Pollen via edip.receiveframe() die Ursache > > für das Problem war. > > Eigentlich sollte das Problem, daß ein eDIP den Bus infolge zu schnellen Sendens lahmlegt, > mit der aktuellen Version 0.50b behoben sein, da vor der Veröfentlichung jemand (nicht ich) > bereits ca. eine Woche lang einen Streßtest mit seinen unzählen im Haus befindenden eDIPs > gamacht hatte, und es bisher zu keinerlei Ausfällen mehr kam. > > Allerdings habe ich nur bei den ASM-Routinen eigene Lese und Schreibroutinen > mit Clockstreching als Ersatz für die internen I²C-Bus-Routinen geschrieben. > Die direkten I²C-Aufrufe in edip.c2 erfolgen noch ohne Clockstreching. > Daher kann ich nicht ausschließen, daß noch nicht alle Probleme beseitigt sind. > Bis zur finalen Version von edip.c2 werde ich nach und nach die ASM-Routinen erweitern, > damit alles, außer das Senden der Startbedingung samt der Adresse, über Clockstreching läuft. > Das Problem ist einfach, daß das eDIP240 die Daten nicht so schnell > verarbeiten, wie die CC2 senden kann. > Das betrifft u.U. auch das Pollen zum Abfragen des eDIP-Sendepuffers. > Daher sollte im normalen Einsatz eine Interruptleitung für den I²C-Bus verwendet werden, > und so nur bei einem Low-Pegel der Leitung <code>edip.receiveframe()</code> aufgerufen werden. > > In Deinem Fall in etwa so: > <code> > o=0; > while not ports.get(IntPort) > { > o=o%2; > edip.receiveframe(eDIPAddr[o],Display[o]); > o=o+1; > } > </code> > Aber noch ein Problem könnte evtl. sein, daß Du bei jedem Schleifendurchlauf > den Displayinhalt komplett aktualisierst: > <code> > if var.Anzeige[o] ==1 anzeige.Kist (eDIPAddr[o]); > else > if var.Anzeige[o] ==2 anzeige.Sist (eDIPAddr[o]); > else > if var.Anzeige[o] ==3 anzeige.SWist (eDIPAddr[o]); > else > if var.Anzeige[o] ==4 ; > else > if var.Anzeige[o] ==5 anzeige.ASollIstK (eDIPAddr[o]); > else > if var.Anzeige[o] ==6 anzeige.betrieb (eDIPAddr[o]); > else > if var.Anzeige[o] ==7 anzeige.oel (eDIPAddr[o]); > else > if var.Anzeige[o] ==9 {anzeige.ver (eDIPAddr[o]);var.Anzeige[o] =0;} > else > if var.Anzeige[o] ==10 {anzeige.Temp (eDIPAddr[o]);} > </code> > Es würde reichen, wenn Du das nur machst, wenn sich der Wert > von <code>var.Anzeige[o]</code> ändert. > Denn sonst bringt die Interrupt-Leitung wenig, wenn Du immernoch nonstop Daten > zu den eDIPs sendest. > Das würde ganz einfach gehen, wenn Du die diese Routinen in eine eigene Funktion setzt, > und in dieser auch das setzen der Anzeige-Variabel übernimmst. > Diese Funktion rufst Du dann einfach aus den Auswertung der Touchtasten auf, > wenn die Menüposition geändert werden soll. > > MfG André H.
