Bascom BASCOM ; Erste Schritte zum Ausprobieren

Toggle invertiert ein Bit (also eine Bitvariable). Null wird zu eins, eins wird zu null. Danach noch zu warten ist Quatsch...
 
Das verstehe ich jetzt überhaupt nicht. Im Lehrbuch steht es so geschrieben. Allerdings in einer Do...Loop Schleife.
 
Im Lehrbuch steht es so geschrieben. Allerdings in einer Do...Loop Schleife.
Wenn das Toggle-Ereignis zu schnell hintereinander folgt, wirst du das LED-an-und-ausschalten gar nicht richtig wahrnehmen können (die Frequenz kann grob im MHz Bereich liegen). Die Pause ist in einer do-loop-Schleife sinnvoll, um das Ereignis zu verlangsamen.

Im Moment empfängst du anscheinend über den USART ein Zeichen und bei "t" wird getoggelt. Du wirst sicher "t" nicht so schnell hintereinander senden. Eine Pause ist hier nicht notwendig und könnte sogar Probleme machen. Es könnten Zeichen während der Pause empfangen werden, wenn diese nicht weiter über eine Softwarelösung gepuffert werden, kann es vorkommen, dass Zeichen "verloren gehen".

Dirk :ciao:
 
Hallo Dirk,
wie ich schon geschrieben habe, muss ich erst mein Laptop Netzteil reparieren um dieses testen zu können.
Dieses toggeln mit senden und empfangen ist neu für mich. Im Grunde genommen ist alles für mich neu.
Wenn aber Zeit vorhanden sein sollte, kann inzwischen schon eine neue Lehraufgabe gestellt werden.
 
Wie würdest Du das toggeln, also das umschalten der LED selbst umsetzen?
Du müßtest erst den Zustand des Beines aus dem PORT-Register abfragen, und dann in einer Fallunterscheidung entweder (IF) die LED anschalten lassen, oder (ELSE) die LED abschalten lassen. Das Abfragen geht in Bascom leicht, insbesondere auch da Du ja "Led_rot" hast.

Bei neueren Controllern kann ein Bein auch direkt durch die Controller-Hardware getoggelt werden, indem das Bit im PIN-Register beschrieben wird; aber nicht beim Mega8. Ob Bascom das ausnutzen würde, hab ich noch nicht kontrolliert.

Die Aufgabe mit der Ausgabe ist noch offen, da haste ja jetzt 'nen weiteren Tip hier zu stehen...

