USI-UART mit ATTiny85: MSB kaputt

[Markus G. (the_grue)]

Servus zusammen,

Seit einiger Zeit versuche ich einen half duplex USI UART auf dem 
ATTiny85 zu implementieren. Das ganze noch in Rust, als gute Gelegenheit 
Erfahrung zu sammeln. Irgendwann soll das mal Sensorwerte via RS-485 
verschicken. Screenshot des Schaltplans anbei.

Inzwischen funktioniert das Senden schon ... fast! Ich kann 
(unglaublich) meinen Testwert 0x45 und 0x00 verschicken und auf Tx/PB1 
kommt raus was ich erwarte (siehe rw_low.png). RS-485 ignorieren wir 
mal.

Dann hab' ich gemerkt, daß ich im Code noch vergessen habe, RW/PB3 auf 
HIGH zu setzen, damit der RS-485 transceiver auch sendet. Als das 
erledigt war, war das MSB von meinen Testwerten kaputt: aus 0x45 = 
0b0100_0101 wurde 0xC5=0b1100_0101 und aus 0x00 wurde 0x80=0b1000_0000 
(siehe rw_high.png). Was man in rw_high.png ganz gut sieht: das MSB wird 
irgendwie auf HIGH gezogen, bevor es dann ganz kurz doch auf LOW geht.

Testwert 0xFF wird mit RW/PB3=LOW auch kaputt gemacht, zu 0x7F.

Und ganz ehrlich: ich habe keine Ahnung was da passiert. Es ist immer 
das MSB, immer abhängig von RW/PB3. Mein Aufbau ist auf einem kleinen, 
ordentlichen PCB, aber um einen möglichst minimalen Test zu habe, habe 
ich das ganze auch auf dem Breadboard aufgebaut, nur mit U1 (ATTiny85) 
und C1. Das Ergebnis ist genau das Gleiche.

Könnt Ihr mir da irgendwie weiterhelfen?

cu
The Grue

PS:
- In Sensor.zip ist der Rust code. Compiliert aber aktuell nur mit 
genau dem richtigen nightly build des Compilers 😬
- In Sensor.zip finden sich auch die Pulseview-Quellen zu rw_*.png

PPS: Weil gerne nach der Motivation gefragt wird: Ich wollte mal wieder 
was mit 'nem möglichst kleinen µC machen, weil das letzte Mal schon 20 
Jahre her ist oder so. In Rust, weil ich Rust lernen möchte. Die 
Kombination Rust auf so nem kleinen µC ist schon haarig, macht aber Spaß 
:)

[Veit D. (devil-elec)]

Hallo,

hat die RO Leitung einen definierten High Ruhepegel? Hat der SN75176A 
dafür irgendwas eingebaut? Pullup? R3 würde ich nicht ohne Grund kleiner 
120 Ohm machen.

[Dietrich L. (dietrichl)]

Veit D. schrieb:
> hat die RO Leitung einen definierten High Ruhepegel? Hat der SN75176A
> dafür irgendwas eingebaut? Pullup?

Nach dem TI-Datenblatt ist RO bei /RE=High hochohmig. Daher braucht man 
einen externen Ziehwiderstand, um einen gewünschten Ruhepegel zu 
erhalten.

[Wastl (hartundweichware)]

Markus G. schrieb:
> Schaltplan.png

R5 und R6 kommen wir etwas hoch vor, das reicht evtl. nicht
für die Datenrate die du dir wünschst. Auf Leiterplatten
passen 50 bis 100 Ohm ganz gut. Zudem sollten die Widerstände
immer jeweils am Ausgang positioniert werden, am Eingang
helfen sie nur wenig.

[Markus G. (the_grue)]

Schon mal vielen Dank für die Hinweise zu den Problemen mit RS-485! Die 
werde ich nachher sicher gut brauchen können :)

Aber wie im ersten Post geschrieben:

RS-485 ignorieren wir mal.
[...]
um einen möglichst minimalen Test zu habe, habe 
ich das ganze auch auf dem Breadboard aufgebaut, nur mit U1 (ATTiny85) 
und C1. Das Ergebnis ist genau das Gleiche.

Drum hier auch nochmal der "Breadboard" "Schaltplan".

[Markus G. (the_grue)]

Dietrich L. schrieb:
> Veit D. schrieb:

> Nach dem TI-Datenblatt ist RO bei /RE=High hochohmig. Daher braucht man
> einen externen Ziehwiderstand, um einen gewünschten Ruhepegel zu
> erhalten.

Reicht der interne 20k - 50k pullup des PB0 beim ATTiny85 nicht?

[Georg M. (g_m)]

