Yuhuu! - aber 2024-11-24 - der UART funktioniert gesichert!

jetzt habe ich das auf der Homepage - der Plan geht jetzt so, ich zeige, Filme, was geht und was nicht. Es ist eindeutig, dass Zeichen übertragen werden, wenn auch falsch. Aber ich probiere jetzt trotzdem erst weiter. Und - vielleicht klappt es doch noch so. Und ich gucke mir noch mehr Parameter an. So weit es die gibt

ich glaube ich verstehe jetzt etwas mehr

1. Datenflusssteuerung auf Protokollebene ist - nur - Vermutung bei TCP/IP - also, das bezieht sich auf die oberen Schichten, wo schon die Hardware verlinkt ist
2. Hardware Datenflusssteuerung bedeutet bei RS232 - folgendes: Wir haben ja noch die anderen Pins CTS/RTS ... usw. Das muss ich noch ganz genau lernen und auf Hardware Ebene heisst ohne Zeichen zu verschwenden, dass wir diese Leitungen nutzen
3. Software Ebene. Die ersten ASCII Zeichen sind ja -

   NAK/ACK, NUL, DC1..DC4... VT, HT, SOH, STX, ETX ETB EOT ...
   

Und das heisst, ich habe die Verbindung hingekriegt, dass Zeichen regulärt gesendet wurden

Warum eigentlich? Wahrscheinlich, weil das was ich verwendet habe, hatte drei Leitungen

1. RxD
   

2. TxD
   

3. GND
   

Und jetzt ist das STK500 im Spiel. Und - jetzt sind ohne es zu wollen, RTS und CTS usw verbunden. Das klingt gut und ist wahrscheinlich schlecht. Weil ich vermute, wenn das Handshanking falsch benutzt wird, ist es schlecher, als, wenn es nicht da ist

Was ist denn Software Handshanking. Wir haben -

RxD, TxD

und

GND

- und wir haben die ersten ich sage 32 Zeichen oder wie viel. Jetzt kommt

ACK/NAK

und

X-ON/X-OFF

- das ist

SI/SO

bzw.

Strg-S, Strg-Q

und würde sagen, das ist eben das Software Handshaking auf Hardware Ebene

Wie gesagt, so weit ich sehe ist Protokollebene, nur für die oberen Schichten. Und ich lerne das noch 100 prozent auch mit RS232

Verstehen tue ich es trotzdem nicht - weil der Witz ist ja - die 8 Bit Zeichen kommen ja trotzdem an. Und so wie Linux gemacht ist geht das mit

echo "abc" > /dev/ttyS3
cat /dev/ttyS3

Die zeichen kommen ja trotzdem an. Genauso wie

ACK/NAK

. Die Zeichen sind ja trotzdem 8 Bit immer, übertragen, oder 5 Bit

Nur, ich glaube das Software Handshaking auf Hardware Ebene ist dazu da - das ende eines Datenpaketes zum beispiel für die nächste ebene ein zu leiten, oder - sagen wir - das Ende der Übertragung

Ich kann mir trotzdem vorstellen, durch das

CTS/RTS

- was jetzt da ist, ist das Ding durcheinander -

es stimmt nicht, was ich sagte, dass das

CTS/RTS

vom STK500 da eine rolle spielt

1. Eine befriedigende Nachricht, ich hatte keine Lust den MAX232, zu löten. Deswegen habe ich mich einem Trick bedient, die gute Nachricht, ich habe die Leitungen RxD TxD bei Sub-D-9 Verstanden. Es sind leitungen 2 und 3. Und - ich habe nie irgendetwas mitübertragen abgesehen von der äusseren Masse. Auch nicht Pin 5. Es hat getan

   Die Gute Nachricht, das funktioniert. Ich habe das gemacht, um die anderen Leitungen zu unterbrechen

2. Jetzt ist mir was aufgefallen
   1. Das Ergebnis ist genau das gleiche, wie wenn ich das Ding direkt drin habe - das ist gut - weil ich die Leitungen richtig im Grif habe, schlecht, weil - nein, es heisst einfach eines: Darin liegt es nicht

   2. Das geht auch gar nicht. Wenn ich ein UART - dann sagen wir, ist jede Leitung

      CTS/RTS
      

      aber eben RxD TxD alles über das UART gesteuert. Es ist allerdings seltsam. Wenn das STK500 selber die Steuerleitungen übernimmt, ich meine, der controller selber generiert ja die Signale, warum soll das STK500 unabhängig vom Controller das machen. Daneben muss ich RxD und TxD ja extra verbinden auf dem Board. Und nebenbei, wenn CTS und RTS - und die sind am Controller nicht dran, aussen, wo sollen die sein auf dem Atmega8 und: Jetzt könnte man sagen, der UART gehört wie beim IBM PC nicht zum 8086er Prozessor. aber hier ist der UART ja auf dem Atmega8. Das geht gar nicht, dass CTS/RTS sich verselbstständigen

OK, es ist eine beschissene Scheisse, ich habe es mir fast gedacht.

Das mit dem Systemtakt ist mir bis jetzt unheimlich, aber ich kann es erklären, ich habe was dazu gelernt.

