Hallo!
Angeregt durch die Anfrage des Mitglieds picass habe ich mich mal hingesetzt und ein wenig mit I²C experimentiert. Mein Compiler (mikroBasic V7.6) erzeugt zusätzlich zu der I²C-Funktionalität einiges an Code zur Behandlung von Time-Out-Problemen um ein "Hängen" des I²C-Bus im Fehlerfall zu vermeiden. Ich nehme an, dass auch andere Compiler ähnlichen Code erzeugen.
Auch wenn die Programmierung mit den in den Compiler-Bibliotheken implementierten Funktionen einfach ist und bestens funktioniert, wünscht man sich manchmal einen möglichst kompakten Maschinencode.

Deshalb habe ich mal die grundlegenden Funktionen nachvollzogen mit:
- PIC18F24K22 @16MHz int. Oszillator (2* SSP,WDT Off, Brown-Out off),  SSP1 benutzt
- FRAM FM24C04 mit I²C- Interface, I²C-Adresse: 0xA2
Test:
- Schreiben von je 1 Byte an Speicherstelle 0 (Wert:15) und 1 (Wert:30)
- Lesen der beiden Bytes von Speicherstelle 0 und 1 und Ausgabe nacheinander auf PORTB

Beide Programmteile "I2C_schreiben" und "I2C_Empfangen" sind einzeln funktionsfähig.
Man sieht, wie wenige Befehle für die I²C- Kommunikation notwendig sind, wenn der eigentliche Datenaustausch über die Hardware abläuft.
Andere PICs haben nur 1 I²C-Schnittstelle, die SSPxCONx- Register sind anzupassen. Ebenso kann die Zuordnung zu den Pins anders sein, die zugehörigen TRIS-Bits sind auf 1 zu setzen.
(Die interessante Lektüre des Datenblattes bleibt also nicht erspart! )

Das mikroBasic-Programm, das daraus generierte ASM-File und das List-File findet Ihr in der Anlage.

Grüße von
PICkel 
I2C_Test.zip

Hallo PICkel!
Dein obiger Beitrag ist bislang noch ohne eine Reaktion geblieben, aber gettz!
Es sieht so aus, als ob ich mich doch mal in dieses Themengebiet einarbeiten müsste. Das wird sich zwar nicht im Sauseschritt vollziehen, im Gegenteil rechne ich mit längerer Dauer, aber ein Anfang könnte schon mal gesetzt werden. Zu diesem Anfang wird das von dir erstellte .asm-Prog eine Hilfe sein und vielleicht kannst du noch auf andere Weise als Brandbeschleuniger auftreten. Im anderen Fred sprachst du von herum liegenden FM24C04B -Bausteinen. Oder war das nur einer? Für einen ersten Test wäre so'n Teil in der Tat was Gutes. Der lässt sich kaufen, is klar, z.B. bei Farnell. Aber ich geniere mich immer, wenn ich in einem Großhandel ein oder zwei Stücke elektronischer Komponenten im Wert von je 1,80 € bestellen sollte, zudem ist der fixe Portoaufwand von z.B. 6 € dann oft gleichgroß oder gar größer. Wenn du also ein oder zwei rumliegen haben solltest, dann würde ich dich bitten, zu prüfen, ob du sie demnächst brauchst oder aber ggf. abgeben könntest.
Damit eines klar ist: das ist weder ein unsittlicher Antrag noch einer, welcher die Unsitte des Schnorrens befördern soll. Klar zahle ich deine Kosten für die Dinger und Porto - ein Großbrief würde ja ggf. reichen. Um's Geld solltest du dir wirklich keine Gedanken machen, nur darum, ob du die Rumlieger noch selbst brauchst.
Grüße, picass

Hallo picass!

Leider ist das mein einziger I²C-FRAM. Ich nehme den zu Testzwecken, weil er schneller ist als ein EEPROM und auch durch vieeele Schreibvorgänge quasi nicht totzukriegen ist.
Ich habe auch mal meine IC-Bestandstabelle durchgesehen: Da gibt es nur noch einen unverbauten RTC-Uhrenchip (Reichelt: RV 3029-C2) mit I²C im Winz-Gehäuse.
(FRAM und RTC sind im Beitrag "Projekte und Eigenbau -> Tipps für PIC-Testplatinen -> Zubehoer_gebastelt.jpg" abgebildet.)

In einer schwachen Stunde könnte ich mich evtl. breitschlagen lassen, Dir die Testplatine bzw. den Chip bis zum Herbst leihweise zu überlassen. Derzeit gibt's den FRAM leider nur als SMD-Ausführung.

Abgesehen davon: Ich habe mal das Datenblatt vom Sensor angesehen/überflogen: Das scheint wesentlich komplexer zu sein als der Datentransfer zum/vom Speicher.   

Gruß
PICkel
 

Zitat von: PICkel in 09.06.2022, 19:37:20 CESTLeider ist das mein einziger I²C-FRAM.

