AVR-ASM M8 USART-Funk problem

[Fritzl W. (friz)]

Ich habe seit Tagen ein Problem mit meinem 433Mhz Funk.
Gesendet wird aus einem Atmega644 über ein Funkmodul (aus unserer Firma)
zum passenden Empfänger an einen Atmega8, welcher am HTerm ausgeben
soll.

Meine Beobachtungen: Controller funkt richtig an Empfängermodul (300Baud
bei 1Mhz UBRR=207). Am ist am Hterm (FTDI) alles wunderbar abzulesen.
Also funktioniert!?
Ein kurzes Programm am M8 soll 8 Bytes einlesen, richtig ordnen, (nach 
0x0f zu lesen beginnen) und dann über FTDI am PC anzeigen zur Kontrolle. 
Und da liegt mein Problem.
Der M8 liest alle 8 Bytes ein und gibt dann blödsinn aus sobald er mehr
als 6 Bytes wieder ausgeben soll. Auf den Bildern ist zu sehen wie es 
aussehen sollte bei 6 BYTES und wie es bei 8 Bytes aussieht.

Es soll ein kontinuierlicher Zeichenstrom am Empfänger ankommen der
immer gleich bleibt wenn keine Taste gedrückt ist damit ich die 
Steuerung dann richtig auf die Antribe ummünzen kann.

Ich weiss nicht ob es am Programm liegt oder an der übertragung zum pc 
)FTDI-Baudrate). Ich hatte bis jetzt noch nie einen Quarz bei Usart 
gebraucht. Vielleicht liegts daran.?!

 * rosnmara.asm
 *
 *  Created: 27.05.2015 16:44:53
 *   Author: zigein
 */ 
   .include "m8def.inc"
;
;
 .def  usart1    =  r0  ;BYTE1: USART Empfangsspeicher
 .def  usart2    =  r1  ;BYTE2: USART Empfangsspeicher
 .def  usart3    =  r2  ;BYTE3: USART Empfangsspeicher
 .def  usart4    =  r3  ;BYTE4: USART Empfangsspeicher
 .def  usart5    =  r4  ;BYTE5: USART Empfangsspeicher
 .def  usart6    =  r5  ;BYTE6: USART Empfangsspeicher
 .def  usart7    =  r6  ;BYTE7: USART Empfangsspeicher
 ;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;MAKROS;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 .macro warte
     ldi     r19,  255
     ldi     r18,  255
 delay1:  dec    r19
      brne  delay1  
      ldi    r19,  255
      dec    r18
      brne  delay1
.endm
 .cseg            
 .org 0x000;;;;;;;;;;Interrupt Einsprung-Adressen
