Ressourcen-Icon

MCP23017 mit dem I2C Bus ansteuern Software 2018-10-25

Hallo achim S.

Ich habe mir Dein *.pdf runtergeladen und dazu Fragen - könntest Du bitte Dein Originalprogramm incl. aller Include-Files hier auch zur Verfügung stellen (die I2C Lib von Peter Fleury habe ich)?
Bei Deinen "Programmschnipseln" schreibst Du ja auf Seite 5 "wenn man weiß wie" ;) (und ich weiß es nicht); außerdem fragst Du (auch auf Seite 5) den Taster ab mit "if( Data & 0x05)"... nimmste da 2 Taster oder wie machst Du das mit dem 0x05? Sollte das nicht 0x04 sein?
Und weshalb gibt es Resourcen "MCP23017 mit dem I2C Bus ansteuern Software 2018-10-25" und "MCP 23017 mit dem I2C Bus ansteuern Software" - was ist da der Unterschied?

mfg
Hero
 
Hallo Hero
habe alle Datein in ein Zip gepackt. Hoffe das ich nichts vergessen habe. Das mit der 0x05 stimmt so. Hängt mit der Abfrage vom Pin zusammen. Ist alles open soft und Hardware.
viel spass
achim
 

Anhänge

  • MCP23017 Programm 1.zip
    8 KB · Aufrufe: 17
Hallo achim S.

Vielen Dank für die rasche Antwort; ich habe mir Dein *.zip runtergeladen; leider ist in Deinem "MCP23017_Prg1.c" keine Tasterabfrage vorhanden - und genau DIE hätte mich interessiert; das "reine Toggeln" der LEDs habe ich schon selbst hinbekommen - nur die Sache mit der Tasterabfrage ... da hatte ich so meine Probleme (zu deutsch "hat nicht gefunzt" :().

Vielleicht könntest Du nochmal Dein Programm hier reinstellen, dann mit der Tasterabfrage, da Dein jetziges Programm nur das "LED Toggeln" enthält - wäre wirklich nett!
Und das mit dem 0x05 habe ich nicht so ganz kapiert - vielleicht könntest Du mich da auch etwas "erhellen" ("...das mit dem 0x05 stimmt so. Hängt mit der Abfrage vom Pin zusammmen.." hat mir nicht geholfen)

Vielen Dank schon im Voraus

mfg

Hero_123
 
Da habe ich wohl das falsche Programm genommen. Kommt da von wenn man nicht richtig hinschaut. Auf ein neues. Vergleiche das 0x05 mit der Hardware. Werde aber noch mal genau das Programm anschauen. Vielleicht habe ich einen Fehler drin.
achim
 

Anhänge

  • MCP23017 Programm 2.zip
    8,3 KB · Aufrufe: 9
Hallo achim S.

Super - vielen Dank; ich habe mir Dein "MCP23017Programm2.zip" runtergeladen, ich habe aber die if-Abfrage if (!(Data & 0x05)) geändert in if(!(Data & 0x02)), da mir Deine Abfrage auf 0x05 etwas seltsam vorkam (0x05 heißt ja, daß Bit0 = 1 und Bit2 = 4 gesetzt sind - fragst Du da 2 Taster ab? Ich habe einen Taster an B1 angeschlossen = 0x02).

Jedenfalls fkt die Tasterabfrage jetzt :).

mfg

Hero_123
 
Hallo achim S.

Ich habe mal Deine beiden Programme (LED & Taster) zu einem Programm zusammengebaut "MCP23017_LED_BUTTON.c" (mit TIMER0 anstatt delay(), watchdog und Interruptfreigabe), läuft bei mir problemlos auf einem ATMega8 mit 3.6 MHz (LEDs blinken mit 600ms); habe es hier mit reingestellt.

mfg

Hero_123
 

Anhänge

  • MCP23017.zip
    8,8 KB · Aufrufe: 12
