Hallo, ich arbeite gerade an einer "Testplatine" auf Basis eines Atmega1284. Die Grundplatine wird ca. 180x250mm groß werden. Auf der Platine sind u.a. 7 32polig Messerleisten aufgelötet, in diese werden dann Einzelplatinen mit jeweils einem i2c 16bit-Portexpander MCP23017 aufgesteckt werden wird. Ebenso wird ein 4 Zeiliges LCD mittels Flachbandkabel, ca. 60cm, mit dem i2c verbunden werden. Meine Frage nun zum i2c. Der Bus auf Hauptplatine und zwischen den Messerleisten wird ca. 30cm lang sein, auf jeder der steckbaren Platinen werden es ca. 10cm sein. Zum LCD 60cm. Ich spiele nun mit dem Gedanken gleich nach dem µC einen i2c Extender P82B715 (oder glw.) einzubauen, das gepufferte i2C dann auf meine Messerleisten und zum Display zu schicken. Auf jede der steckbaren Platinen und an das LCD kommt dann ebenfalls ein Extender. Auf dem i2c wird nicht in Highspeed gesenden.. einzige Highspeed-Anwendung wird wohl das beschreiben des LCD's sein. Die ganzen Portexpander werden bei Bedarf vereinzelt angesprochen, nie mehrere kurz hintereinander. Das Display wird auch nur bei bedarf aktualisiert. Soll ich die Extender einbauen, oder schafft der normale i2c den maximal 100cm langen Bus alleine? Danke Gruß Stefan!
bei 100kHz sehe ich erst mal keine Beschränkung, kommt halt auf die Kabelkapazität und der Treiberleistung deiner Bauteile an. Ich würde erst mal einen Musterbau ohne Extender machen und mir evtl. Probleme ansehen. Ein LCD muss auch nicht immer aktualisiert werden alle 250ms reicht, schneller kann man kaum lesen.
Versuch einen anderen io expnader als den MCP23017 zu nehmen. Bei den Versuch mehrerer Bausteine gleichzeitig an einen i2c bus zu betreiben gab es nur Probleme mit den Pins pa7 und pb7. Siehe internet¹. Ich bin dann auf den mcp23s17 umgestiegen. ¹ http://www.microchip.com/forums/m/tm.aspx?m=831656&p=2 MfG Tobi
Danke für die Antworten! Auf einen anderen Expander umzusteigen ist leider nicht möglich, es gibt schon einige der Steckplatinen, auf denen ist es möglich einen i2c Treiber nachzurüsten (aktuell sind die Pins gebrückt). Diese Steckmodule wurden bislang einzeln betrieben. @tobi: wenn ich das richtig verstanden habe, möchten die in dem verlinkten Beitrag ein 1 Mhz-Signal an den Ports 7 einlesen?? Tritt denn das Problem auch meinen maximalen 0,5Hz auf? Ich muss lediglich 1 oder 0 abfragen machen und dies maximal 1 mal in 1 Minuten..?
Bei deinen Längen dürftest du keinerlei Probleme haben. Betreibe selber die verschiedensten IC mit 3,3V und 5V am Bus bis zu einer Länge von ca 3 bis 5m. Geht alles bei 100kHz ohne Probleme. Die anderen Frequenzen habe ich nicht getestet MFG KL
> Soll ich die Extender einbauen, oder schafft der normale i2c den > maximal 100cm langen Bus alleine? Wenn ich mich recht erinnere tauchte I2C erstmal in den alten megafetten Video2000 Viderecordern von Philips auf und da duerften aehnliche Leitungslaengen verbaut gewesen sein. Von daher sehe ich da kein Problem. Wenn es Probleme gibt dann liegen sie eher bei dir. Also Leitungsfuehrung, Stoereinstrahlung wegen unvermoegen Schaltnetzteile zu bauen usw. Ansonsten gilt das Fehler bei jeder Art von Datenuebertragung vollkommen normal sind. Du musst damit leben das alle paar Wochen auch mal ein Bit falsch uebertragen wird. Selbst wenn der Grund nur ein Blitzenschlag drei Haeuser weiter war. Der Nachteil von I2C ist allerdings das sich der Bus dann weghaengen kann. Es liegt an dir dafuer zu sorgen das du dann alles wieder sauber aufsetzt und initialisierst. Arduinokids die nur fertige Libaries verwenden sind damit aber ueberfordert. > Ein LCD muss auch nicht immer aktualisiert werden alle 250ms reicht, > schneller kann man kaum lesen. Wir leben 2016 und haben Microcontroller mit 20kRam und mehr. Also Shadowram und nur Segmente uebertragen die sich geaendert haben. In Pausen inkrementell aktualisieren. Bei fehlendem ACK neu initialisieren. Dann kannst du dein Display im Betrieb abstecken, neu anstecken und 2s spaeter ist alles wieder zu lesen. Olaf
Olaf schrieb: > Wir leben 2016 und haben Microcontroller mit 20kRam und mehr. Also > Shadowram und nur Segmente uebertragen die sich geaendert haben. Auch 2016 hat sich die Auffassungsgabe des menschlichen Hirns gegenüber jagderfahrenen Steinzeitvorfahren wohl kaum nennenswert geändert. Da nützen auch 20kB Shadow-RAM nichts.
Die Länge ist eigentlich unerheblich. In der Spec stehen maximal 400pf für jedes Signal. Das kann man bei einem kurzen Bus überschreiten, wenn man es ungeschickt macht. Das wird aber auch nicht länger als xxx werden, weil die Kapazität selbst eines einzelnen Drahts nicht 0 ist. Miss also die Kapazität deiner Anordnung aus und entscheide dann. MfG Klaus
Bezüglich MCP23017: Das Problem tritt auch bei kleineren Frequenzen auf. Es dauert nur länger bis der Fehler kommt. Laut forum: "It shows at 60Hz as well, but only once every 20 seconds or so"
Olaf schrieb: > Wir leben 2016 und haben Microcontroller mit 20kRam und mehr. Also > Shadowram und nur Segmente uebertragen die sich geaendert haben. ach was, das mache ich doch sogar auf 6x SchattenRAM fürs Nokia5110 Display Was geändert werden soll pro Menü 1-6 wird in den Schattenram vom Screen geschrieben, alle 250ms wird aus dem Schattenram der aktuelle Menüscreen aufs LCD geschrieben, bei 6 Zeilen a 14 Zeichen = 84 Bytes muss ich nicht grübeln welche Zeichen sich änderten.
:
Bearbeitet durch User
Stefan schrieb: > Soll ich die Extender einbauen, oder schafft der normale i2c den maximal > 100cm langen Bus alleine? Du hast zwei Schrauben an denen Du noch drehen kannst ohne einen Extender zu brauchen. Erstens die Pullup-Widerstände, je kleiner desto mehr Kapazität kann der Bus vertragen, ABER das ist ein zweischneidiges Schwert, du darfst nicht kleiner werden als der schwächste Teilnehmer am Bus noch erlaubt, schau also in die Datenblätter aller Busteilnehmer wieviel Strom die an den I²C-Pins versenken können wenn sie Low ausgeben wollen. Ich hab schon LCD-Module gesehen die waren diesbezüglich extrem schwächlich, man konnte auf dem Oszi deutlich erkennen wie sie beim ACK sichtlich Mühe hatten den SDA ordentlich auf Low zu ziehen. Berücksichtige bei längeren Strecken eine eventelle unerwünschte Ground-Anhebung, spendiere daher alles unbenutzte Kupfer im Kabel für die GND-Leitung. Zweitens die Taktrate, wenn Du auf dem Oszi nur noch Dreiecke siehst ist sie zu hoch, die Signale sollten schon noch wenigstens halbwegs erkennen lassen daß ursprünglich mal als Rechtecke auf die Welt gekommen sind, die aufsteigende Flanke wird immer etwas verwaschen sein aber spätestens nach der Hälfte einer Bitdauer sollte es schon annähernd den vollen High-Pegel erreicht haben. Ein Oszilloskop ist unumgänglich um die Qualität der Signale in Augenschein zu nehmen und mögliche Probleme zu erkennen, achte auch auf die Pegel der ACK-bits eines jeden einzelnen Teilnehmers, achte darauf dass Low wirklich ausreichend Low ist, bei längeren Strecken miss auch mal am anderen Ende des Kabels.
:
Bearbeitet durch User
Ich hab jetzt auf einem Steckbrett 3 MCP23017 aufgebaut, jeweils die Ports7 auf +5V gesteckt. Das ganze frage ich alle 0,5 sec ab. Bislang konnte ich keine Fehler feststellen... läuft schon seit einer halbe Stunde, mal schauen was daraus wird... bzgl. des Display aktualisieren's: ich hab es mir so angeeignet, die Displaydaten nur zu senden wenn sich daran was geändert hat. Ob das so richtig oder sinnvoll ist, ist doch egal -oder nicht?
> Was geändert werden soll pro Menü 1-6 wird in den Schattenram vom Screen > geschrieben, alle 250ms wird aus dem Schattenram der aktuelle Menüscreen > aufs LCD geschrieben, bei 6 Zeilen a 14 Zeichen = 84 Bytes muss ich > nicht grübeln welche Zeichen sich änderten. Das stimmt natuerlich. Aber da wir 2016 haben, erlaube ich es mir mittlerweile die Textbasierten Anzeigen als altmodisch zu empfinden. :) Mit den kleinen GrafikLCD hast du aber fuer gewoehnlich so 1024Byte. Da lohnt es sich schon nicht immer alles zu uebertragen. Besonders dann wenn die Schaltung Batterie betrieben ist und sie moeglichst lange im Sleepmode sein soll. Ich habe mein Schattenram in 32Segmente von jeweils 32Byte aufgeteilt und da muss dann nur noch erstaunlich wenig uebertragen werden. Olaf
Olaf schrieb: > Das stimmt natuerlich. Aber da wir 2016 haben, erlaube ich es mir > mittlerweile die Textbasierten Anzeigen als altmodisch zu empfinden. :) da die Grafik EA DOGs nicht so billig sind und sie mir auf dem Steckbrett schon 2x gestorben sind (OK ich habe sie auch lange hin und her transportiert, SW Entwicklung fällt mir halt schwerer als HW)weiche ich lieber während der Entwicklung auf Nokia 5110 aus, leben alle noch und sind billig. Grafik ist zwar nett aber Gimick wenn man 'nur'Status und Bedientext -> Menüführung braucht. Für derlei Spielereien fehlt mir die Zeit.
Melde mich nochmal zurück um einen Zwischenbericht abzugeben... auch bei mir zeigte sich immer wieder der Fehler, dass einer oder mehrere der IC's plötzlich nicht mehr auf dem Bus gefunden wurden. Dann sind sie plötzlich wieder da.... Das Problem dürfte an dem Reset-Pin des Expanders liegen! Im Datenblatt von Microchip ist dieser Pin bei den Gehäusen PDIP, SOIC und SSOP als AUSGANG!! gekennzeichnet, beim Gehäuse QFN ist er dann plötzlich als EINGANG gekennzeichnet......????????? Da stimmt doch was nicht.....?? Im Blockschaltbild und im Text ist dann nur noch von Eingang die Rede.. Ich habe diesen Pin natürlich lt. dem zuerst gesehenen Bild im Datenblatt als Ausgang deklariert und daher nicht beschaltet - was soll ich auch damit... durch den nicht beschalteten (Ausgang) - nö - es ist ja offensichtlich ein Eingang, machte der Baustein ab einem gewissen "Spannungspegel" einen Reset und verschwand auf dem BUS für die Zeit solange er im Reset ist. ich habe den Pin jetzt mit +5V verbunden und siehe da KEINE BUSAUSFÄLLE mehr! lasse das ganze jetzt mal bis morgen durchlaufen, bin gespannt was da rauskommt... Aber offensichtlich kleine Ursache - große Wirkung Im Datenblatt habe ich für die Beschaltung keine Hinweise gefunden.. Gruß Stefan
lief den ganzen Tag auch ohne nur einen Ausfall eines Busteilnehmers oder falscher Messwerte!
Joachim B. schrieb: > Grafik ist zwar nett aber Gimick wenn man 'nur'Status und Bedientext -> > Menüführung braucht. > Für derlei Spielereien fehlt mir die Zeit. Kann ich nur bestätigen. Eine GUI kostet ~90% der Entwicklungszeit, die restlichen 10% sind die eigentliche Funktionalität. Oder anders gesagt, mit Text-LCD ist man 10-mal schneller fertig.
> Eine GUI kostet ~90% der Entwicklungszeit, die restlichen 10% sind die > eigentliche Funktionalität. Noe. Ich bezug mich ja auf die optischer Wirkung der ueblichen 2x16 Zeichen LCDs. Also z.b diese Einzelzeichendarstellung mit Abstand. Das wirkt auf mich halt sehr nach 80er Jahre. Wenn man dasselbe, also nur Textaufsgabe auf einem Grafikdisplay macht dann kostet das kein bisschen mehr Entwicklungszeit. Lediglich etwas mehr Flash fuer den Zeichensatz. Aber daran mangelt es ja heute nicht mehr. Dafuer muss man sich dann aber auch nicht fuer Sonderzeichen den Arsch aufreissen. Natuerlich wenn man mehr Funktionalitaet haben will, dann muss man mehr Aufwand investieren. Halte ich aber auch fuer ueberschaubar da man viel Arbeit wieder verwenden kann. Man muss ja nicht gleich Qt nachprogramieren! Und die Preise fuer Bastler sind ja laut Pollin fuer Grafik-LCDs auch ueberschaubar geworden. Und in der Industrie sowieso... Olaf
Thread beobachten
Seitenaufteilung abschaltenBitte 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.