die lokale Variable Xsoll rausnehmen.
Auch wenn Serialin2_data ein Alias für Xsoll ist und dieses Xsoll
eigentlich hier
1
Dim Xsoll As Integer
2
Serialin2_data Alias Xsoll
gelten sollte, so würde ich da Bascom nicht über den Weg trauen. Da sind
auch noch andere seltsame Dinge augefallen. Es würde mich nicht wundern,
wenn der Compiler den Alias so auflöst, dass er bei der Verwendung von
SerialIn2_data sich erneut auf die Suche macht, mit welcher anderen
Variablen der Alias verknüpft werden soll. Und dann stösst er halt auf
die lokale Variable als erster Kandidat für die Auflösung des Alias.
Das ist jetzt allerdings mehr geraten als gewusst.
Wozu eigentlich der Alias?
Ja, gut man kann das natürlich machen. Man kann aber auch sich selbst
ins Bein schiessen und solange Aliase einführen, bis kein Schwein
(inklusive Compiler) mehr durchblickt, welche Variable jetzt welche ist
und wo zugewiesene Daten dann eigentlich tatsächlich landen.
was spricht gegen?
1
Sub Serial2charmatch()
2
Input Xsoll Noecho
3
End Sub Serial2charmatch()
Wäre das zu einfach? Zu durchschaubar? Zu naheliegend? Zu leicht
nachzuvollziehen?
Ausserdem:
Serialcharmatch ist eine Sub, die aufgerufen wird, wenn im Eingabestrom
ein bestimmtes Zeichen auftritt, wobei man das Zeichen, auf welches
reagiert werden soll, konfigurieren kann/muss.
Aus der BASCOM Hilfe
(Der ASCII Code von 'A' ist 65. Der ASCII Code von 'B' ist 66. Daher die
Zahlen in den Bytematch Angaben)
Ich kann bei dir weder eine entsprechende Konfiguration mit einem
Bytematch entdecken, noch wäre der Name der Sub im anderen Falle
korrekt. Man beachte, dass bei der UART2 das Label "Serial2charmatch"
heißt, bei der UART3, die aber laut Kommentar auf alle Zeichen reagieren
soll, heisst das Label "Serial3bytereceived".
Vielleicht doch ein bischen besser die Doku studieren?
http://avrhelp.mcselec.com/index.html?config_serialin.htm
und ein wenig studieren und überlegen, was man in den jeweiligen
Demo-Codes so alles sieht, warum das dort ist und was der Ersteller des
Demo Codes damit beispielhaft zeigen möchte?
Danke Karl-Heinz !!!
Mache es wohl zu kompliziert?!!!!!
Habe ich das jetzt richtig verstanden ?:
Durch
Sub Serial2charmatch()
Input Xsoll Noecho
End Sub Serial2charmatch()
werden die empfangenden Daten der Variablen Xsoll zugewiesen, nach
eingang von CR?
Kalle
sorry!!
Danke für den Hinweis.
Die Doku habe ich immer wieder gelesen, ich mache wohl einen ganz blöden
,einfachen Fehler ??!
Habe ich leider aus Versehen nicht mit in die Frage kopiert!
Ist aber auch drin im code:
Config Serialin1 = Buffered , Size = 20 , Bytematch = 13
Config Serialin2 = Buffered , Size = 20 , Bytematch = 13
.....................
Ist die Sub jetzt besser,richtig ?:
Sub Serial1charmatch()
Local Xist As Integer
Input Xist Noecho
End Sub Serial1charmatch()
....................
Leider werden daten trotzdem nicht, zB Xist, zugewiesen.
Ob von eineim anderen µC gesendet oder von einem Terminalprogramm,
leider hat Xist und Xsoll immer den Wert Null????!
sorry!
Hallo Kalle,
hier der erste Satz aus der Hilfe zu Config SerialIn:
Configures the hardware UART to use a buffer for input
Die beiden HW UARTS kannst du nicht verwenden?
Senden geht mit Soft UART immer noch relativ gut, aber empfangen ist
dann schon etwas aufwändiger. Du wirst nicht von der HW über eingehende
Zeichen informiert. Du könntest höchstens den PCINT von D.5 und D.6
benutzen.
Du musst dann übrigens in Input, Inputbin und ähnlichen Befehlen wieder
den Kanal angeben, den du im Open Befehl zugewiesen hast.
Ansonsten wird der HW UART abgehört.
Hallo my gast,
brauche den HW uart für eine sichere Ausgabe!
Hat der at644 zwei HW uarts ?
Wie mache ich das ?:
"Du musst dann übrigens in Input, Inputbin und ähnlichen Befehlen wieder
den Kanal angeben, den du im Open Befehl zugewiesen hast."
Lese ich den Wert nicht durch Local im Sub ein ?
Danke schön , schonmal !!
Kalle
Ich würde mir erstmal ein Protokoll überlegen, wie man zuverlässig
Paketanfang und -ende erkennen kann.
Und dann immer ein komplettes Paket in einem Puffer ablegen.
Und dann in diesem Puffer die Nachricht parsen.
Wenn Du nichtmal weißt, daß Du zum Sender synchron bist, dann hast Du
nur einen Haufen einzelner Bytes und weißt von keinem, was es bedeuten
soll.
Kalle Kohn schrieb:> Lese ich den Wert nicht durch Local im Sub ein ?
Äh nein.
Ein Byte kriegt man von der UART mittels eines Aufrufs von Input oder
Inkey oder dergleichen.
Bitte STUDIER die Beispiele in der Doku!
Lies nach, was die einzelnen Befehle wirklich machen.
Du kommst auf Dauer nicht darum herum. Programmieren (auch mit BASCOM)
ist eine der komplexesten Tätigkeiten, die es auf diesem Planeten gibt.
Das lernt man nicht zwischen Tür und Angel. Und auch nicht durch Raten.
Egal was dir die BASCOM Verfechter einreden: Selbst wenn in BASCOM
manche Dinge einfacher sind als in anderen Sprachen - du kommst nicht
drum herum, die Dinge zu lernen! Und das beinhaltet auch das Studium der
Doku und der dort angegebenen Beispiele.
Und ja - das alles beinhaltet auch Eigeninitiative und Testprogramme um
die Dinge zu ergründen. Es ist unmöglich, alle die kleinen Details in
Forenbeiträgen zu erklären. Du musst da auch selber soweit sein, dass du
ein Gedankenmodell erstellst und überprüfst ob dein Modell stimmt.
Habe jetzt statt der soft uart die HW uart zum einlesen des Wertes
genommen,
so klappen die Routinen.
Der gesendete Wert wird gelesen und verarbeitet!
Vielleicht steige ich besser auf den at2560 um, der hat 4HW uarts ?!
Kann mir das jemand bestätigen dass dies einfacher/sicherer sein wird?
danke für die bisherigen Tipps!
Kalle
Kalle Kohn schrieb:> Kann mir das jemand bestätigen dass dies einfacher/sicherer sein wird?
Da niemand weiß, was Du mit den 4 UARTs machen willst: Nein
Ohne ein geeignetes Protokoll ist sämtliche Übertragung unsicher.
Ein Protokoll muß mindestens:
- unterbrochene oder fehlerhafte Nachrichten erkennen können
- sich auf die nächste fehlerfreie Nachricht synchronisieren können
Danke für die ehrliche Antwort Peter.
Mein Anwendung ist ein soll-/ist- Wert vergleich mit Steuerung einer
Motorhardeware (Ausgabe der Steuerbefehle muss über RS232 erfolgen).
Der Ist Wert kommt von einem anderen µC, der Soll Wert über USB von
einem PC.
Die eingegangen Werte sollen zwischen gespeichert werden , soweit
erforderlich?!
mfG Kalle
Noch ein VERSUCH ;
MAN OH MAN OH MAN; Ich empfange einfach kein Zeichen über die soft
uart!!!
Was mach ich bloß falsch? Kann mir niemand dabei helfen ?
Gesendet wird laufend Xist von einem µC mit folgendem Code:
1
$regfile = "m644Pdef.dat "
2
$crystal = 16000000
3
$baud = 9600
4
$hwstack = 32
5
$swstack = 32
6
$framesize = 32
7
$baud = 9600
8
9
Rem TASTER1 an PD2
10
Taster1 Alias Pind.2
11
Config Taster1 = Input
12
Portd.2 = 1 'PullUp-Widerstand einschalten
13
14
Rem Taster2 An Pd3
15
Taster2 Alias Pind.3
16
Config Taster2 = Input
17
Portd.3 = 1
18
Do
19
If Taster1 = 0 Then Print 100
20
If Taster2 = 0 Then Print 500
21
Loop
22
End
Empfangen möchte ich laufend den Xist Wert über eine soft uart ,zum
Vergleich mit Xsoll,
mit folgendem Code:
------------------------------------------------------------------------
---
Fehler bei den Interups? Oder den Integer Variablen ?Oder beim senden
des Wertes Xist ? CR und LF falsch gesendet ?
Mit der Bitte um Hilfe........und freundlichem Gruß
Kalle
Nach dem kleinen Ausrutscher über den funktionierenden HW UART bist du
jetzt wieder beim Soft UART angekommen.
Da gelten die Regeln wie oben beschrieben, falls du dich erinnerst:
Config Serialin = Buffered
funktioniert nur beim HW UART. Gehe 7 Beiträge zurück.
Danke für den Hinweis mue_c !
Die HW uart brauche ich für die Motosteurung weil sie scheinbar darüber
viel schneller anzusprechen ist und die Geschwindigkeit hier massgebend
ist.
Wenn es mit der soft uart nicht geht muss ich es wohl drauf ankommen
lassen und den Motor (Antrieb einer Pumpe) viel langsamer laufen lassen.
Ist denn sonst noch ein Fehler vorhanden ?
Ist das senden und das laufende empfangen des Xist Wertes auf diesem
Weg möglich ?(Wenn der Code richtig an die HW uart angepasst ist ?
mfG
Kalle
Ich sage ja nicht, dass es über einen Soft UART nicht geht, aber du
kannst dafür keine Funktionen nutzen, die den HW UART erfordern.
Wenn du z.B. über den PCInt feststellst, dass Daten kommen, liest du
über inkey(#x) ein byte ein. x steht dabei für den zugewiesenen Kanal.
Danke nochmals!!
Werde ich morgen mal versuchen. Sorry , dass die Komunikation zwischen
µC "s doch nicht so einfach ist habe ich nicht gewusst und die
Problematik unterschätzt .
Hoffe ich kann weiter Hilfe bekommen , auch wenn meine Anfägerfragen
nerven und ich mich scheinbar im Kreise drehe ?????!!!!!!!!!!!!
schönen Sonntag
Kalle
Hallo zusammen,
sehe ich das richtig:
ischarwaiting klappt nicht mit der SW uart?
inkey kann den Wert Null nicht empfangen um ihn weiter zu verarbeiten ?
Kalle
Kalle Kohn schrieb:> Hallo zusammen,> sehe ich das richtig:> ischarwaiting klappt nicht mit der SW uart?
Ja.
> inkey kann den Wert Null nicht empfangen um ihn weiter zu verarbeiten ?
Wie kommst du da drauf?
Inkey gibt eine 0 zurück, wenn kein Char eingetroffen ist und du kannst
am Ergebnis nicht unterscheiden, ob nichts oder der Wert 0 empfangen
wurde.
Deshalb wird beim HW UART vorher IsCharWaiting aufgerufen. Beim SW UART
musst du das anders erkennen, z.B. über einen ausgelösten PCInt.
Thread beobachten
Seitenaufteilung abschalten