Hmm... neue Aufgabe... ich grübel noch, welche Richtung ich jetzt einschlage...
Schonmal den Timer, aber erstmal ohne Berücksichtigung von PWM?
In #20 hatte ich ja die von Dir gelieferte Timer1-Konfiguration analysiert. In unserem derzeitigen Programm kommentierst Du erstmal den gesamten IF..Then..Else-Block (also den gesamten Schleifeninhalt) aus.
Timer1 lief im Phasenkorrekten PWM, also zwischen 0 und 255 hin und her - die "0" wird alle 510 Schritte erreicht. Der Timer ist mit einem Vorteiler von 64 an den Systemtakt (8MHz) gekoppelt.
Die PWM an den beiden Output Compare Beinen ignorieren wir einfach mal...
Jedesmal, wenn der Timer "0" erreicht, wird das TOV1-Bit im TIFR-Register gesetzt (Das TIFR ist beim Mega8 das Timer Interrupt Flag Register - dort befinden sich die Interrupt-Flags aller Timer. Das Interrupt vergessen wir dabei erstmal, stell es Dir als Statusanzeige vor. Du bist der Rechenkern des Controllers, und sitzt an Deinem Schreibtisch. Neben Dir hast Du ein großes Panel mit Lampen und Schaltern (sind immer bis zu acht zusammengefaßt - Bytes halt), die I/O-Register. Und eines dieser zusammengefaßten Lampen ist das TIFR. Es hat sieben Lampen; vier davon betreffen Timer1, die anderen drei die anderen beiden Timer. Uns interessiert erstmal nur eine Lampe, die wo TOV1 drübersteht. Die geht jedesmal automatisch an, wenn der Timer in irgendeiner Form überläuft, im hier verwendeten Phasenkorrekten Modus (hin und her) ist das beim erreichen der "0" der Fall.
Ein kurzer Blick von Deinem Schreibtisch auf das Panel sagt Dir, ob irgendwann mal so ein "Überlauf" stattfand. Allerdings wird die Lampe nicht selbständig gelöscht - dafür hast Du 'n Taster unter der Lampe, der sie zurücksetzt.
Ziel wäre es jetzt eine andere LED - sagen wir mal an C3 - blinken zu lassen.
In der letzten Aufgabe bestimmt das Empfngene UART-Zeichen Aktionen von Led-rot.
Die Aktionen der C3-Led sollen durch die "Timerüberläufe" ausgelöst werden.

Kannst Du ausrechnen, mit welcher Frequenz der Timer bei dieser Frequenz überläuft, und mit welcher Frequenz die LED blinkt (wenn man sie bei jedem Überlauf toggelt)?
(die nötigen Werte stehen eigentlich alle in Diesem Beitrag)
 
Ich habe heut erst einmal ein neues Netzteil für mein Laptop hergerichtet.
Jetzt konnte ich meine Lösung aus #59 testen. Hab ich mir nach den Kritiken schon denken, nichts passierte mit der Led_rot.
Kann drücken was ich will (0, 1 oder t), keine Reaktion, weder auf dem Steckbrett noch im Simulator.
Gibst Du mir die Auflösung mit Beschreibung, was im eigentlichem Sinne passiert. Vielleicht werde ich dann ein bisschen schlauer.
 
Kann drücken was ich will (0, 1 oder t),
Hast Du auch das Enter (Carriage Return) mitgesendet?
Das waitms 500 bewirkt lediglich, daß Du nach einem empfangenen und verarbeiteten "toggle" 'ne halbe Sekunde warten mußt, bis das nächste Zeichen empfangen und ausgewertet werden kann.
Abgesehen vom "?"-Teil sieht meine funktionierende Lösung nahezu identisch aus - ich verwende halt Set und Reset, aber Bit=0 und Bit=1 sollten dasselbe machen...
 
Damit sendet HTerm lediglich den vorgegebenen String/Bytefolge/Bitfolge/… ab. Input wartet aber zusätzlich auf ein Carriage Return (CR bzw 0x0D). Da skannst Du entweder als Byte miteintippen (als HEX eben 0D), oder aber Du wählst bei Send on Enter das CR aus.

Baudrate korrekt in HTerm eingestellt (vergesse ich gern mal).
 
Im Simulator wird bei jedem Schritt sehr kurz Runnig und dann Pause angezeigt.
Mit"Carriage Return" meinst Du bestimmt "Enter".
 
Wenn Du das im Simulator durchsteppst, bleibt in der Input-Zeile das Running stehen (Du kommst da auch nicht weiter, da Input auf das Carriage Return wartet), DANN kannst Du im blauen UART0-Bereich 'n Zeichen und ein Enter eintippen. Da Du das lokale Input-Echo nicht unterdrückst, siehst Du die Eingabe auch.
Nach dem Enter kannst Du weitersteppen, je nach Zeichen geht's in die Verzweigung. Das setzen der LED siehst Du, wenn Du da wo wir den SRAM-Speicher angesehen hatten jetzt auf IO umschaltest, im PORTD-Register.

Die halbe wait-Sekunde dauert im Simulator allerdings ewig...

Hab Deinen Code übrigens mal in meinen Mega8 geflasht - läuft (schnelle "t"s werden verschluckt, wie @Dirk bereits andeutete, das Fragezeichen hast Du noch nicht implementiert, und das lokale Echo halt...)
 
Ich habe ja keine Input Zeile.


CodeBox BascomAVR
$regfile = "m8def.dat"
$crystal = 8000000
$hwstack = 40
$swstack = 16
$framesize = 32
$baud = 19200

Config Portd.7 = Output
Config Portd.7 = 1

Dim Zeichen As String * 1

Led_rot Alias Portd.7

Do
   Input Zeichen
   If Zeichen = "1" Then
     Led_rot = 1
   Elseif Zeichen = "0" Then
      Led_rot = 0
   Elseif Zeichen = "t" Then
      Toggle Led_rot
      Waitms 500
   Elseif Zeichen = "?" Then
   End If
Loop
End
Zeile 16??

Wie gesagt: der Code läuft, und macht auch was er soll. Abgesehen von der Zwangspause nach dem toggeln und der fehlenden "?"-Implementierung...
 
OK, die Zeile 16 hab ich hinzugefügt. Der Simulator bleibt dort stehen und wartet auf eine Eingabe.
Das Waitms 500 habe ich raus genommen und das ganze in eine Do..Loop Schleife gesetzt.
Die Zeile mit " Elseif Zeichen = "?" Then" da kann ich mir nicht anders helfen.
Im Simulator zeigt es nach mehrerem hin und herdrücken auch an, was in Print geschrieben steht, Selbst der I/O hat mal in der obersten Zeile eine 1 ausgegeben.
Aber, auf dem Steckbrett passiert überhaupt nichts! Warum nicht?


CodeBox BascomAVR
$regfile = "m8def.dat"
$crystal = 8000000
$hwstack = 40
$swstack = 16
$framesize = 32
$baud = 19200

Config Portd.7 = Output
Config Portd.7 = 1

Dim Zeichen As String * 1

Led_rot Alias Portd.7

Do

  If Zeichen = "1" Then
     Led_rot = 1
     Print "Led An"
  Elseif Zeichen = "0" Then
     Led_rot = 0
     Print "Led Aus"
  Elseif Zeichen = "t" Then
     Toggle Led_rot
     Print "Led An Aus"
  Elseif Zeichen = "?" Then
     Print "Led Wartet"
     'LED-Zustand Rückmelden
  End If
Loop
End

 
die Zeile 16 hab ich hinzugefügt.
???
Im Code in #59 war sie doch drin, den hatte ich in #75 nochmal kopiert.
In #76 fehlt sie hingegen...

Du hattest lediglich das lokale Echo nicht unterdrücken lassen, d.h. das eingetippte Zeichen wird zurückgesendet (vom simulierten Controller wie auch vom tatsächlichen Controller).
Input wartet aber auch auf das ASCII 0x0D (Carriage Return, CR, Wagenrücklaufzeichen) - erst dann geht es mit dem IF weiter.

Laß mal direkt vor der Hauptschleife 'ne Bereitschaftsmeldung senden. Also bei dem Code in #76 in Zeile 14:

CodeBox BascomAVR
Print "bereit..."

Input kann auch vorher etwas senden - ist dann quasi ein kombiniertes Print-Input.
Ergänze die (in #76 eh fehlende) Input-Zeile (Zeile 16) zu:


CodeBox BascomAVR
Input "Zeichen eingeben: " , Zeichen

Dadurch wird erst jedesmal "Zeichen eingeben:" gesendet (als wenns Print wäre), danach wartet die Instruktion auf ein Carriage-Return-Zeichen. Vorher kann bis zu ein Zeichen eingegeben werden (weil die Stringvariable in Zeile 11 so definiert wurde - ein ASCII eben), dieses wird durch das Echo auch ausgegeben. Aber erst das Carriage Return beendet diese Eingabe, und das Programm macht in Zeile 17 weiter, wo das Zeichen ausgewertet wird.

Zum "?"-Block:
Zum Anschalten der LED hast Du Led_rot 'ne "1" zugewiesen, Led_rot ist also "1".
Zum Ausschalten der LED hast Du Led_rot 'ne "0" zugewiesen, Led_rot ist also "0".
Um den Status der LED abzufragen mußt Du also nur Led_rot abfragen. Auswerten mit If then Else, wie das bereits mit "Zeichen geschehen ist...

Ein frohes Osterfest wünsche ich Dir und deiner Familie
Danke, Euch ebenso.
 
Hallo und allen einen schönen Ostersonntag.

Aber, auf dem Steckbrett passiert überhaupt nichts! Warum nicht?

In #76 vermisse ich eine Zuweisung für die Variable Zeichen, das Input fehlt.

Wurde denn eigentlich schon einfach mal eine LED blinken lassen. So dass man auch den tatsächlichen Systemtakt einschätzen kann (-> stimmen die Fuses für Systemtakt)?

Dirk :ciao:
 
Wurde denn eigentlich schon einfach mal eine LED blinken lassen. So dass man auch den tatsächlichen Systemtakt einschätzen kann (-> stimmen die Fuses für Systemtakt)?
Hätte ich eigentlich ausgeschlossen wegen:
deine Anleitung habe ich Schritt für Schritt nachvollzogen und hat auch die gewünschten Ergebnisse ausgegeben.
Da sollte Print ja eigentlich funktioniert haben...
Aber man weiß ja nie...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)