Entfernungsmessung mit dem I2C Bus und SRF02 1

[achim S.]

In deinem Beitrag 14 erwänst du auch das Datenblatt auf der Seite. Das Programm ist aber komplett in Basic geschrieben. Ist für mich nicht zu verwenden.

 

[Hero_123]

Sage einfach was ich besser machen kann oder sogar falsch ist.

Siehe meinen Beitrag 16 und 19 - Stichwort "Versionierung"

 

[Hero_123]

Zu Deinem "Tut" der SW - wenn Du externe h- (und somit externe c-Files) includierst, die NICHT (!!) von Dir bzw nicht Teil des C-Compilers sind - gib' wenigstens die Quellen dafür an.
Was soll denn ein User mit Deinem Programm anfangen, wenn die "i2clcd.h" und "i2cmaster.h" (und die dazugehörenden c-files fehlen); ohne diese compiliert das Ding ja nicht mal.

 

[Hero_123]

Achim

Ich habe mir mal Deine Software angesehen. Naja, da sind ja einige ... unorthodoxe Sachen drin (Funktionen, Aufrufabfolge, keine Fehlerbehandlung)... schau Dir mal an:
- Aufrufabfolge: "startanzeige()", "testbus()" etc
- Fehlerbehandlung: I2C funktioniert nicht, SFR02-Modul fkt nicht, LCD fkt nicht - was passiert dann
- Anzeigen bei Fehlern (welche Fehler kann es geben, wie reagieren etc)
Auch hätte man die Funktionen etwas einfacher bzw sinnvoller machen können.

Ich habe den Eindruck, Dir geht es darum, ein "Tut" auf Biegen oder Brechen rauszuhauen (speziell bei Software) ohne auch eine Fehlerbehandlung zu implementieren oder auf eine korrekte bzw sinnvolle Aufrufabfolge zu achten.
Dein Anspruch ist ja, "Tuts" zu erstellen, damit Anfänger beginnen können, sich in die Materie einzuarbeiten (die Intention ist ja durchaus lobenswert) , und da sollte die SW / HW schon korrekt und sinnvoll sein.

Nichts für ungut

Du verwendest ja den ATMega1284p - da kannst Du ja leicht ein paar LEDs als "Fehleranzeigen" implementieren, genügend IOs hat das Ding ja und Du wirst ja wohl auf Deiner Platine P30 diese frei verfügbar (und schon verdrahtet!) haben...

 

[achim S.]

Muss ganz ehrlich sagen, auf die Sache mit der Fehlerbehandlung bin ich noch nicht gekommen, ist aber eine super Idee.
Es geht mir nicht darum ein Programm auf Biegen und Brechen zu machen. Versuche immer kleine Programme zu erstellen die ich jederzeit weiter verwenden kann und neue Funktionen einzubinden.

- Aufrufabfolge: "startanzeige()", "testbus()" etc
- Fehlerbehandlung: I2C funktioniert nicht, SFR02-Modul fkt nicht, LCD fkt nicht - was passiert dann

Wie kann ich die Aufrufabfolge verbessern? Durch die kurzen Programmaufrufe unterteile ich doch die Funktionen und kann dadurch auch besser Fehler finden. In diesem Programm habe ich die Kontrolle I2C Bus untergliedert. Wenn die Adresse des SRF02 nicht stimmt wird es angezeigt. Fehleranzeig für das Display mach ich auch. Du schreibst "was passiert dann ..", kann ich mir nur eine LED die blinkt vorstellen.

Auch hätte man die Funktionen etwas einfacher bzw sinnvoller machen können.

Das müsstest du mir mal näher erklären. Hatte eigentlich die Erfahrung gemacht, das es kaum noch kürzer oder einfacher geht ohne die Übersicht zu verlieren.
Beim Atmega1284p habe ich 2 LEDs angeschlossen. Kann auch über eine zusätzliche Anzeige mit LEDs mehr machen. Sehe das Problem vielleicht beim Attiny841. Da sind die Pins knapp.

 

[Hero_123]

Also gut:

