Sie haben die Platine sorgfältig aufgebaut, aber bei der
Initialisierung des Controllers tritt ein Fehler auf? Dafür können verschiedene
Ursachen in Frage kommen. Der häufigste Fehler ist eine falsche Bestückung oder
ein Lötfehler wie z.B. eine kalte Lötstelle. Auch wenn zuerst alles
funktionierte, später aber nicht mehr, kann eine kalte Lötstelle verantwortlich
sein. Es könnte sich z.B. eine Verbindung an der DB-9-Buchse gelöst haben, die
an Anfang so gerade eben funktionierte. Theoretisch auch möglich ist ein Defekt
im RS232-Kabel oder eine defekte Schnittstelle des PC.
1. Test, Sichtkontroller: Sind die Widerstände vertauscht?
Oben sieht man die beiden mit 100 kΩ, darunter 1 kΩ. Eventuell hilft eine
Messung mit dem Ohmmeter. Oder sind vielleicht die Dioden verdreht eingebaut?
2. Test: Gibt es kalte Lötstellen? Beim Löten muss jede
Lötstelle so heiß werden, dass das Lötzinn in die Durchkontaktierung läuft und
an der anderen Seite sichtbar aufsteigt. Eine nur oberflächlich aufgesetzte
Lötstelle kann sich leicht wieder lösen oder einen Wackelkontakt verursachen.
3. Test: Verbindungen zur Schnittstelle noch ohne den
Controller testen.
Dazu braucht man ein Digitalmultimeter und die Software zum
Lernpaket. Die Messung erfolgt ohne den Controller. Die RS232-Pegel von 10 V
(RS232) oder 6 V (Laptop oder USB/Seriell-Wandler) werden durch die Schutzdioden im Tiny13 im
normalen Betrieb begrenzt.
Starten Sie die Software und öffnen Sie die Registerkarte
Terminal. Nun können Sie einzelne Leitungen einschalten und Leitungszustände mit
der Software lesen.
Messung 1: RTS an, VCC= 5 V kann gemessen werden
Messung 2: DTR an, ca. +10V an PB0 kann gemessen werden
Messung 3: TXD an, ca. +10V an PB2 kann gemessen werden
Messung 4: Brücke von VCC nach PB1, CTS-Kästchen ist an
(Häkchen)
Hinweise:
PB0 und PB2 sind über 100 kΩ angeschlossen, deshalb muss man
mit einem hochohmigen DVM (Ri 10 MΩ)
messen.
Der Eingang CTS am PC ist relativ niederohmig (ca. 3 kΩ) und
wird deshalb über 1 kΩ angesteuert. Damit der PC einen High-Zustand sieht, muss
PB1 niederohmig an VCC gelegt werden. Falls CTS nicht erkannt wird könnten z.B.
die Widerstände vertauscht sein oder eine Unterbrechung vorliegen.
Test auf Kurzschlüsse zwischen Signalleitungen: Schalten Sie
DTR aus: An PB0 muss eine negative Spannung stehen.
Software-Probleme?
Wenn die Hardware in Ordnung ist und trotzdem kein Zugang
zum Controller mehr besteht, kann es an einer faschen Fuses-Einstellung liegen:
Diverse Versuche führten irgendwie dazu, dass der Tiny13 nicht mehr
programmiert werden konnte. Die Fuses wurden vermutlich fälschlich auf eine
geringe Taktrate gestellt, vielleicht durch einen Wackelkontakt oder etwas
ähnliches. Das ISP-Programm aus dem Lernpaket Mikrocontroller brachte die
Lösung. Mit diesem Tool wurden die Fuses auf die Default-Einstellungen gesetzt.
Alles funktioniert jetzt wieder. Die Theorie dazu: Das ISP-Tool programmiert so
langsam, dass die Fuses neu programmiert werden können. Maximal ist ja nur ¼
der aktuellen Taktrate als Programmiertakt erlaubt.
MSR-Software unter Vista/Windows 7
Die Frage kommt öfter auf: Läuft das Lernpaket
Mikrocontroller oder ein anderes Gerät an der RS232 problemlos unter Vista oder
Windows 7? Getestet habe ich schon den Kosmos-Mikrocontroller, einige
Interfaces von Modul-Bus und das Lernpaket Mikrocontroller sowie das neues
Lernpaket „MSR", das einen FT232R als
USB/Seriell-Brücke verwendet.
Alles funktioniert, wenn man eine Kleinigkeit beachtet:
Vista und Windows 7 sind ganz auf Sicherheit getrimmt und verweigert deshalb
zunächst ohne jede Meldung den Zugriff auf eine serielle Schnittstelle. Man
muss ein Programm deshalb erst einmal mit der rechten Maustaste anklicken. Es
erscheint ein Auswahlfenster. Hier aktiviert man „als Administrator
öffnen". Danach funktioniert der serielle Zugriff wie unter den älteren
Systemen.
Siehe auch:
Serielle Schnittstellen unter Windows 7
Lernpaket Mikrocontroller unter Win7, 64 Bit
Probleme mit den Fusebits
Einige Anwender sind auf Probleme bei der Initialisierung
gestoßen oder hatten Probleme, wenn der Chip mit LPmikroISP auf 9,6 MHz
umgestellt wurde. Es gab Situationen, in denen der Tiny13 von keiner Software
mehr angesprochen werden konnte. Normalerweise sollte aber mit LPmikroISP alles
wieder richtig eingestellt werden können, d.h. man stellt den Controller zuerst
wieder zurück auf 1,2 MHz und kann dann neu initialisieren.
In den Fällen, wo dies nicht mehr funktioniert hatte, war
oft eine virtuelle Schnittstelle an einem USB-Seriell-Wandler oder ein Laptop
beteiligt. In beiden Fällen ist die Signalspannung mit ca. 6 V geringer als bei
einer RS232 mit ca. 10 V. Ralf Beesner hat herausgefunden, dass es hilfreich
sein kann, die 100-kΩ-Widerstände auf der Platine gegen 22 kΩ auszutauschen,
wie es auch beim ISP-Adapter zum PingPong gemacht wurde. Die Theorie dazu: Die
zu weiche Ansteuerung über 100 kΩ kann zu einem Verschmieren der Signalflanken
führen, wobei dann einzelne Bits falsch übernommen werden. (Ralf Beesner: Möglicherweise werden die
(Fuse-) Bits bei der Übertragung zu stark verschliffen und es kommt für das
Fusebit SPIEN statt einer 0 eine 1 an.)
Siehe auch: Arduino rettet verfuste ATtinys
Tiny13 stand alone
Frage
Ein auf der LP- Platine programmierter Attiny 13, der in Verbindung zum
Laptop tadellos funktioniert, funktioniert nicht auf einer normalen
Platine / Steckboard. Das Programm ist also definitiv fehlerfrei.
(Spannung ist vorhanden, Reset-Pin nach + über 20 kOhm
und 100 nF nach Masse , alle Verbindungen sind okay). Ich habe
auch auf einen 2. nagelneuen Controller, wie im Buch beschrieben, den
Bootloader installiert und mit meinem Programm "beschrieben". Aber auf
externer Platine läuft nichts. Kann der Bootloader irgendwie
deaktiviert werden? Ich habe das Gefühl, das der µC auf
Signale vom Bootloader wartet.
Lösung: Das Problem ist auch
im Handbuch erwähnt: Der Pin PB2, auf dem der Tiny3 Daten
empfängt, ist hochohmig. Man muss ihn mindestens mit einem
Widerstand an GND legen, sonst kann es passieren, dass der Controller
meint, er soll neu geflasht werden.
Erfolgmeldung: Es klappt. Von 10 kOhm bis zum Kurzschluss funktioniert alles von PB2 bis nach Masse geschaltet.
Software-UART und Kalibrierung, von Karl-Heinz
Schwäbe
Bei
dem Vorhaben, mein MC-Eprom-Programmiergerät aus dem Jahr 1984 (CD4094-Kette an
LPT1, Pascal/Delphi) ins neue Jahrtausend zu führen, kam mir Ihr
LehrPaket-msr-USB wegen des kleineren Aufwandes gegenüber Pollin-Spiel1 (meiner
altern. Entwicklungsplattform) entgegen. Die intensive Beschäftigung mit
"init.asm" (gleich wie im LP Mikrocontroller) führte zu zwei Programm-Modifikationen, die ich Ihnen vorstellen
möchte: Veränderung der Kalibrierung des RC-Oszillators: konvergiert jetzt viel
schneller - und die Portierung der Atmel-AN AVR305 auf init.asm (klein,
sparsam).
Update
der Kalibrierung 22.7.15: Der Algorithmus wurde mit mehreren
ATtiny13(-/A) im Bereich Faktory-OSCCAL = {57 ... 106} mit
unterschiedlichen Anfangswerten geprüft. Während der
Kalibrierungs-Schritte werden die jeweiligen Abweichungen und
aktuelle OSCCAL-Werte ausgegeben. Der letzte Wert ist der akzeptierte
OSCCAL-Wert der Kalibrierung. Wenn die Anfangswerte zu stark
ausreissen, kann man den Tiny mit einem Reset zurückholen (Ihre Routine
OscKorrektur). Die folgende Kalibrierung spielt dann immer einwandfrei.
Manchmal reicht aber statt des Resets auch schon ein zweiter
Kalibrierungslauf (ohne Spannungsunterbrechung!).
;
;Kalibrierung des RC-Oszillators mit 9,6 MHz, DIV8 = 1,2 MHz über den OSCCAL-Wert
;
;PC sendet $00, Tiny misst 9 H-Pegel mit 5 cy-Loops: nom. 25 Loops x 9 Bit = 225 Loops
;vergleich mit nom. Wert: 9 x 104,1666us = 0,9375ms = 225 Loops: 9 x 25 x 5 x 0,8333us
;mod. 2015 07 14 khs
Cal: ;RC-Oszillator gegen RxD, 9 Bit-Zeiten, 9600 Bd abgleichen
in B,osccal ;OSCCAL -> B für Regelung (successive Approximation)
mov EEadr,B ;OSCCAL in EEadr zwischenspeichern, f. korrekte Anzeige unten
subi B,$0A ;B=OSCCAL-10, initialer Versuchswert, ca. -11%!
ldi D,$2D ;max. Abweichung: 45 = $2D, Vorgabewert
ldi Cnt2,$0F ;Loop-Cntr, Initialwert 15, für Not-Abbruch!
C1:
out osccal,B ;OSCCAL aus B setzen, akt. Versuchswert f. Messung
inc D ;(Max+1)-Wert, da Tiny nichtlinear bzw. Messfehler auftreten
rcall RdRXD ;RxD: H->L; Dauer messen: 9 Bits a 25*5cy = 225 cy
subi A,$E1 ;225 = $E1: Regelschwelle
neg A ;kleinerer OSCCAL-Wert ergibt negative Abweichung
cp D,A ;Vergleiche Abweichung A gegen (Max+1)-Wert in D
brsh C3 ;A =< D; A > D: Schleifen-Ende wenn Abweichung ansteigt
C2:
ldi Cnt2,1 ;1 -> 0: Schleifen-Ende; 224->> 225 <<-226!
neg A ;- x - = +! (minus mal minux gibt plus)
dec D ;für korrekten Vergleich mit D (Max+1) - 1
cp A,D ;Regel-Abweichung vergleichen
brsh C4 ;akt. OSCCAL ist schlechter (Abw.n+1 >= Abw.n)
C3:
mov C,B ;akt. OSCCAL in C sichern
C4:
mov D,A ;Abweichung in D sichern
out osccal,EEadr ;OSCCAL setzen für korrekte Anzeige/Ausgabe
rcall WrCOM ;Abweichung aus A ser. ausgeben
mov A,B ;akt. OSCCAL -> A
rcall WrCOM ;akt. OSCCAL ser. ausgeben
mov A,D ;Neuen OSCCAL aus Abweichung bestimmen:
lsr A ;div 2
lsr A ;div 2: div 4 (ohne Rest)
brne C5 ;wenn A > 0, sonst...
inc A ;A=0: 0 konvertiert nicht, daher +1!
C5: add B,A ;Verbesserung des Versuchswertes OSCCAL
dec Cnt2 ;15, 14, ... 0 oder Abbruch
brne C1 ;Schleifen-Ende bei Cnt2=0
;
mov A,C ;Bester OSCCAL-Wert der Regel-Schleifen
out osccal,A ;OSCCAL setzen
ldi EEadr,$3F ;EE-Adr für Speichern des OSCCAL-Wertes
rcall WrEE ;EE($3F) setzen (A bleibt erhalten)
rcall WrCOM ;A ser. ausgeben: Bester OSCCAL-Wert
ret
;
RdRXD: ;ImpulsDauer messen: RxD=1 bis RxD=0: _|........|_._
sbis PINB,RXD ;RxD testen; $00, 9,6 kBaud, 25 Loops/Bit, 9 Bits = 225 cy
rjmp RdRXD ;RxD=0, auf Startbit RxD=1 warten
ldi A,0 ;RxD=1, Zaehler-Anfangswert=0
RXD1: inc A ;A=A+1, H->L auszaehlen ;1cy
nop ;dt ;1cy (25,50,75,100,125,150,175,200,225)
sbic PINB,RXD ;RxD testen ;1cy (w/o skip)
rjmp RXD1 ;RxD=1 ;2cy ; total 5 Takte
ret ;RxD=0, all done
;
;---
;
;
; Software-UART von AVR305 auf LPmsrUSB init.asm portiert, 2015 04 28 khs
;---
; RS232-Invertierung: Stoppbit (Ruhe): -5V := TTL=0, log. Wert=1
; spielt! Startbit: +5V := TTL=1, log. Wert=0
;
; ;Byte ser. Empfangen, st,8b,1sp
RdCOM: sbis pinb,RXD ;2cy, Test RxD wg Stt-Bit
rjmp RdCOM ;RxD=-5V (RS232-Invertierung)
; ;RxD=+5V Stt-Bit: +5V, TTL=1,log 0
ldi Cntr,9 ;1cy, st,8b,1sp
ldi Delay,20 ;1cy ;125+62=187
rcall WDL2 ;3cy ;113+12+20*3-1+4=185; ~1,5 Bit
;
RL: rcall WDL1 ;3cy ;125-12=113: 36*3-1+6=113 ;
nop ;1cy ;timing
sec ;1cy
sbic pinb,RXD ;___---
clc ;1cy+1cy
dec Cntr ;1cy
breq WEX ;1cy, go home (bei WrCOM)
ror A ;1cy
rjmp RL ;2cy, LOOP
;
;
; RS232-Invertierung: Stoppbit (Ruhe): -5V := TTL=0, log. Wert=1
; spielt! Startbit: +5V := TTL=1, log. Wert=0
;
WrCOM: ldi Cntr,10 ;1cy, Byte ser. Senden, st,8b,1 1/2sp
com A ;1cy, A=/A, C=1, wg RS232-Inv. Stt/Stp-Bit, s.u.
WxL: brcs Wx1 ;2/1cy, teste C
cbi PORTB,TXD ;2cy--- C=0: TxD=0 (RS232-Inv.: Stp-Bit=-5V (1))
rjmp WxC ;2cy
; system. Flanken-Jitter (0,8us/104us)
Wx1: sbi portb,TXD ;2cy--- C=1: TxD=1 (RS232-Inv.: Stt-Bit=+5V (0))
nop ;1cy, wait
WxC: rcall WDL1 ;3cy ;125-12=113: 36*3-1+6=113
lsr A ;1cy, A,b0->C, nächstes Bit zur Ausgabe
dec Cntr ;1cy, Zähler verkleinern
brne WxL ;2/1cy_ LOOP
;
WDL1: ldi Delay,36 ;1cy, Delay for 9600 Bd Bit soll: (104,16 us := 125 cy)
nop ;1cy ;timing, Time-DL1: 36*3-1+6=113
WDL2: dec Delay ;1cy
brne WDL2 ;2/1cy: 3cy/Loop Time-DL2: n*3cy-1cy+4cy
WEX: ret ;4cy
;
;----
;