ATtiny3217 UART Schnittstelle

Droid E. schrieb:

> #define USART0_BAUD_RATE(BAUD_RATE) ((float)(F_CPU * 64 / (16 *
> (float)BAUD_RATE)) + 0.5)


F_CPU * 64 ist bereits größer als der Datentyp int auf dem AVR.
Besser wäre m.E.

 (float)(F_CPU)*64.0 / ...

Grüßle
Volker

wendelsberg schrieb:
> Droid E. schrieb:
>> void uart_send(char c)
>
> Du sendest je ein Byte mit dem Zaehlwert, also 0x00, dann 0x01 usw.
> Sieh in der Tabelle nach, was das fue ASCII Zeichen sind.
>
> wendelsberg

Hallo Wendelsberg,

ich verstehe leider deinen Einwand hier nicht. Der Zähler ist als "char" 
doch genau ein Byte, wo ist das Problem?

Volker B. schrieb:
> Droid E. schrieb:
>
>> #define USART0_BAUD_RATE(BAUD_RATE) ((float)(F_CPU * 64 / (16 *
>> (float)BAUD_RATE)) + 0.5)
>
>
> F_CPU * 64 ist bereits größer als der Datentyp int auf dem AVR.
> Besser wäre m.E.
>
>  (float)(F_CPU)*64.0 / ...
>
> Grüßle
> Volker

Hallo Volker, ich habe nun den errechneten Wert von 1389 direkt in das 
Register geschrieben:

1

USART0.BAUD = 1389;

Problem besteht leider immer noch.

Droid E. schrieb:

> Problem besteht leider immer noch.

Wenn mich nicht alles täuscht, musst Du den TxD-Pin auch noch explizit 
als Ausgang konfigurieren.

Grüßle
Volker

S. Landolt schrieb:
> Wird es vielleicht besser, wenn counter mit 'A' startet statt mit 0?

Ich übertrage anstatt eines Counters, jetzt einfach nur 'A'

1

//uart_send(++counter);

2

uart_send('A');

Und außerdem zeigt HTerm die empfangenen Werte als ASCII  Hex  Dec / 
Bin an. In allen steht immer eine Null und außerdem zeigt HTerm auch an 
das der empfangende Datensatz einen Fehler an.

Datenblatt lesen und Punkt 2. beachten...

> 24.3.1 Initialization
> For setting the USART in Full-Duplex mode, the following initialization
> sequence is recommended:
> 1. Set the TxD pin value high, and optionally set the XCK pin low (OUT[n]  > in 
PORTx.OUT).
> 2. Set the TxD and optionally the XCK pin as an output (DIR[n] in
> PORTx.DIR).
> 3. Set the baud rate (in the USARTn.BAUD register) and frame format.
> 4. Set the mode of operation (enables XCK pin output in Synchronous mode).
> 5. Enable the transmitter or the receiver, depending on the usage.

Grüßle
Volker

Volker B. schrieb:
> Wenn mich nicht alles täuscht, musst Du den TxD-Pin auch noch explizit
> als Ausgang konfigurieren.
>
> Grüßle
> Volker


Hallo Volker,

ich habe vor dem Aufruf von uart_init jetzt folgendes hinzugefügt:

[code]
PORTB.DIRSET = PIN2_bm; // TX
PORTB.DIRCLR = PIN3_bm; // RX
PORTB.DIR |= PIN7_bm;   // XDIR
[code]

Leider immer noch keine Besserung.

Anbei noch ein Screenshot von HTerm, weil der Haken "Show Errors" 
angewählt ist, wird alles Rot dargestellt.

Volker B. schrieb:
> Datenblatt lesen und Punkt 2. beachten...

Full-Duplex?

Droid E. schrieb:

> ich habe vor dem Aufruf von uart_init jetzt folgendes hinzugefügt:
>
> [code]
> PORTB.DIRSET = PIN2_bm; // TX
> PORTB.DIRCLR = PIN3_bm; // RX
> PORTB.DIR |= PIN7_bm;   // XDIR
> [code]

