Hallo,
ich möchte mit dem Attiny13 eine Drehzahlmessung realisieren und habe
dazu die unten angehängte Schaltung aufgebaut.
Den Ausgang des Attiny13 (PB1) und GND habe ich nicht wie im Schaltplan
angegeben an eine serielle Schnittstelle, sondern an einem FT232R
angeschlossen, welcher über USB an den PC geht (aus dem Franzis
Lernpaket MSR mit dem PC).
Am PC läuft ein Programm, welches die vom Attiny13 über RxD ausgegebenen
Bytes in die Frequenz / UPM umrechnet und anzeigt.
Das Projekt ist hier genauer beschrieben:
http://www.elo-web.de/elo/mikrocontroller-und-programmierung/avr-anwendungen/drehzahlmessung-mit-tiny13
Leider funktioniert der Aufbau bei mir nicht. Die Schaltung habe ich mit
Sicherheit richtig aufgebaut, bei Abdeckung des Optokopplers reagiert
die Kontroll-LED entsprechend und auch der Signalpegel an PB4 des
Attiny13.
Ist die Verbindung zum FT232R so wie beschrieben okay ?
Wie kann ich am Attiny13 prüfen, ob er überhaupt Bytes ausgibt ?
Unten steht der Maschinencode, den ich in den Attiny13 geladen habe.
Grüße,
Ralf
Mit welcher Tackfrequenz läuft dein ATtiny?
4.8 oder 9.6MHz.
Nach ein einigen rumgerechne von mir, sollte er mit 4.8MHz laufen, um
angenähert 38400 Bd an der emulierten serielen Schnittstelle auszugeben.
Hallo Detlef,
laut der Dokumentation von meinem Franzis Lernpaket heißt es "Das
Lernpaket arbeitet mit dem 9,6 MHz Oszillator und dem Vorteiler durch 8,
sodass der Prozessortakt 1,2 MHz beträgt." Gleichzeitig wird gesagt,
dass mit einer definierten Übertragungsrate von 9600 Baud gearbeitet
wird und mit einer RC-Oszillator Kalibrierung eine Genauigkeit von ca.
1% erreicht wird.
Wenn Du bei 4,8 MHz ca. 38400 Baud errechnet hast, müsste entsprechend
bei 1,2 MHz ja 9600 Baud passen.
In dem VB - Programm für den PC habe ich folgenden Befehl gefunden:
OPENCOM("COM2:9600,N,8,1:"). Dann würden die 9600 Baud ja mit dem Attiny
übereinstimmen. Dieses Programm ist jedoch für den Betrieb an einer
"echten" seriellen Schnittstelle geschrieben worden. Kann der FT232
nicht eine 9600 Baud Schnittstelle emulieren oder muss die
Geschwindigkeit 38400 Baud betragen ?
Grüße,
Ralf
Ist die Sub-D Buchse so zum Anschluss an den PC gedacht, ohne
Pegelwandler dazwischen?
Wie betreibst Du den FT232? Sind dort Pegelwandler dran? Ich kenne das
Franzis-Paket nicht.
Sollten dort keine dran sein, könnte das schon das Problem sein:
Die U(S)ART am µC oder am FT232 sind neben den unterschiedlichen Pegeln
auch noch invertiert zu dem, was auf RS232 Schnittstellen passiert.
Sollte es das sein, kommst Du mit einem Inverter weiter. Hierfür reicht
u.U. schon ein Transistor mit zwei Widerständen.
Oder Du modifizierst die SW im Tiny ...
Ach: Der FT232 stellt für den PC eine ganz normale RS232-Schnittstelle
dar und kann alle Funktionen und Baudraten, die eine eingebaute
Schnittstelle auch kann. Und die Anwendungssoftware merkt da keinen
Unterschied.
Gruß
Jobst
Hallo Jobst,
in der Projektbeschreibung (die ja mit dem Lernpaket Mikrocontroller
arbeitet - Anschluss über serielle Schnittstelle) wird ein direkter
Anschluss ohne Pegelwandler beschrieben, dort heisst es: "Die grüne
Leitung ist wie auf der Platine des Lernpakets Mikrocontroller [1] über
einen Widerstand von 1 k mit dem Anschluss RxD und eine blaue Leitung
mit dem Anschluss GND einer 9-poligen SUB-D-Buchse verbunden. Über sie
findet die Kommunikation mit dem PC statt."
Bei meinem Franzis - Paket ist auf der Platine lediglich ein FT232R
nebst 2 Kondensatoren und einem Widerstand enthalten, also keine
Pegelwandler. In der Anleitung wird auch beschrieben, dass der FT232R
invertiert. Bei dem Lernpaket ist jedoch eine Software dabei (MProg),
mit der ich per Programmierung eine (weitere) Invertierung der RS232
Signale und weitere I/O Einstellungen des CBus vornehmen kann. Eine
weitere Invertierung aller Leitungen ist bereits eingestellt, so dass im
Ergebnis nicht invertierte Leitungen vorliegen.
Ich habe mal mit dem Oszillographen das Ausgangssignal des Attiny13 an
PB1 gemessen, dort müsste doch irgendwie ein digitales Rechtecksignal zu
messen sein, war aber nicht der Fall. Wie müsste die dortige AUsgabe der
Bytes am Oszi aussehen ?
Grüße,
Ralf
Hi
>In der Anleitung wird auch beschrieben, dass der FT232R>invertiert.
Der invertiert nichts. Den FT232R kann man direkt an die UART eines µC
anschließen.
Allerdings gibt deine WrCOM-Routine ein invertiertes Signal aus, mit dem
der FT232 nichts anfangen kann.
MfG Spess
@Spess: Wenn also der Attiny13 ein invertiertes Signal ausgibt und ich
in der FT232R STeuersoftware eine Invertierung der Signale einstelle,
stimmt es dann im Ergebnis ?
Oder anders gefragt: Muss ich bei der FT232R - Software jetzt eine
Invertierung einstellen, damit der Attiny13 und der FT232R sich
"verstehen" ?
Grüße,
Ralf
Hi
>Oder anders gefragt: Muss ich bei der FT232R - Software jetzt eine>Invertierung einstellen, damit der Attiny13 und der FT232R sich>"verstehen" ?
Sollte gehen. Allerdings verstehe ich absolut nicht, warum hier eine
Software-UART verwendet wird die inkompatibel zu sämtlichen
Hardware-UARTs ist.
MfG Spess
Ralf R. schrieb:> Muss ich bei der FT232R - Software jetzt eine> Invertierung einstellen, damit der Attiny13 und der FT232R sich> "verstehen" ?
Moment. Was passiert denn da? Wird der FT232 in dieser Anwendung im
UART-Modus oder im Bitbang-Modus betrieben?
Im UART-Modus kannst Du das, soweit mir bekannt, nicht umdrehen.
Und hier den Bitbang-Modus zu nutzen, finde ich recht exotisch ...
spess53 schrieb:> Allerdings verstehe ich absolut nicht, warum hier eine> Software-UART verwendet wird die inkompatibel zu sämtlichen> Hardware-UARTs ist.
Nein, man möchte sich den Pegelkonverter sparen. Ist 'ne Pfuschlösung.
Gruß
Jobst
Hi
>Im UART-Modus kannst Du das, soweit mir bekannt, nicht umdrehen.>Und hier den Bitbang-Modus zu nutzen, finde ich recht exotisch ...
Ich lese das anders (Datenblatt):
Additionally, the UART signals can each be individually inverted and
have a configurable high drive strength capability. Both these features
are configurable in the EEPROM.
MfG Spess
Hallo,
ich habe mal oben einen Screenshot des MProg - PRGs angefügt.
Im Gegensatz zu dem Bild sind bei mir rechts oben alle Häkchen für die
Invertierung gesetzt.
Ob der FT232 in dieser Anwendung im UART-Modus oder im Bitbang-Modus
betrieben wird, dazu finde ich in der Anleitung nichts.
Aber vielleicht ergibt sich das aus den CBus - Einstellungen rechts
unten.
Im Gegensatz zu dem angefügten Bild sind bei mir statt "I/O" für C0-C3
folgende Optionen eingestellt:
C0: TXLED#
C1: RXLED#
C2: TXDEN
C3: PWRON#
C4: SLEEP# (wie im Bild)
Könnte das Problem hier darin liegen, dass die "Pfuschlösung" zur
Einsparung der Pegelkonverter verwendet wurde ?
Einen Transistor zur Pegelanpassung zu verwenden wäre für mich kein
Problem.
Wie müsste ich den schalten und was für Einstellungen wären dann für den
FT232R notwendig ?
Grüße,
Ralf
Hi
>Im Gegensatz zu dem angefügten Bild sind bei mir statt "I/O" für C0-C3>folgende Optionen eingestellt:>C0: TXLED#>C1: RXLED#>C2: TXDEN>C3: PWRON#>C4: SLEEP# (wie im Bild)
Das sind die Default-Werte, mit denen ein FT232R ausgeliefert wird. Bei
einem 'Bit Bang' Mode sähe das eher wie in deinem Bild aus.
MfG Spess
Okay dann fasse ich mal zusammen, dass mein FT232R im UART-Modus läuft,
und die Invertierung so eingestellt ist, dass eine Kommunikation möglich
ist.
Vielleicht läuft das Maschinenspracheprogramm ja aus irgendwelchen
Gründen im Attiny13 nicht. Ich habe das Programm allerdings schon in 2
Attinys geflashed, zuvor habe ich simple LED-Blink-Programme aus dem
Lernpaket in den Attiny geladen, das hat funktioniert.
Dann habe ich auf dem PC ein Simpel - Terminal - Programm aus dem
Lernpaket gestartet, bei dem am FT232R einfach eine Brücke von TXD zu
RXD gelegt wird. Man gibt dann Zahlen oder Zeichen in dem Sendefenster
ein, welche dann im Empfangsfenster erscheinen. Auch das funktioniert.
Wenn ich aber die in meinem ersten Beitrag gezeigte Schaltung über RXD
(nebst VCC und GND) an die FT232R - Platine hänge, zeigt das
Terminalprogramm keine Empfangenen Bytes an. Bei korrekter Funktion des
PRGs im Attiny müssten doch die jede Sekunde gesendeten Bytes im
Empfangsfenster angezeigt werden, oder ?
Grüße,
Ralf
Hi
>Bei korrekter Funktion des>PRGs im Attiny müssten doch die jede Sekunde gesendeten Bytes im>Empfangsfenster angezeigt werden, oder ?
Ja. Aber du hast geschrieben:
>Ich habe mal mit dem Oszillographen das Ausgangssignal des Attiny13 an>PB1 gemessen, dort müsste doch irgendwie ein digitales Rechtecksignal zu>messen sein, war aber nicht der Fall.
Wenn da nichts rauskommt kann der PC auch nichts empfangen.
Bist du sicher, das das richtige Programm auf dem ATTiny ist?
MfG Spess
Ralf R. schrieb:> Leider funktioniert der Aufbau bei mir nicht.
Dann gehe schrittweise vor.
Schreib erstmal ein Programm, was nur einen Buchstaben ausgibt.
Dann einen Text, dann eine Zahl, dann den Zählwert usw.
Ich habe gerade nochmals mit dem Oszi gemessen, am Ausgang sind alle 0,4
uS Nadelimpulse mit einer Amplitude von ca. 5 mV sichtbar, also kein
vernünftiges Signal.
Ich glaube schon, dass ich das richtige Programm in die CPU geladen
habe.
Mir ist aber von der Prorgammierung des ATMega in Erinnerung, dass man
bei der Programmierung (mit Ponyprog) irgendwelche Bits und Fuses setzen
musste. Das wird von dem Programm beim Lernpaket automatisch gemacht,
dort kann ich nichts einstellen. Vielleicht sind diese automatisch
gemachten Einstellungen für das Programm Frequenzmessung ja nicht
geeignet ? Aber welche Einstellungen müsste ich bei einem anderen
Programm machen, damit das Programm läuft ?
Grüße,
Ralf
Ich habe jetzt einen anderen Verdacht, woran es liegen könnte.
Der Attiny13 ist bei der Initialisierung mit einem Bootloader
beschrieben worden, der eine Selbstprogrammierung der CPU ermöglicht.
Der Bootloader steht im oberen Bereich ab $0180 ($0300 im Hex-Editor).
Jedes Programm springt an der Adresse $0000 erst zum Bootloader nach
$0180 ($0300). Soll kein neues Programm geladen werden, springt der
Bootloader nach $017E ($02FC). Dort steht ein Sprung zum Programmanfang
bei $0010 ($0020).
Ab $0000 stehen die Bytes 3a 30 32 30, was wohl rjmp $0180 entspricht,
sowohl beim LED-Blinkprogramm (was ja funktioniert hat) als auch beim
Frequenzmessungsprogramm.
Der Bootloader springt also dann an die Adresse $0010 (im Hex-Editor
$0020), wo das eigentliche Programm starten soll. Es lässt sich bei dem
LED-Blinkprogramm im HEX-Editor auch erahnen, dass bei $0020 der
Programmcode losgeht:
0000 :020000020000FC.
0010 .:1000000000C008
0020 E107BB08E008BB04
....
Bei dem Frequenzmessprogramm zeigt der Hex-Editor folgendes:
0000 :020000020000FC.
0010 .:0200000003C03B
0020 ..:1000060022C0B
0030 99ABB9A03E003BF0
.....
Dort sieht es so aus, als ob der Programmcode erst bei $0030 losgeht.
Wenn der Bootloader hier also nach $0020 springt und dort nichts
sinnvolles steht, vielleicht läuft das Programm deshalb nicht.
Das Programm stammt zwar von der CD des Lernpakets, ist aber in der
Anleitung nicht dokumentiert.
Gibt es eigentlich für den Maschinencode des Attiny13 einen
Disassembler, mit dem der Code dann ab einer vorgegebenen Adresse
angezeigt werden kann ?
Grüße,
Ralf
Hi
>Gibt es eigentlich für den Maschinencode des Attiny13 einen>Disassembler, mit dem der Code dann ab einer vorgegebenen Adresse>angezeigt werden kann ?
Womit programmierst du? Mit dem 4er AVR Studio geht das einfach mit File
open-> Hexfile.
MfG Spess
Eigentlich habe ich bisher gar nicht programmiert (außer vor knapp 30
Jahren den 6510 des C64), sondern wollte nur diesen Drehzahlmesser nach
Anleitung aufbauen .....
Auf das AVR - Studio bin ich gerade auch gestoßen und habe mir Version
4.18 installiert. Das HEX-File des Frequenzmesser-PRGs konnte dort wie
folgt disassembliert werden:
1
+00000000: C003 RJMP PC+0x0004 Relative jump
2
+00000001: FFFF ??? Data or unknown opcode
3
+00000002: FFFF ??? Data or unknown opcode
4
+00000003: C022 RJMP PC+0x0023 Relative jump
5
+00000004: 9AB9 SBI 0x17,1 Set bit in I/O register
6
+00000005: 9ABB SBI 0x17,3 Set bit in I/O register
7
+00000006: E003 LDI R16,0x03 Load immediate
8
+00000007: BF03 OUT 0x33,R16 Out to I/O location
9
+00000008: E002 LDI R16,0x02 Load immediate
10
+00000009: BF09 OUT 0x39,R16 Out to I/O location
11
+0000000A: 2722 CLR R18 Clear Register
12
+0000000B: 2733 CLR R19 Clear Register
13
+0000000C: 2755 CLR R21 Clear Register
14
+0000000D: 2766 CLR R22 Clear Register
15
+0000000E: 9478 SEI Global Interrupt Enable
16
+0000000F: 99B4 SBIC 0x16,4 Skip if bit in I/Oreg.cl.
17
+00000010: C004 RJMP PC+0x0005 Relative jump
18
+00000011: 9AC3 SBI 0x18,3 Set bit in I/O register
19
+00000012: 3031 CPI R19,0x01 Compare with immediate
20
+00000013: F450 BRCC PC+0x0B Branch if carry cleared
21
+00000014: CFFA RJMP PC-0x0005 Relative jump
22
+00000015: 9BB4 SBIS 0x16,4 Skip if bit in I/Oreg.set
23
+00000016: C004 RJMP PC+0x0005 Relative jump
24
+00000017: 98C3 CBI 0x18,3 Clear bit in I/O register
25
+00000018: 3031 CPI R19,0x01 Compare with immediate
26
+00000019: F420 BRCC PC+0x05 Branch if carry cleared
27
+0000001A: CFFA RJMP PC-0x0005 Relative jump
28
+0000001B: 9553 INC R21 Increment
29
+0000001C: F409 BRNE PC+0x02 Branch if not equal
30
+0000001D: 9563 INC R22 Increment
31
+0000001E: 3031 CPI R19,0x01 Compare with immediate
+0000002A: 342B CPI R18,0x4B Compare with immediate
44
+0000002B: F010 BRCS PC+0x03 Branch if carry set
45
+0000002C: 2722 CLR R18 Clear Register
46
+0000002D: 9533 INC R19 Increment
47
+0000002E: BF4F OUT 0x3F,R20 Out to I/O location
48
+0000002F: 9518 RETI Interrupt return
49
+00000030: 9BB2 SBIS 0x16,2 Skip if bit in I/Oreg.set
50
+00000031: CFFE RJMP PC-0x0001 Relative jump
51
+00000032: E37A LDI R23,0x3A Load immediate
52
+00000033: 957A DEC R23 Decrement
53
+00000034: F7F1 BRNE PC-0x01 Branch if not equal
54
+00000035: E000 LDI R16,0x00 Load immediate
55
+00000036: E088 LDI R24,0x08 Load immediate
56
+00000037: 9506 LSR R16 Logical shift right
57
+00000038: 99B2 SBIC 0x16,2 Skip if bit in I/Oreg.cl.
58
+00000039: 6800 ORI R16,0x80 Logical OR with immediate
59
+0000003A: E276 LDI R23,0x26 Load immediate
60
+0000003B: 957A DEC R23 Decrement
61
+0000003C: F7F1 BRNE PC-0x01 Branch if not equal
62
+0000003D: 958A DEC R24 Decrement
63
+0000003E: F7C1 BRNE PC-0x07 Branch if not equal
64
+0000003F: E276 LDI R23,0x26 Load immediate
65
+00000040: 957A DEC R23 Decrement
66
+00000041: F7F1 BRNE PC-0x01 Branch if not equal
67
+00000042: 9500 LAT R16 Load and Toggle
68
+00000043: 9508 RET Subroutine return
69
+00000044: 9AC1 SBI 0x18,1 Set bit in I/O register
70
+00000045: E276 LDI R23,0x26 Load immediate
71
+00000046: 957A DEC R23 Decrement
72
+00000047: F7F1 BRNE PC-0x01 Branch if not equal
73
+00000048: E088 LDI R24,0x08 Load immediate
74
+00000049: FD00 SBRC R16,0 Skip if bit in reg. cl.
75
+0000004A: C003 RJMP PC+0x0004 Relative jump
76
+0000004B: C000 RJMP PC+0x0001 Relative jump
77
+0000004C: 9AC1 SBI 0x18,1 Set bit in I/O register
78
+0000004D: C002 RJMP PC+0x0003 Relative jump
79
+0000004E: 98C1 CBI 0x18,1 Clear bit in I/O register
80
+0000004F: C000 RJMP PC+0x0001 Relative jump
81
+00000050: E276 LDI R23,0x26 Load immediate
82
+00000051: 957A DEC R23 Decrement
83
+00000052: F7F1 BRNE PC-0x01 Branch if not equal
84
+00000053: 9506 LSR R16 Logical shift right
85
+00000054: 958A DEC R24 Decrement
86
+00000055: F799 BRNE PC-0x0C Branch if not equal
87
+00000056: 98C1 CBI 0x18,1 Clear bit in I/O register
88
+00000057: E276 LDI R23,0x26 Load immediate
89
+00000058: 957A DEC R23 Decrement
90
+00000059: F7F1 BRNE PC-0x01 Branch if not equal
91
+0000005A: 9508 RET Subroutine return
Wenn ich das Programm im AVR-Simulator starte, hängt sich das AVR-Studio
auf, die CPU-AUslastung geht im Task Manager über 50% und lässt sich nur
noch mit Task beenden stoppen.
Wenn ich mir den generierten Sourcecode anschaue, scheint kein Sprung in
den Bootloader zu erfolgen, wie es im Handbuch des Lernpakets
beschrieben ist. Insbesondere der Relative Jump am Anfang erscheint
merkwürdig, warum liegen dahinter 4 Bytes mit dem "unknown opcode" $FF ?
Bezieht sich der Sprung "PC+0x0004" auf + 4 Bytes oder auf + 4
Datenworte (jew. 2 Bytes) auf Zeile / Adresse +00000004: SBI 0x17,1 ?
Grüße,
Ralf
Hi
>Insbesondere der Relative Jump am Anfang erscheint>merkwürdig, warum liegen dahinter 4 Bytes mit dem "unknown opcode" $FF ?
Das entspricht:
> rjmp Anfang> .org 0x0003> rjmp TIM0_OVF ;Timer0 Overflow>Anfang:> sbi ddrb,TXD
Durch das .org gibt es für zwei Word (4 Byte) keinen Programmcode. Der
gelöschte Flash enthält 0xFFs, aber für den Opcode 0xFFFF gibt es keinen
gültigen Assemblerbefehl.
>Bezieht sich der Sprung "PC+0x0004" auf + 4 Bytes oder auf + 4>Datenworte (jew. 2 Bytes) auf Zeile / Adresse +00000004: SBI 0x17,1 ?
Letzteres. Bei AVRs ist die Befehlslänge ein Vielfaches von einem Word.
Wie kommt eigentlich der Bootloader in den ATTiny? Der besitzt keinen
geschützten Bootloaderbereich, so daß der Bootloader überschrieben oder
gelöscht werden kann.
MfG Spess
Hi,
der Bootloader wird mit der "Initialisierung" der Lernpaket-Software in
den Attiny ab $0180 programmiert. Davor wird ein Interface-Programm
geladen, welches ein Terminalprogramm, Interface, Simpel-Oszilloskop und
ein Upload-Programm enthält. Insgesamt werden damit die 1 KByte des
Attiny13 voll ausgefüllt. Mit der upload - Funktion können dann andere
Programme (bis max. ca. 750 Byte, sonst wird der Bootloader
überschrieben) hochgeladen werden, wodurch das Interface-Programmpaket
dann überschrieben wird.
Jetzt habe ich in der Anleitung gelesen, dass bei jedem upload vor das
hochzuladende Programm automatisch der Sprungbefehl in den Bootloader
eingefügt wird. Somit wurde auch bei dem Frequenzmessungs - PRG dieser
Sprungbefehl vorne angefügt - soweit so gut.
Der Bootloader springt dann, nachdem er festgestellt hat, dass kein
Programm geladen werden soll, an die Adresse $0010. Und ich glaube da
liegt das Problem: Auf die Adresse $0010 (entspricht im o.a.
disassemblierten PRG der Adresse $000F, weil ja vorne noch der
Sprungbefehl in den Bootloader hinzukommt) springt der Bootloader mitten
in das Programm, ohne dass vorher Bits gesetzt, Register gelöscht,
Interrupt enabled werden kann.
Bei dem Blink-LED Programm, welches ja funktioniert hat, dürfte der
Sprung mitten in das Programm keine Probleme verursachen, da es sich
lediglich um simple Schleifen handelt.
Müsste ich bei dem Frequenzmessungsprogramm also irgendwie 14
"Leerworte" voranstellen, damit an der Adresse $0010 dann der Befehl
RJMP PC+0x0004 steht ?
Grüße,
Ralf
Hi
>Jetzt habe ich in der Anleitung gelesen, dass bei jedem upload vor das>hochzuladende Programm automatisch der Sprungbefehl in den Bootloader>eingefügt wird.
Eher wird der Reset-Vektor durch einen Sprung zum Bootloader ersetzt.
>Der Bootloader springt dann, nachdem er festgestellt hat, dass kein>Programm geladen werden soll, an die Adresse $0010.
Bist du sicher, das es 0x0010 und nicht 10 (Dezimal) ist? 10D oder
0x000A wäre nämlich die erste Adresse nach der Interruptvektor-Tabelle.
>Müsste ich bei dem Frequenzmessungsprogramm also irgendwie 14>"Leerworte" voranstellen, damit an der Adresse $0010 dann der Befehl>RJMP PC+0x0004 steht ?
Nein. Du musst nur deinen Programmanfang auf 0x0010 oder 0x000A setzen:
Üblicher Weise arbeitet ein Botloader so:
Er erwartet, daß an der Adresse 0x0000 ein Sprungebefehl steht. Diesen
schreibt er dann hinter das Programm und ersetzt ihn durch einen Sprung
zu sich selber.
Dein Programm muß sich also um nichts kümmern, für Dich existiert der
Bootloader quasi nicht.
Hallo,
hier mal Auszüge aus dem Initialisierungsprogramm, welches den Speicher
des Attiny13 mit dem Interface - Programm und im oberen viertel mit dem
Bootloader vollständig füllt:
;RS232, Empfangen und Senden mit 9600 Baud bei 1,2 MHz
12
13
.def A = r16
14
.def Delay = r17
15
.def Count = r18
16
.def Kom = r19
17
.def B = r20
18
.def C = r21
19
.def D = r22
20
.def Count2 = r23
21
.def EEadr = r24
22
.def EEmode = r25
23
24
;Port B
25
.equ TXD = 1
26
.equ RXD = 2
27
.equ PWM = 0
28
29
.org $0000
30
rjmp $0180
31
32
.org $0010
33
34
Anfang:
35
...
Danach erfolgt bei $0000 der Sprung in den Bootloader und bei $0010
beginnt das Programm.
Hier noch ein Auszug aus dem Bootloader, bei dem der Sprung zurück nach
$0010 erfolgt:
1
....
2
.org $017E
3
rjmp $0010
4
5
6
.org $0180
7
8
.def spmcsrval =r28
9
10
RESETboot:
11
cli
12
rcall OscKorrektur
13
....
Ich glaube, dass bei dem upload - Vorgang nicht nur automatisch der
Sprung in den Bootloader (rjmp $0180) vorhangestellt wird sondern auch
der Programmstart auf $0010 gesetzt wird (.org 0x0010). Diese Befehle
habe ich bei keinem der Beispielprogramme des Lernpakets gefunden, außer
bei dem Initialisierungsprogramm, mit dem der Bootloader erstmals auf
den Attiny13 gebracht wird.
Wenn somit der Programmstart des PRG "Frequenzmessung" ordnungsgemäß
erfolgt, stellt sich wieder die Frage, warum keine Bytes ausgegeben
werden. Ich kenne mich mit dem Lesen und Interpretieren von
Maschinencode nicht aus, deshalb nochmal die Frage: Liest das oben im
ersten Beitrag angezeigte Maschinenprogramm denn tatsächlich die
Frequenz an PB4 ein und gibt diese an PB1 im Sekundetakt in Form von 2
Bytes aus ?
Grüße,
Ralf
Hi
>Ich glaube, dass bei dem upload - Vorgang nicht nur automatisch der>Sprung in den Bootloader (rjmp $0180) vorhangestellt wird sondern auch>der Programmstart auf $0010 gesetzt wird (.org 0x0010).
Glaube ich nicht. Der Bootloader erwartet einfach den Programmstart auf
0x0010. Ein Assemlerprogramm kann an einer beliebigen Stelle im Speicher
starten. Entscheident dafür ist, was im Resetvektor an Adresse 0x0000
steht.
> Liest das oben im>ersten Beitrag angezeigte Maschinenprogramm denn tatsächlich die>Frequenz an PB4 ein ...
Prinzipielle Fehler Fehler habe ich nicht gefunden. Einiges geht
einfacher.
>und gibt diese an PB1 im Sekundetakt in Form von 2 Bytes aus ?
Mit dem Sekundentakt habe ich meine Zweifel. Der Overflow-Interrupt wird
etwa alle 1,7ms ausgelöst. Wie du da mit den 75 auf eine Sekunde kommst
ist mir schleierhaft.
MfG Spess
Hi,
jetzt habe ich einen Teilerfolg erzielt. Ich habe den Attiny13 nochmals
neu initialisiert und direkt anschließend das PRG Frequenzmessung
hochgeladen.
Für die Programmierung habe ich die o.a. Schaltung des Lernpakets
verwendet.
Dann habe ich das Simpel - Terminalprogramm angeklickt und siehe da,
etwas schneller als im Sekundentakt werden jew. 2 Bytes empfangen.
Starte ich das VB-Programm zur Drehzahlanzeige am PC, werden Werte
empfangen und angezeigt.
Wenn ich den erfolgreich programmierten Attiny13 jetzt auf die Platine
für die Drehzahlmessung setze und die Leitungen RXD, VCC und GND mit der
FT232R-Platine verbinde, passiert wieder nichts.
Muss ich evtl. weitere Leitungen verbinden (z.B. Resetleitung RTS),
damit das Programm im Attiny13 startet ?
Grüße,
Ralf
Hallo,
sobald der ATtiny13 des Lernpaketes mit der Lernpaket-Software
programmiert wurde, nun aber extern betrieben werden soll, d.h. nicht in
der Platine des Lernpakets, dann muss PB2 auf GND gelegt werden.
Wenn PB2 in der Luft hängt kann es vorkommen, dass sich der bootloader
angesprochen fühlt und meint, er müsse nun eine neue Software empfangen.
Das oben Beschriebene muss aber auch irgendwo im Handbuch des
Lernpaketes stehen.
Viel Erfolg
gatsby
Hallo Gatsby,
das war der entscheidende Hinweis ! PB2 auf Masse gelegt und das Ding
läuft!
In meinem Lernpaket (MSR - Elektronikstart mit USB) steht davon nichts,
das wird wahrscheinlich in dem originären Lernpaket Mikrokontroller
stehen, was ich mir auch noch besorgen werde.
Danke nochmals allen für die tatkräftige Hilfe.
Grüße,
Ralf
Hi
>In meinem Lernpaket (MSR - Elektronikstart mit USB) steht davon nichts,>das wird wahrscheinlich in dem originären Lernpaket Mikrokontroller>stehen, was ich mir auch noch besorgen werde.
Das Geld kannst du wesentlich besser als in diesen maßlos überteuerten
Paketen anlegen.
MfG Spess
Thread beobachten
Seitenaufteilung abschalten