-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 23

Thema: BASCOM-Terminalemulator-Stk500 funktioniert nicht

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    25.03.2010
    Beiträge
    12

    BASCOM-Terminalemulator-Stk500 funktioniert nicht

    Anzeige

    Hallo.
    bevor ich mit meinem Problem komme, ersteinmal paar Einstellungen.

    STK500
    Jumper: Default
    Prozessor: ATMEGA88
    ISP6PIN->SPROG2
    Takt: Intern 8MHZ (im ATMEL8
    Anschluss: RS232 CTRL
    Baud: 115200

    Bascom
    Programmer: STK500 native driver (STK500.exe funktioniert nicht)
    Clock 125000
    Timeout 100

    Mein Problem:
    Daten zum STK500 ATMEL8 schreiben wie auch lesen kein Problem!

    Aber, wenn ich im Bascom mit "Imput" oder "Print" arbeite, erscheint im AVR Terminal emulator keine Anzeige/keine reaktion!
    Was mache ich falsch? Was muß gemacht werden das es funktioniert?

    Bisher habe ich mit dem Lernpaket Mikrokontroller Technik mit Bascom (Franzis) gearbeite. Mit dem Terminalemulator kein Problem!!! Daten übertragen, paar Sk. später erschien auf dem Terminal die Auffoderung Daten einzugeben.
    Dann habe ich mir das STK500 angeschaft......???????

    Ich bitte um Hilfe. Sonst komme ich nicht weiter!!!!
    Meinen Dank im Voraus

    Viele Grueße

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Das im Auslieferungszustand gesetzte CKDIV8-Fusebit hast Du gelöscht?

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    25.03.2010
    Beiträge
    12
    Halo Sauerbruch,
    meinen Dank für die Hilfe!

    Mit AVR-Studio habe ich die Fusebits ausgelesen. CKDIV8 ist gesetzt (Haken). In der Funktion des Terminal emulators. Auch nach Löschen von CKDIV8 hat sich nichts bgeändert!
    Kann es am Header des jeweiligen Programmes hängen? Irgend etwas vergessen?

    Gruß
    Tueftler

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Kann es am Header des jeweiligen Programmes hängen? Irgend etwas vergessen?
    Lass´ uns doch mal den Code incl. Header sehen!

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    25.03.2010
    Beiträge
    12
    Hallo Sauerbruch,
    Hier der Bascom-Code (PWM-Anst.)

    'Bascom Hardware-PWM

    $regfile = "m88def.dat"
    $crystal = 8000000
    $baud = 115200

    Dim Duty As Word

    Config Pinb.1 = Output
    Config Pinb.2 = Output

    Config Timer1 = Pwm , Prescale = 8 , Pwm = 8 , Compare A Pwm = Clear Down , Compare B Pwm = Clear Down

    Enable Interrupts


    Do

    Input "Datenbyte (0-255): " , Duty
    Print "Duty = " ; Duty
    Pwm1a = Duty
    Pwm1b = Duty

    Loop
    End

    Das Prog. läßt sich absolut sicher übertragen! Die LED an PINb.2 PINB.2 leuchten. Nur auf dem Terminal erscheint nicht die "Input" Auffoderung, Werte ein zu geben. Keine Reaktion.

    Nochmals meinen Dank für die Hilfe!

    Gruß
    Tueftler

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Meine Erfahrung mit UART ist zwar recht überschaubar, aber zwei Dinge liest man immer wieder:

    1. kann die Ungenauigkeit des internen RC-Oszillators dazu führen, dass eine kritische Abweichung von der erwarteten Baudrate entsteht

    2. lassen sich aus einer definierten Taktfrequenz nicht alle beliebigen Baudraten ganz ohne Fehler erzugen.

    Einen Baudraten-Rechner findest Du z.B. hier:

    http://www.gjlay.de/helferlein/avr-uart-rechner.html

    Bei einem Takt von 8 MHz liegen die nächsten Baudraten 8% über oder 3,5% unter dem Sollwert von 115.200 Baud, und das ist schon ganz schön viel. 5800, 9600, 19200 und 38400 Baud lassen sich dagegen mit einem Fehler von nur 0,2% erzeugen. Versuchs doch mal für´s erste damit, vielleicht klappt´s ja!

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Stimmt, mit einen externen Quarz klappt das besser.
    Außerdem kommt es gelegentlich vor das man erst einmal
    mit der Mous ins Terminal Fenster klicken muss um es
    "einzuschalten"....

    Gruß Richard

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    25.03.2010
    Beiträge
    12
    Hallo,
    ich habe die Baudzahl auf 19200 reduziert. Ich benutze den Internen RC-Oszilator mit 8Mhz. Verwende den ISP-Mode.
    Kann es sein, das das STK500 defekt ist?
    Trotz alle dem es funktioniert nicht!!!! Ich bin mit meiner Weissheit am Ende!!
    Es wäre sehr schön wenn Dir/Euch noch etwas dazu einfallen würde. Nach meiner Erfahrung sind es oft Kleinigkeiten die man Übersieht!
    Ich hoffe auf Eure Hilfe
    Danke
    Gruß
    Tüftler

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Okay, dann müssen wir noch ein wenig weitersuchen

    Mit so etwas noblem wie dem STK500 hatte ich bisher noch nichts zu tun - aber das Franzis-Board kommuniziert doch ausschließlich über USB mit dem PC, oder?

    Falls die Kommunikation zwischen dem STK500 und dem PC über ein 9-pol-Kabel erfolgt - verwendest Du denn tatsächlich auch ein "Nullmodem"-Kabel?

  10. #10
    Neuer Benutzer Öfters hier
    Registriert seit
    25.03.2010
    Beiträge
    12
    Hallo,
    Verwendest Du ein 0-Modemkabel? Ich sage Ja! Das Beschreiben und Lesen des Flash-Speichers vom Atmega88 funktioniert! Also gehe ich davon aus, das es das richtige RS232 Kabel ist. Es lag ja beim STK500 bei.
    Es ist ja nur, nur!! das dieser Verdammte Terminal emulator nicht funktioniert. Auf Grund dessen, dass nur diese Sache nich funktioniert, gehe ich mal vorsichtig von aus, das die Hardware I.O. ist. Ev. muß ein Jumper auf dem STK500 gesetzt werden. Zur Zeit ist alles Standard eingestellt. Ist es eine Einstellung in dem BASCOM? Ich weiß es nicht! Ich hoffe auf euch Wissende.

    Nochmals meinen herzlichen Dank für die Mühe.

    Gruß
    Tüftler

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

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