- LiTime Speicher und Akkus         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 12 von 12

Thema: Datenaustausch per I2C

  1. #11
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.651
    Anzeige

    Praxistest und DIY Projekte
    Eine Fehlerquelle .. blieb _eine_ Abfrage auf I2C stecken .. unerklärlich .. (es sei denn, eine der Librarys spuckt in diese Suppe) ..
    Bei der I²C-Kommunikation in meinem archie hatte ich ebenfalls Probleme. Zuerst mit dem Multi-Master-Konzept. Als die in sinnvoller Zeit nicht gelöst werden (konnten) hatte ich umgestellt auf Ein-Master-mehrere Slaves (Anm.: Topo ist veraltet). Der zentrale Master "pollt" bei Bedarf (auf Anforderung) Werte von den Slaves. Ansonsten bin ich zu I²C der übliche Anfänger/Noncompos.

    Bei diesen Arbeiten hatte ich mal die I²C-Bibliothek von Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury durchgeforstet - und die I²C-Gebetbücher wie Philips Semiconductors: THE I 2C-BUS SPECIFICATION, VERSION 2.1, JANUARY 2000, document order number: 9398 393 40011 sowie die ATMEL APPLICATION NOTE Atmel-2565E-Using-the-TWI-Module-as-I2C-Slave_AVR311_Application Note-03/2016. Auffällig war dabei (siehe rot - evtl. scrollen):

    Code:
    /*************************************************************************
    * Title:    I2C master library using hardware TWI interface
    * Author:   Peter Fleury <pfleury@gmx.ch>  http://jump.to/fleury
    * File:     $Id: twimaster.c,v 1.3 2005/07/02 11:14:21 Peter Exp $
    * Software: AVR-GCC 3.4.3 / avr-libc 1.2.3
    * Target:   any AVR device with hardware TWI 
    ..
    **************************************************************************/
     . . .
    
    /*************************************************************************    
      Issues a start condition and sends address and transfer direction.
      return 0 = device accessible, 1= failed to access device
    *************************************************************************/
    unsigned char i2c_start(unsigned char address)
    {
        uint8_t   twst;
    
        // send START condition
        TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);
    
        // wait until transmission completed
        while(!(TWCR & (1<<TWINT)));
    
        // check value of TWI Status Register. Mask prescaler bits.
        twst = TW_STATUS & 0xF8;
        if ( (twst != TW_START) && (twst != TW_REP_START)) return 1;
    
        // send device address
        TWDR = address;
        TWCR = (1<<TWINT) | (1<<TWEN);
    
        // wail until transmission completed and ACK/NACK has been received
        while(!(TWCR & (1<<TWINT)));
    
        // check value of TWI Status Register. Mask prescaler bits.
        twst = TW_STATUS & 0xF8;
        if ( (twst != TW_MT_SLA_ACK) && (twst != TW_MR_SLA_ACK) ) return 1;
    
        return 0;
    
    }/* i2c_start */
    /*************************************************************************
    Entsprechend der Philips-Bibel zum I²C wird hier vorschriftsgemäß gewartet bis eine Antwort kommt. Und wenn keine kommt hängt sich das Zeugs auf. Das Stretching ist aber sowieso nicht unkompliziert.

    Meine Änderung war nun ein Counter der ne Weile zum runterzählen braucht und alternativ zum NICHT eintrudelnden Signal die Routine beendet (teils mit Fehlerflag). Das löste einerseits die Häng-ihn-auf-Probleme, andererseits klappte es nicht immer mit ner alternativen Lösung. Egal - mittlerweile läufts, siehe Link auf das Topo oben. Allerdings habe ich mittlerweile meinen I²C-Bus über ein ca. 2 m langes, nicht abgeschirmtes Flachbandkabel im archie mit 800 kHz in Betrieb. Anm.: Hab leider kein aktuell geltendes Topo in meiner "Bilderbibliothek".
    Code:
    /* I2C clock in Hz */
      #define       SCL_CLOCK       800000L
                                    // ... hier 800 kHz, TWBR = 4 (komma 5)
    Fazit: möglicherweise könntest Du Dein Problem durch ne vergleichbare Änderung lösen?
    Ciao sagt der JoeamBerg

  2. #12
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    55
    Beiträge
    2.197
    Auf dem Arduino laufen eigentlich drei Bibliotheken, die I2C nutzen: wire (das ist die Standard-Lib für das TWI-Interface), die Adafruit fürs Display und eine für den Kompass.
    Um das umzusetzen, müsste ich die letzteren beiden zerlegen und sehen,was die genau treiben. Dass die wire "nach Vorschrift" arbeitet, davon geh ich mal aus.
    Und das in Python zu realisieren, ganz ehrlich..da fehlt mir noch ne genze Menge an Verständnis.
    Python ist in vielem so....seltsam.

    Im Grunde hab ich drei Möglichkeiten:

    -entweder ich ernenne den Nano kurzerhand zum Busmeister
    oder
    -ich realisiere eine Busy-Leitung zusätzlich
    oder
    ich ernenne den Raspberry zum alleinigen Meister.

    Letzteres erscheint mir weniger sinnvoll denn dann müsste der Raspi sich z.B. auch um den Kompass kümmern- samt Software-Kalibrierung.
    Das alles läuft auf dem Nano schon- und ist gar nicht ganz ohne.
    Und da es aber "nur" ein Raspi Zero(W) ist, und der mir später auch noch nen Livestream der Kamera liefern soll, dürfte er genug zu tun haben.

    Die Busy-Leitung ist ne machbare Option, allerdings müsste ich da noch zwei Strippen ziehen.
    Das ist also erstmal Plan B.
    Plan A ist die erste Option: den Nano zum Meister über alles ernennen.
    Hat den Nachteil, dass ich später die Fahrsignale, die ja im Pi (über den hübschen "Joystick" im Panel) erzeugt werden,dauernd abfragen muss, ist aber ohne jegliche Hardware-Änderung machbar.
    Daher probier ich das erstmal aus.
    Dazu werd ich im Python-Interface allerdings _einiges_ umbauen müssen, mal rausfinden, wie _das nun wieder_ geht...
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

Seite 2 von 2 ErsteErste 12

Ähnliche Themen

  1. Roboter Datenaustausch
    Von hammerle im Forum Suche bestimmtes Bauteil bzw. Empfehlung
    Antworten: 4
    Letzter Beitrag: 27.04.2010, 19:12
  2. Datenaustausch PC
    Von Facharbeit im Forum Assembler-Programmierung
    Antworten: 12
    Letzter Beitrag: 22.10.2009, 17:25
  3. Datenaustausch mit Interrupts: volatile
    Von ikarus_177 im Forum C - Programmierung (GCC u.a.)
    Antworten: 8
    Letzter Beitrag: 06.07.2009, 21:25
  4. BTM222 Datenaustausch
    Von crusico im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 30.11.2008, 08:33
  5. Datenaustausch
    Von martin66119 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 9
    Letzter Beitrag: 05.02.2007, 21:37

Berechtigungen

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

LiTime Speicher und Akkus