hi, kann mir einer vielleicht anhand eines Beispieles zeigen wie ich anhand STX und ETX und Checksumme mein Programm erweitern könnte habe den AT90S8515 Muss von LabView Daten seriell schicken Soweit funktioniert es, dass ich über mein UART Daten an meinem STK500 empfangen kann und senden, aber da ist das Protokoll nicht dabei das check ich irgendwie noch nicht, da ich keinerlei Beispiele gesehen habe vielen vielen Dank .include "8515def.inc" .def temp1 = R16 .def SchlZaY = R17 .def out1 = R18 .EQU fqu = 3686000 .EQU fbd = 9600 .EQU bddv = (fqu/(16*fbd))-1 ldi temp1, LOW(RAMEND) out SPL, temp1 ldi temp1, HIGH(RAMEND) out SPH, temp1 ldi temp1, 0xFF out DDRB, temp1 ldi temp1,bddv ;Baudrate des UART einstellen out UBRR,temp1 sbi UCR,TXEN sbi UCR,RXEN Empfangen: sbis USR,RXC rjmp Empfangen in tenmp1, UDR out PortB, temp1 Senden: sbis USR,UDRE rjmp Senden out UDR, temp1
[SYN+] STX Len SRC DST Cmd [Data] CRC das ist ja noch komplexer als ich dachte, wie sieht das in Assembler erst aus?? brauche doch nur vor meinen Nutzdaten dieses STX, mit einer XOR-Verknüpfung müsste ich irgendwie die Checksumme überprüfen und dann noch das ETX STX|Nutzdaten|Nutzdaten|Nutzdaten|Checksumme|ETX irgendwie muss man nur 0x02 für STX und 0x03 für ETX und die Nutzdaten werden automatisch gefiltert???
Das kann man machen, automatisch ist allerdings gar nichts. Im Empfaenger hat man immer eine Statusmaschine, die arbeitet das Protokol ab. Auch in ASM sieh t das wie eine lange statusmaschine aus. Ja, als Checksumme, kannst Du alle Daten XOR nehmen, oder alle Daten in ein Byte aufsummieren. Vieles ist moeglich. Es gibt auch Leute, die Wollen dass STX und ETX nicht in den Daten vorkommen und codieren die dann um, aus einem 0x02 wird dann ein 0x02 0x02, oder ein % davor usw.
okay, dankeschön also mein Empfänger ist ja das UART, UART Daten Regeister mir Statusmaschine meint man was genau?? oja ich dachte auch das STX und ETX net in den Daten vorkommen
Eine statusmaschine :
Rxd:=UDR; // uart daten register
switch state {
0: if Rxd=STX then state=1; |
1: data[0]=Rxd; State=2; |
2: data[1]=Rxd; State=3; |
3: data[2]=Rxd; State=4; |
4: ....
N: pruefe CRC
N+1: hier kommt ETX
ok nop, und diese statusmaschine muss ich dann auch implementieren, das ist dann zwingend zu meinem Protokoll, richtig?? oder das ist dann mein vollständiges Protiokoll??
Die statusmaschine arbeitet das Protokol ab. Wie du beim code von Rene siehst, sagt dir die statusmaschine wann die Meldung komplett ist. Zum Senden musst du die Meldung entsprechend zusammenkleben.
ja in diesem Code versuch ich gerade was nützliches zu filtern;)
macht es kein unterschied, da in diesem Code-Beispiel "Kommunikation ist Halbduplex-, wenn auch das Medium gleichzeitige Übertragung und Empfang erlauben würde" ist doch ein Unterschied, zum voll-duplex das ich benutze beim AT90S8515 (ersetzt ATMega8515)
Vollduplex heisst das Medium erlaubt gleichzeitiges Senden und Empfangen. Mach das auch Sinn fuer die Anwendung ? Ein Master Slave betrieb zwischen PC und Device ist naturgemaess nur Halbduplex. Der PC will was, das Device antwortet.
ja eben, so gleich zeitig kann das ja net ganz gehen, "quasi gleichzeitig" hab ich auch gedacht
Nicht mal das. Der PC will was, das Device antwortet, ist definitiv sequenziell. In der Fachsprache halb duplex. Demgegenueber kann man sich in einer anderen anwendung vorstellen, dass der PC kontinuierlich DAC werte sendet und das Device asynchron dazu hin und wieder etwas quittiert. Das waere dann Vollduplex. Die physikalische Leitung kann Vollduplex sein, das Protokol kann trotzdem halbduplex sein. Umgekehrt geht nicht mehr.
okay ungefähr versteh ich dich nop, mein Device muss zum PC auch ein Protokoll zurücksenden zur Bestätigung, bevor ich die RELAIS auf meiner Platine dann schalten lasse sprich ich brauche ein Vollduplex Protokoll??
manuete wrote:
> sprich ich brauche ein Vollduplex Protokoll??
Nein. Du hast es immer noch nicht.
Stell es dir so vor:
Bei Vollduplex kann gleichzeitig in der Hin-Richtung und in
der Rück-Richtung übertragen werden.
Bei Halbduplex kann etweder in der Hin-Richtung oder in
der Rück-Richtung übertragen werden. Aber nur hintereinander
und nicht gleichzeitig.
Ein Telefon zb. wird praktischerweise im Halbduplex eingesetzt.
Der Eine spricht, der andere hört zu. Und andersrum: der Andere
spricht, der Eine hört zu. Aber wenn beide gleichzeitig
sprechen, versteht keiner was.
Noch deutlicher ist das beim Funk.
Wenn die Sprechtaste am Funnkgerät gedrückt wird, wird der
Lautsprecher abgeschaltet und du kannst ins Mikrofon sprechen.
Lässt du die Sprechtaste los, wird der Lautsprecher wieder aktiv
aber dafür kannst du nicht senden.
Voll-Duplex / Halb-Duplex hat nichts damit zu tun ob ich Daten
nur von A nach B oder auch von B nach A übertragen kann.
Voll- / Halb-Duplex trifft nur eine Aussage darüber, ob der
Informationsfluss gleichzeitig in beide Richtungen laufen kann
oder nicht.
hmmm ok, dann halbduplex Protokoll gibt es ausser dem oberen Link noch weitere Beispiele in asm die ein halbduplex Protokoll mit STX/ETX verwenden ich weiss net wie ich anfangen soll, und mit was und wie
manuete wrote: > hmmm ok, dann halbduplex Protokoll > gibt es ausser dem oberen Link noch weitere Beispiele in asm die ein > halbduplex Protokoll mit STX/ETX verwenden > ich weiss net wie ich anfangen soll, und mit was und wie Fang damit an, dir ein Protokoll auszudenken. Was willst du überhaupt machen? Dann stell dir deine kleine Schwester vor. Die ist zwar brav aber unheimlich dämlich (soll jetzt keine Beleidigung sein). Der musst du alles sagen, von alleine macht sie gar nichts. Aber: Wenn du ihr was sagst, dann macht sie das auch und liefert ein 'OK' oder irgendeine sonstige Rückmeldung. Wenn du jetzt der Befehlssender bist und deine Schwester der Befehlsempfänger, welche Kommandos brauchst du, damit deine Schwester die gestellte Aufgabenstellung erfüllen kann. Auch wichtig: Angenommen ihr seid beide (mit ein paar Freunden) im Raum: Woran kann deine Schwester erkennen, dass jetzt ein Kommando für sie dabei ist und du nicht einfach so mit deinen Freunden sprichst. Im Grunde läuft es meistens auf das gleiche hinaus: Es gibt ein Zeichen, mit dem wird signalisiert: Hier beginnt ein Kommando Es gibt ein Zeichen, mit dem wird signalisiert: Hier endet ein Kommando Die beiden Dinge sind wichtig, denn wenn der Befehlsabarbeiter mitten in eine Übertragung hineinplatzt (Stecker eingesteckt oder dergleichen), dann muss es für ihn eine Eindeutige Kennung geben, bis wohin er noch Zeichen aus einer vorhergehenden Übertragung mitkriegt, und wo denn nun das nächste Kommando anfängt. Erst wenn er dieses Zeichen empfängt, weiss er, dass es hier tatsächlich los geht. Daraus folgt aber auch: Diese Start und Ende Kennzeichnungen dürfen in der restlichen Übertragung nicht vorkommen. Diese Zeichen sind ausschliesslich für diesen einen Zweck reserviert: Den Start und das Ende eines Kommandos zu kennzeichnen. Und das dazwischen: Denk dir was aus. Wenn du zb. Relais schalten willst: Du könntest zb einen String R10 schicken. Und das heist dann R Ich möchte ein Relais schalten ... 1 ... und zwar das Relais Nr 1 0 ... das möchte ich ausschalten
Damit da keine Missverständnisse aufkommen. <STX>/<ETX> kann man zur Start/Stop Synchronisierung benutzen, muss aber nicht. Du kannst dir auch selbst etwas ausdenken. Zb. wird auch gerne sowas benutzt Es gibt kein <STX>/<ETX>. Wann immer der Sender ein Kommando senden will, dann tut er das (der Empfänger darf nur nach Aufforderung senden), allerdings beendet der Sender jedes Kommando mit einem speziellen Zeichen. Das kann zb. ein ';' sein oder der allseits beliebte 'Return'. Das wichtige daran ist: Du machst das so wie du es haben willst und wie du dir am leichtesten tust. Es gibt kein richtig/falsch. Was du dir ausdenkst ist per Definition richtig solange es den gestellten Zweck erfüllt.
dankeschön karl heinz;) für deine so schöne Erklärung, Meine Aufgabe ist es. eine bestehende parallele Schnittstelle die über SPI realisiert ist durch die RS232 ersetzen. Sprich nicht mehr üer SPI sonder über das UART, und das ganze wird durch LabView angesteuert, sprich ich steuere meine RelaisMatrix in LabView und schalte so die gewünschten Relais, dies soll dann mein UART richtig empfangen, bevor er schalten darf, soll er wieder zurück an LabView senden dass er richtig empfangen hat und wenn nicht die Checksumme übereinstimmt dann muss er nochmals warten bis ich über LabView die Daten senden Also: ich muss im Programm lediglich noch dieses Start of Text, Nutzdaten, Checksum und End of Text einfügen, dann müsste es ja klappen An meinem STK500 hat das senden und empfangen der gesendeten Bytes über LabView funktioniert halt ohne Protokoll
manuete wrote: > dankeschön karl heinz;) für deine so schöne Erklärung, > > Meine Aufgabe ist es. eine > bestehende parallele Schnittstelle die über SPI realisiert ist durch die > RS232 ersetzen. > Sprich nicht mehr üer SPI sonder über das UART, > > und das ganze wird durch LabView angesteuert, sprich ich steuere meine > RelaisMatrix in LabView und schalte so die gewünschten Relais, dies soll > dann mein UART richtig empfangen, bevor er schalten darf, soll er wieder > zurück an LabView senden dass er richtig empfangen hat und wenn nicht > die Checksumme übereinstimmt dann muss er nochmals warten bis ich über > LabView die Daten senden > AH. OK. Das heist dann aber auch: Das Protokoll steht bereits und du musst es nur noch ... was den nu? Schreibst du den Sender oder den Empfänger? > Also: ich muss im Programm lediglich noch dieses Start of Text, > Nutzdaten, Checksum und End of Text einfügen, dann müsste es ja klappen > Das klingt jetzt mehr nach: Du programmierst am Sender. Musst also die richtigen Bytes in der richtigen Reihenfolge auf den Weg bringen. Jetzt hab ich den Faden verloren :-) > An meinem STK500 hat das senden und empfangen der gesendeten Bytes über > LabView funktioniert halt ohne Protokoll Na ja. ist doch schon was!
"AH. OK. Das heist dann aber auch: Das Protokoll steht bereits und du musst es nur noch ... was den nu? Schreibst du den Sender oder den Empfänger?" Nein das Protokoll steht nicht;) Da es vorher so ablief: Die Dateneingabe gigen über ne Data-Schnittstelle PortA des Mikrocontrollers und über PortB wurde die SPI sprich MOSI, MISO über /ss (Pin4) des Port aktiviert, also die Datenübertragung Und jetzt muss ich es halt mit der RS232 und einen MAX232 ersetzen, Vorher kamen die Daten parallel und jetzt sollen sie seriell übertragen eben über dieses UART, und dazu verwendet man eben statt PortB -->Port D Pin PD0(RXD) und Pin PD1(TXD) und ich muss es in meinem Assemblerprogramm diese SPI-Schnittstelle ersetzen, und dieses neue RS232-Protokoll einfügen, die Datenübertragung soll aber weiterhin sicher sein... die LabView - Ansteuerung sendet an das UDR des UART insgesamt 11 BYTES, STX,8mal Nutzdaten, Checksumme und ETX (=11Bytes) Der Mikrocontroller empfängt die 11 DAtenbytes und errechnet ebenfalls die CS der empfangenen Nutzdaten, und sendet 3Bytes zurück an die LabView Anwendung. STX,Nutzdaten FF= Ja, ETX -->3BYTES Zumindestesn habe ich es mir so gedacht, nur habe ich keinen Plan wie ich das in dem Code oben einfügen kann
OK. Ich denke ich verstehe jetzt ein bischen besser.
Ja. Eine Statusmaschine für den Empfang, wie oben
angedacht, wäre eine Möglichkeit.
Welche Zustände gibt es denn?
* Zustand: Ausgangsposition.
Es liegt kein Kommando vor
Bezeichnung: INIT
* Zustand: Zeichen werden gesammelt
Bezeichnung: COMMAND
* Zustand: Fehler
Bezeichnung: FEHLER
Dann musst du dir noch überlegen, wie denn der Übergang
der Maschine von einem Zustand zum nächsten erfolgt.
Klarerweise wird ein Zustandsübergang durch den Empfang
eines Zeichens ausgelöst. Aber welche Zeichen führen
zu welchem neuen Zustand
Zustand empfangenes Zeichen neuer Zustand
INIT <STX> COMMAND
alles andere INIT
COMMAND <ETX> INIT
alles andere COMMAND
FEHLER <ETX> INIT
Fehlen nur noch die Aktionen, die bei jedem Zustandswechsel
durchgeführt werden sollen:
INIT alles andere keine Aktion INIT
<STX> Commandobuffer vorbereiten COMMAND
Anmerkung: INIT ist der Grundzustand. Der Sinn dieses
Zustands ist es, auf das <STX> Zeichen zu warten,
welches den Beginn eines Kommandos einleitet. Wird
es angetroffen, so wird alles zur Zwischenspeicherung
des Kommandos vorbereitet und in den Zustand COMMAND
übergewechselt.
COMMAND <ETX> Auswertung INIT
alles andere empf. Zeichen speichern COMMAND
Anmerkung: beim Speichern des Zeichens kann es natürlich
passieren, dass mehr als 9 Bytes empfangen werden.
In so einem Fall wird dann das empfangene verworfen
und in den Zustand FEHLER gewechselt
Nach dem Empfang von ETX kann die Auswertung erfolgen.
ETX kann nur erreicht werden, wenn weniger oder exakt
9 Bytes empfangen wurden. D.h. man wird hier mal
überprüfen, ob das auch genau 9 Bytes waren. Weiters
wird man prüfen, ob die Checksumme stimmt.
Ist eine der beiden Prüfungen negativ, so wird der
Sender benachrichtigt und sofort in den Zustand INIT
gewechselt (und damit auf den Beginn des nächsten
Kommandos gewartet).
Sind beide Bedingungen erfüllt, wird der Sender
über den korrekten Empfang benachrichtigt und
das Kommando zur Weiterverarbeitung freigegeben.
Danach geht es wieder in den Zustand INIT
FEHLER <ETX> INIT
alles andere empf. Zeichen verwerfen FEHLER
Anmerkung: Der Sinn des Zustands FEHLER ist es, alle
Zeichen zu überlesen, bis der ETX empfangen wird.
Der Sender wird über den Fehlerfall informiert
und es geht wieder ab in den Zustand INIT
Tja. So oder so ähnlich könnte deine State-maschine aussehen.
Der Zustand (Status) ist einfach nur eine Variable. Je nachdem
in welchem Zustand die Maschine ist, hält sie unterschiedliche
Werte ( zb. 0 = INIT, 1 = FEHLER, 2 = COMMAND, etc.. )
Wenn ein Zeichen über die Serielle Schnittstelle hereinkommt,
dann sieht die Empfangsfunktion nach, welcher Zustand gerade
anliegt und verzweigt dann in Programmteile, die die beschriebene
Funktionalität realisieren. Steht ein Zustandswechsel an, dann
schreibt die ausführende Funktion einfach nur einen neuen Wert
in diese Status Variable hinein.
im Befehlsatz vom AT90S8515 habe ich keine XOR-Verknüfung gefunden, nur eine OR-Verknüpfung, könnte ich das auch für die Checksummen Überprüfung anwenden, oder net
Denk nach. Wenn du nur genügend unterschiedliche Bytes miteinander OR verknüpfst, dann wird da meistens 0xFF (also alle Bits gesetzt) herauskommen. Nicht besonders sinnvoll für eine Prüfsumme.
manuete wrote: > im Befehlsatz vom AT90S8515 habe ich keine XOR-Verknüfung gefunden, nur > eine OR-Verknüpfung, könnte ich das auch für die Checksummen Überprüfung > anwenden, oder net EOR? Einfach aufmerksam lesen... ;)
Hi an alle, habe hier mal mein Protokoll versucht... Wenn ich es mit meinem STK500 teste, dann funkts net so ganz auf Anhieb, sprich es könnte sein das ich meine Checksumme die ich vom LabView bekomme und im AT90S8515 vergleiche nicht richtig berechne, was ich nicht denke;) Oder liege ich mit dieser Vorgehensweise total falsch???
1 | .include "8515def.inc" |
2 | |
3 | .def ZwiSpa = R18 |
4 | .def temp1 = R25 |
5 | .def SchlZaX = R23 |
6 | .def SchlZaY = R24 |
7 | |
8 | ;.EQU fqu = 4000000 ;Quarzfrequenz des AVR |
9 | .EQU fqu = 3686000 |
10 | .EQU fbd = 9600 ;Baudrate des UART |
11 | |
12 | .EQU bddv = (fqu/(16*fbd))-1 ;Baudraten-Teiler |
13 | |
14 | ;************************************************************ |
15 | |
16 | |
17 | ldi R20,High(RAMEND) |
18 | out SPH,R20 |
19 | ldi R20,LOW(RAMEND) |
20 | out SPL,R20 ;Stack ini |
21 | |
22 | ldi temp1, 0xFF ;Port B = Ausgang, zum Testen auf STK500 |
23 | out DDRB, temp1 |
24 | |
25 | ldi temp1,bddv ;Baudrate des UART einstellen |
26 | out UBRR,temp1 |
27 | |
28 | ;Einstellen des Datenformats: 8 Datenbytes, 1 Stoppbit |
29 | ;Aktivieren von receiver und transmitter |
30 | |
31 | sbi UCR,RXEN |
32 | sbi UCR,TXEN |
33 | |
34 | ;hier empfängt das UART 11Bytes von LabView (STX,8malDaten,CS,ETX) |
35 | ;CS=Checksumme |
36 | ;z.B. 02FF FFFF FFFF FFFF FF00 03 |
37 | ;die Checksumme wird anschließend ausgewertet |
38 | |
39 | EmpfangenS: ldi R26,$00 |
40 | ldi R27,$02 |
41 | |
42 | Empfangen: |
43 | sbis USR,RXC |
44 | rjmp Empfangen |
45 | |
46 | FrameError: sbic USR,FE |
47 | rjmp Empfangen |
48 | |
49 | in temp1,UDR |
50 | st X+,temp1 |
51 | |
52 | out PortB,temp1 |
53 | |
54 | inc SchlZaY |
55 | cpi SchlZaY,11 |
56 | brne Empfangen |
57 | |
58 | ;hier überprüfe ich die 8 Datenbytes mit der XOR-Verknüfung und |
59 | ;vergleiche es mit der empfangene Checksumme (0x0A) |
60 | |
61 | Checksumme: ldi ZwiSpa,0x00 |
62 | ldi temp1,0x00 |
63 | ldi SchlZaX,0x00 |
64 | |
65 | ;das STX/ETX wird nicht mit in der Checksumme XOR verknüpft |
66 | ldi R26,$0A |
67 | |
68 | ld ZwiSpa,-X ;Lade Wert -X in ZwiSpa |
69 | Loop7: ld temp1,-X |
70 | |
71 | eor ZwiSpa,temp1 |
72 | inc SchlZaX |
73 | cpi SchlZaX,7 ;insgesamt 7Verknüfungen |
74 | brne Loop7 |
75 | |
76 | |
77 | ldi R26,$0A |
78 | ld temp1,X ;empfangene CS laden 0x0A |
79 | |
80 | ;Errechnete CS und empfangene CS vergleichen |
81 | cp ZwiSpa,temp1 |
82 | |
83 | brne CheckSumFalse |
84 | rjmp CheckSumOK |
85 | |
86 | ;Prokoll zurück STX;1Daten;ETX |
87 | ;hier sende ich 3 Bytes zurück, mit der Quitierung der Checksumme; |
88 | ;OK nicht OK |
89 | |
90 | CheckSumOK: ldi SchlZaY,0x00 |
91 | ldi temp1,0x00 |
92 | |
93 | sendSTX1: sbis USR,UDRE |
94 | rjmp sendSTX1 |
95 | ldi temp1,0x02 ;STX |
96 | out UDR,temp1 |
97 | inc SchlZaY |
98 | |
99 | sendOK: sbis USR,UDRE |
100 | rjmp sendOK |
101 | ldi temp1,0xFF ;FF= OK |
102 | ;mov temp1,ZwiSpa ;Errechnete Checksumme zurück |
103 | out UDR,temp1 |
104 | |
105 | inc SchlZaY |
106 | sendETX1: |
107 | sbis USR,UDRE |
108 | rjmp sendETX1 |
109 | ldi temp1,0x03 ;ETX |
110 | out UDR,temp1 |
111 | |
112 | inc SchlZaY |
113 | cpi SchlZaY,3 |
114 | brne CheckSumOK |
115 | rjmp EmpfangenS |
116 | |
117 | ;Falls die errechnete CS nicht identisch ist |
118 | CheckSumFalse: ldi SchlZaY,0x00 |
119 | ldi temp1,0x00 |
120 | |
121 | sendSTX0: sbis USR,UDRE |
122 | rjmp sendSTX0 |
123 | |
124 | ldi temp1, 0x02 ;STX |
125 | out UDR, temp1 |
126 | inc SchlZaY |
127 | |
128 | |
129 | sendFalse: sbis USR,UDRE |
130 | rjmp sendFalse |
131 | |
132 | |
133 | ldi temp1,0x00 ;00= Nicht OK |
134 | out UDR, temp1 |
135 | |
136 | inc SchlZaY |
137 | |
138 | |
139 | sendETX0: sbis USR,UDRE |
140 | rjmp sendETX0 |
141 | ldi temp1,0x03 ;ETX |
142 | out UDR, temp1 |
143 | |
144 | inc SchlZaY |
145 | cpi SchlZaY,3 |
146 | brne CheckSumFalse |
147 | |
148 | rjmp EmpfangenS ;wieder zu Empfangen |
> dann funkts net so ganz auf Anhieb,
Das ist eigentlich ziemlich normal, dass Dinge nicht auf Anhieb
funktionieren. Kein Grund zu verzweifeln.
Hast du schon mal probiert, die Bytes die du vom LabView
kriegst mitzuprotokollieren und mal händisch (auf Papier)
die Checksumme auszurechnen? Wenn du das hinkriegst und
auch alle Zwischenergebnisse auf dem Papier kennst, kannst
du hergehen und im Simulator mal diese Bytes einspeisen
und den Programmfluss verfolgen und nachsehen, ab welchem
Zwischenergebnis das Programm zu falschen Werten kommt und,
noch viel wichtiger, wo dein Denkfehler liegt.
hi karl;) ist ja süss das du mir so schnell antwortest... mit Anhieb meinte ich, wenn ich es teste, muss ich an meinem STKBoard öfters was von LabView schicken damit ich was zurücksende Yep hab ich gemacht, also die CS berechnet bei FFFF FFFF FFFF FFFFF ist sie 0... haa sprich ich könnte mein Programm so ändern, dass ich nix einlese sondern einfach diese 8Bytes Schritt für Schritt auswerte, versuch ich jetzt mal;) dankeschön
manuete wrote: > hi karl;) > ist ja süss das du mir so schnell antwortest... > > mit Anhieb meinte ich, wenn ich es teste, muss ich an meinem STKBoard > öfters was von LabView schicken damit ich was zurücksende > > Yep hab ich gemacht, also die CS berechnet bei FFFF FFFF FFFF FFFFF ist > sie 0... Nimm besser 8 reale Bytes die du vom LabView bekommst. Im Web findest du Programme die 'serial Port Monitor' heissen. Die klinken sich auf deinem PC zwischen Programm und serieller Schnittstelle ein und protokollieren jeglichen Datenverkehr mit. Dort kannst du zb. vergleichen ob das, was dein µC empfängt identisch ist mit dem was am PC gesendet wird (ist nicht so selbstverständlich wie es jetzt klingt). Auch kann man damit ganz schnell einen Testdatensatz zu Debug-Zwecken abgreifen. > haa sprich ich könnte mein Programm so ändern, dass ich nix einlese > sondern einfach diese 8Bytes Schritt für Schritt auswerte, versuch ich > jetzt mal;) Yep. Endlich mal wer, der nicht davor zurückschreckt sein in stundenlanger, mühsamer Arbeit erstelltes Programm zu debugzwecken auch mal zu verändern.
hmmm:) das sind eigentlich 8 Reale Bytes die ich vom LabView schicke 02FF FFFF FFFF FFFF FF00 03 das gebe ich in LabView "Basic Serial Write an Read.Vi Panel" write string ein dann kommt im LabView read string zurück: 02FF 03 Bei meinem Code, kommt leider noch manchmal bei der selben Eingabe, mal das und 02FF 0302 FF03 --> egal ob die Checksumme richtig ist oder net... sprich ich über LabView: 02FF FFFF FFFF FFFF FF11 03 schicke, und eigentlich 0200 03 erwarte, für Checksumme nicht Ok, laut meinem Code: Natürlich ist Baudrate, data bits und COM usw richtig eingestellt in LabView, damit die Kommunikation richtig funkt.
"Yep. Endlich mal wer, der nicht davor zurückschreckt sein in stundenlanger, mühsamer Arbeit erstelltes Programm zu debugzwecken auch mal zu verändern." und das hat gewirkt, habe alle Fehler beseitigt, waren ein paar Kleinigkeiten bezüglich des Pointers und des Pointers laden;) zumindestens ganze Feste 11Bytes werden in diesem Protokoll berücksichtigt... supi, dankeschön für den Tipp, hat ein wenig gedauert aber hab es ja noch hingekriegt nach ein paar Stunden;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.