Markus G. schrieb:
> PPS: Weil gerne nach der Motivation gefragt wird: Ich wollte mal wieder
> was mit 'nem möglichst kleinen µC machen, weil das letzte Mal schon 20
> Jahre her ist oder so.

Der ATtiny85 ist schon 19 Jahre alt. Die neueren tinyAVRs sind besser 
ausgestattet.

[Hmmm (hmmm)]

Markus G. schrieb:
> Was man in rw_high.png ganz gut sieht: das MSB wird
> irgendwie auf HIGH gezogen, bevor es dann ganz kurz doch auf LOW geht.

Schaltest Du den Treiber zu früh ab? Woher stammt Dein Takt?

Und was schon angemerkt wurde: Internen Pullup für RXD aktivieren, sonst 
ist der beim Senden floating, und Du empfängst ggf. beim Senden Müll.

[Bruno V. (bruno_v)]

Der Ruhepegel einer sio ist 1. Das MSB wird zuletzt versendet (danach 
parity und Stopp)

Wenn das MSB immer 1 statt 0 ist, schaltest Du irgendwas zu früh ab.

uC haben in der Regel kein Interrupt wenn das Zeichen fertig ist, 
sondern nur einen, wenn sie intern fertig sind.

[Markus G. (the_grue)]

Vielen Dank schon mal an alle! Mit dem Timing könnte es vielleicht 
tatsächlich ein Problem geben. Auf jeden Fall kann ich in der Richtung 
weitersuchen.
Wenn's was neues gibt, schreib' ich hier weiter.

Schönen Sonntag!

[Peter D. (peda)]

Markus G. schrieb:
> Das ganze noch in Rust, als gute Gelegenheit
> Erfahrung zu sammeln.

Damit können die meisten aber nichts anfangen. Wie kommt man darauf?
Sieht so aus, als wären das alles nur Lib-Aufrufe ohne den eigentlichen 
Code dahinter.

[Maxim B. (max182)]

Georg M. schrieb:
> Der ATtiny85 ist schon 19 Jahre alt. Die neueren tinyAVRs sind besser
> ausgestattet.

Ist es dadurch schlechter? Ich spiele oft eine Orgel, die ca. 160 Jahre 
alt. Eigentlich ein ganz gutes Instrument... Die Werke von heute schon 
338 Jahre alten J.S.Bach klingen schön... Die Werke von 199 Jahre alten 
Anton Bruckner mag ich auch gerne. Und hier so junge Tiny, nur 19 Jahre 
alt...

Was ATtiny85 betrifft: ich bin immer von drei Sachen abgeschreckt (nicht 
von Alter) - zu wenig Füße, kein JTAG und komische USI. Übrigens, es 
gibt Sachen, wo USI gut wäre. Dann lieber so etwas wie ATmega645 oder 
ATmega649 nehmen: USI und USART zusammen und gleichzeitig. Auch JTAG, 
viele Füße und viel mehr SRAM und FLASH als bei ATtiny85.

Sonst, wenn keine andere Gedanken, nehme ich fast immer ATmega1284. Wenn 
ich als Liebhaber nur gelegentlich etwas bastele, ist es vernünftig, mit 
weniger Typen zu hantieren: so lernt man sie besser und so macht man 
folglich weniger Fehler. Preis ist dann zweitrangig, und für die meisten 
Aufgaben ist ATmega1284(P) ausreichend. Es sei denn, man braucht mehr 
als zwei USART und mehr Füße, dann kommt ATmega2560 in Frage, zwar etwas 
schwieriger zu löten, geht aber auch... Diese zwei Typen würde ich für 
alles empfehlen. Für CAN noch AT90CAN128, aber man kann auch ohne, mit 
einem externen CAN-Controller alles machen.
Aber 8-Füßler - wozu?

[Harald K. (kirnbichler)]

Maxim B. schrieb:
> kein JTAG

Dafür aber Debugwire.

[Maxim B. (max182)]

Harald K. schrieb:
> Dafür aber Debugwire.

Verschleiß von Flash ist dadurch inakzeptabel.

[Harald K. (kirnbichler)]

Maxim B. schrieb:
> Verschleiß von Flash ist dadurch inakzeptabel.

Da das nur in der Entwicklungsphase auftritt, das Flash des Tiny85 über 
10000 Lösch/Schreibzyklen aushält, würde ich sagen: Du übertreibst.

Notfalls musst Du halt alle paar Monate einen neun Tiny85 für Dein 
Entwicklungssystem verwenden.

Ist das ein realistisches Szenario? Arbeitest Du monate-, gar jahrelang 
immer mit genau dem selben µC und änderst weder dessen Firmware noch 
lässt dessen Firmware selbst das Flash beschreiben, und bestehst Du dann 
auch noch darauf, diesen "Entwicklungs"-µC weiterhin in der fertigen 
Zielschaltung betreiben zu können?