Alles klar.... wie es immer heisst! Also fast! Hätte sein können, und wäre eine "nette" Interaktion gewesen. Hätte....
Habe aber gesten Abend bei Farnell reingeschaut, und - wenig überraschend - dort gibt es reichlich. Da ich das in einem anderen Fred beschriebene Paket gestern tatsächlich auf den Retourenweg gebracht hatte, muss nun eh' der "richtige" Sensor, also die analoge Version bestellt werden. In dem Zusammenhang mit desse Einsatz hab ich noch ein gänzlich anderes Prob, dass ich in einem passenden Fred einstellen werde. Wäre nett, wenn du dort auch mal reinschauen würdest.

In der Tat ist das Hin-u. Her des Datenaustausches mit genau diesem SHT31-DIG -Sensor ein rechtes Gewusel. Das ist wirklich sehr komplex. Und wenn man das zuende denkt, fällt auf, dass dieses Gewusel keinerlei Vorteile gegenüber dem analogen Brüderchen bringen würde, denn beide liefern am Ende einen 16-Bit-Wert ab - der beim analogen wird natürlich vom ADC im PIC generiert - , und dann muss jedesmal eine Formel ran, um das zu translaten.
Nehmen wir mal grosszügig an, dass für beide Formeln der Aufwand gleich sei, dann fällt beim ananlogen B das ganze Gewusel flach! Aus diesem Grunde hatte ich mich gestern entschlossen, die digitalen B's zurück zu senden bis auf den einen, den ich schon aus der Verpackung entnommen und zwecks Erstellung eines Footprints begutachtet hatte. Der liegt nun in einer Schachtel und ob der jemals....?
Also werde ich den analogen Zweig weiter verfolgen. Es betrübt mich, dass nun das Engagement von gleich zwei Forenmitgliedern dann ganz oder teilweise ins Leere laufen sollte. So ganz aber nicht, denn mit der neuen Bestellung werde ich mal ein paar Exemplare des von dir genutzten Speicherchips mitbestellen und die Kommunikation mit dem ausprobieren. Die scheint ganz ähnlich der zu sein, die ich in meinem Projekt "Öltemperatur-Anzeige" beim internen EEProm verwendet habe, und du hattest ja oben auch ein Beispiel-Prog eingestellt. Einen Versuch ist mir das wert, dauert etwas, aber so scheint ein Einstieg in I²C mit einfacheren Mitteln möglich zu sein.
Grüße, picass

Nachdem es mir mit eurer Hilfe - danke sehr - gelungen ist, einen Einstieg in die Welt der LCD-Anzeigen-Ansteuerung zu finden, wäre die nächste Baustelle, die seriellen Verbindungen zu heute verbreiteten Sensoren zu erlernen. Das könnte dann I²C sein.
Der Konjunktiv ist mir da nicht aus Versehen rein gerutscht, denn nach einigen Blicken in das oben angebotene File und - is klar - in das Datenbuch des PIC18F14K22, sehe ich mich als Blinden im Nebel und - ach ja - dann noch des Nachts. Während für das Einlesen eines analogen Wertes in den PIC im Datenblatt wenige Seiten absolut reichen, sind der seriellen Übermittlung ganze 43 Seiten  gewidmet, davon 24 der "Unterabteilung" I²C ! Das "einfache" Programm-Beispiel oben füllt vier DIN-A-4-Seiten zur Gänze! Und dann sind solche Übertragungen auch noch sehr zeitkritisch, will sagen, aufwendig einzustellen.

Mal im Ernst: hat je irgendjemand von euch solchen Datenverkehre in Assembler in seinem Prog selbst erstellt und benutzt?
Es gibt Grenzen für Alles und solch Zeilenungetüm immer wieder von Neuem......, da erkenne ich keinen Fortschritt, rsp. Sinn.
Grüße, picass

Ich würde als Einstieg erstmal SPI verwenden, das ist meiner Meinung nach einfacher zu programmieren. Ich meine ich habe so ein Programm, welches eine alte PC Tastatur abfragt in Assembler schon programmiert. In C habe ich auch schon ein EEProm mit I2C programmiert. Da muss man halt die Taktfreqenz und die Adressierung beachten. Ich meine beim 18er Pic macht das die Hardware automatisch.

Zitat von: picass in 03.11.2024, 13:20:51 CETDas "einfache" Programm-Beispiel oben füllt vier DIN-A-4-Seiten

Sicher ist die I2C-Programmierung mittels einer Hochsprache wesentlich einfacher und der Quellcode viel kompakter als mit ASM. Die von Dir angesprochenen 4 Seiten Code ergeben aber letztendlich nur 250Byte Programmspeicher, und darin sind auch noch die sowieso nötigen Voreinstellungen (Oszillator, Porteinstellungen,...) enthalten.
Zeitkritisch ist da eigentlich auch nichts, solange man mit dem I2C-Takt im zulässigen Breich bleibt, meist bis 400kHz, aber auch bis 1MHz.
Letztendlich muß man "nur" die richtigen Steuerbits setzen, den Rest, also das Senden bzw. Empfangen eines Datenbytes,  macht die Hardware eigenständig.

ASM ist nur im Notfall bei zeitkritischen Anwendungen (z.B. WS2812-Ansteuerung) mein Ding, aber da ließe sich vielleicht was machen...

Gruß
PICkel