Ich bin was das betrifft nicht 100 pro das gebe ich zu, da lege ich auch keinen Wert drauf, muss ich ehrlich sagen. Das kommt noch. Wenn man es braucht

Also, das erste ist - ich habe die ganze Zeit vermutet, es liegt an der Baudrate - weil - ich habe alles und jedes bisschen gemacht und den einzigen Fortschritt den ich erzielen konnte, war indem ich RAW einstellte - bei stty

Und - ich habe die Parität richtig auf ODD gestellt, wie ich im Controller Aktiviert - ebenso hatte ich zwei Stop Bit. Und ich habe das zusätzlich angeschaltet, ging nicht

Dann habe ich - das zurücknommen, das ist Std nicht drin. Nichts ging. Aber zeichen kam. und bei RAW ging was

Dann habe ich - aber manchmal mit der Baudrate gespielt, und komischerweise hat sich was verändert an den Zeichen

Jetzt kam mir die Idee das STK500 und den Atmega8 aus zu lesen, auf welchem CPU Takt der läuft.

und da muss ich sagen, verstehe ich avrdude und STK500 nicht zu 100 prozent

Das eine war. Ich dachte, hat etwa, da der verdoppelte Takt eine Rolle gespielt, das geht ja

Und ich habe dann im Netz gelesen, der Takt ist beim Atmega8, wenn man den kauft und ich habe die ja nicht mit STK500 gekauft, das sind alles neue - ist immer auf 1MHz eingestellt

Das hat mich gewundert. Es gibt diesen magischen Wert

4000000 = 4MHz

Und daneben gibt es den anderen magischen Wert:

 3.6864 MHz

So, aber im Netz stand:

1MHz

und jetzt habe ich das STK500 ausgelesen, dann ergibt sich

Dann steht da ja

 Oscillator      : 3.686 MHz

Dann bin ich selber stutzig geworden. Weil oben stehen die Fuses für den Atmega8. Aber, wenn man hinguckt:

         Programmer Type : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Controller : 2.10
         Topcard         : Unknown
         Vtarget         : 4.6 V
         SCK period      : 832.8 us
         Varef           : 4.5 V
         Oscillator      : 3.686 MHz

r Und dann dachte ich - hey Moment mal diese 3.686 MHz beziehen sich auf das Board und der Atmega8 läuft mit internen Takt, das muss sein, weil - wenn man die ausbaut, kann man die so nehmen, da braucht man zum Glück keinen Quarz

dann dachte ich probiere ich es mit 1MHz

Und, dann habe ich noch ein bisschen mehr geguckt, da gibt es so eine rechnung, bei mikrocontroller.net und die Baudrate, nicht die Baudrate - aber was in UBRR steht oder doch die Baudrate - muss 1 prozent. Und weil nichts ging habe ich mal das verwendet

Keine Sorge, an dem Code von mir ist kein Fehler, der wäre heimlich drin. Ich nehme gleich meinen Code, wie ich ihn bisher nahm und nehme entsprechendes, sie werden sehen mein Code geht genauso mit den richtigen Werten, für letzten UBRRH und UBRRL, der Teiler muss anders sein, wenn CPU Takt und Baudrate sich unterscheiden

Aber die haben das so gebaut, dass bei einem falschen Wert, von Verhältnis CPU Takt und UBBR gibt es eine Meldung. Das ist nicht die welt. Das ist ein Makro. Ich habe es verwendet, auf die Schnelle

Das geht auch so - weil sie haben ja - das Datenblatt. Da steht auch die Formel drin, wie sie mikrocontroller.net anbietet, aber das ist nicht nötig, weil - es gibt in dem Datenblatt für Atmega8 Tabellen für die MHz des Prozessors bezüglich der Baudrate

Der Witz ist - der Prozessor läuft mit 1MHz und die Baudrate mit 9600 geht dann nicht, sondern max. 2400. Und dann geht es.

Hier stehen die Tabellen, jetzt mein eigenes Programm. Ich nehme den Wert aus der Tabelle, für meines Und dann mache ich änderung 2 Stopbits - und - Parität ein Mal Odd und ein Mal even und dann mache ich noch - empfangen - dass die LED blinken.

Es tut auch mit dem eigenen.

Mit dem Wert 25 in UBRR und 2400 Baud. Ich muss eine Besserung machen, das Ding scheint sich bisher nicht gut zu widerholen. Mit jedem neuem RESET kommt eine Meldung. Ich weiss auch, wo der Fehler war. Jetzt läuft da wild "Hallo" herunter. Jetzt hatten die ausgerechnet die Routine sync eingebaut, die ich zunächst verwendet hatte, so sinnvoll ist die nicht. Die hat nicht so viel damit zu tun. Das ist einfach eine Warteschleife, die verzögert und die haben das unter dem Hintergrund gemacht, wenn das Kabel getrennt wird und verbunden, dann wird ohne Pause weiter gesendet und dadurch dass das so weiter läuft, wird beim Wideranschliessen, so zu sagen - der Empfang, der PC - der Terminal nicht zur Ruhe kommen Wenn ich weglasse, geht es jetzt Jetzt teste ich parität - odd und zwei Stop bit

