|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
YZF
Anmeldungsdatum: 11.08.2012 Beiträge: 2
|
Verfasst am: 12.08.2012, 13:05 Titel: Atmel MC via RS232 steuern |
|
|
Servus!
Bin verwundert, das trotz uralt Software und altem Wunsch vieler (MC-Steuerung via PC), ich keinen fertigen oder leicht verständlicher QBasic Code gefunden habe. Wollte ja nur mal schnell testen...
Später soll der PC durch eine kleine Tastatur mit MC ersetzt werden.
Es geht um folgendes: habe mir in QB ein kleines Programm geschrieben, das bei Tastenbetätigung die Strings "#01$" und "#02$" sendet. Diese werden vom Microcontroller empfangen und eine Aktion ausgeführt.
Mein Problem: Möchte ich den Zustand gewisser Funktionen abrufen (String "#00$" wird gesendet), hängt das Programm bis die vollständige Antwort (vier Bytes, die (später) das Format "%00&" (für beide "aus") empfangen wurde. Mittels GtkTerm funkrtionert das auch soweit.
Was ich jetzt ganz gerne hätte:
1.) Wenn Antwort nicht innerhalb von Zeit x, dann Meldung und beenden des wartens auf Antwort.
2.) Eine elegante / "schöne" Prüfung, das der empfangene String mit "%" beginnt und mit "&" endet.
Wäre schön, wenn ihr ma da helfen könntet, da ich von dem ganzen Thema nicht wirklich Ahnung habe - und leider auch etwas die Zeit drängt (wie immer halt... ).
Das ist bisher mein "Konstrukt":
Code: | SCREEN 0: COLOR 2: CLS
OPEN "COM1:9600,N,8,1,ds0" FOR RANDOM AS #1
PRINT " Programmende (ESC) "
PRINT " "
PRINT " Funktion 1 (1) _ Funktion 2 (2) _ Zustand? (3)"
DO
DO: taste$ = INKEY$: LOOP WHILE taste$ = ""
PRINT " "
SELECT CASE taste$
CASE "1": LOCATE 3, 15: COLOR 7: PRINT "1": PRINT #1, "#01$"; : SLEEP 1: LOCATE 3, 15: COLOR 2: PRINT "1"
CASE "2": LOCATE 3, 34: COLOR 7: PRINT "2": PRINT #1, "#02$"; : SLEEP 1: LOCATE 3, 34: COLOR 2: PRINT "2"
CASE "3": PRINT #1, "#00$";
LOCATE 3, 51: COLOR 7: PRINT "3"
LOCATE 5, 3: COLOR 2: PRINT "Antwort: ";
PRINT INPUT$(4, #1): SLEEP 1
LOCATE 3, 51: COLOR 2: PRINT "3"
LOCATE 5, 3: PRINT " "
CASE CHR$(27) ' Programm/Ende
LOCATE 1, 17: COLOR 7: PRINT "ESC"
SLEEP 1
CLOSE
CLS
SYSTEM
CASE ELSE: LOCATE 1, 22: COLOR 4: PRINT "?": SLEEP 1: LOCATE 1, 22: COLOR 1: PRINT " "
END SELECT
LOOP |
Sicherlich nicht der beste Weg, aber bis hierher funktioniert es erstmal.
Für eure Antworten und Bemühungen danke ich im Voraus!
Zuletzt bearbeitet von YZF am 13.08.2012, 08:21, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
Cherry
Anmeldungsdatum: 20.06.2007 Beiträge: 249
|
Verfasst am: 12.08.2012, 17:27 Titel: |
|
|
Bevor du Input(...) verwendest kannst du mit Lof(...) checken wie viele Bytes warten. Wenn das 4 sind, fragst du sie ab, ansonsten schaust du ob der Zeitrahmen überschritten wurde...
Übrigens: "§" wird ein Problem werden weil das Zeichen nicht im (7-Bit-)ASCII-Zeichensatz enthalten ist! Wird also ziemlich sicher vom µC anders interpretiert als vom PC. |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 12.08.2012, 18:15 Titel: |
|
|
Artikel aus meiner Sammlung:
http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/SerielleKommunikation.html
Generell: Ich würde Non-Blocking-IO anstreben, also in der INKEY$-Schleife gleichzeitig ständig nach angekommenen Zeichen schauen (LOC()-Funktion) und diese "abholen" (hier dann INPUT$()).
Ansonsten musst Du halt die grundlegenden Dinge wie Kommunikationsparameter (Baudrate, Anzahl Daten- und Stopp-Bits, Parity usw.) der Dokumentation zum Microcontroller entnehmen, ebenso das genaue Byte-Protokoll (ist z.B. alles ASCII und gilt CHR$(13) als Abschlusszeichen eines "Befehls"?) und dann passend umsetzen. Ebenso spielt noch die Verdrahtung vom seriellen Kabel eine Rolle, damit Dinge wie Hardware-Handshake zur Verfügung stehen. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
YZF
Anmeldungsdatum: 11.08.2012 Beiträge: 2
|
Verfasst am: 13.08.2012, 08:27 Titel: |
|
|
Vielen Dank schon einmal!
In die Funktion LOC und LOF muß ich mich dann erst einmal einlesen und schauen ob ich die eingebastelt bekomme.
Zur Verdrahtung: Bisher funktioniert das via 0-Kabel zwischen PC (Linux) und Laptop (DOS). Wird dann evtl noch einmal spannend, wenn die RS485 Wandler dran kommen (besonders auf der MC-Seite) - muß halt eine Strecke von über 600 m überbrücken.
Der Wandler (Eigenbau) funktioniert auch soweit. Hatte mal einen Test gemacht, in dem der MC immer schneller gesendet hat - augenscheinlich wurde das fehlerfrei empfangen - war halt eine einseitige Geschichte...
Cherry hat Folgendes geschrieben: | ...
Übrigens: "§" wird ein Problem werden weil das Zeichen nicht im (7-Bit-)ASCII-Zeichensatz enthalten ist! Wird also ziemlich sicher vom µC anders interpretiert als vom PC. |
Meine Güte, daran hätte ich gar nicht gedacht. Hab's oben schon mal geändert. |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 13.08.2012, 09:22 Titel: |
|
|
Hallo!
YZF hat Folgendes geschrieben: | In die Funktion LOC und LOF muß ich mich dann erst einmal einlesen und schauen ob ich die eingebastelt bekomme. |
Hier habe ich etwas Ähnliches mal ganz grob gepostet: http://forum.qbasic.at/viewtopic.php?p=95177#95177
Das ist allerdings FreeBASIC-Code. Das heißt, zum Übertragen nach QB müsste man ein paar kleinere Änderungen vornehmen (z. B. "Dim As String A, B, C" gibt es in QB ja in der Form nicht). Aber im Prinzip sollte es in QB ganz genauso gehen.
YZF hat Folgendes geschrieben: | Wird dann evtl noch einmal spannend, wenn die RS485 Wandler dran kommen (besonders auf der MC-Seite) |
Ich hab auch schon mehrmals Bastelprojekte mit der Kombination ATMEL AVR, avr-gcc (C), RS485 und FreeBASIC/VisualBASIC gehabt. Hat immer sehr gut funktioniert.
Wenn du den RS232->RS485 Wandler selber baust und keinen aktiven Konverter mit µC verwenden möchtest, wirst du vielleicht - je nach Aufbau - ein Signal brauchen, das dem RS485-Transceiver "mitteilt", ob er gerade senden oder empfangen soll (für die Eingänge RE und DE des RS485-Treibers). Dafür lässt sich ganz gut wahlweise einer der RS232-Statuspins (z. B. RTS) verwenden. Das heißt, von der RS232-Schnittstelle würde man nicht nur RX/TX anbinden, sondern noch einen weiteren als Flussrichtungs-Steuerung für den Half-Duplex-Transceiver.
Es gibt zwar auch passive Schaltungen (hauptsächlich ein MAX232 plus ein MAX485 oder baugleich), die das automatisch anhand der Datenleitungen versuchen, aber so richtig zuverlässig hat das bei mir nicht immer funktioniert bzw. schnell genug. Da war das explizite Schalten über einen weiteren Pin schon deutlich besser.
Aber dafür muss man im PC-Programm natürlich entsprechend ein Togglen dieses Ausgabepins vorsehen.
YZF hat Folgendes geschrieben: | muß halt eine Strecke von über 600 m überbrücken. |
Das ist aber sogar für RS485 ja schon relativ weit, glaube ich. So eine lange Strecke hatte ich noch nicht in Betrieb.
Da würd ich auf jeden Fall eine sehr niedrige Baudrate verwenden, zumal du ja anscheinend ohnehin immer nur ein paar Statusbytes übertragen möchtest, wo das nicht so kritisch ist.
Und ich würde Twisted-Pair-Kabel verwenden (ordentlich verdrillt und kein zu kleiner Aderquerschnitt).
Ansonsten könntest du bei der Entfernung eigentlich schon über Glasfaser nachdenken.
oder auch
Ist leider schon ein paar Jahre her, dass ich zuletzt intensiver damit gearbeitet habe, aber vielleicht hilft dir das als Ideensammlung ja trotzdem etwas weiter.
Viele Grüße!
Sebastian _________________
Der Markt regelt das! | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|