1)
Byte_1 = low(crcval) ' das ist das eine Byte von dem word
Byte_2 = high(crcval) ' das ist das andere
2)
von sich aus verdreht er da nix. wie kommst du drauf ?
Druckbare Version
1)
Byte_1 = low(crcval) ' das ist das eine Byte von dem word
Byte_2 = high(crcval) ' das ist das andere
2)
von sich aus verdreht er da nix. wie kommst du drauf ?
1.
hab mir mal die empfangenen bytes im lcd anzeigen lassen, und die sind immer irgendwie nicht in der richtigen reihenfolge.ab und zu, gibt er auch anstelle von 115 nur den wert 112 aus.
2.
kann es sein, das ich nach jedem empfang eines bytes meinen buffer löschen soll, weil immer wenn ich die empfangsprozedur öffter als 1mal durchführe bekopmme ich einen anderen wer:
1. durchlauf: z.b. 001 005 176 156 099 156 176 002
2... durchlauf: 003 006 143 178 005 070 090 076
die werte sind nur erfunden.
mfg
xeus
er gibt mir daraufhin immer fehler aus:
dim crc_l as byte
dim crc_l as byte
dim crc as word
crc_l=low(crc)
crc_h=high(crc
an was kann das liegen?
Es kann im Prinzip immer auch kommunikationsfehler geben, wenn z.B. sende- und empfangsseitig die erzielten baudraten knapp an den Toleranzgrenzen sind ( Baudraten haben immer einen %-Fehler)
Aber rein Erfahrungsmäßig würde ich das, solang noch das mit den Bytefolgen irgendwie unsicher ist, mal nicht annehmen. sondern erstmal das restliche Terrain absichern.
Der Befehl:
inputbin Packete(1),8 überschreibt auf jeden Fall 8 Byte des Buffers, da brauchst du nix löschen.
Mach ganz einfach mal den Buffer größer, wenn es sich irgendwie ausgeht:
CONFIG SERIALIN = buffered, SIZE = 128
und schau, obe sich das Verhalten ändert
dim crc_l as byte
dim crc_l as byte
zweimal gleich. Verschrieben ?
also wegen der crc muss ich mich berichtigen, hab nur die variablen vertauscht, leider kann ich die crc16 nicht verwenden, gibt mir falsche werte aus.werd die prozedur doch selbst machen müssen.
ist es nicht so das für empfang und senden nur einen puffer git? da ich ja 10 bytes sende aber nur 8 empfange, nicht das er die letzten 2bytes mit in die andere prozedur überträgt.
Nein, nein, die Buffer sind schon getrennt, keine Sorge. Können auch verschieden groß sein.
aber auf wieviel soll ich den buffer erhöhe, wenn ich ihn auf 128 hochsetz kommt nichts mehr an.
auszug von dem was der PC senden, und was der mc Empfängt:
pc:000 006 002 002 002 000 105 115
mc 000 103 114 000 006 002 002 002
??? kann das am buffer liegen
Irgendwie kommen Sender / Empfänger aus dem Tritt.
Wenn der Sender immer 8 Byte schickt, und der Empfänger immer 8 Byte liest (auch wenn er sie nicht verwertet) kann das so nicht sein.
Kann es sein, daß du beim lesen auf die 2 Byte CRC vergißt ?
nein, die werden mit gesendet und auch mit empfangen, aber halt nicht berechnet.komisch senden tut er die 8bytes+2bytes einwandfrei zum pc, nur irgendwie haut er das mit dem empfangen immer durcheinander.
hab mal versucht den buffer zu erhöhen, aber dan macht er garnichts mehr.
Hartnäckige Sache.
Kannst du bitte deine Source komplett, so wie sie ist, reinstellen ?
Code:$regfile = "m16def.dat"
$crystal = 19999998 'Quarz: 3.6864 MHz
$baud = 19200
Dim I As Byte
Config Lcdpin = Pin , Db4 = Porta.6 , Db5 = Porta.5 , Db6 = Porta.4 , Db7 = Porta.3 , E = Porta.7 , Rs = Porta.2 ' Natürlich so wie es wirklich angeschlossen ist (4-Bit-Modus)
Dim A As Byte
Config Lcd = 20 * 4 'Baudrate der UART: 9600 Baud
Config Pind.1 = Input
Config Pind.0 = Output
Config Pinb.3 = Output
Config Pind.5 = Output
Config Pind.2 = Input
Dim Crc_l As Byte
Dim Crc_h As Byte
Dim New As Byte
Dim Tmp As Byte
Dim Bcclo As Byte
Dim Bcchi As Byte
Dim X As Byte
Dim Crce As Word
Dim Crcs As Word
Dim Packets(10) As Byte
Dim Packete(8) As Byte
Declare Sub Sendewr
Declare Sub Empfangewr
Declare Sub Clc
Declare Sub Lcdout
Declare Sub Status
Declare Sub Auswahltyp
Dim Wrtyp As String * 10
Declare Sub Auswahlanzahl
Dim Anzahl As Integer
Dim Line1 As String * 20
Dim Line2 As String * 20
Dim Line3 As String * 20
Dim Line4 As String * 20
'PowerLED
Portd.5 = 1
Portb.3 = 1
'Init Packets
Packets(1) = 002
Packets(2) = 050
Packets(3) = 000
Packets(4) = 032
Packets(5) = 032
Packets(6) = 032
Packets(7) = 032
Packets(8) = 032
Packets(9) = 037
Packets(10) = 135
'Config Serialin = Buffered , Size = 8
Do
'Gosub Auswahltyp
'Taster 1
'If Pind.2 = 1 Then
' Line2 = " reset"
' Print "reset"
' Gosub Lcdout
'End If
'Taster 2
If Pind.4 = 1 Then
Gosub Sendewr
Gosub Empfangewr
'Gosub Status
End If
Loop
'- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
'SUBs
Sub Sendewr
Line2 = " sende Anfrage"
Printbin Packets(1) ; 10
Gosub Lcdout
'Gosub Clc
Return
End Sub Sendewr
' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sub Empfangewr
Line2 = " warte auf Daten"
'Gosub Lcdout
Inputbin Packete(1) , 8
Printbin Packete(1) ; 8
Crce = Crc16(packete(1) , 6)
Crc_l = Low(crce)
Crc_h = High(crce)
Cls
Locate 1 , 1
Lcd "Empfangenes Paket:"
Locate 2 , 1
Lcd "1:" ; Str(packete(1))
Locate 2 , 5
Lcd "2:" ; Str(packete(2))
Locate 2 , 9
Lcd "3:" ; Str(packete(3))
Locate 2 , 13
Lcd "4:" ; Str(packete(4))
Locate 2 , 17
Lcd "5:" ; Str(packete(5))
Locate 3 , 1
Lcd "6:" ; Str(packete(6))
Locate 3 , 5
Lcd "7:" ; Str(packete(7))
Locate 3 , 9
Lcd "8:" ; Str(packete(8))
Locate 4 , 1
Lcd "CRC_l:" ; Crc_l
Locate 4 , 12
Lcd "CRC_H:" ; Crc_h
'Gosub Status
Return
End Sub Empfangewr
'- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
'Checksumme berechnen
Sub Clc
Bcclo = &HFF
Bcchi = &HFF
Return
End Sub Clc
'- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
'LCD Ausgabe
Sub Lcdout
Cls
Locate 1 , 1 '1. Zeile
Lcd Line1
Locate 2 , 1 '2. Zeile
Lcd Line2
Locate 3 , 1 '3. Zeile
Lcd Line3
Locate 4 , 1 '4. Zeile
Lcd Line4
Return
End Sub Lcdout
'- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
'Status Auswertung
Sub Status
If X = 6 Then
Line3 = "ok"
Print "kein fehler"
Else
Line3 = "Fehler"
Print "fehler"
End If
Gosub Lcdout
Return
End Sub Status
'- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
End
also anscheinend empfängt er alle bytes, aber er ordnet sie falsch.
byte 6,7,8 stellt er immer vorran.
wenn ich ein zweites paket sende überschreibt er byte 7, 8 garnicht
beim dritten paket überschreibt er alle bis auf byte 8
VERZWEIFLUNG!!!
Ich schau' mir dein Programm grad an, bleib locker.
Wenn du grad in der Panik-Phase bist, die immer irgendwann eintritt, dreh' ein paar Runden ums Haus oder füttere die Katze, kraulen ist noch besser. In dem Zustand sieht man den Wald vor Bäumen nicht mehr.
(glaub' mir, ich mach das schon länger)
Guter tipp danke, das problem ist nur dass es sich hierbei um ein projekt für die arbeit ist und ich am 15.nov abgabetermin habe.
Aaaallsooo:
Im Programm ist KEIN direkter Fehler, es geht ums Timing
Vom Sendwr bis zum Inputbin brauchst du offenbar mal zu lange, da geht was verloren.
du MUSST config serialin = buffered angeben, der Sender schickt nach Empfang sicher sofort los, anders kriegst du die Hälfte nicht mit.
soweit, sogut.
aaaaber:
Der Sender schickt (ziemlich sicher) nicht nur ein Paket, sondern mehrere.
Es könnte sein, daß er deinen "Bestätigungs-printbin" gleich nach dem Empfangen als Aufforderung versteht, oder es hat andere Gründe.
Deswegen klappt's ja auch einmal, aber dann nichtmehr.
Da du ja das Empfangspaket eh' auf dem LCD zeigst, kannst du diesen "Retour-print" ja mal weglassen, vielleicht reicht das schon.
Sonst muß man sich den Sender näher anschauen.
Nochmal: DU MUSST den serialin-Buffer nehmen (size = 8 muss reichen, wenn der Sender auch wirklich nur ein Paket schickt)
Wenn sich der Sender nicht disziplinieren läßt, müssen wir deinen input auf asynchron umstellen. Wenn der einfach drauflosplappert, wird sowas immer wieder passieren.
Hast du Info, WANNN WER WEM was zu schicken hat ?
Und such keinen Fehler, da is keiner (s.o)
Aufgabenstellung:
also ich hab in diesem fall 12 geräte mit 12 adressen (2-13)
mein mc soll anfangs sequeziell den status der geräte abfragen und den status am lcd und über usart ausgeben.
immer wenn ich eine anfrage an eine gerät sende bekomme ich gleich darauf antwort.
ich glaub nicht, dass was verloren geht, da ich das packet bei der anfrage ja komplett empfange, halt nur in einer falschen reihenfolge.Zitat:
Vom Sendwr bis zum Inputbin brauchst du offenbar mal zu lange, da geht was verloren.
du MUSST config serialin = buffered angeben, der Sender schickt nach Empfang sicher sofort los, anders kriegst du die Hälfte nicht mit.
soweit, sogut.
das hab ich schon versucht, nur dann empfängt er anscheinend garnichtsmehr.
bei weiteren anfragen, bleibt immer das 8byte gleich wie beim ersten und ändert sich nicht.
nein, er schickt sicher nur ein antwort-paket mit 8bytes + 2bytes crcZitat:
Der Sender schickt (ziemlich sicher) nicht nur ein Paket, sondern mehrere.
welchen bestätigungs-printbin?Zitat:
Es könnte sein, daß er deinen "Bestätigungs-printbin" gleich nach dem Empfangen als Aufforderung versteht, oder es hat andere Gründe.
ich sende gerät empfängt und gibt darauf antwort
das hab ich nur gemacht, dass ich die packete am pc mitbeobachten kannZitat:
Da du ja das Empfangspaket eh' auf dem LCD zeigst, kannst du diesen "Retour-print" ja mal weglassen, vielleicht reicht das schon.
Der Inputbin ist einfach und übersichtlich: Er schreibt ab der angegebenen Addresse ( Packete ( 1 ) ) die nächsten 8 Byte, die er erwischt, strikt aufsteigend rein. Da gibt's keine Querschläger.
Das hab ich überprüft, das steht so in der Hex-file.
Wenn also der Sender tatsächlich nur ein paket mit 8 Byte schickt, dann stehen die auch genau so drin, wie sie weggeschickt wurden.
( Ich ignoriere mal die Möglichkeit, daß der Sender was verdreht )
Solange du dich drauf fixierst, daß so ein Buffer schon mal durcheinander kommen kann, hast du schlechte Karten
bis jetzt, hab ich das ganze ja nur mit einem prog das ich geschrieben hab getestet, vielleicht bringt auch das etwas durcheinander. werd mich mal auf den weg machen und es mal schnell in reality testen.
bis jetzt, hab ich das ganze ja nur mit einem prog das ich geschrieben hab getestet, vielleicht bringt auch das etwas durcheinander. werd mich mal auf den weg machen und es mal schnell in reality testen.
also, ich habs jetzt mal vorort getestet und einen pc dazu geschalten, der die empfangenen pakete mitliest:
der pc hat auf die anfrage vom gerät eine antwort bekommen, aber der mc zeigte keine reaktion.
wie kann ich testen, ob beim mc was ankommt. kann ich einfach zwischen die readleitung und gnd eine led reinlöten?
hab den buffer jetzt mal auf 9 gesetzt und hab über ein prog vom pc aus ein 8byte paket zu mc gesendet, und wow er hats richtig angezeigt. auch komisch das ich den auf neun setzten muss, bedeutet dass das die software doch noch etwas anderes mitsendet?
Nun, es zeigt zumindest, daß die Sache nicht ganz so ist, wie angenommen.
Wenn du einen PC als Spion einsetzen kannst, ist es ja super. Schau die die diversen Meldungung genau an.
Bis das geklärt ist, schreib meinethalben auch 11 komma 5 rein, hauptsache, man kommt der Sache näher
ok, das mit dem buffer klappt jetzt auch wie gewollt.
was meinst du mit 11 komma 5?
Ich mein damit, schreib alles rein, was hilft, auch wenn es seltsam scheinen mag
Diese 9. Zeichen schon mal angeschaut, was das ist ?
(Vergiß nicht, ggf. auch Packete(x) anzupassen)
ne habs jetzt anders gemacht, er nimmt auch die acht, er wollte nur das ich auch den ausgang configuriere.
ha ha, die probleme minimieren sich schön langsam. juhu.
ich schließe die geräte die ich ansteuern will nicht direkt am mc an, sondern über ein funkteil, das leider nicht an meinem arbeitsplatz steht sondern einpaar straßen weiter in einem anderen gebäude. so das ich wenn ich es real,ohne softwaresim testen will immer dorthin fahren muss.
das ist macht die sache etwas unflexible, aber naja hilft ja nichts.
bleibt nur noch das große problem warum der mc wenn er mit den geräten verbunden ist keine reaktion zeigt aber der pc schon. könnte es vielleicht sein das der mc zu langsm ist? oder die rx leitung vom funkteil wo anders aufgelekt ist?
gibt es vielleicht irgendeine möglichkeit, dass ich mir eine meldung am lcd ausgeben lasse, sobalt irgendwelche daten empfangen werden. egal ob 1byte oder 20 nur um zusehen ob was ankommt hauptsache rs232 pegel
Hast du jetzt einen serialin= Buffer drin ?
Wenn der MC zu langsam ist, dann ZWISCHEN den "inputbin". Die ganzen LCD-Geschichten brauchen schon ihre Zeit.
Die RX-Leitung woanders ? Da mußt du nachschauen. Gibt's nicht, gibt's nicht.
1)
das mit dem buffer funzt (habs nur mit dem pc getestet)
2)
soll ich die lcd geschichte mal weglassen, und mir nur am schluss, also wenn das empfangen zuende ist, eine meldung anzeigen lassen?
2) versuch es mal.
@gast:
mich hät ja interessiert wie ich das am effektievsten mach
Ich würd mal alles weglassen, was nicht unbedingt notwendig ist.
Aber irgendwie muß es natürlich kontrollierbar sein. Mach es vielleicht mal so, dass du nur dann den Buffer herzeigst, wenn die empfangene Meldung irgendwie nicht passt und es eh' nicht mehr weiter geht.
Für jede OK Meldung zählst du nur irgendwo mit und sagst dann am Schluß
Empfangen: n ok: m
gibt es nicht irgendwie die möglichkeit, das ich beim empfang von daten einen interrupt auslöse und dadurch eine led angeht, nur das ich seh, das der mc auch was empfängt.
Naja. auf dem RX-Interrupt sitzt schon der BasCom drauf.
Du kannst aber eins machen:
Sub Empfangewr
while ischarwaiting() = 0
' LED aus
wend
' LED on hier kommt er nur her, wenn irgendwas ankommt
inputbin .... usw.
Inputbin Packete(1) , 8
passt wunderbar. es hat geklapt bin gerade hingefahren und habs getestet und tatsächlich empfängt er bytes und gibt sie mir ans lcd aus.super
mein nächster schritt:
ich werd versuchen die crc irgendwie mit einzubinden. weis nur noch nicht, wie ich die prozedur mach, denn er muss ja den schritt b für jedes byte machen aber immer unter verwendung von bcclo und bcchi. werd also die init der bcc's relativ weit zu beginn machen und dan eine prozedure für b. muss halt nach dem übertragen der beiden bcc's diese neu initialisieren, damit ich für das nächste packet empfangsbereit bin.
nochmals vielen vielen danke für deine hilfe, und für deine gedult mit mir.
Genau. Initialisieren ganz vorn und dann nach jeder Erstellung oder Prüfung.
Also , weiterhin viel Erfolg !
hab mich gerade mal ans crc gemacht und ne eigene sub erstellt, in der ich dein berechnung 8 mal (pro byte1x) durchlaufen lasse (pro packets(1)...1x)
und am schluss lass ich sie mit ausgeben, aber da kommt er immer auf 0 0. gibts da nicht ne einfachere variante das zu machen, ist ja ein ewig langer code sonst.
0 0 wird zwar nicht stimmen, aber da muß wo ein Hund drinnen sein.
Aber eine Shift-Orgie ist das auf jeden Fall, da is nix zu machen
Also wie schon gesagt, die anfrage und das erhalten einer antwort von mehreren geräten funzt schon mal.
jetzt hab ich gerade auf meine platine noch einen 2 m16 + max232 aufgelötet. der soll die speicherung der daten und das aufbereiten dieser übernehmen.
nun überlege ich schon die ganze zeit was einfacher und sinnvoller ist, i²C oder über ein software uart das einfach den uart datenstrom des 1.mc mitließt. Was denkst du?
gruß
xeus