-         

Ergebnis 1 bis 6 von 6

Thema: Raspberry Pi B+ [C] verschluckt erstes Bit I2C Problem

  1. #1

    Idee Raspberry Pi B+ [C] verschluckt erstes Bit I2C Problem

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Hallo Liebe Forengemeinde.
    Ich habe an einem Raspi einen Atmega per I2C hängen. Ich versende dabei im Moment immer 2 bytes und lese 2 bytes. Der Atmega ist mit einer Flachbandleitung an den Pi angeschlossen(Leitungslänge: ca. 150mm; Keine zusätzlichen Pullups am Atmega).

    -Eine Änderung der Baudrate bewirkt leider keine Besserung.

    Ich habe mir nun das Signal mit einem Logicanalyzer angeschaut und verglichen. Bild1: Korrekt "0XFF" gelesen; Bild2 & 3: "0x7F" gelesen.
    Klicke auf die Grafik für eine größere Ansicht

Name:	RPI <a href=I2C prob.JPG Hits: 13 Größe: 69,9 KB ID: 31481" class="thumbnail" style="float:CONFIG" />

    Es kommt sporadisch vor, dass aus einem 0XFF welches vom Slave(Atmega) gesendet wird mal ein 0X7F am Raspi wird.
    Ich bin leider kein Elektronikfachmann aber für mich schaut das ja danach aus als ob das erste BIT nicht korrekt vom Pi erkannt wird.

    Hat jemand schonmal das gleiche Problem gehabt und kann mir erklären was ich genau Falsch mache?


    Vielen Dank schonmal.

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.431
    ich habe (im Effekt )ähnliche Probleme bei meinen AVR-Arduinos beobachtet. Ein Arbeiten per I2C war hier absolut nicht möglich, da der Raspi sehr empfindlich auf clock-stretching reagiert, wodurch die I2C-Verbindung abbricht.

    Ich weiß nun ntl nicht, wie sich deine Atmega i2c-lib von der Arduino-AVR-i2c-lib (Wire) unterscheided oder ihr ähnelt, immerhin klappt es mit den AVR-Arduinos aus diesem Grund nicht.

    Dieselbern i2c-lib Funktionen laufen aber einwandfrei auf einem ARM-Arduino (Arduino-DUE), hier gibt es keine data transmission oder i2c-bus Probleme:

    http://www.mindstormsforum.de/viewto...p=67815#p67908 (siehe Punkt 10 d) !!)


    HTH!
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  3. #3

    Blinzeln

    Hi die verwendete c. Lib ist von Manfred Langemann falls es jemanden interessiert.

    Da immer nur das erste byte Schrott ist und die darauffolgenden korrekt, sende ich nun immer 3 byte und lese 3bytes. Das erste byte wird dann bei mir im Code nicht verarbeitet.

    Nicht schön aber funktioniert wenigstens.

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    18.05.2007
    Ort
    Berlin
    Alter
    46
    Beiträge
    765
    Hallo,

    so wie ich das sehe, wird CLK gleichzeitig mit DAT gesetzt. Sieht für mich bald nach Software TWI am Atmel aus. Das sollte sich anpassen lassen. Besser wäre, wenn CLK bissel später kommt, wie bei dem io-Beispiel. Bei tatsächlich Hardware TWI könnte der Atmel zu viel Zeit benötigen. Da das Programm optimieren oder den Raspi eine Pause vor dem Einlesen machen lassen.

    Auch möglich, dass da evtl. ein kleinerer Pullup an DAT als an CLK hilft, damit die Flanke schneller steigt. Denk dabei aber daran, die Ports des Raspi durch einen zu hohen Strom nicht zu stark zu belasten. Z.B. 10k0 an CLK und 4k7 an DAT. Viel Hoffnung würde ich mir da aber nicht machen.
    Wenn das Herz involviert ist, steht die Logik außen vor! \/

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.431
    Raspi eine Pause vor dem Einlesen machen lassen
    ob das klappt?
    wie bereits erwähnt: der Raspi steigt bei clock-stretching aus, sonst gäbe es wohl auch kein Problem bei den AVR-Arduinos mit der AVR-Wire-Lib.
    Der Ausweg wäre höchstens Bitbang-I2C, aber dann auf dem Raspi...

    Allerdings soll der Jessie-kernel dafür demnächst verbessert werden!
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    18.05.2007
    Ort
    Berlin
    Alter
    46
    Beiträge
    765
    In diesem speziellen Fall hier lässt sich leider nur spekulieren. Von Vorteil wären beide Codes. Wenn der Atmel als Testcode nur darauf wartet, seinen Wert zu senden, dann braucht er keine Zeit dehnen.

    Ansonsten hatten wir das Thema ja neulich mit ARDUINO schon. Da habe ich mangels Notwendigkeit nicht weiter gemacht.
    Wenn das Herz involviert ist, steht die Logik außen vor! \/

Ähnliche Themen

  1. Alternativen zum Raspberry PI (wegen i2c Bus Problem)
    Von Ritchie im Forum Raspberry Pi
    Antworten: 14
    Letzter Beitrag: 03.09.2014, 12:28
  2. [ERLEDIGT] Problem mit GPIO beim Raspberry Pi
    Von Kampi im Forum Raspberry Pi
    Antworten: 19
    Letzter Beitrag: 25.08.2012, 18:49
  3. USART verschluckt zeichen...
    Von ustech im Forum C - Programmierung (GCC u.a.)
    Antworten: 3
    Letzter Beitrag: 12.10.2008, 16:43
  4. AVISARO WLAN verschluckt at kommandos
    Von aphex-world im Forum Elektronik
    Antworten: 8
    Letzter Beitrag: 26.09.2008, 18:13
  5. Controller verschluckt 4. Zeichen
    Von AVRbrauns im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 17
    Letzter Beitrag: 12.12.2007, 11:24

Stichworte

Berechtigungen

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