Hallo Hero
Die ganzen Tuts und Programme sollen anregen selber was zu machen. Denke an meine Anfänge dabei zurück. Habe mir einen kleinen Fahrroboter gebaut. Die Frage dabei war: Der ist fertig und was mache ich damit?
Habe die ersten Programme immer auf einfach gemacht, damit jeder es nach vollziehen kann. Um so mehr freut mich deinen Programm. Werde es mir gern ansehen. Besonders der Teil mit dem watchdog. Habe damit noch nichts gemacht. Wenn du einen Tmer verwendest solltest du auch Multitasking damit versuchen. Die Erklärungen dazu stehen bereits im Netz.
achim
 
Die beiden ICs gibts übrigens auch für den SPI-Bus. Statt der (ersten) "0" ein "s" im Namen...

Was ich allerdings (schon bei den PCFs) nicht nachvollziehen kann, ist der Hype um diese Portexpander. Warum sind die Dinger so beliebt?
Sie schreiben mir (neben dem eigentlichen I²C-) ein Kommunikationsprotokoll usw vor, stellen mir genau acht bzw sechzehn Beine bereit.

Hat man nur zuwenig Beine - dann könnte man auch über einen anderen Controller nachdenken.
Sollen diese Beine räumlich vom Controller getrennt werden, kann man doch ebenso einen eigenen Controller ankoppeln - gegenüber den Expandern ist man aber deutlich flexibler.
Von der Beinanzahl her, das Protokoll betreffend, bei Bedarf kann weitere Controllerhardware genutzt werden, der Adressraum ist variabler usw.
(Wenn die Expander andere Leistungsdaten als die Controllerbeine hätten...ok)

Außerdem könnten die "Slaves" von sich aus Rückmeldungen geben (jaja, die Expander können das in gewissem Sinn auch über 'ne seperate Interruptleitung machen, aber eben über 'ne zusätzliche Leitung, und der Master weiß dann nur, daß da wer was will - wer und was muß er jetzt bei allen Busteilnehmern erfragen.)

Hat jetzt nur am Rande mit dem Thema zu tun, aber da Du Dich offensichtlich intensiv mit den Dingern auseinandergesetzt hast...
 
Du hast vollkommen Recht. Habe verschiedene Gründe darauf einzugehen. Ersteinmal geht es um die Verwendung einzelner ICS. Es gibt wunderschöne ICs zu kaufen mit den tollsten Funktionen. Leider gibt es für viele ICs zwar ein Datenblatt mit Hinweisen auf die Funktion aber so gut wie keine Beispiele. Leider sehe ich mich oftmals ausserstande etwas neues dazu zu schaffen. Finde ich ein Beispiel im Netz mit Ansteuerung oder ähnliches kann ich das ganze auseinander nehmen und weitermachen. Das andere ist die Vorstellung von Funktionen und eine Anwendung zu zeigen. Dann kann jeder damit weitermachen und eigenes zu entwickeln. Ein weitereer Grund ist die Vernetzung und WLAN und LAN. Wenn ich einen Atmega 1284p mit einem Attiny 2313 über den Bus koppeln kann, dann kann ich Rechenleistung verteilen und mehr gleichzeitig ausführen. Ein IC übernimmt die Kommunikation mit dem PC oder Handy, der andere überwacht die Sensoren, der nächste Steuert die Motore, der nächste macht eine Anzeige in Farbe, der nächste macht die Eingabe usw.
Es gibt die tollsten Sachen zu machen und viel Anwendungen und Möglichkeiten. imm einmal das Multitasking, was ich vorgestellt habe. Du kannst damit rund 1000 LEDs separat schalten mit unterschiedlichen Ein-, Aus- und Pausenzeiten. Es gibt komplexe Systeme dazu. Mag alles sein, nur ich möchte es verstehen und auch Platz für eigenen Programme haben. Du kannst beim Multitasking auch Berechnungen machen. Diese brauchst du nicht alle ms ausführen, es reichen auch alle 50 ms. Damit ergeben sich die tollsten Möglichkeiten was zu machen.
Mit SPI habe ich nichts gemacht. Hatte mich auf den I2C Bus festgelegt.
Gern können wir weiter darüber uns unterhalten. Gibt bestimmt noch viele Sachen zu klären oder zu diskutieren. Vielleicht auch für andere.
achim
 
Hallo LotadaC

Du magst wohl recht haben und es gibt bestimmt andere, intelligentere Möglichkeiten als diese Port Expander.
Zum Kennenlernen der Thematik "I2C" ist der MCP23017 imho nicht schlecht; ich möchte ihn zusammen mit einem PC9555 betreiben um überhaupt mal in das Thema "I2C" reinzukommen - ein Baby lernt auch erst Stehen, dann Gehen, Laufen und irgendwann Rennen.

mfg
Hero_123
 
Die beiden ICs gibts übrigens auch für den SPI-Bus. Statt der (ersten) "0" ein "s" im Namen...

Was ich allerdings (schon bei den PCFs) nicht nachvollziehen kann, ist der Hype um diese Portexpander. Warum sind die Dinger so beliebt?
Sie schreiben mir (neben dem eigentlichen I²C-) ein Kommunikationsprotokoll usw vor, stellen mir genau acht bzw sechzehn Beine bereit.

...
Klar, man könnte auch Schieberegister nehmen. Aber beispielsweise bei meiner Widerstandsdekade. Da verwende ich gleich 4 davon, mal ganz davon abgesehen dass noch mehr am Bus hängt. Der Vorteil ist klar, der ganze Kram läuft in Hardware. Ok, SPI auch, aber da bräuchte man pro "Client" n CE Signal. Das würde schnell kompliziert werden wenn einem die Beine ausgehen. Außerdem müsste man, wenn man Shift Register nutzt, (in meinem Fall) immer 32 Bit in Software rüber tackern, statt nur 1 Byte zu senden (+Adresse). Und die PCF sind eigentlich einfach, zumindest die die ich nutze. Nur das typische I²C Adressbyte senden und dann den Wert der Pins senden oder empfangen. Zumindest da gibt es kein großes Protokoll mit Registern etc.
Ok, Shift Register an SPI wäre Semi-Hardware (es müssen ja trotzdem alle 4 Bytes gesendet werden)...
 
aber da bräuchte man pro "Client" n CE Signal
Jain. Bei den MCPs kannst Du (wenn ich das so auf die Schnelle richtig überflogen habe) auch mehrere parallel an einer CS haben, und die dann wie beim I²C adressieren (bzw mußt das sogar). Hatte das nur eingeworfen, falls bei einem Controller eh der SPI genutzt wird, und der I²C aus irgendwelchen Gründen nicht verwendbar/vorhanden ist.

Aber wie gesagt - wenn man den eigentlichen (Haupt-) Controller nicht größer wählen kann - warum dann nicht statt des Portexpanders einen zweiten (dritten..vierten) Controller. Der kann ja auch SPI/I²C/whatever, und man selbst kann das Protokoll festlegen.
Warum einen IC mit acht I/Os, wenn ich nur fünf brauche? Oder wenn ich neun brauche, warum dann ein Achtundzwanzig-Bein-Monster?

Und wenn ich (extern) drei weitere I/Os und'n Temperatursensor brauche, warum dann nicht irgend'n kleinen Tiny mit internem Temperaturfühler über den ADC und den fünf I/Os (drei + SDA/SCL) -> 'n SOIC8?

Da kannste dann auch gleich 'n Teil der "Intelligenz" hin auslagern...

Es gibt wunderschöne ICs zu kaufen mit den tollsten Funktionen.
eben, und mit den AVR beschäftigste Dich ja eh schon - die können das auch...

Mit SPI habe ich nichts gemacht. Hatte mich auf den I2C Bus festgelegt.
SPI ist eigentlich viel einfacher, da lediglich die Inhalte der Datenregister der beiden beteiligten Teilnehmer getauscht werden.