RxD sollte nach dem Reset bereits als Eingang konfiguriert sein. XDIR 
nutzt Du nicht, muss also auch nicht initialisiert werden.

Da das Ausgangsregister des TxD-Pins mit 0 initialisiert ist, empfängt 
Dein PC ein Startbit, sobald Du TxD als Ausgang konfigurierts. Also 
besser den Pin zuerst auf 1 setzten, wie's das Datenblatt vorschlägt.

Grüßle
Volker

Volker B. schrieb:
> Da das Ausgangsregister des TxD-Pins mit 0 initialisiert ist, empfängt
> Dein PC ein Startbit, sobald Du TxD als Ausgang konfigurierts. Also
> besser den Pin zuerst auf 1 setzten, wie's das Datenblatt vorschlägt.
>
> Grüßle
> Volker

Es tut mir leid, aber im Moment kann ich dir nicht folgen! Wann und wie 
sollte ich denn jetzt die entsprechenden Register setzen?

S. Landolt schrieb:
> Die Hardware ist mir unbekannt, aber könnte es sein, dass da eine
> Invertierung des Signals fehlt?

Hallo Landolt,

wie gehe ich dabei vor? Bzw. wie macht man das denn sonst?

S. Landolt schrieb:
> Die Hardware ist mir unbekannt, aber könnte es sein, dass da eine
> Invertierung des Signals fehlt?

Gute Idee. Ich sehe jetzt erst, dass der TO RS485 verwenden will. Warum 
er dann den USART wie folgt konfiguriert, verstehe ich nicht wirklich 
:-(

> USART0.CTRLA =
(...)
> USART_RS485_OFF_gc;     /* RS485 Mode disabled */

Vielleicht sollte er erst mal mit RS232 anfangen...

Grüßle
Volker.

Volker B. schrieb:
> Vielleicht sollte er erst mal mit RS232 anfangen...

Wie genau müssen denn jetzt die Register konfiguriert werden?

Droid E. schrieb:
> Volker B. schrieb:
>> Vielleicht sollte er erst mal mit RS232 anfangen...
>
> Wie genau müssen denn jetzt die Register konfiguriert werden?

Zeig' zuerst mal Deinen Aufbau. Wie sind ATtiny und PC verbunden?
Mir wird's so langsam zu blöde...

Grüßle
Volker

Volker B. schrieb:
> Zeig' zuerst mal Deinen Aufbau. Wie sind ATtiny und PC verbunden?
> Mir wird's so langsam zu blöde...
>
> Grüßle
> Volker

Hallo Volker,

meinst du folgenden Teil:

Verwendete Hardware:
- ATtiny3217 xplained pro
- RS485 xplained pro
- USB auf Seriell Adapter
https://www.amazon.de/gp/product/B007VZY4CW/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

Verwendete Software
HTerm
Port: COM5; Baud: 9600; Data: 8 Bit; Stop: 1; Parity: Even

Adapter[RS485+] mit XPRO[PIN2(B)] und Adapter[RS485-] mit XPRO[PIN3(A)]

Droid E. schrieb:

> Adapter[RS485+] mit XPRO[PIN2(B)] und Adapter[RS485-] mit XPRO[PIN3(A)]

Mach' ein Foto. Deine "Prosa" sagt mir nichts!

Grüßle
Volker

S. Landolt schrieb:
> Zugegeben, ich habe keine Ahnung, wieviel es bringen könnte, aber wollen
> Sie nicht doch eben mal schnell diese Invertierung versuchen, kostet ja
> keine Minute? PORTB.PIN2CTRL=0x80?

Was auch immer du möchtest ;)

Ich bekomme in der tat jetzt ein 'A' allerdings immer mit einer Null 
abwechselnd und außerdem verstehe ich nicht warum HTerm mir diese alle 
mit Fehler anzeigt.

> Mach' ein Foto. Deine "Prosa" sagt mir nichts!
>
> Grüßle
> Volker

