-         

Ergebnis 1 bis 9 von 9

Thema: Atmega8 via RS232 mit PC verbinden scheitert (Linux)

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    03.08.2007
    Beiträge
    31

    Atmega8 via RS232 mit PC verbinden scheitert (Linux)

    Anzeige

    Nabend.
    Seit einiger Zeit versuche ich, eine serielle Verbindung zwischen meinem Mega 8 und meinem PC herzustellen. Leider hat es bisher nicht geklappt und diverse Forenbeiträge und tutorials haben nichts gebracht.
    da ich nicht genau weiß, ob mein problem software oder hardwarebedingt ist, habe ich erstmal hier gepostet.

    Bei mir sieht es wiefolgt aus:


    Der Microcontroller initialisiert den UART mit 9600 Baud (8MHz externer Quarzoszillator)

    Code:
    #define BAUD 9600
    #define MYUBRR F_CPU/16/BAUD-1
    unsigned int ubrr = MYUBRR;
    UBRRH = (unsigned char)(ubrr>>8);
    UBRRL = (unsigned char)ubrr;
    UCSRB = (1<<TXEN); // Sendekanal aktivieren
    UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0); // Asynchron 8N1
    Dann sendet er immer, wann möglich, aber durch nen timer auf 6Hz (willkürliche zahl) begrenzt:
    Code:
    if(UCSRA & (1<<UDRE)) // UART Data Register Empty = 1 => Senden
    {
    	UDR = (char)'x';
    }
    An Pin 3 des Controllers kann ich 5V messen. Da mir kein Oszilloskop zur Verfügung steht, kann ich da leider ncihts weiter drüber aussagen.

    Der TTL Pegel wird dann durch einen Ordnungsgemäß beschalteten MAX232 umgewandelt (ja, er hat auch ne stromversorgung).
    Hier messe ich -7.2V.

    das verlängerungskabel ist ca 2m lang und hat zwei buchsen.

    Am Rechner selbst lese ich die serielle Schnittstelle unter linux mit "cat /dev/ttyD1" aus.
    Aber es passiert nichts.
    Konfiguration der Schnittstelle:

    Code:
    homeserv:~# setserial /dev/ttyD1 -a
    /dev/ttyD1, Line 1, UART: 16550A, Port: 0x1008, IRQ: 18
    	Baud_base: 9600, close_delay: 50, divisor: 0
    	closing_wait: 3000
    	Flags: spd_normal skip_test
    Jetzt kommt das kuriose:
    Wenn ich den Controller über den MAX232 mit dem PC verbinde, kommt garnichts an.
    Wenn ich aber den TTL Pegel direkt mit dem PC verbinde und ein wenig über den Kontakt kratze (wohl prelleffekt) kommen am PC nicht identifizierbare daten an:

    Ich weiß leider nicht, wo der Fehler steckt, allerdings habe ich ein paar Überlegungen angestellt:

    *Die serielle Schnittstelle am PC funktioniert, da ich an kommende daten sehe.
    *sind ankommende daten wegen des pegels falsch oder sendet er nicht richtig ?
    *wieso kommen nur daten an, wenn ich über den kontakt kratze
    *wieso kommen über den MAX garkeine sichtbaren daten an ?
    *ein problem mit modem / nullmodem kabel meine ich ausschließen zu können, da mit TTL am richtigen pin etwas ankommt. die beschaltung hier muss also auch okay sein



    kann mir da einer weiterhelfen ?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken seriell.png  

  2. #2
    Hy,

    ja, ja die serielle kann ärgern
    ich gehs immer so an?

    haste ein echtes fertiges Nullmodemkabel

    haste schon damit 2 PC verbunden und mit ganz kleinen einfachen
    Terminalprogrammen ein paar daten hin und hergeschaufelt (AVterm , Binterm), passende Bauds, Handshakes usw

    haste das richte fuse bit gesetzt damit der externe Quarz auch tatsächlich verwendet wird und nicht der interne mit 1 MHz (beim neuen chip !)

    haste schon ein Loopback versucht nur mit Max232 ohne controller auf der 5V-Seite rx und tx verbinden

    haste ein einfahes Bascom mit Print und Input das garantiert läuft schon getestet

    Genauso läuft bei mir die Fehlereingrenzung

    mfg
    helle

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    03.08.2007
    Beiträge
    31
    *Das Kabel muss das richtige sein, da bei berührung des TxD Pins ja was am PC ankommt.
    (allerdings noch nicht zwei PCs verbunden, wozu soll das gut sein ?)
    *Den externen Quarzoszillator benutze ich schon länger und der läuft auch defintiv
    *loopback gestern noch getestet, funktioniert auch.
    das mikrocontroller programm läuft also auch.

    ist es möglich, dass der pegelwandler kaputt ist ?

  4. #4
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Den Pegelwandler kann gerade mit dem Loopback hinter dem Wandler testen.
    Fürs Loopback gibts mehrere Möglichkeiten:
    1) rein passiv am Stecker -> Test für PC, Kabel (ab nicht auch TX/RX tauschen)
    2) hinter Pegelwandler -> Test für Pegelwandler, Kabelbelegung
    3) in Software -> kompletter Test incl. µC Hardware

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.183
    Ich nehme mal an du hast die Init aus dem Datenblatt abgeschrieben, da hast du allerdings nicht 1 sondern 2 Stopbits. Das (1<<USBS) weglassen.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    03.08.2007
    Beiträge
    31
    Zitat Zitat von Hubert.G
    Ich nehme mal an du hast die Init aus dem Datenblatt abgeschrieben, da hast du allerdings nicht 1 sondern 2 Stopbits. Das (1<<USBS) weglassen.
    ich habe das mal geändert. das war scheinbar eins von mehreren problemen. über den MAX kommt immernoch nichts an. (nur über meine TTL-kratzmethode , dafür sind die zeichen da jetzt wesentlich klarer, was aber wohl aufgrund des falschen pegels kein wirklicher erfolg ist )

  7. #7
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.183
    Solltest du den Mega8 in einem Sockel haben, dann mal herausnehmen und im Sockel RX und TX verbinden. Dann in deinem Terminalprogramm etwas schreiben, das sollte dann als Echo zurückkommen. Wenn es nicht funktioniert dann mal vor dem MAX232 probieren. Die Kratzmethoden ist sinnlos, da kannst du von überall her was bekommen.
    Vielleicht kannst du auch mal deine Schaltung zeigen, bzw. den Schaltplan.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  8. #8
    Benutzer Stammmitglied
    Registriert seit
    03.08.2007
    Beiträge
    31
    der schaltplan entspricht ist exakt so aufgebaut, wie beim RN-Control im schaltplan verzeichnet. daran kann es nicht liegen. ich vermute, dass es an der PCI karte des PCs liegt, ich teste das die tage mal (derzeit wenig zeit) mal, auch inklusive der hier genannten methoden.

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    03.08.2007
    Beiträge
    31
    So, nach diversen Versuchen ist folgendes herausgefunden:

    Die Schaltung, Beschaltung und das Kabel etc sind alles in Ordnung.
    Auf einem Windows-Hyperterminal hat es auch sofort funktioniert.

    Das Kuriose:

    Es lag dem Linux Devise. Obwohl die Einstellungen mit setserial alle korrekt durchgeführt wurden, läuft es nur, wenn nebenbei das Linux-Terminalprogramm minicom läuft, was das Gerät noch einmal richtig initialisiert hat.

    Dann kann man auch mit cat oder nem selbstgeschriebenen programm, drauf zugreifen.

    Zwar läuft es jetzt provisorisch, aber bei mir kommt nun die Frage auf, wie das dauerhaft nicht-provisorisch eingestellt werden kann.

    ggf das thema hierzu in ein anderes forum verschieben.

    (ich schreibe hier auch nur nochmal rein, da ich unter den entsprechenden suchwörtern diesen thread wiedergefunden habe und das unschön ist, wenn der bei google drin steht, aber keine lösung aufweist)

    Gruß
    Krampfda

Berechtigungen

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