- fchao-Sinus-Wechselrichter AliExpress         
Ergebnis 1 bis 10 von 33

Thema: FM-Radio mit Arduino Pro Mini und Si4703 - Programm hängt sich auf!

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    131
    Zitat Zitat von HaWe Beitrag anzeigen
    Aber mal eine ganz andere Frage :
    Wo in deinem Sketch (void setup() ) startest du denn überhaupt Wire mit Wire.begin() - irgendwie sehe ich es nicht....?
    Du hast Recht, den Befehl Wire.begin() gibt es bei mir bisher nicht. Wenn das ein Fehler ist, muß ich das ggf. ändern.
    Allerdings hab ich mich beim Aufbau des Code an ein Beispiel aus der originalen "radio.h" Library angelehnt.
    Siehe hier:
    Code:
    #include <Wire.h>
    #include <radio.h>
    #include <SI4703.h>
    
    #include <RDSParser.h>
    
    SI4703   radio;    ///< Create an instance of a SI4703 chip radio.
    
    
    RDSParser rds;    /// get a RDS parser
    
    
    /// State definition for this radio implementation.
    enum RADIO_STATE {
      STATE_PARSECOMMAND, ///< waiting for a new command character.
    
      STATE_PARSEINT,     ///< waiting for digits for the parameter.
      STATE_EXEC          ///< executing the command.
    };
    
    RADIO_STATE state; ///< The state variable is used for parsing input characters.
    
    
    /// Update the Frequency on the LCD display.
    void DisplayFrequency(RADIO_FREQ f)
    {
      char s[12];
      radio.formatFrequency(s, sizeof(s));
      Serial.print("FREQ:"); Serial.println(s);
    } // DisplayFrequency()
    
    
    /// Update the ServiceName text on the LCD display.
    void DisplayServiceName(char *name)
    {
      Serial.print("RDS:");
      Serial.println(name);
    } // DisplayServiceName()
    
    
    void RDS_process(uint16_t block1, uint16_t block2, uint16_t block3, uint16_t block4) {
      rds.processData(block1, block2, block3, block4);
    }
    
    
    
    
    
    /// Setup a FM only radio configuration with I/O for commands and debugging on the Serial port.
    void setup() {
      // open the Serial port
      Serial.begin(57600);
      Serial.print("Radio...");
      delay(500);
    
      // Initialize the Radio 
      radio.init();
    
      // Enable information to the Serial port
      radio.debugEnable();
    
      radio.setBandFrequency(RADIO_BAND_FM, 8760);
    
      // delay(100);
    
      radio.setMono(false);
      radio.setMute(false);
      // radio.debugRegisters();
      radio.setVolume(8);
    
      Serial.write('>');
    
      state = STATE_PARSECOMMAND;
    
      // setup the information chain for RDS data.
      radio.attachReceiveRDS(RDS_process);
      rds.attachServicenNameCallback(DisplayServiceName);
    
    } // Setup
    
    
    /// Constantly check for serial input commands and trigger command execution.
    void loop() {
      int newPos;
      unsigned long now = millis();
      static unsigned long nextFreqTime = 0;
      static unsigned long nextRadioInfoTime = 0;
    
      // some internal static values for parsing the input
      static char command;
      static int16_t value;
      static RADIO_FREQ lastf = 0;
      RADIO_FREQ f = 0;
    
      char c;
      
    
    
      // check for RDS data
      radio.checkRDS();
    
      // update the display from time to time
      if (now > nextFreqTime) {
        f = radio.getFrequency();
        if (f != lastf) {
          // print current tuned frequency
          DisplayFrequency(f);
          lastf = f;
        } // if
        nextFreqTime = now + 400;
      } // if  
    
    } // loop
    
    // End.
    Dort gibt es den Befehl auch nicht. Da es beim Kompilieren keine Probleme gab habe ich vermutet, das die Library "radio.h" das implementiert hat. Eventuell passiert das im Befehl "radio.init()" im Setup?
    Ich meine auch andere Beispiele gesehen zu haben, wo das mit dem fehlenden Wire.begin() so ist!?

    Gruß Uwe
    Geändert von basteluwe (17.02.2018 um 13:04 Uhr)

  2. #2
    HaWe
    Gast
    ja, du hast Recht, es kann sein dass der Befehl in einer der Libs versteckt ist, wenn du eine Klasse initialisierst.
    Kann dann aber auch passieren, dass eine andere Klasse nicht korrekt initialisiert und gestartet wird.

    Ich schreib Wire.begin() allerdings immer bei mir als allerersten Wire-Befehl in setup() rein, dann läuft nichts falsch.

    Was machen deine I2C ioerr Fehler ?

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.261
    ich finde bare-metal-C-Tipps zu Arduino C++ Klassen wie Wire auch nicht so hilfreich
    Da hast Du natürlich recht.
    Aber es geht hier ja um mal einzugrenzen wo der Fehler liegt.
    Wie man das dann bei ARDUINO umsetzt ist wieder eine ganz andere Sache.

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    131
    Zitat Zitat von HaWe Beitrag anzeigen
    Ich schreib Wire.begin() allerdings immer bei mir als allerersten Wire-Befehl in setup() rein, dann läuft nichts falsch.
    Das scheint logisch. Kann das aber keine Konflikte geben, wenn der Befehl aus den Libraries dann auch aufgerufen wird?

    Zitat Zitat von HaWe Beitrag anzeigen
    Was machen deine I2C ioerr Fehler ?
    Gute Frage! Ich habe subjektiv den Eindruck, sie sind weniger geworden. Im Moment läuft er gerade seit ca. 15min OK. Ich gebe jetzt parallel zur OLED die Daten auch auf dem seriellen Terminal aus. Falls er sich wieder aufhängt, hoffe ich so zu sehen, ob die eigentliche Steuer und Anzeigeroutine trotzdem noch geht und "NUR" der I2C spinnt. Im schlimmsten Fall ist der Si4703 defekt. Das wäre Mist, weil schon endgültig eingebaut. Austausch wäre ein Albtraum!

    So! Gerade hat er sich wieder aufgehängt und natürlich bleibt auch die Anzeige im seriellen Monitor komplett stecken! Es geht also NICHTS mehr.
    Was ein Mist!

    Gruß Uwe

  5. #5
    HaWe
    Gast
    Zitat Zitat von basteluwe Beitrag anzeigen
    Das scheint logisch. Kann das aber keine Konflikte geben, wenn der Befehl aus den Libraries dann auch aufgerufen wird?
    nein, das gibt keine Konflikte: Wire wird immer mit den gerade aktuellen settings gestartet, anfangs eben mit den defaults.
    Ändert dann eine andere Funktion die Wire-settings nachträglich und startet Wire.begin() erneut, gelten ab dann die neuen settings.

    Wenn du also sicher bist, was deine 1. Wire-Device lib macht, kannst du ggf. darauf verzichten, aber wenn du z.B. erst ein OLED oder einen Portmuxer initialisierst, und dann erst dein Radio, kann es schief laufen. Daher macht es Sinn, anfangs Wire.begin() zu schreiben, um sicher zu gehen, denn schaden tut es ja nicht.

    Tipp:
    füge vor alle i2c-Befehle also den ping-Befehl ein, um deinen I2C Bus zu testen.

    Passieren viele Fehler, überprüfe deine Kabel und Steckbretter.
    Sind alles Kabel ok, füge mal je ein delay(1); zwischen alle Wire-Befehle ein.

  6. #6
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    131
    Zitat Zitat von HaWe Beitrag anzeigen
    Daher macht es Sinn, anfangs Wire.begin() zu schreiben, um sicher zu gehen, denn schaden tut es ja nicht.
    Ich bin nicht sicher, das das beim Si4703 so funktioniert, weil der I2C offensichtlich nicht schon nach Einschalten aktiv ist. Ich hatte an der Hardware einen I2C-scanner laufen lassen. Der hat nur das OLED (0x3C) gefunden, nicht aber den Si4703 (0x10). Erst als ich in den Scaner-Code auch die library und den Befehl "radio.init();" eingefügt habe, hat er beide Adressen gefunden.
    Ich denke daher, das in diesem speziellen Fall Wire.begin() am Anfang nichts bringt, weil ja der Si4703 nicht aktiv ist, oder?

    Jetzt gerade versuche ich mal eine andere Sache. Bisher rattert die main loop ständig vor sich hin und bei jedem Durchlauf wird die komplette Anzeige Subroutine aufgerufen. Ich denke, das ist Unfug. Ich werde den Aufruf mit timer steuern (millis) bzw. nur jeweils nach einer Tasten-Eingabe abrufen. Das sollte den Verkehr auf I2C massiv reduzieren, oder nicht? Vielleicht bring das ja was.

    Gruß Uwe

  7. #7
    HaWe
    Gast
    Zitat Zitat von basteluwe Beitrag anzeigen
    Ich bin nicht sicher, das das beim Si4703 so funktioniert, weil der I2C offensichtlich nicht schon nach Einschalten aktiv ist. Ich hatte an der Hardware einen I2C-scanner laufen lassen. Der hat nur das OLED (0x3C) gefunden, nicht aber den Si4703 (0x10). Erst als ich in den Scaner-Code auch die library und den Befehl "radio.init();" eingefügt habe, hat er beide Adressen gefunden.
    Ich denke daher, das in diesem speziellen Fall Wire.begin() am Anfang nichts bringt, weil ja der Si4703 nicht aktiv ist, oder?
    stimmt, aber schaden tut es ja auch nicht. Wäre nur möglicherweise der Fall, falls du andere I2C Geräte vorher lädst, wie ein OLED etc.
    Wenn du also nicht wirklich genau weißt, was deine Libs im Einzelnen machen, ist ein Wire.begin() am Anfang niemals falsch, insbesondere dann, wenn du irgendwelche "Hänger" bei deinem Busbetrieb beobachtest.

    Das sollte den Verkehr auf I2C massiv reduzieren, oder nicht? Vielleicht bring das ja was.
    stimmt, genau deshalb habe ich oben ja auch mindestens die delay(1) zwischen allen i2c-Bus-Zugiffen vorgeschlagen.

    Bei anspruchsvolleren Controllern (ARM) verwende ich genau deshalb auch immer Multithreading mit einem extra (langsamen) Thread nur für die Anzeige.


    PS:
    und vor blindem Herumprobieren ist es ntl immer gut, exakte Daten zu haben, daher pinge doch mal deine geräte kurz vorher an, wie ich oben beschrieben habe, bevor du sie ausliest und Daten schreibst, nur so wirst du wissen, wo und wann etwas nicht richtig funktioniert.

  8. #8
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    131
    Zitat Zitat von HaWe Beitrag anzeigen
    daher pinge doch mal deine geräte kurz vorher an, wie ich oben beschrieben habe, bevor du sie ausliest und Daten schreibst, nur so wirst du wissen, wo und wann etwas nicht richtig funktioniert.
    Das "Anpingen" würde ich ja gern probieren, nur wie macht man das? Unwissenheit kann nerven, ich weiß!
    Gibt es einen Befehl in der Wire-Library (keinen gefunden), oder muß man das jeweils handisch coden, ähnlich wie im I2C-Scanner Code?

    Gruß Uwe

Ähnliche Themen

  1. Unit 1.2 hängt sich auf
    Von Billy51 im Forum Open Source Software Projekte
    Antworten: 0
    Letzter Beitrag: 06.03.2011, 12:52
  2. Timer hängt sich auf?
    Von Ineedhelp im Forum C - Programmierung (GCC u.a.)
    Antworten: 15
    Letzter Beitrag: 22.08.2008, 16:49
  3. Programm hängt sich auf
    Von martin66119 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 5
    Letzter Beitrag: 07.10.2007, 21:06
  4. LCD hängt sich auf
    Von hotijack im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 30.05.2007, 16:47
  5. Lade Programm geht nicht (hängt sich auf)
    Von REX im Forum Robby CCRP5
    Antworten: 1
    Letzter Beitrag: 11.09.2004, 04:19

Berechtigungen

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

Labornetzteil AliExpress