Dafür kannst Du beim I²C viel einfacher größere Netze aufbauen (eben wegen der Soft-Adressierung/nicht nötigen CS-Leitungen). Insbesondere mit beliebig vielen Mastern (jeder Teilnehmer kann Master sein).
(Bei einem Multi-Master-Netz muß jeder Teilnehmer als Slave geschaltet werden können, folglich müßte bei einem Multi-Master-SPI jeder Teilnehmer via CS adressiert werden können. Abgesehen vom trivialen Doppel-Master-Spezialfall müßte jede CS von mehreren Teilnehmern aus aktiviert werden können, also dominant/rezessiv. Beim I²C ist das mit den Pullups und den Startconditions eh so. Dann muß noch behandelt werden, wann ein Teilnehmer die Kontrolle an sich reißen, Master werden darf, und wie verhindert werden soll, daß es mehrere gleichzeitig tun. Multi-Master-Arbitrierung. Beim SPI über die dominant-rezessive CS, beim I²C über die dominant-rezessive SDA.)
 
Da kommen doch recht Interessante Sachen raus. Stellen wir mal eine Frage dazu. Die meisten ICs haben eine spezielle Aufgabe oder 8 bis 16 Eingänge. Will ich es anders machen, kann ich einen 2313 nehmen, 10 Adresseingänge machen und ein oder zwei Eingänge oder ADC. Dadurch kann ich in einem weiten Umfeld meine Adressen einstellen. Nehme ich einen klineneren Prozessor z.B. attiny 13 oder so wird alles noch kleiner und für einen bestimmten Zweck nutzbar. Denke dabei z.B. an einen Helligkeitsfühler. Der hat nur eine Aufgabe brauch dafür euîne unterschiedliche Adresse. Packe ich noch einen Chip für die übertragung dazu kann ich es längere Strecken übertragen. Bleibt ein Problem dabei, die Ütragung an sich. Hatte schon mal USI getestet, leider gefällt es mit gar nicht. Hat da jemand ein paar Ideen dazu. So von einem Prozessor angefangen bis zur Übertragung bis zur Anwendung?
achim
 
