RaspberryPi - I2C - unter LAZARUS

[hpt]

Liebe Experten!
Wer von Euch hat den I2C-Bus am GPIO des RaspberryPI schon erfolgreich programmiert? Damit meine ich jetzt kein Command_Line Programm, sondern eine GUI-Standart-Anwendung unter Linux in Lazarus. Im Netz habe ich keine befriedigenden Anwendungen oder wenigstens die elementaren Teile davon gefunden. Ich beschäftige mich seit einiger Zeit mit dem I2C-Bus und Anwendungen für I2C-Sensoren, welche ich aber bis jetzt in der Atmel-Welt in BASCOM programmiert habe.
Am Raspberry bin ich soweit, dass ich die Adresse des Bausteins mit dem "i2cdetect -y 1" sehen kann.
Meine Motivation wäre jetzt, ein I2C-Device von Lazarus aus, auf ,z.B. Knopf-Druck zu I2C-starten, I2C-lesen, oder schreiben, I2C-stopp usw.zu können. Die Auswertung eines "Ack" wäre auch ganz hilfreich.
Es gibt wohl Ansätze von Programmen, aber meist in anderen Sprachen und mit diversen Librarys welche von Lazarus aus nicht einzubinden gehen, zumindest ist es mir noch nicht gelungen.
Ich würde mich über jede Art der Hilfe sehr freuen.
Danke schon mal
HPT

[Christian]

Was erhoffst du dir davon das Thema 2x im selben Forum zu posten ?

[hpt]

Hi - ich bin einen kleinen Schritt weitergekommen. Danke an Socke! Jetzt wäre noch schön, könnte man das Acknowledge vom I2C abfragen. Nochmals die Bitte - wer hat sich mit dem I2C-Bus unter LAZARUS schon beschäftigt. Es müsste ja mehreren Leuten interessieren oder ?
Würde mich über Erfahrungsberichte auch freuen....
Schönen Abend HPT

[mschnell]

Nochmals die Bitte - wer hat sich mit dem I2C-Bus unter LAZARUS schon beschäftigt. Es müsste ja mehreren Leuten interessieren oder ?

Nö. Eigentlich ist das nicht der richtige Weg.

Bei Schnittstellen wie I²C (oder USB oder SPI), die eine bestimmte Interface-Hardware verwenden um auf eine ganze Menge unterschiedliche Geräte zuzugreifen, verwendet man richtigerweise eine doppelte Treiber-Struktur. Ein Treiber für die Interface - also (I²C-) Bus-Konnektor - Hardware und einen Treiber für das Gerät hinter dem (I²C) Bus. Dazwischen gibt es ein "Subsystem", das alle (I²C-) Bus - Geräte hostet.

Sowohl der Treiber für die I²C-Bus - Hardware als auch der für das einzelne an den Bus angekoppelte Gerät ist dann ein Kernel - Treiber (Modul) und muss in C geschrieben werden. Das Endgerät wird dann abstrakt als Device im "/dev" Filesystem dargestellt. Auf dieses Device-File kann dann die (in Lazarus geschriebene) Userland - Software mit völlig normalen Mitteln (File open ...) zugreifen.

Also: "I2C-Bus unter LAZARUS" ist der falsche Ansatz.

Natürlich geht es auch anders, aber das ist die Linux-mäßige Methodik.

-Michael

[Christian]

Soweit mit bekannt schreibt für einzelne I2C Bus Bausteine keiner eigene Treiber. Ich kenn das auch so das man da über /dev/i2c direkt drauf zugreift.

[hpt]

guten Abend
Auf jeden Fall freut es mich, wenn sich jemand meldet. Ich bin eher für anschauliche Beispiele. Es ist mir klar, dass es unterschiedliche Ansätze gibt. Aber wirklich überzeugend ist, wenn man Code-Beispiele hat, die man probieren kann. Theorie ist, wenn man alles weiß, aber nichts funktioniert und Praxis, wenn es funktoniert und keiner weiß warum - so hat mal jemand gesagt, dem es wohl ähnlich gegangen ist wie mir!
Es gibt immer mehrere Wege, welcher der richtige ist, soll man selbst erkennen - das wäre schön.
Bitte um konstrukive Beispiele - wie lässt sich der I2C- Bus ansprechen und mit LAZARUS steuern?
Ich bin jedenfalls für Anregungen offen und sehr dankbar.
Noch bin ich nicht wirklich zufrieden....
Wo sind die Experten -- es grüßt ein Imperte!

[Christian]

hasts damit
http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi/de#4._rpi_hal-Hardware_Abstraction_Library_.28GPIO.2C_I2C_und_SPI_Funktionen_und_Prozeduren.29
schonmal probiert ?

[hpt]

mit der hal-componente hatte ich keinen Erfolg. Entweder mache ich etwas nicht ric htig, jedenfalls gibts bei mir schon beim Einbinden errors.

[pluto]

Nun ich weiß nicht ob es auch für den PI gilt, aber für ein Uart schon:
Wenn ich ein atMega per Uart an einem PC anschließe kann ich per echo auf das Device schreiben.

