ATmega328P: 9-Bit UART

Simon F. schrieb:
> resh = (resh >> 1) & 0x01;
>   return ((resh << 8) | resl);

Caste das mal nach int

vom Prinzip würde bit0 in einem
>  unsigned char status, resh, resl;
nach  <<8 im status landen und wird deswegen nicht so gerne 
implementiert.
Eigentlich ist da eher die Frage wie der Code in das Datenblatt kommen 
konnte spannend (durch einen Compilerfehler UND return -1 statt return 1 
könnte es zufällig klappen)

evtl. eine Kurzversion:

1

2

unsigned int Extended_USART_Receive (void)      

3

{ while (!(UCSR0A & (1<<RXC0)));          

4

  if UCSR0A & ((1<<FE0) | (1<<DOR0) | (1<<UPE0)))

5

     return -1; 

6

  if UCSR0B & (1<<RXB8)

7

     return (0x100 + UDR0)

8

  return (UDR0)

9

}

H.Joachim S. schrieb:
> Kann denn der FTDI überhaupt 9bit?
Windows behauptet zu 9bit:"The number of data bits must be 5 to 8 bits"
- hTerm: 5..8bit
dazu das C-Beispiel das eigentlich nicht funktionieren 'darf' und der µC 
bei dem 9-bit nicht eingestellt wurde ...
... nur:
>Das auslesen Funktioniert ohne Probleme,[..]
dürfte dann das Hauptproblem sein.

Für µC<->µC könnte 9bit praktisch sein, aber sonst wohl schwierig.

Dirk schrieb:

> Windows behauptet zu 9bit:"The number of data bits must be 5 to 8 bits"

> Für µC<->µC könnte 9bit praktisch sein, aber sonst wohl schwierig.

Nicht wirklich, jedenfalls nicht für Windows. Das unterstützt zwar nur 8 
Datenbits, aber zusätzlich ein Paritätsbit und zwar in den Ausprägungen 
even, odd, mark und space. Also ist es trivial, das Wordformat auf 8M1 
oder 8S1 festzulegen und die Information des 9. Datenbits eben als 
Parity-Error zu empfangen. Kinderkram, das habe ich schon vor >30 Jahren 
erstmals machen müssen...

Allerdings: für hohe Datenraten ist das Konzept eher nicht geeignet. Da 
fehlt dann doch zunehmend die Hardwarunterstützung...

Simon F. schrieb:
> Habe mich nur mal aus Interesse an das 9-Bit UART gestürzt ;)
vom Prinzip ist 9-bit für 8-bit Daten + 1-bit meta/out-of-band/(andere 
Bezeichnung je nach Betrachtung oder Verwendung) Datum ja auch eine u.U. 
praktische Idee. Im letzten Jahrtausend wurden allerdings Kinder mit der 
Idee malträtiert, da für die damaligen BWL-ler Kinderarbeit praktisch 
kostenlos kalkuliert wurde und µC in der Leistungsklasse eines C0,64 als 
Transciver/Proxy etc. ein (umgerechnet) Pullover gekostet hätten.
Den jungen Menschen denen damals erzählt wurde Bit/Byte-Banging sei 
trivial, da Bits nur in den Ausprägungen Mark/Space 0/1 low/high ../.. 
vorkommen und die erst bei hohen Modemgeschwindigkeiten die 
Schwierigkeiten von 9/10/.. oder auch 4-bit Übertragungen bemerkt haben 
(bzw. teilweise wohl nicht) ging es da nicht so gut.
Rein praktisch ist 9-bit auch eher für synchrone Übertragung geeignet, 
da leichte Gangunterschiede sich bei der Asynchronen summieren. Also 
9-bit als 2*6-bit (inkl. Meta information)mit doppelter Baudrate dürfte 
schneller und zuverlässiger als 1*9 bit sein.
So ein Kinderkram kann ja auch durchaus Spass machen und ich fände es 
auch spannend was da genau schief gelaufen ist. Ich hab zumindest 
herausgefunden, dass ich wohl nächstes WE 8-bit mit 6-bit getestet hätte 
(einige Atmel µC benötigen das UMSEL-bit für USCRC) und manchmal 
passieren die unbeschreiblichsten Fehler gerade wenn ein Teil ohne 
Probleme läuft und bspw. zur Fehlersuche noch kurz die Kontroll-Led 
initialisiert wird und der µC daraufhin komplett abstürzt. Kurzer Blick 
ins Handbuch: VCC gehört doch direkt mit einer Spannungsquelle verbunden 
und die Notstromversorgung über einen versehentlich als Eingang 
geschalteten Pin ist gar nicht dokumentiert (und funktioniert wohl auch 
nur mit falsch angeschlossener LED). Kurz: es gibt bei dem 
Versuchsaufbau zu viele Möglichkeiten von einfachst bis kompliziert 
Fehlerchen, als dass es im Forum wirklich konsequent gecheckt werden 
könnte und wenn du so einen µC ohne Spannungsversorgung, leicht 
unterschiedliches Modell, falscher Takt,.... hast, dann passieren 
schnell die zwei Meinungen:
a) der µC hat eine Stromversorgung, da er eigentlich funktioniert und
b) der µC hat keine Stromversorgung, da der Pin nicht angeschlossen ist 
und
c) die Frage: "benötigt der µC eine Stromversorgung an VCC ?" im Forum 
passt auch nicht.
Solche Fehler sind dann schwer zu finden.
(ganz genau bekomme ich den Fehler nicht rekonstruiert, aber +5V an VCC 
hat in dem Fall geholfen)

Hier wäre spannend ob der falsche Atmel-Code mit einem nicht ganz 
korrekt arbeitenden Compiler evtl. das gewünschte Ergebnis bringen 
könnte, ansonsten ob und wie die anderen Bits ankommen.

c-hater schrieb:
> even, odd, mark und space. Also ist es trivial, das Wordformat auf 8M1
> oder 8S1 festzulegen und die Information des 9. Datenbits eben als
> Parity-Error zu empfangen. Kinderkram, das habe ich schon vor >30 Jahren
> erstmals machen müssen...
häufig sollen bei bei einer Datenübertragung mehrere Daten übertragen 
werden und dann erschließt sich sich die Schwierigkeit von solchem 
Byte-Banging, auch wenn diu als junger Mensch dazu gezwungen wurdest ...

NB.: triviales Bit empfangen von IR-FB mit einem PC kann auch 
interessante Fehler verursachen: mir ist damals der PC bei Sonnenschein 
abgestürzt, da da der IR-Detektor wohl bei Überdosis angefangen hast zu 
schwingen und so eine hohe Datenrate geliefert hat. Dadurch dass 
damalige Mäuse tw. ähnliche Effekte hatten ging die Fehlersuche noch 
einigermaßen schnell und Strahlenschutzmaßnahmen haben geholfen, aber 
ein PC der beim ersten Sonnenstrahl der ihn trifft abgestürzt hat schon 
einen gewissen Charme ;-)