10 Adresseingänge machen und ein oder zwei Eingänge oder ADC. Dadurch kann ich in einem weiten Umfeld meine Adressen einstellen.
Du kannst die Adresse auch zur Laufzeit ändern, über den I²C selbst. Du kannst auch auf ganze Adressbereiche reagieren lassen (durch Maskierung entsprechender Adressbits (damit kannst Du dann zB einem neuen Teilnehmer durch den Master 'ne Adresse zuteilen lassen)) - Die AVR können natürlich auch auf einen "General Call" (Slave-Adresse 0x00 scharfgeschaltet werden) .
Bleibt ein Problem dabei, die Ütragung an sich. Hatte schon mal USI getestet, leider gefällt es mit gar nicht.
Du kannst natürlich den I²C auch in Software implementieren, oder einen Controller mit echtem Hardware-I²C wählen (wenn Du USI nicht magst).
In meiner Tiny-Übersicht sind bisher nur Tinies mit Slave-only-TWI (wenn überhaupt), also nichts mit Multi-Master Arbitrierung. Wenn ich mich recht erinner (nagel mich nicht drauf fest), besitzt der Tiny48/88 'n vollwertigen (Master-fähigen) TWI. Der Tiny1634 nur Slave. Der Tiny40 sollte auch irgendeinen TWI haben... muß da echt mal weitermachen

Und dann haben meiner Meinung nach alle (insbesondere auch die 8/16beiner) X-Core-Tinies 'n Hardware-TWI.

Hat da jemand ein paar Ideen dazu. So von einem Prozessor angefangen bis zur Übertragung bis zur Anwendung?
Lösungen lassen sich für konkrete Anwendungen suchen finden. Kann natürlich auch 'ne Übungsanwendung sein...

P.S.: der Tiny2313 hat keinen internen ADC, oder meintest Du was anderes?
 
Zuletzt bearbeitet:
Beim 2313 meine ich den Vergleicher. Gibt ja auch andere schöne ICs z.B. 261. Bei der übertragung geht es mir um das Verständnis. Habe USI noch nicht verstanden. Habe zwar selber ein Beispiel in meinen Programmen, empfinde es als relativ kompliziert. Kennst du ein Beispiel mit guter Erklärung dazu?
achim
 
Hallo

Zum ATtiny 2313 - so wie ich das Datenblatt (http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2543-AVR-ATtiny2313_Datasheet.pdf) verstanden habe, gibt es MISO/MOSI, DI/DO (für USI), RxD und TxD (USART) und TWI; zum Programmieren ein ISP Interface.

Wenn ich den ATtiny2313 mit meinem ATMega8 kommunizieren lassen will, könnte ich doch somit USART, TWI, USI nehmen - das ist doch korrekt?
Und ich muss dem ATtiny 2313 erst noch einen BootLoader verpassen, damit ich den Kleinen auch programmieren kann - das ist doch korrekt?
Woher bekomme ich einen Bootloader für den ATtiny2313 und kann ich den dann über den SPI Port programmieren (wie und mit welchem Tool)? Ich möchte nicht die Arduino-IDE nehmen (kenne mich damit nicht aus)

mfg
Hero_123
 
Und ich muss dem ATtiny 2313 erst noch einen BootLoader verpassen,
Nein, grundsätzlich kannst Du ihn über SPI-ISP (es sei denn eine der beiden entsprechenden Fuses ist entsprechnd umgestellt) oder über High Voltage Parallel Programming (HVPP) programmieren.
Für das SPI-ISP hast Du die Schnittstelle bereits benannt, das SPI ist beim 2313/4313 nur fürs Programming verwendbar. Beim HVPP werden fast alle (bis auf D0 und A1) Pins verwendet. Die eventuelle Schaltung muß außerdem 12V am Reset tolerieren

Außerdem (alternativ) kann der Tiny sich selbst ("von innen") programmieren. Dazu benötigst Du natürlich 'ne entsprechende Software im Tiny, die das abarbeitet (den genannten Bootloader), und irgendeinen Kanal, über den Du dem Controller den neuen zu flashenden Code zuführst. Das kann theoretisch ein beliebiges Software-Protokoll sein (Morsecodes, IR-Fernbedienungskram, was auch immer Du implementierst), oder eben eine vorhandene Hardware-Schnittstelle. Der 2313 hat 'nen U(S)ART und 'ne USI (die kann SPI und TWI … mehr oder weniger in Hardware/mit gewissen Einschränkungen, außerdem kann es mit Einschränkungen auch als UART verwendet werden).
Beim 2313A bzw 4313 (das ist eigentlich auch ein A) kann der USART alternativ als Master-SPI verwendet werden.

Bootloader hab ich bisher nicht verwendet, wenn Du mit "Tool" die Programmier-Hardware meinst - ich hab 'n STK500 und 'n AVRisp mkII (den echten natürlich). Und früher mal zwei selbstgebastelte Programmer, die sich wie ein AVRisp (ohne mkII) verhalten - allerdings über USB kommunizieren.
Wenn Du die Programmier-Software meinst - immer irgendein AVR/ATMEL-Studio (aus BASCOM heraus flashe ich nicht).

(P.S.: unter Android hab ich mal irgend'n Flasher verwendet, der den AVRispmkII unterstützt - allerdings braucht man dafür den HexCode, und so'n Assembler selbst zu schreiben reizt mich zwar auch etwas … aber vollständig motiviert bin ich noch nicht. Inzwischen wird dort allerdings auch nicht mehr wirklich weiterentwickelt, und irgendwann wird mir @Dirk wohl einen ICE verkaufen müssen. Da der da (bisher) eh nicht unterstützt wird...)

Wenn ich den ATtiny2313 mit meinem ATMega8 kommunizieren lassen will, könnte ich doch somit USART, TWI, USI nehmen - das ist doch korrekt?
Eine der vorhandenen Hardware-Schnittstellen, oder irgendwas beliebiges in Software. Wir haben hier auch schon mal Timer und UART kombiniert, um UART über 'ne IR-LED zu senden, und mit 'nem TSOPfragmichnicht am anderen Ende am UART empfangen. Du kannst auch acht bit parallel übertragen, oder vier-Bit-Nibbles … denk nicht so beschränkt … Du bestimmst, was Dein Controller machen soll. Du mußt Deine Idee am Ende nur in Code packen...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)