Wie kann ich die Aufrufabfolge verbessern?

Siehe Beitrag 24 - Stichwort "Aufrufabfolge" oder "sinnvolle Reihenfolge der Funktionsaufrufe" - die ist nämlich .... Murks - schau sie Dir nochmal GENAU an ...

Fehleranzeig für das Display mach ich auch.

Wo??

Du schreibst "was passiert dann ..", kann ich mir nur eine LED die blinkt vorstellen.

Das ist das Mindeste an Fehleranzeigen - siehe Beitrag 24

Das müsstest du mir mal näher erklären.

Z. B. die Anzeige der Werte - es reicht, immer nur den Wert auf dem Display zu aktualisieren (und noch anderes, das findest Du aber bestimmt selbst heraus...)

Du siehst, es gibt VIEL Verbesserungspotential....

Und wenn Du schon dabei bist, eine neue Version zu erstellen - vergiss nicht:
- Versionierung
- Angabe der Quellen
- Richtigstellen der Kommentare (sind teilweise auch falsch ....siehe i2c_start(adr_srf02 + 1); // I2C Slaveadresse übergeben )

 

[Hero_123]

Beim Atmega1284p habe ich 2 LEDs angeschlossen. Kann auch über eine zusätzliche Anzeige mit LEDs mehr machen. Sehe das Problem vielleicht beim Attiny841. Da sind die Pins knapp.

Dann mache eben eine neue Platine mit I2C Verbindung mit einem MCP23017 und 8 per Hardware (RC-Glied!!) entprellte Taster und 8 verschieden farbige LEDs - und schon ist das Problem beim Attiny841 erledigt - ganz einfach und kompatibel!! So eine Extender-Platine ist sowieso ganz sinnvoll!

 

[LotadaC]

Der Tiny441/841 besitzt zwei UARTs und ein SPI. Das sonst Tiny-typische USI ist hier einem echten TWI gewichen, welches allerdings nur(!) als Slave verwendet werden kann.

Nur fürs Debugging einen Master-TWI implementieren?

Entweder ein SPI-Portexpander oder irgendwas über UART wäre mMn sinniger...

 

[Hero_123]

Nur fürs Debugging einen Master-TWI implementieren?

Entweder ein SPI-Portexpander oder irgendwas über UART wäre mMn sinniger...

Ich wusste nicht, dass der Tiny441/841 nur als Slave bezüglich TWI verwendet werden kann.
Da der Kollege eh' keine Ahnung vom SPI hat (siehe Beitrag 13!!), empfiehlt sich wohl am besten UART - davon hat er allerdings auch keine Ahnung.

 

[LotadaC]

In ASM machst Du den UART mit nem Fünfzeiler klar, gesendet wird, was Du ins UDR schreibst. Also 256 Statusmeldungen auf eibfachstem Weg.
Unter BASCOM reicht ein einfaches Print, der Compiler macht dann selbst den UART klar.
(wobei der Tiny jetzt zwei hat, im worst case isses dann immer der falsche)

Um Kommandos entgegenzunehmen halt den Receive-IRQ...

 

[achim S.]

Mit SPI hast du Recht. Ist das aller erste mal das ich was mit SPI mache. Den MCP23017 am I2C Bus Master gibt es bereits. Auch die Tasterentprellung nach Peter für den Atmega1284p und Attiny841 gibt es bereits. Wie du schon richtig sagst, der Attiny841 hat bei I2C nur Slave. Eine Verbindung zwischen den beiden mit dem I2C Bus als Master und Slave gibt es auch, ist allerdings nicht als Tut erschienen. Der I2C Bus beim Attiny841 unterscheidet sich stark zu anderen ICs.
In dem Programm mit der P30 ist eine Abfrage zum Display drin. Wenn die Adresse zum Display stimmt wird es angezeigt, sonst halt nicht.
Das mit der Anzeige verwende ich z.B. bei Multitasking und der Laufschrift. Bin jetzt erst einmal an den LEDs dran.

 

[Hero_123]

In dem Programm mit der P30 ist eine Abfrage zum Display drin. Wenn die Adresse zum Display stimmt wird es angezeigt, sonst halt nicht.

Und was sieht der User, wenn die Adresse zum Display NICHT stimmt oder der I2C NICHT funktioniert - nichts. Er sieht ÜBERHAUPT nichts.
Er weiß nicht, ob das Programm korrekt kopiert/abgetippt/kompiliert/übertragen wurde - er ist komplett hilflos.
Er weiß nicht mal, ob der Prozessor funktioniert, ob die Schaltung korrekt ist usw...

Du hast jetzt über 10 (!!) Jahre Erfahrung mit ATMega's (NIBO2 etc!) und dennoch willst Du unerfahrenen Usern oder Bastlern mit derartigem Murks wie diesem Programm "helfen" (da sind ja nicht mal die Kommentare korrekt). Da hätte ich schon etwas mehr Weitsicht hinsichtlich Darstellung /Abfangen von Fehlern erwartet und einen Test dieser.
Aber wenn man Codefetzen zusammenkopiert...

Das mit der Anzeige verwende ich z.B. bei Multitasking

Multitasking - aha! Hoffentlich ist da Deine SW etwas "robuster" hinsichtlich möglicher Fehler

Bin jetzt erst einmal an den LEDs dran.

Verwende den UART zur Darstellung von Zuständen/Fehlern auf dem PC (hTerm läßt grüßen); genügend SW bezüglich Verwendung des UART gibt es ja im Netz (P. Danneger, P. Fleury etc).
Mach DAS erst mal, das geht OHNE Modifikation Deiner Hardware, Kollege!!
Und eine Fehlersuche per UART ist das Einfachste, da entsprechend ausbaufähig!!

 

[LotadaC]

Der I2C Bus beim Attiny841 unterscheidet sich stark zu anderen ICs.

?
Die Controller haben doch gar keinen Bus, der Bus ist die Verbindung zwischen den Teilnehmern.
Die Controller besitzen Schnittstellen, mit denen sie auf den Bus zugreifen können (oder eben auch nicht, bzw eben unterschiedliche Schnittstellen).
Meintest Du das?
Abgesehen von den X-Core-Controllern sind mir folgende TWI-Hardware-Architekturen bekannt:

• Vollwertiges Master/Slave-TWI - das, was wahrscheinlich die meisten ATmega haben; der einzige mir bekannte Tiny ist der ATtiny48/88
• USI - Universelles serielles Interface, salopp gesagt ein einfaches Schieberegister mit direktem zugriff auf Pins kombiniert mit einem 4-Bit-Zähler (der durch Flanken am Pin getriggert wird), dazu 'ne Interrupt-Maschine und 'ne Start-Condition-Detection. Entsprechend konfiguriert laßt sich damit mit überschaubarem Aufwand Slave-TWI, und (mit zusätzlichem Aufwand (weitgehend manuelle Clock-Erzeugung) auch Master-TWI implementieren. Mir bekannte Tinies sind: ATtiny25/45/85, ATtiny24/44/84, ATtiny2313/4313, ATtiny26/261/461/861, ATtiny87/167, ATtiny1634 und der ATtiny43U, sowie die entsprechenden Low-Voltage- und Automotive-Varianten.
• Slave-TWI - kann halt nur als Slave genutzt werden. Entsprechend existiert keine Clock-Erzeugung usw; die Konfiguration ist deutlich überschaubarer. Mir bekannte Tinies sind: ATtiny441/841, ATtiny20, ATtiny40, ATtiny828 und der ATtiny1634 (ja, der hat Slave-TWI und USI)
• keine TWI-Hardware - alle anderen halt...

Also meiner Meinung nach sind die Unterschiede zwischen USI und vollwertigem TWI deutlich größer, als die zwischen vollwertigem- und Slave-TWI. Insbesondere die nötige State-Machine sollte beim USI wesentlich aufwändiger ausfallen (so muß zB nach der Start-Condition sowie für die Behandlung des N-/ACK-Bits jedesmal mit dem 4-Bit-Counter jongliert, die Adresse manuell ausgewertet werden usw.)