es geht mit zwei Stop bit und odd parität und ich habe festgestellt, das hat zunächst keine Auswirkung auf die Funktion, es wird genauso gesendet.

;; das rauf z"ahlen tut auch vom Sender: Voller erfolg, hier der Code

.include "m8def.inc"

ldi r16, HIGH (RAMEND)
out SPH, r16
ldi r16, LOW (RAMEND)
out SPL, r16

ldi r16, 0xff
out DDRB, r16

.equ BAUDRATE = 25
ldi r16, HIGH (BAUDRATE)
out UBRRH, r16
ldi r16, LOW (BAUDRATE)
out UBRRL, r16

;ldi r16, (0 << UCSZ2)
;out UCSRB, r16
ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0)
;ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0)
out UCSRC, r16

;;ldi r16, (1 << TXEN)
;;out UCSRB, r16
;sbi UCSRB, TXEN
; Enable Receiver and Transmitter
ldi r16, (1<<RXEN)
out UCSRB,r16

recieve_loop:
sbis UCSRA, RXC
rjmp recieve_loop
in r16, UDR
com r16
out PORTB, r16
rjmp recieve_loop

mit dem C Code habe ich die Zählroutine der Bash zu zeichen verwandelt - die ich mit echo senden kann

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main (int argc, char *argv []) {
    printf ("%c", atoi(argv[1]));
return 0;
}

hier das Bash Skript Das video folgt

#!/bin/bash

i=0
while [ true ]
do
    while [ $i -lt 255 ]
    do
        i=$(($i+1))
        ./atoi $i > /dev/ttyS3
        ./atoi $i
        sleep 1
    done
done

Und die Codes folgen natürlich auch

.include "m8def.inc"

ldi r16, HIGH (RAMEND)
out SPH, r16
ldi r16, LOW (RAMEND)
out SPL, r16

;ldi r16, 0b00000010
;out DDRD, r16

.equ BAUDRATE = 25
ldi r16, HIGH (BAUDRATE)
out UBRRH, r16
ldi r16, LOW (BAUDRATE)
out UBRRL, r16

;ldi r16, (0 << UCSZ2)
;out UCSRB, r16
;ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0) | (1 << USBS) | (1 << UPM0) | (1 << UPM1)
ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0)
out UCSRC, r16

;;ldi r16, (1 << TXEN)
;;out UCSRB, r16
;sbi UCSRB, TXEN
; Enable Receiver and Transmitter
ldi r16, (1<<TXEN)
out UCSRB,r16

again:
ldi r16, 'H'
rcall rs232out
ldi r16, 'a'
rcall rs232out
ldi r16, 'l'
rcall rs232out
ldi r16, 'l'
rcall rs232out
ldi r16, 'o'
rcall rs232out
ldi r16, 10
rcall rs232out
ldi r16, 13
rcall rs232out
rjmp again

rs232out:
sbis UCSRA, UDRE
rjmp rs232out
out UDR, r16
ret

Und hier

.include "m8def.inc"

ldi r16, HIGH (RAMEND)
out SPH, r16
ldi r16, LOW (RAMEND)
out SPL, r16

;ldi r16, 0b00000010
;out DDRD, r16

.equ BAUDRATE = 25
ldi r16, HIGH (BAUDRATE)
out UBRRH, r16
ldi r16, LOW (BAUDRATE)
out UBRRL, r16

;ldi r16, (0 << UCSZ2)
;out UCSRB, r16
ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0) | (1 << USBS) | (1 << UPM0) | (1 << UPM1)
;ldi r16, (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0)
out UCSRC, r16

;;ldi r16, (1 << TXEN)
;;out UCSRB, r16
;sbi UCSRB, TXEN
; Enable Receiver and Transmitter
ldi r16, (1<<TXEN)
out UCSRB,r16

again:
ldi r16, 'H'
rcall rs232out
ldi r16, 'a'
rcall rs232out
ldi r16, 'l'
rcall rs232out
ldi r16, 'l'
rcall rs232out
ldi r16, 'o'
rcall rs232out
ldi r16, 10
rcall rs232out
ldi r16, 13
rcall rs232out
rjmp again

rs232out:
sbis UCSRA, UDRE
rjmp rs232out
out UDR, r16
ret

das kommt zu den Std. Übungen, Externe Interrupts und RS-232. Und jetzt kommt noch - alles auf die Homepage - aber - LCD HD44780 und - was ich gucke, hat der Atmega8 einen DA Wandler.

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Analoge_Ein-_und_Ausgabe

Ja, wenn ich mit dem Timer auch fertig bin, werde ich mal probieren, folgendes zu tun. Ich werde mich nachdem auch i2c habe, mich dem Thema AD-Wandler und DA-Wandler zu wenden. Und - und ich werde - einfach mal FFT aussen vor lassen. Einen Sound Abtasten und ich werde versuchen ihn unweigerlich wieder mit der entsprechenden Frequenz auf einen Lautsprecher zu schicken. Mal sehen, was man hört. Das kommt später.