Wenn das nicht ausreicht kann ich auch gerne ein Foto ohne Verkabelung 
senden, auch gerne von der Rückseite.

S. Landolt schrieb:
> Schön, wenigstens ein Stückchen weiter. Ich darf mich verabschieden,
> schönes Wochenende!

:(

S. Landolt schrieb:
> Sie haben das richtig verstanden, dieses 'PORTB.PIN2CTRL=0x80' gehört in
> die Initialisierung?
>
> Jetzt muss ich endgültig weg.

Warum kommt dann immer das 'A' und eine 0 abwechselnd?

>> Adapter[RS485+] mit XPRO[PIN2(B)] und Adapter[RS485-] mit XPRO[PIN3(A)]
>
> Mach' ein Foto. Deine "Prosa" sagt mir nichts!
>
> Grüßle
> Volker

So,

nun ein Foto von
- Vorderseite
- Rückseite
- Adapter

Droid E. schrieb:

> nun ein Foto von
> - Vorderseite
> - Rückseite
> - Adapter

OK, Du willst also via RS485 kommunizieren. Warum schreibst Du das nicht 
explizit?

Kannst Du mir dann bitte erklären, warum Du in der MCU den RS485-Modus 
deaktivierst (letzte Zeile)?

>    USART0.CTRLA =
>        (0 << USART_RXCIE_bp)   /* Receive Complete Interrupt */
>     | (0 << USART_TXCIE_bp)   /* Transmit Complete Interrupt */
>     | (0 << USART_DREIE_bp)   /* Data Register Empty Interrupt */
>     | (0 << USART_RXSIE_bp)   /* Receiver Start Frame Interrupt */
>     | (0 << USART_LBME_bp)    /* Loop-back Mode Enable */
>     | (0 << USART_ABEIE_bp)   /* Auto-baud Error Interrupt Enable */
>     | USART_RS485_OFF_gc;     /* RS485 Mode disabled */

Liest Du eigentlich die Kommentare, die Du in Deinen eigenen Code 
schreibst oder sind das Write-Only-Kommentare?

Dann zur Verdrahtung. A gehört auf + und B auf -
Wenn man's andersherum macht, gibt's Probleme, wie Du ja selber bereits 
festgestellt hat. Die Invertierung des Signals ist keine wirklich gute 
Idee. Hinweis: Einfach mal ins Datenblatt der verbauten 
RS485-Transceiver gucken. Wenn man nach Trial&Error verdrahtet, sollte 
man auch den Error-Fall erkennen können.

Dann sollte die Masse der RS485-Busteilnehmer ebenfalls verbunden 
werden.

Auch sollte sichergestellt sein, dass der Bus im Ruhezustand im 
inaktivem Zustand ist. Dazu sollte eines der Interfaces am Bus mit 
entsprechenden Widerständen beschaltet werden. Such' mal unter den 
Stichworten "RS485" und "Bias". Ob das eine der von Dir verwendeten 
Baugruppen macht, weiß ich nicht und ich recherchiere das auch nicht für 
Dich.

Grüßle
Volker

S. Landolt schrieb:
>> Die Invertierung des Signals ist keine wirklich gute Idee
> Sollte ja auch keine dauerhafte Lösung sein,

Stimmt, ich wäre nicht auf die Idee gekommen, dass jemand RS485 so 
merkwürdig verdrahtet.

> (...) sondern nur zur Abklärung
> dienen. Bevor da wieder jemand von Faktor 64 oder CLK_PER schwadroniert
> ...

Ja, unser lieber Hassknecht... ;-)

Grüßle
Volker

Volker B. schrieb:
> Stimmt, ich wäre nicht auf die Idee gekommen, dass jemand RS485 so
> merkwürdig verdrahtet.

Ich wollte mich noch bei euch allen dafür bedanken dass ihr mir geholfen 
habt, ich hoffe das ich der Community in Zukunft ebenfalls helfen kann, 
danke und Daumen hoch :)