Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Atmel MC via RS232 steuern

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu QBasic.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
YZF



Anmeldungsdatum: 11.08.2012
Beiträge: 2

BeitragVerfasst am: 12.08.2012, 13:05    Titel: Atmel MC via RS232 steuern Antworten mit Zitat

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... mit den Augen rollen ).
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! cool


Zuletzt bearbeitet von YZF am 13.08.2012, 08:21, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Cherry



Anmeldungsdatum: 20.06.2007
Beiträge: 249

BeitragVerfasst am: 12.08.2012, 17:27    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2507
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 12.08.2012, 18:15    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
YZF



Anmeldungsdatum: 11.08.2012
Beiträge: 2

BeitragVerfasst am: 13.08.2012, 08:27    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland

BeitragVerfasst am: 13.08.2012, 09:22    Titel: Antworten mit Zitat

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. lächeln 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. grinsen

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. zwinkern

Viele Grüße!
Sebastian
_________________

Der Markt regelt das! | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu QBasic. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
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.

 Impressum :: Datenschutz