-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 30

Thema: I2C auf 16F876A klappt nicht

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938

    I2C auf 16F876A klappt nicht

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Hallo.

    Ich habe jetzt etwa 10-15 Stunden intensiv Microchip-Doku gelesen, probiert, geändert, allgemein recherchiert ..., ohne dem PIC16F876A eine I2C-Kommunikation entlocken zu können. Der Austausch mit einem fabrikneuen Teil hat nichts geändert. Versorgungsspannungen sind Oszi-gesichtet und OK.
    Kupferseitig ist alles getestet, PullUps vorhanden (wobei die 3,3kOhm-Widerstände in der Schaltung bei gestecktem Controller als 1,7kOhm gemessen werden ???).

    Auf der Basis von PIC16F886 hatte ich schon verschiedene I2C-Bausteine zum Sprechen gebracht; einer davon war aktuell verwendet worden - ebenfalls bewährte Hardware. Der Code war eigenentwickelt, sodass schon etwas Erfahrung mit diesem Bus und dem Controller vorliegt.

    Was nicht gelingen will, ist die Portierung auf den PIC16F876A, obwohl ich keinerlei Hinweise darauf habe, dass sich Register, Bits oder Logik des MSSP-Moduls zwischen den beiden Typen unterscheiden könnten.

    Die SCL-Leitung ist trotz des PullUps sehr EMV-empfindlich; bereits die Berührung mit dem Oszi-Tastkopf bringt den Programmablauf in einen Blockierzustand (Warten auf Godot). Diesen führe ich darauf zurück, dass meine I2C-Codeabschnitte keine Timeout-Absicherungen haben - das war bisher nie nötig.

    Hat jemand ähnliche Erfahrungen und das Problem gelöst?

    Gruß
    RoboHolIC

    P.S.:
    Dieses Problem ist "Hobby" innerhalb des Hobbies - im Grunde unwichtig, aber Aufgeben ist keine Art, mit solchen Problemen umzugehen, oder?

  2. #2
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    Hallo!

    Zitat Zitat von RoboHolIC Beitrag anzeigen
    Was nicht gelingen will, ist die Portierung auf den PIC16F876A, obwohl ich keinerlei Hinweise darauf habe, dass sich Register, Bits oder Logik des MSSP-Moduls zwischen den beiden Typen unterscheiden könnten.
    Man kann nicht alle mögliche vom Microchip eingeführte Änderungen nur anhand Datenblätter erkennen. Ich habe immer nach Programablaufdiagram nacheinander kleine Fragmente von gesamten auf anderen PIC geprüften Program zum Laufen gebracht. Es gibt nie zu viel Übung und Erfahrung.
    MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!

  3. #3
    RN-Premium User Roboter-Spezialist Avatar von witkatz
    Registriert seit
    24.05.2006
    Ort
    NRW
    Alter
    47
    Beiträge
    458
    Blog-Einträge
    16
    Zitat Zitat von RoboHolIC Beitrag anzeigen
    10-15 Stunden intensiv Microchip-Doku gelesen
    Hast du auch das MSSP Erratum studiert?

    Gruß
    witkatz

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Danke Euch für die Hilfestellung.

    Die 10-15 Stunden beziehen sich auf alle Tests, Arbeiten am Source, Verschmelzungen etc. gesamt.
    Dieses Erratum kenne ich schon seit meinen PIC-Anfängen, ich sehe aber keine Anknüpfungspunkte zu meinem Code; trotzdem Danke.

    Zur Konkretisierung reiche ich die Symptome des Nicht-Funktionierens nach:
    - SDA ist (fast) immer "H", die angeblich gelesenen Bytes sind alle 0xFF
    - gestern habe ich allerdings einiges Gezappel auf SDA entdeckt; dessen Wiederholfrequenz dürfte der Durchlaufzeit der Hauptschleife entsprechen, die fast auschließlich von der Aktualiserung des LCD bestimmt wird
    - SCL scheint EMV-sensibel zu sein oder mit seinem Echo zu sprechen - bereits das begrabschen des I2C-Flachbandkabels führt zur Störung / Blockierung; Oszi-Tastkopf dito (allerdings bilden die Schirmungen von Oszi und PICkit3 -- USB -- PC eine "Brummschleife") Es sind keine SCL-Pulse darstellbar, weil der Controller dann sofort im Programmdurchlauf hängen bleibt.
    - der elektrische Test bestand darin, SCL und SDA als I/Os mit L-Pegel zu konfigurieren, die beiden TRISC-Bits zu toggeln und den Pegelwechsel zu oszilloskopieren. Am SCL war bei der fallenden Flanke ein hässlicher Unterschwinger bis etwa -2V zu sehen.

    Jetzt würde ich gerne die OpenDrain-Konfiguration testen. Man kann ja I2C per Firmware emulieren. Läuft das mit TRISC-Registern oder steuert man dann die OpenDrains direkt an? Und falls ja, wie? Das Blockschaltbild für I2C-Master-Betrieb macht mir allerdings wenig Hoffnung auf einen direkten Zugriff auf die OpenDrains.

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    05.11.2007
    Ort
    Berlin
    Beiträge
    523
    Hallo RoboHolIC

    Das klingt irgenwie als wäre der SCL Pin hochohmig.

    Für einen Fullspeed Modus sollten deine beiden Pullups bei 3,3 Volt Versorgung 1K haben.
    Hier sehe ich aber eher nicht das Problem.

    Könnte es sein, dass dein TRISC-Register von einer anderen Initialisierung überschrieben wird.
    Durch ein sogenanntes Read Modify Write kann dies unvorhergesehene Ergebnisse haben und deine Initialiseiugn des Registers stimmt nicht mehr.

    Schau mal im Datenblatt: 4.3 PORTC and the TRISC Register, ist bei mir die Seite 46

    Aus dem Datenblatt:
    When enabling peripheral functions, care should be
    taken in defining TRIS bits for each PORTC pin. Some
    peripherals override the TRIS bit to make a pin an
    output, while other peripherals override the TRIS bit to
    make a pin an input. Since the TRIS bit override is in
    effect while the peripheral is enabled, read-modifywrite
    instructions (BSF, BCF, XORWF) with TRISC as the
    destination, should be avoided. The user should refer
    to the corresponding peripheral section for the correct
    TRIS bit settings.

    Versuche mal deine Software so zu ändern, dass Du nur ein "einziges" Mal einen Zugriff auf das TRISC Register hast.
    weis jetzt nicht ob Du in Assembler oder C programmierst. Also TRISC = xxxx;

    oder
    movlw xxx
    movwf TRISC


    Siro
    Geändert von Siro (27.10.2015 um 09:47 Uhr)

  6. #6
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    Für erfolgreiches Portieren eines geprüftes Programms muss die Software lauffähig ganz unabhängig von der Hardware sein.
    MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!

  7. #7
    RN-Premium User Roboter-Spezialist Avatar von witkatz
    Registriert seit
    24.05.2006
    Ort
    NRW
    Alter
    47
    Beiträge
    458
    Blog-Einträge
    16
    @RoboHolIC: wenn das mein ASM Projekt wäre, würde ich prüfen, ob ich die Bank für TRISC richtig selektiert habe (und zu 50% läge ich damit richtig). Für einen alten Hasen wie dich ist dieser Tipp wohl überflüssig. Leider habe ich keinen PIC16F876A um das Problem nachzustellen. Ich kann dir nur anbieten, über dein Quellcode drüberzuschauen, wenn du es posten magst (sonst gerne per PN oder Mail).

  8. #8
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    Ich vermute bisher unbekannte fehlerhafte Zuweisung von Pins. Ich mag eben nur über etwas konkretes reden.
    MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Danke euch für die vielen Beiträge.

    @Siro: Ich programmiere in ASM. Die TRISx-Register setze ich gleich zu Anfang und immer byteweise. Dann wird per bcf TRISC,3 und bsf TRISC,3 die eventuelle I2C-Busbelegung weggetaktet; erst dann erfolgt die Aktivierung des MSSP-Moduls als I2C-Master.

    @witkatz: Jo, kann alles passieren, passt aber.

    @PICture: Grundsätzlich gebe ich dir recht: Konkreter Code ist besser als rätseln. Weil ich jetzt eine Reihe zugemüllter und verbastelter Source-Varianten habe, ist da erstmal eine Konsolidierung fällig.

    Ich habe eine ande Minimal-Schaltung mit PIC16F886, einem LCD-Modul und I2C-Anschluss herumliegen. Die war für mein Altimeter bestimmt, passte aber wider Erwarten (ich Dussel !) in keines der beim großen C..... verfügbaren handlichen Gehäuse . Für sie - und eben den 16F886 - existiert funktionierender I2C-Code. Den hatte ich dieser Tage schon auf Minimum reduziert und mit meiner bewährten Ausleseroutine für den Zielbaustein (den bisher noch unerwähnten BMA020 auf dem Breakout von ELV) angepasst, um rauszukriegen, ob
    a) das Trägerplatinchen für den BMA020 noch funktioniert und
    b) ich nicht zu doof zum ASM-Programmieren geworden bin.

    Das Ergebnis lag binnen Stundenfrist vor und war in jeder Hinsicht erfreulich. Der (oben erwähnte) Portierungsversuch auf den anderen Controller und das andere "Biotop" (die eigentliche Ziel-Leiterplatte) war wie beschrieben erfolglos verlaufen.

    Jetzt werde ich den Spieß umdrehen und versuchen, die funktionierende Kombination durch Chiptausch und Codeanpassung auf 16F876A umzustricken. Dieser Weg sollte ja der kürzere sein. Vielleicht entpuppt sich so die große handgestrickte und später umfangreich modifizierte Ziel-Leiterplatte als Fehlerquelle.

    Ich bin gespannt und werde berichten.

    Gruß
    RoboHolIC

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    938
    Hallo an alle, die bis hierher mitgedacht und sich bemüht haben.

    Zitat Zitat von RoboHolIC Beitrag anzeigen
    Jetzt werde ich den Spieß umdrehen und versuchen, die funktionierende Kombination durch Chiptausch und Codeanpassung auf 16F876A umzustricken ...
    ... Ich bin gespannt und werde berichten.
    Uuups - der Spieß hat sich gedreht, nur nicht so wie ich es mir vorgestellt hatte. Der angedeutete Testfall findet nicht statt, weil das für den 16F886 entwickelte Platinchen aus der Grabbelkiste dem 16F876A nicht den benötigten externen Taktgeber/Schwinger bieten kann. Da fällt mir doch glatt der technische Fortschritt auf die Füße ...

    Natürlich könnte ich den Lötkolben anheizen, die Teilekiste auspacken und loslegen:
    Zitat Zitat von RoboHolIC Beitrag anzeigen
    Dieses Problem ist "Hobby" innerhalb des Hobbies - im Grunde unwichtig, aber Aufgeben ist keine Art, mit solchen Problemen umzugehen, oder?
    Aber angesichts eines Restbestands von zwei Stück 16F876A vielleicht wiederum doch ...

    Gute Nacht wünscht
    RoboHolIC

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. RP6 (M32) -- ISP klappt nicht ?!?
    Von AsuroPhilip im Forum Robby RP6
    Antworten: 3
    Letzter Beitrag: 24.03.2012, 06:53
  2. SPI klappt nicht
    Von p_mork im Forum Assembler-Programmierung
    Antworten: 0
    Letzter Beitrag: 22.04.2007, 14:10
  3. I2C Slave klappt nicht
    Von p_mork im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 17.01.2007, 21:20
  4. suche 16F876A.inc Datei
    Von HoStAn im Forum PIC Controller
    Antworten: 2
    Letzter Beitrag: 06.09.2006, 11:39
  5. I2C klappt bei mir nicht
    Von Matthias Mikysek im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 14
    Letzter Beitrag: 16.02.2005, 07:27

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •