www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232 Protokoll mit RXD/TXD und STX/ETX?


Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wow dankeschön,

schau mich mal schlau;)

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[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???

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja
in diesem Code versuch ich gerade was nützliches  zu filtern;)

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja eben, so gleich zeitig kann das ja net ganz gehen, "quasi 
gleichzeitig" hab ich auch gedacht

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin total ein neuling,aber geb mein bestes

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8x8 Matrix

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen Dank an Dich Karl Heinz

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;)

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dankeschön an euch beiden, cool;)

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???
  .include "8515def.inc"

  .def  ZwiSpa  = R18
  .def  temp1   = R25
  .def  SchlZaX = R23
  .def  SchlZaY  = R24
  
  ;.EQU fqu = 4000000      ;Quarzfrequenz des AVR
  .EQU fqu = 3686000
  .EQU fbd = 9600         ;Baudrate des UART

  .EQU bddv = (fqu/(16*fbd))-1   ;Baudraten-Teiler

;************************************************************


    ldi  R20,High(RAMEND)
    out  SPH,R20
    ldi  R20,LOW(RAMEND)
    out  SPL,R20    ;Stack ini  
      
    ldi temp1, 0xFF     ;Port B = Ausgang, zum Testen auf STK500
    out DDRB, temp1
  
    ldi temp1,bddv     ;Baudrate des UART einstellen
    out UBRR,temp1

;Einstellen des Datenformats: 8 Datenbytes, 1 Stoppbit
;Aktivieren von receiver und transmitter

    sbi  UCR,RXEN    
    sbi  UCR,TXEN  
              
;hier empfängt das UART 11Bytes von LabView (STX,8malDaten,CS,ETX)
;CS=Checksumme
;z.B. 02FF FFFF FFFF FFFF FF00 03
;die Checksumme wird anschließend ausgewertet      
  
EmpfangenS:  ldi R26,$00          
    ldi R27,$02
        
Empfangen:  
    sbis USR,RXC  
    rjmp Empfangen

FrameError:  sbic USR,FE  
    rjmp Empfangen

    in temp1,UDR  
    st X+,temp1      
          
    out PortB,temp1

    inc SchlZaY       
    cpi SchlZaY,11                            
    brne Empfangen         

;hier überprüfe ich die 8 Datenbytes mit der XOR-Verknüfung und 
;vergleiche es mit der empfangene Checksumme (0x0A)  
          
Checksumme: ldi ZwiSpa,0x00
     ldi temp1,0x00
     ldi SchlZaX,0x00
    
;das STX/ETX wird nicht mit in der Checksumme  XOR verknüpft  
     ldi R26,$0A  
    
     ld ZwiSpa,-X  ;Lade Wert -X in ZwiSpa
Loop7:     ld temp1,-X
          
     eor ZwiSpa,temp1            
     inc SchlZaX
     cpi SchlZaX,7  ;insgesamt 7Verknüfungen
     brne Loop7


     ldi R26,$0A
     ld temp1,X  ;empfangene CS laden 0x0A
    
;Errechnete CS und empfangene CS vergleichen
     cp ZwiSpa,temp1  

     brne CheckSumFalse 
     rjmp CheckSumOK

;Prokoll zurück STX;1Daten;ETX        
;hier sende ich 3 Bytes zurück, mit der Quitierung der Checksumme; 
;OK nicht OK      
          
CheckSumOK:  ldi  SchlZaY,0x00
    ldi  temp1,0x00

sendSTX1:           sbis  USR,UDRE  
    rjmp  sendSTX1          
    ldi  temp1,0x02  ;STX
    out  UDR,temp1            
    inc     SchlZaY 
  
sendOK:    sbis  USR,UDRE  
    rjmp  sendOK
    ldi  temp1,0xFF  ;FF= OK
    ;mov  temp1,ZwiSpa  ;Errechnete Checksumme zurück
    out  UDR,temp1
  
    inc      SchlZaY 
sendETX1:  
    sbis USR,UDRE  
    rjmp sendETX1
    ldi temp1,0x03  ;ETX
    out UDR,temp1

    inc   SchlZaY          
    cpi   SchlZaY,3                         
    brne  CheckSumOK                  
    rjmp EmpfangenS    

;Falls die errechnete CS nicht identisch ist
CheckSumFalse:  ldi SchlZaY,0x00
    ldi temp1,0x00

sendSTX0: sbis USR,UDRE
    rjmp sendSTX0        
          
    ldi temp1, 0x02    ;STX
    out UDR, temp1              
    inc SchlZaY 
  
  
sendFalse:  sbis USR,UDRE        
    rjmp sendFalse


    ldi temp1,0x00    ;00= Nicht OK
    out UDR, temp1
  
    inc SchlZaY 
  

sendETX0: sbis USR,UDRE
    rjmp sendETX0
    ldi temp1,0x03    ;ETX
    out UDR, temp1

    inc     SchlZaY           
    cpi     SchlZaY,3                          
    brne    CheckSumFalse     

    rjmp   EmpfangenS    ;wieder zu Empfangen

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab mir docklight installiert...
test mal ein wenig

Autor: manuete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.