Habe mir dafür ein kleines Interface geschrieben für Arduino. So kann ich Problemlos auch von einer Lazarus-Anwendung aus auf meine Platine zugreifen. Außerdem ist dieser Weg meiner Meinung nach viel Sicherer.

Wenn du ein Fehler machst, ist dein PI hin. Machst du bei Arduino ein Fehler, geht vielleicht die Platine verloren oder einzelne Bauteile, aber nicht der PI.

So ein Uart Kostet ca um die 3 bis 4 Euro. Mein Tipp: Achte darauf das der Uart ein DTR pin hat. Dann hast du ein Auto Rest.

[Socke]

Soweit mit bekannt schreibt für einzelne I2C Bus Bausteine keiner eigene Treiber. Ich kenn das auch so das man da über /dev/i2c direkt drauf zugreift.

Die Kernel-Entwickler sagen: es geht beides. Kernel-Treiber für einzelne Bausteine sind immer dann interessant, wenn viele/verschiedene Anwendungen darauf zugreifen sollen.

Jetzt wäre noch schön, könnte man das Acknowledge vom I2C abfragen.

Das gesamte I2C-Protokoll wird vom Linux-Kernel verwaltet. Du kannst nur noch sagen, welche Daten über die Leitung gehen. Falls der Baustein kein Acknowledge sendet (bzw. kein Baustein mit der passenden Adresse am Bus hängt), sollten die Linux-Funktionen einen Rückgabewert von nicht 0 haben.

Bitte um konstrukive Beispiele - wie lässt sich der I2C- Bus ansprechen und mit LAZARUS steuern?

Zu genau dieser Frage hatte ich deine E-Mail beantwortet. Falls da noch weitere spezifische Fragen sind, kannst du die natürlich gerne stellen. Andernfalls wäre es gut, wenn du deine Frage weiter eingrenzen kannst (ansonsten kommst du immer wieder auf die genannten Seiten zurück).

[hpt]

... es ist interessant, weil es immer mehrere Lösungen gibt und ich denke mir, dass gerade dieses Forum sich mit Lösungen mit LAZARUS beschäftigt. Zu Pluto darf ich sagen, auch ich habe mit ATmega's schon eingies erfolgreich probiert, aber mit dem RPI hat man halt doch mehr Möglichkeiten. Socke hat mir auf die Sprünge geholfen, damit ich in Lazarus überhaupt mal eine Kommunikation mit dem I2C-Bus erreicht habe - danke nochmal dafür.

Jetzt geht es mir noch darum, Fehlermeldungen auszuwerten, wenn z.B. ein oder auch kein Device am Bus ist, das entsprechend anzuzeigen. Noch ist mir nicht ganz klar, wie man das am Besten löst. Also frage ich nochmals in die Runde, ob jemand das "Acknowledge" am I2C-Bus, welches der Slave nach der Adressierung zurückgibt schon mal ausgewertet hat, und wie !?

Wahrscheinlich liegt es auch an mir, dass ich so neugierig bin, aber es könnte auch andere interessieren, wie und womit man etwas lösen kann!
Mit Lazarus beschäftigt sich sonst von meinen direkten Bekannten niemand - deshalb nochmals an euch die Bitte um Diskussion und Lösungsvorschlägen.
Ich danke schon mal ganz herzlich dafür.

[mschnell]

mit ATmega's schon eingies erfolgreich probiert, aber mit dem RPI hat man halt doch mehr Möglichkeiten.

Noch viel mehr Möglichkeiten bezüglich "embedded" Peripherie hast Du mit dem BeagleBone.

Das ACK am I²C Bus ist eine einzige Signal-Flanke auf dem Draht. Das wertet schon der "Treiber" für die I²C Kommunikations-Hardware (unabhängig vom über I²C angesprochenen End-Chip) aus und sollte (wie bereits oben beschrieben) durch einen Rückgabe-Wert anzeigen, wenn vom Chip statt einer Antwort (also ACK) ein Timeout (also kein ACK) kommt.

Wenn das auf den bestimmten Chip nicht passt (kein ACK bedeutet nicht Timeout-Fehler, sondern etwas anderes) wird es u.U. schwierig.

(Ich persönlich koppele für solche Sachen lieber einen 2€-PIC Chip per USB Serienport-Emulation an die PC-oder ARM-Hardware und behandele dort die dirty Details der Low-Level Kommunikation mit der Embedded Hardware da).

-Michael

[pluto]

Zu Pluto darf ich sagen, auch ich habe mit ATmega's schon eingies erfolgreich probiert, aber mit dem RPI hat man halt doch mehr Möglichkeiten. Socke hat mir auf die Sprünge geholfen, damit ich in Lazarus überhaupt mal eine Kommunikation mit dem I2C-Bus erreicht habe - danke nochmal dafür.

Wenn man weiß was man macht, ja, aber ein Fehler und dein Bord ist hin. Ich denke mit einem AtMega kann man sehr viel machen. Klar, ein PI kann vielleicht mehr, z.b. Musik Abspielen aber das kann ein atMega auch.
Aber das muss halt jeder selbst wissen.

