- 12V Akku mit 280 Ah bauen         
Ergebnis 1 bis 5 von 5

Thema: Hilfe! Problem mit meinem LPT-Logger...

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    12.06.2007
    Beiträge
    42

    Hilfe! Problem mit meinem LPT-Logger...

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Moin!

    Ich bin's mal wieder mit einem kleinen bis mittleren Problem.

    Folgende Situation:

    Ich habe ein Gerät (Scanner), dass über den Parallel-Port gesteuert wird. Meine Aufgabe ist es, die Daten, die über den LPT-Port geschickt werden, im EEPROM eines Tiny2313 zu speichern. Zu diesem Zweck wird der Controller auf eine kleine Platine gesteckt, auf der natürlich auch der LPT-Port ist.

    Ich habe mir das Programm folgendermaßen gedacht:

    Code:
      iLptBytePB = PINB;
      iLptBytePD = PIND;
      //
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,'P');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,'B');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,':');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,PINB);
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,'P');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,'D');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,':');
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,PIND);
      eeprom_write_byte((uint8_t*)iEEPROMCounter++,' ');
      //
      for(;;) {
        if( iLptBytePB != PINB ) {
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'P');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'B');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,':');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,PINB);
          iLptBytePB = PINB;
        }
        if( iLptBytePD != PIND ) {
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'P');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'D');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,':');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,PIND);
          iLptBytePD = PIND;
        }
        if( iEEPROMCounter >= 120 ) {
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'E');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'N');
          eeprom_write_byte((uint8_t*)iEEPROMCounter++,'D');
          break;
        }
    
      }
    Wenn sich an Port B bzw. D etwas ändert, wird das ganze Byte im EEPROM gespeichert. So logisch wie simpel. Die überflüssigen chars ("PB:", ...) sind natürlich nur zu Testzwecken implementiert. Außerdem wird vor Beginn der Schleife der Anfangszustand der Ports gespeichert.

    Mein Problem ist, dass das Programm grundsätzlich funktioniert, jedoch muss ich den Controller ja erstmal im STK500 brennen, und da fängt das Programm bereits an zu laufen und beschreibt das EEPROM.
    Beim ersten Mal ist das kein Problem, schließlich werden diese Bytes wieder überschrieben, sobald das Programm auf der Zielplatine läuft. Da ich das EEPROM jedoch nur über das STK500 wieder einlesen kann, und das Programm dort zwangsläufig startet, sobald Strom da ist, werden meine Daten natürlich wieder überschrieben.

    Nun weiß ich nicht so recht, wie ich diesem Phänomen zu begegnen habe. Mein erster (und bislang einziger) Einfall war, irgendwie zu erkennen, wo der Controller sich befindet.

    Hat jemand schonmal ein ähnliches Problem gehabt? Kann ich irgendwie erkennen, dass ich mich auf dem STK500 befinde?

    Im Voraus schonmal vielen Dank für eure Mühe!

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    12.06.2007
    Beiträge
    42
    Mir fällt gerade eine Notlösung ein:

    Man könnte einfach am Anfang des Programms ein delay von, sagen wir mal, 20 Sekunden einbauen. Dann müsste ich nach dem Brennen direkt den Strom wegnehmen. Ebenso muss das Auslesen des EEPROM dann schnell gehen.

    Ist natürlich keine schöne Lösung, ich wäre froh, wenn jemandem was besseres einfällt.

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.03.2007
    Beiträge
    176
    so ganz hab ich dein Problem nicht verstanden

    aber ioch versuch mal ne Antwort

    1 du kannst einen 2ten LPT nachrüsten um die Scanner Daten vom Prommer zu trennen !
    2 du kannst die ISP Speisespannung auswerten als Bit wenn ISP Spannung kommt kein Eprom brennen

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    12.06.2007
    Beiträge
    42
    Hi jar!

    So, wie du mein Problem nicht verstanden hast, verstehe ich deine Anwort leider auch nicht ganz...

    Ein zweiter LPT ist nicht möglich. Meinst du damit einen zweiten LPT am Rechner? Ich meine ja die Platine mit LPT-Buchse, die in den Scanner kommt.

    Deinen zweiten Punkt verstehe ich leider gar nicht. Deshalb könnte es sein, dass der Vorschlag die Lösung ist. Kannst du das vielleicht nochmal genauer erklären?

    Nochmal ganz genau das Problem:

    Unsere Firma stellt spezielle Scanner her (Anwendung erstmal irrelevant). Im Scanner ist eine kleine Platine, die man herausnehmen kann. Dort ist eine LPT-Buchse verbaut, und meinen Controller kann ich auf die Platine setzen. Der Controller ist natürlich mit den LPT-Pins verbunden. Z.B. sind die LPT Pins 1-8 mit dem Port B des Controllers verbunden.

    Nun soll ich die Daten, die über die LPT-Schnittstelle gejagt werden, loggen und im EEPROM speichern. Mein Ansatz ist, bei jeder Veränderung von Port B bzw. D den neuen Zustand des Ports (/Bytes) festzuhalten.

    Dies sollte ja eigentlich nicht auf dem Testboard, sondern nur im Scanner passieren. Da aber direkt nach dem Brennen auf dem STK500 das Programm anfängt zu laufen, habe ich das Problem, dass er bereits dort das EEPROM beschreibt, und zwar mit Werten, die mir verständlicherweise nicht nützen.

    Stecke ich den Controller nun in den Scanner, wird das EEPROM wieder von vorne beschrieben, die fehlerhaften Werte werden also überschrieben. So weit, so gut. Wenn ich ihn dann wieder zurück aufs STK500 stecke, um das EEPROM auszulesen, kann ich ja nicht verhindern, dass das Programm dort wieder von vorne läuft und somit wieder falsche Werte speichert.

    Deshalb war meine Idee, einen Weg zu finden, wie ich das Testboard von der eigentlichen Zielumgebung unterscheiden kann. Dann könnte ich darauf abfragen und bei "Erkennung" des Testboards das Speichern deaktivieren.

    So, ich hoffe, ich konnte mein Problem halbwegs verständlich schildern. Leider kann ich bei solchen Beschreibungen nicht mit Fachwörtern glänzen, da ich (noch) kein AVR-Experte bin, aber ich denke, die Aufgabenstellung sollte klar geworden sein.

    Gruß Matze

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    12.06.2007
    Beiträge
    42
    Ich habe eine Lösung gefunden!

    Ich habe ich mein Problem so gelöst, dass Pin 1 von Port D
    (eigentlich low) auf dem Testboard mit dem TXD-Pin (Transmitter für
    UART) verbunden ist. Somit ist der Pin high (anders als im Scanner) und ich habe ein eindeutiges
    Unterscheidungsmerkmal. Funktioniert perfekt!

    Gruß Matze

Berechtigungen

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

12V Akku bauen