Ernsthaft?

[Maxim B. (max182)]

Harald K. schrieb:
> Da das nur in der Entwicklungsphase auftritt
Für Liebhaber, zum Unterschied von Profis, gibt es nur die 
Entwicklungsphase.

Na ja, vielleicht kann man auch aus 8-Füßler was vernünftiges machen. 
Etwas ganz einfaches... Aber gerade für Liebhaber ist Debug am 
wichtigsten. Profi kann auch ohne oder mit Minimum von Debug alles 
richtig machen. Deshalb würde ich kleine Tiny lieber für Profi lassen, 
wo es um Serienprodukt geht und wo Kosten minimiert sein sollten. Für 
private Projekte lieber etwas Größeres nehmen, mit 40 Fuß und mehr.

Das merke ich selbst: als Liebhaber habe ich keine Möglichkeit, Tag für 
Tag mit Mikrocontrollern zu hantieren. Wenn wieder nach einigen Monaten 
Bedarf besteht, muß ich vieles wieder erfrischen. Deshalb Fehler, 
Fehlersuche und Programm schrittweise. Bei Debugwire bedeutet aber jeder 
(!) Schritt eine Umprogrammierung von Tiny. 1000 Schritte und keine 
Garantie weiter, Schluß... In SO-8 heißt das Umlöten, dann wird Platine 
vielleicht beschädigt, wieder eine neue Platine (gut daß man in China 
gleich 5 Stück macht), andere IC, R, C, L und alles mögliche löten...

[Harald K. (kirnbichler)]

Maxim B. schrieb:
> 1000 Schritte und keine Garantie weiter, Schluß...

Du liegst um Faktor 10 daneben. Und natürlich wird der µC beim 10001. 
Schritt sofort die Funktion einstellen.

[Maxim B. (max182)]

JTAG ist sowieso praktischer. Außerdem wenn man genug Pins hat, kann man 
die Pins für Programmieren nur dafür lassen, so werden zusätzliche 
Fehler vermieden. Wenn nur 8 Pins und zwei dafür sind Vcc und Gnd, dann 
(für USART) noch zwei Pins für Quarz, eins für RESET. Was bleibt?

[Harald K. (kirnbichler)]

Maxim B. schrieb:
> JTAG ist sowieso praktischer.

Inwiefern?

[Georg M. (g_m)]

Maxim B. schrieb:
> Na ja, vielleicht kann man auch aus 8-Füßler was vernünftiges machen.
> Etwas ganz einfaches... Aber gerade für Liebhaber ist Debug am
> wichtigsten. Profi kann auch ohne oder mit Minimum von Debug alles
> richtig machen. Deshalb würde ich kleine Tiny lieber für Profi lassen,
> wo es um Serienprodukt geht und wo Kosten minimiert sein sollten. Für
> private Projekte lieber etwas Größeres nehmen, mit 40 Fuß und mehr.

Wo ist das Problem? Auch die 8-Pin-Tinys haben ein Debug-Interface.

 
ATtiny412:
 
• Single-cycle I/O access
• Two-level interrupt controller
• Two-cycle hardware multiplier
• Single-Pin Unified Program and Debug Interface (UPDI)
• One 16-bit Timer/Counter type A (TCA) with a dedicated period register and three compare channels
• One 16-bit Timer/Counter type B (TCB) with input capture
• One 12-bit Timer/Counter type D (TCD) optimized for control applications
• One 16-bit Real-Time Counter (RTC) running from an external crystal, external clock, or internal RC oscillator
• One USART with fractional baud rate generator, auto-baud, and start-of-frame detection
• One host/client Serial Peripheral Interface (SPI)
• One Two-Wire Interface (TWI) with dual address match, Philips I²C compatible
• Analog Comparator (AC) with a low propagation delay
• 10-bit 115 ksps Analog-to-Digital Converter (ADC)
• 8-bit Digital-to-Analog Converter (DAC) with one external channel
• Multiple voltage references (VREF)
• Event System (EVSYS) for CPU independent and predictable inter-peripheral signaling
• External interrupt on all general purpose pins
 

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny212-214-412-414-416-DataSheet-DS40002287A.pdf

[Harald K. (kirnbichler)]

Georg M. schrieb:
> Auch die 8-Pin-Tinys haben ein Debug-Interface.

Schrieb ich ja schon. Wurde aber abgelehnt, weil das die Lebensdauer des 
Flash reduziert, und das ist ja unzumutbar. Denn dann hält so ein µC, 
der zur gelegentlichen Entwicklung im Hobbybereich genutzt wird, ja 
vielleicht nicht mehrere Jahre Dauerdebugbetrieb durch.