(Ich persönlich koppele für solche Sachen lieber einen 2€-PIC Chip per USB Serienport-Emulation an die PC-oder ARM-Hardware und behandele die dirty Details der Low-Level Kommunikation mit der Embedded Hardware da).

Muss ich mal nach Googlen, aber ich denke, dass kommt meiner Lösung schon recht nahe und ist auch Sinnvoller.

Die Gripo Leiste geht direkt an den Prozessor von PI. Ein Kurzschluss(was schnell passieren kann) und das ganze Bord kann hin sein(habe ich jedenfalls gelesen) oder einmal + und minus vertauscht und Fertig oder einmal zu viel Spannung angelegt.

so ein atMega mag zwar auch nicht zu viel Spannung, aber ihm macht es nichts aus wenn man + und - vertauscht. Dann wird er nur sehr warm.
Selbst Kurzschlüsse halten die aus. Bei mir sind schon mal die "Funken" geschlagen.

[mschnell]

Muss ich mal nach Googlen, aber ich denke, dass kommt meiner Lösung schon recht nahe und ist auch Sinnvoller.

z.B: http://www.microchip.com/wwwproducts/De ... MX210F016B

Kostet im Einzelstück 1.62 nimm aber lieber den für 20 Cent mehr mit doppelt so viel Flash).

Gibt es im Bastler-freundlichen 28 PIN DIL Gehäuse. Es gibt natürlich auch preiswerte Bastel-Platinen mit einem PIC32 Chip drauf (-> http://www.dipmicro.com/store/PCB-PK28 für ca. 4 Euro, mit USB habe ich auf den ersten Blick http://microcontrollershop.com/product_ ... ts_id=4641 ca. 15 Euro gefunden.).

Für USB brauchst Du keine zusätzliche Hardware.

Hat I²C Hardware eingebaut (und Uart, I²S, SPI, Counter, PWM, Analog in, ...)

In der Serie gibt es auch (pin-) kompatible viel schnellere Chips mit viel mehr RAM und Flash bis 200 Mips (512 K Flash, 640 K RAM und Ethernet Hardware für ca. 8 Euro).

IDE-Software und C-Libraries gibt es umsonst zum Download ("MPLABX", "XC32" Compiler, bei dem man allerdings nur zeitbegrenzt oder nach Bezahlen die Optimierung einschalten kann, geht aber sowieso meist auch ohne.)

Zum Programmieren mit MPLAB brauchst Du einen "PicKIT-3" Adapter für ca 50 Euro. Wenn Du die Arduino-kompatible "Pinguino" Umgebung mit dem http://microcontrollershop.com/product_ ... ts_id=4641 Board verwendest, brauchst Du den auch nicht (habe ich aber noch nicht versucht).

ist eine MIPS32 CPU. Dafür gibt es einen FPC-Cross-Compiler (allerdings noch keine RTL)

-Michael

[pluto]

Kostet im Einzelstück 1.62 nimm aber lieber den für 20 Cent mehr mit doppelt so viel Flash).

Danke für den Hinweis. Ist das vergleichbar mit atMel?

Für USB brauchst Du keine zusätzliche Hardware.

Das ist Praktisch. Bei atMel brauche ich in der Regel ein Uart. Es gibt zwar auch Typen wo der mit eingebaut ist z.b. 16U8(meine ich) aber leider nur in SMD bauweise.

mit USB habe ich auf den ersten Blick http://microcontrollershop.com/product_ ... ts_id=4641 ca. 15 Euro gefunden.).

OK. Dann ist atMel doch günstiger.

Z.B. ein attiny kostet ca unter 1€ + ein Uart kostet ungefähr 3 bis 4€. Fertig. Vielleicht noch ein Externen Taktgeber.
Muss aber nicht unbedingt sein.

Zum Programmieren mit MPLAB brauchst Du einen "PicKIT-3" Adapter für ca 50 Euro. Wenn Du die Arduino-kompatible "Pinguino" Umgebung mit dem http://microcontrollershop.com/product_ ... ts_id=4641 Board verwendest, brauchst Du den auch nicht (habe ich aber noch nicht versucht).

Das ist das Schöne an Arduino. Hier braucht man nicht unbedingt Teure Hardware um ein IC zu Programmieren.
Z.B. gibt es von Arduino günstige Nachbauten. Eins kostet sogar unter 10€, Probiert habe ich es noch nicht, aber ich bin mir sehr sicher das man damit auch einen atMega Programmieren kann.

Hardware Real-Time Clock and Calendar (RTCC)

Das klingt schon mal gut. Bei Arduino gibt es sowas nur Extra. Diese Pic's sind auch Doppelt so schnell wie Arduino. Aber die Spannung gefällt mir nicht so.

Operating voltage range of 2.3V to 3.6V

Bei Arduino ist sie bei bis 5,5 V von 1,8(Da bin ich mir gerade nicht sicher). Sie können sogar mit Wechselspannung arbeitet(angeblich).