rjmp  reset          ; RESET 
reti      ; INT0 External Interrupt Request 0
reti      ; INT1 External Interrupt Request 1
reti      ; TIMER2 COMP Timer/Counter2 Compare Match
reti      ; TIMER2 OVF Timer/Counter2 Overflow
reti      ; TIMER1 CAPT Timer/Counter1 Capture Event
reti      ; TIMER1 COMPA Timer/Counter1 Compare Match A
reti      ; TIMER1 COMPB Timer/Counter1 Compare Match B
reti      ; TIMER1 OVF Timer/Counter1 Overflow
  reti      ; TIMER0 OVF Timer/Counter0 Overflow
  reti      ; SPI, STC Serial Transfer Complete
  reti      ; USART, RXC USART, Rx Complete
  reti      ; USART, UDRE USART Data Register Empty
  reti      ; USART, TXC USART, Tx Complete
  reti      ; ADC ADC Conversion Complete
  reti      ; EE_RDY EEPROM Ready
  reti      ; ANA_COMP Analog Comparator
  reti      ; TWI Two-wire Serial Interface
  reti      ; SPM_RDY Store Program Memory Ready
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; RESET ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  reset:  
    ldi    r16, high(ram
     out    sph,  r16
    ldi    r16,  low(ramend)
    out    spl,  r16
;
;;;;;;;;;;;;;;;;;;;Ports initialisieren;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;        
        ldi  r16,  (1<<RXEN)|(1<<TXEN)    
   out  UCSRB,  r16
   ldi     r16,  (1<<UCSZ1)|(1<<UCSZ0)  ; 8-Bit-modus
   sts  UCSRC,  r16
   ldi  r16,  207        
   out  UBRRL,  r16    
;
loop:
  
  sbis  UCSRA,    rxc        
rjmp    loop
  in  usart1,    udr        
  ldi  r16,    0xf0
  cp  usart1,    r16  ; nur wenn erstes Byte 0xf0, 
  breq  usartgo    
  cbi  portb,    2
rjmp          loop
;
usartgo:
  sbi  portb,    2
uart1:
   sbis  UCSRA,    rxc      
  rjmp  uart1
  in  usart1,    udr        
uart2:
   sbis  UCSRA,    RXC        
   rjmp  uart2
   in  usart2,    udr        
uart3:
  sbis  UCSRA,    RXC    
  rjmp  uart3
  in  usart3,    udr    
uart4:
  sbis  UCSRA,    RXC  
        rjmp  uart4
  in  usart4,    udr        
uart5:
  sbis  UCSRA,    RXC  
  rjmp  uart5
  in  usart5,    udr        ; ;  
uart6:
  sbis  UCSRA,    RXC    
  rjmp  uart6
  in  usart6,    udr          
uart7:
  sbis  UCSRA,    RXC  
  rjmp  uart7
  in  usart7,    udr
warte

usart_tx0:
  sbis  ucsra,    udre      
  rjmp usart_tx0
  ldi  r17,    0x0f
  out  udr,    r17
usart_tx1:
  sbis  ucsra,    udre    
  rjmp usart_tx1
  out  udr,    usart1    
usart_tx2:
  sbis  ucsra,    udre    
  rjmp usart_tx2
  out  udr,    usart2    
usart_tx3:
  sbis  ucsra,    udre  
  rjmp usart_tx3
  out  udr,    usart3    
usart_tx4:
  sbis  ucsra,    udre  
  rjmp usart_tx4
  out  udr,    usart4    
usart_tx5:
  sbis  ucsra,    udre      
  rjmp usart_tx5
  out  udr,    usart5    
;
usart_tx6:
  sbis  ucsra,    udre  
  rjmp usart_tx6
  out  udr,    usart6    
usart_tx7:
  sbis  ucsra,    udre  
  rjmp usart_tx7
  out  udr,    usart7    
  rjmp  loop

[S. Landolt (Gast)]

> Ein kurzes Programm am M8 soll 8 Bytes einlesen

Der Empfangsteil ist doch nur für 7 Bytes ausgelegt, danach startet das 
Senden - ich verstehe es nicht.


Nur am Rande:
>  ldi     r16,  (1<<UCSZ1)|(1<<UCSZ0)  ; 8-Bit-modus
>  sts  UCSRC,  r16
Das ist doppelt falsch: es fehlt URSEL und es wird ins SRAM geschrieben.

[Fritzl W. (friz)]

S. Landolt schrieb:
> Der Empfangsteil ist doch nur für 7 Bytes ausgelegt, danach startet das
> Senden - ich verstehe es nicht.

Das Erste Byte ist für die Synchronisation, die nächsten 7 werden für 
die verarbeitung gebraucht. (3Bytes für die Tsten und 4 Bytes für die 
Analogsticks des PS-Controllers). Ich verschicke die 7 Bytes nur zum 
Testen ob alles richtig ankommt. Der Teil im Programm der Sendet kommt 
dann später weg wenn die Funkferbindung für meine Anwendung passt.

S. Landolt schrieb:
>>  ldi     r16,  (1<<UCSZ1)|(1<<UCSZ0)  ; 8-Bit-modus
>>  sts  UCSRC,  r16
> Das ist doppelt falsch: es fehlt URSEL und es wird ins SRAM geschrieben.

"Ursel" eingefügt und "OUT" ausgebessert, ohne Erfolg, aber Danke für 
den Hinweis.

Mir ist gerade aufgefallen, das jeder 2. Sendevorgang korrekt ist also 
vermute ich das es ein Fehler im Programm ist.

[S. Landolt (Gast)]

Sehe ich das richtig: zwischen diesen 8-Byte-Paketen des 644 liegen 
mindestens rund 250 ms?

[Fritzl W. (friz)]

Puh, das habe ich nicht nachgemesessen.
Was wäre das Problem?

Hab mir 8 Leds an den M8 gehängt und auf die Bytes reagieren lassen (im 
Programm).
Bei jedem Tastendruck leuchtet das richtige Led. Auch am Oszi sind keine 
spitzen erkennbar, auch nicht an den nackten Pins ohne Led. Die annahme 
(RX) sollte also funktionieren.

[S. Landolt (Gast)]

> Was wäre das Problem?

Nachdem der ATmega8 das 8. Byte empfangen hat, wartet er 65 ms, 
anschließend sendet er 267 ms lang; da das letzte Byte im Sendepuffer 
übernommen wird, haben wir in der Summe rund 300 ms. Die 
Empfangshardware hat einen 'two-level-FIFO', also darf frühestens nach 
rund 235 ms wird etwas hereinkommen, sonst gehen Empfangsdaten verloren.

[S. Landolt (Gast)]

Okay, aber wegen des Synchronisationsbytes dürften nur komplette Blöcke 
verschwinden. Jetzt weiß ich erstmal nicht weiter.

[Fritzl W. (friz)]

Ohhh ja, Bitte nochmal für den DAU.

Was ist mit der Empfangshardware gemeint? Sollte ich ein Delay zwischen 
empfangen und ausgeben einbauen?

Empfangsdaten gehen permanent verloren. Der M8 soll auch nur Bytes lesen 
wenn er mit dem erledigen seiner Aufgaben fertig ist. Erst dann soll er 
wieder lauschen was seine nächsten Aufgaben sind. Danach wird eventuell 
verglichen oder kontrolliert und dann reagiert, bis er wieder lauscht 
wies weitergeht.

Nochmal, das der M8 über FTDI(USART) mit dem PC verbunden ist und die 
Daten wieder ausgiebt ist nur eine Hilfestellung für mich damit ich den 
Sendevorgang überwachen kann. So eine art Debugleitung zum selber 
programmieren. Sehr primitiv und umständlich, aber .....so bin ich!

S. Landolt schrieb:
> Jetzt weiß ich erstmal nicht weiter.
Danke fürs drüberschaun

[S. Landolt (Gast)]

Ich glaube weniger, dass es am internen RC-Oszillator liegt, aber die 
Quarzfrage lässt sich leicht entscheiden, indem man um +- 2 % verstellt, 
also UBRRL auf 203 bzw. 211 setzt und schaut, ob es funktioniert.

[S. Landolt (Gast)]

Ihn dünkt, er säh' 'nen Friederich
  in der Autorenzeile.
Er guckt' noch mal, und merkt', es war
  die Brille nicht mehr heile.
"Bis Montag dauert es", sprach er,
  "doch eine ganze Weile."

[Fritzl W. (friz)]

Ich habe an dem Programm nichtz geändert und seit gestern den Rasenmäher 
im Betrieb und der Funk macht keine Probleme. Nichtmal die Lichtmaschine 
neben über dem Empfänger oder der die ZündSpule(Zündkerze) machen 
Probleme. Danke fürs Drüberschaun.