Es handelt sich hier um den Assemblercode eines umprogrammierten
Fahrtreglers für ein Modell. Die Empfänger Signale werden ausgelesen und
per PWM die entsprechenden FETs angesteuert. Der kleine Haken ist, ich
hätte gern ein Deathband im Bereich zwischen 1179 und 1219 damit der
Motor auch wirklich steht und 0 Volt hat. Das ist dann die
Mittelstellung das Knüppels +\- 20. Kann man in dem Assembler Code noch
etwas ändern? Ein Paar Werte hab ich schon an meine Fernbedienung
angepasst.
1
;--- Brushed ESC By Rolf R Bakke, May 2012
2
3
.include "m8def.inc"
4
5
.include "macros.inc"
6
7
.def t=r16
8
9
.org 0
10
ldi t, low(ramend)
11
out spl, t
12
ldi t, high(ramend)
13
out sph, t
14
15
16
;--- Port setup ---
17
18
; 76543210
19
ldi t, 0b11001100
20
out ddrc, t
21
22
; 76543210
23
ldi t, 0b11111111
24
out ddrb, t
25
26
; 76543210
27
ldi t, 0b10111011
28
out ddrd, t
29
30
31
;--- PWM output setup ---
32
33
; 76543210
34
ldi t, 0b10100000
35
out tccr1a, t
36
37
; 76543210
38
ldi t, 0b00010001
39
out tccr1b, t
40
41
ldi t, high(255) ;set PWM range
42
out icr1h, t
43
ldi t, low(255)
44
out icr1l, t
45
46
47
;--- arming ---
48
49
ar2: ldi zl, 0
50
51
ar1: rcall GetPwm
52
brcs ar2 ;time out, reset counter
53
54
ldy 1159 ;1180 orginaler Wert im Code
55
cp xl, yl
56
cpc xh, yh
57
brlo ar2 ;too low, reset counter
58
59
ldy 1239 ;1220 orginaler Wert im Code
60
cp xl, yl
61
cpc xh, yh
62
brsh ar2 ;too high, reset counter
63
64
inc zl ;in range, increase counter
65
cpi zl, 50 ;50 in a row?
66
brne ar1 ;no, arming not OK
67
68
69
;--- Main loop ---
70
71
ma1: rcall GetPwm ;get input PWM value
72
73
subi xl, low(1199) ;subtract 1500 uS 1200 orginaler Wert im Code
74
sbci xh, high(1199) ;1200 orginaler Wert im Code
75
76
brcs ma4 ;wich direction?
77
78
79
;--- forward ---
80
81
clr t ;turn off B half-bridge PWM
82
out ocr1bh, t
83
out ocr1bl, t
84
rcall delay ;wait one PWM cycle to let the B PWM hardware finish it current cycle
85
a_top_off ;set top transistors for forward configuration
86
b_top_on
87
out ocr1ah, xh ;update A half-bridge with current throttle
88
out ocr1al, xl
89
90
rjmp ma1
91
92
93
;--- reverse ---
94
95
ma4: clr yl ;Y = NEG(X)
96
clr yh
97
sub yl, xl
98
sbc yh, xh
99
100
clr t ;turn off A half-bridge PWM
101
out ocr1ah, t
102
out ocr1al, t
103
rcall delay ;wait one PWM cycle to let the A PWM hardware finish it current cycle
104
b_top_off ;set top transistors for reverse configuration
105
a_top_on
106
out ocr1bh, yh ;update B half-bridge with current throttle
107
out ocr1bl, yl
108
109
rjmp ma1
110
111
112
;--- SUBS ---
113
114
;--- delay ----
115
116
117
delay: ldi t, 0 ;96 uS delay
118
de1: dec t
119
brne de1
120
ret
121
122
123
124
;--- get PWM input value ---
125
126
127
GetPwm:
128
clr xl
129
clr xh
130
131
;wait for low to high transition on ppm input
132
133
ldy 0xffff
134
ge1: sbiw y, 1
135
brcs ge5 ;timeout (49mS)
136
sbic pind, 2
137
rjmp ge1
138
139
ldy 0xffff
140
ge2: sbiw y,1
141
brcs ge5 ;timeout (49mS)
142
sbis pind, 2
143
rjmp ge2
144
145
;measure high pulse time, 1.25 uS = 1 count
146
147
ldy 8000
148
ge3: adiw x, 1 ;2
149
sbiw y, 1 ;2
150
brcs ge5 ;1 ;exit with c=1 if timeout (10mS)
151
nop ;1
152
nop ;1
153
sbic pind, 2 ;1
154
rjmp ge3 ;2
155
156
;set to 1500uS if below 900uS or above 2100uS
157
158
ldy 720
159
cp xl, yl
160
cpc xh, yh
161
brlo ge4
162
ldy 1680
163
cp xl, yl
164
cpc xh, yh
165
brlo ge6
166
167
ge4: ldx 1199 ;out of limits, set to 1500uS 1200 orginaler Wert im Code
168
169
;
170
171
ge6: clc ;exit with c=0 if no timeout
172
ret
173
174
ge5: ldx 1199 ;time out, set to 1500uS and c=1 1200 orginaler Wert im Code
175
ret
Hier noch die Include
1
.macroa_top_on
2
sbiportd,4
3
.endmacro
4
5
.macroa_top_off
6
cbiportd,4
7
.endmacro
8
9
10
11
.macrob_top_on
12
sbiportd,5
13
.endmacro
14
15
.macrob_top_off
16
cbiportd,5
17
.endmacro
18
19
20
21
22
.macroldx
23
ldixl,low(@0)
24
ldixh,high(@0)
25
.endmacro
26
.macroldy
27
ldiyl,low(@0)
28
ldiyh,high(@0)
29
.endmacro
30
.macroldz
31
ldizl,low(@0)
32
ldizh,high(@0)
33
.endmacro
34
35
36
37
38
.macrodebug_on
39
sbiportb,5
40
.endmacro
41
42
.macrodebug_off
43
cbiportb,5
44
.endmacro
Ich hoffe es hat jemand eine Lösung. Ich kann kein Assembler nur bissl
Arduino für den Hausgebrauch.
Größe Andre
Ja ich kann es leider nicht. Ich glaub nicht das ich das noch lerne.
Etwas Arduino bekomm ich gerade noch hin. Deswegen wende ich mich an
dich. Ich hab versucht den Code zu verstehen aber ich begreife nicht.
Die Hardware kann ich beschreiben.
Ich vermute wenn ich mir den Code anschaue muss noch eine Berechnung
rein.
Grüße
Andre
Thomas H. schrieb:> Du fragst aber offensichtlich nach "Wer hat Lust das für> mich zu machen".
Du hast offenbar die Lust nicht. Das ist in Ordnung -nur: Warum
antwortest Du dann überhaupt?
Franz Rapid schrieb:> Du hast offenbar die Lust nicht. Das ist in Ordnung -nur: Warum> antwortest Du dann überhaupt?
Einige Gründe: weil's ein Diskussionsforum ist, er schreiben kann
solange er lustig ist und es Dich damit einen feuchten Kehricht angeht.
Andre M. schrieb:> ma4: clr yl ;Y = NEG(X)> clr yh> sub yl, xl> sbc yh, xh
YL auf 50 setzten, statt mit CLR auf 0. Nach SUB/SBC auf positiv (carry)
testen, solange positiv, YL löschen. Das war's schon. Die "Deadzone"
befindet sich damit im negativen Bereich (Rückwärtsgang) und solange
etwas weniger Leistung dort ok ist, stört's dort auch nicht. Das kann
man natürlich auch in der Auswertung auf "positiv" ähnlich machen, um's
genau auf die Mitte um 1200 zu legen. Oder man zieht mehr als 1199 ab
und murkst es so zurecht ;D
Als Beispiel kann der gezeigte Code dienen, alle zu verwendeten Opcodes
sind dort in ähnlicher Form und Kombination bereits verwendet. Es ist
nur ein wenig Kombinationsgabe notwendig und bei ein wenig Eigenleistung
helfen die Forumsmitglieder sicher gerne.
Hallo MWS,
Danke, das ist der erste konstruktive Beitrag. Ich bin auch gewillt mich
mit dem Code auseinander zu setzen. Es ist halt schwer wenn man gänzlich
bei Null anfängt. Da hilft ein Schubs in die richtige Richtung ungemein.
Ich werd mich mal versuchen. Ich hoffe ich bekomme es auch in der
positiven Richtung (Forwärtsgang) hin. Werd jetzt mich gleich hinsetzen
und den Code studieren.
Werde über das Ergebnis berichten.
Grüße
André
Also wenn ich das jetzt richtig verstehe, bezeichnet yl das Register
welches mit dem Befehl clr auf Null gesetzt wird.
Ich muss jetzt den Befehl finden der dem yl Register den Wert 50
zuweist.
> ma4: clr yl ;hier muss der Befehl rein für die Wert=50 Zuweisung> clr yh> sub yl, xl> sbc yh, xh
;hier soll yl überprüft werden ob der Wert positiv ist
und solange er positiv ist soll yl gelöscht werden (clr yl nehme ich
an?)
Bin ich auf dem richtigen Weg?
Und bitte mich nicht gleich wieder in der Luft zerreißen.
Grüße
André
MWS schrieb:> YL auf 50 setzten, statt mit CLR auf 0. Nach SUB/SBC auf positiv> (carry) testen, solange positiv, YL löschen.
War ein Denkfehler.
Korrektur bzw. Auflösung:
1
ma4:
2
clr yl
3
clr yh
4
sub yl, xl
5
sbc yh, xh
6
7
sbiw YL, 50 ; Umfang der Deadzone
8
brcc outofDZ
9
clr yl
10
clr yh
11
outofDZ:
12
13
clr t ;turn off A half-bridge PWM
14
out ocr1ah, t
15
; ...
Nach dem sbiw muss die Schreibweise verwendetet werden, die der
Assembler fordert, zum Beispiel "sbiw YH:YL, 50"
Ich wieder
"Nach dem sbiw muss die Schreibweise verwendetet werden, die der
Assembler fordert, zum Beispiel "sbiw YH:YL, 50" "
Nachdem ich mir jetzt jeden Befehl übersetze kommt geringfügig Licht ins
dunkle.
Der Befehl sbiw YH:YL, 50 bedeutet doch subtrahiere vom Registerpaar
YH/YL den Wert 50. Muss das YH und YL nicht klein geschrieben werden?
Ich benutze AVR Studio 4.19.
Funktioniert der sbiw Code für Vorwärts auch so ähnlich?
Andre M. schrieb:> Der Befehl sbiw YH:YL, 50 bedeutet doch subtrahiere vom Registerpaar> YH/YL den Wert 50. Muss das YH und YL nicht klein geschrieben werden?
Schreib's so, dass der Assembler nicht meckert, ich habe nicht das
Studio verwendet, um's zu testen, müsste ich also erst machen, das
kannst Du auch selbst.
> Funktioniert der sbiw Code für Vorwärts auch so ähnlich?
Er würde sogar identisch so funktionieren, unterschiedliche Labelnamen
vorausgesetzt.
Ok ich werde das mal vorsichtig ausprobieren. Hauptsache der Regler
bleib heile. Bin leider nicht zu Hause, werde jetzt noch den Code weiter
übersetzen damit ich den Inhalt verstehe.
Für Vorwärts müsste es dann glaub ich so aussehen
ma1: rcall GetPwm ;get input PWM value
subi xl, low(1199) ;subtract 1500 uS
sbci xh, high(1199)
sbiw XL:XH, 50 ; Umfang der Deadzone
brcc outofDZ2
clr xl
clr xh
outofDZ2:
brcs ma4 ;wich direction?
Andre M. schrieb:> Für Vorwärts müsste es dann glaub ich so aussehen
Da glaubst Du falsch, der SBIW-Block muss nach dem brcs ma4 stehen.
Dafür gibt's mehrere Gründe, einer davon ist, dass Brcs das intakte
Carry-Flag aus dem SBI/SBCI benötigt, welches durch das SBIW zerstört
würde.
Außerdem muss der DZ-Wert halbiert werden, da er nun bei Vor- und
Rückwärts abgezogen wird.
Im Übrigen würde ich das nur bei Rückwärts einbauen. Vorausgesetzt der
Code ist so angepasst, dass ein maximaler Knüppelausschlag gerade eben
100 Prozent Motorleistung ergibt, so fehlt der abgezogene DZ-Wert.
D.h. theoretisch wird der Motor dann keine 100 Prozent erreichen und das
Messergebnis der Pulslänge müsste skaliert werden. Geht, aber macht
etwas mehr Aufwand. Die einfache Alternative wäre etwas weniger Leistung
im Rückwärtsgang.
Kann aber auch sein, dass bereits jetzt die Leistung 100 Prozent
deutlich vor Ende des Knüppelausschlags erreicht, dann wird's nichts
ausmachen.
Ok das versteh ich. Als müsste der Wert auf 25 gesetzt werden.
Für vorwärts so...
ma1: rcall GetPwm ;get input PWM value
subi xl, low(1199) ;subtract 1500 uS
sbci xh, high(1199)
brcs ma4 ;wich direction?
sbiw XL:XH, 25 ; Umfang der Deadzone
brcc outofDZ2
clr xl
clr xh
outofDZ2:
Für rückwärts so...
ma4:
clr yl
clr yh
sub yl, xl
sbc yh, xh
sbiw YL, 25 ; Umfang der Deadzone
brcc outofDZ
clr yl
clr yh
outofDZ:
Ist es richtig das ich bei vorwärts outofDZ2 schreibe und bei rückwärts
outofDZ. Die Namen müssen doch unterschiedlich sein oder.
Kurze Rückmeldung Code sieht jetzt so aus und Deathband ist ausreichend.
1
ma1: rcall GetPwm ;get input PWM value
2
3
subi xl, low(1199) ;subtract 1500 uS 1200 Wert
4
sbci xh, high(1199) ;1200Wert
5
6
brcs ma4 ;wich direction?
7
8
sbiw xl:xh, 50 ; Umfang der Deadzone
9
brcc outofDZ2
10
clr xl
11
clr xh
12
outofDZ2:
13
14
15
16
;--- forward ---
17
18
clr t ;turn off B half-bridge PWM
19
out ocr1bh, t
20
out ocr1bl, t
21
rcall delay ;wait one PWM cycle to let the B PWM hardware finish it current cycle
22
a_top_off ;set top transistors for forward configuration
23
b_top_on
24
out ocr1ah, xh ;update A half-bridge with current throttle
25
out ocr1al, xl
26
27
rjmp ma1
28
29
30
;--- reverse ---
31
32
ma4: clr yl ;Y = NEG(X)
33
clr yh
34
sub yl, xl
35
sbc yh, xh
36
37
sbiw yl:yh, 50 ; Umfang der Deadzone
38
brcc outofDZ
39
clr yl
40
clr yh
41
outofDZ:
42
43
44
45
clr t ;turn off A half-bridge PWM
46
out ocr1ah, t
47
out ocr1al, t
48
rcall delay ;wait one PWM cycle to let the A PWM hardware finish it current cycle
49
b_top_off ;set top transistors for reverse configuration
50
a_top_on
51
out ocr1bh, yh ;update B half-bridge with current throttle
52
out ocr1bl, yl
53
54
rjmp ma1
Eine Kleinigkeit ist mir noch aufgefallen, ich hoffe ich kann das
beschreiben. Also Knüppel voll vorwärts Motor dreht vorwärts, wenn ich
dann den Knüppel loslasse, fällt er in Mittelstellung zurück. Kommt er
dabei geringfügig in Richtung rückwärts ruckt der Motor weil er noch im
Ausdrehen ist und in Richtung rückwärts umgepolt wird. Das passiert
obwohl sich der Knüppel im Deathband befindet. Wenn man das noch in den
Griff bekäme wärs perfekt.
Grüße
Abdré
Ich würde erst einmal die Fernsteuerung nach Vorwärts trimmen, damit der
Schuldige eindeutig festzumachen ist.
Dann würde sich die Frage stellen, warum Rückwärts bei Leistung 0
irgendetwas anderes bewirkt als Vorwärts bei Leistung 0.
Könnte man meines Erachtens sauber lösen, wenn man zu Vor-/Rückwärts
einen dritten Status einführt, in dem nur die PWMs auf 0 gesetzt werden,
die Richtung dagegen unverändert bleibt.
Das würde mehr Umbaumaßnahmen erfordern, da reicht's nicht mehr aus, nur
zwei kleine Blöcke einzufügen.
Mit der Trimmung hab ich schon probiert, weil ich den Gedanken auch
hatte. Das verschiebt nur de Auslösepunkt. In einer Richtung bekommt man
es dann hin. Es passiert auch nur wenn man den Knüppel in die
Nullstellung schnippsen läßt. Macht man es langsam und er rutscht nicht
kurz über den Nullpunkt drüber passiert nix.
Gefährlich wird dier Ruck für die Abtriebswelle am Motor wegen den
Scherkräften.
Langsam wird auch klar warum der Autor des Codes die Variante verworfen
hat. Es gib ja noch einen anderen. Dort ist mir aber die PWM Frequenz zu
niedrig und der Regelbererich zu klein.
Man könnte höchstens dort mal schauen ob das mit weniger Aufwand zu
ändern ist.
Soll ich den Code mal posten ?
Grüße
Andre
Andre M. schrieb:> Soll ich den Code mal posten ?
Wie wärs, wenn wir mitsammen einen neuen schreiben - mit Arduino
Bordmitteln.
D.h. falls deine Hardware so aufgebaut ist, dass man mit analogWrite auf
die beiden Pins deiner PWM Halbbrücken ran kommt.
mehr als ein
1
#define inputPin Pinnummer des Eingangs an dem der Kanalpuls reinkommt
2
#define leftBridge Pinnummer des Ausgangs, an dem die eine Halbbrücke hängt
3
#define rightBridge Pinnummer des Ausgangs, an dem die andere Halbbrücke hängt
else{// Knüppel steht in Mittelstellung, alles aus
48
analogWrite(LEFT_BRIDGE,0);
49
analogWrite(RIGHT_BRIDGE,0);
50
}
51
}
52
}
ist der jetzige Code nämlich im Prinzip nicht.
Das ist im Prinzip die ganze Funktionalität deines Assembler Programms
(des ersten), wobei der Arduino Code jetzt schon komfortabler ist, was
die Einstellung der Bereichsgrenzen angeht. Was noch fehlt, das ist die
Einschaltsicherung, die verhindert, dass der Motor nach dem Einschalten
loslaufen kann, wenn der Knüppel nicht in Mittelstellung steht. (Und
eine setup() musst du noch schreiben, in der du die Eingänge bzw.
Ausgänge richtig definierst)
Worums mir geht: Das Programm sollte auch für dich soweit verständlich
sein, dass du es an deine Bedürfnisse anpassen kannst, ohne jemanden
dazu zu benötigen. Ich will dich keineswegs dazu überreden, das ganze
nicht in Assembler zu machen. Da du aber erwähnt hast, dass du
normalerweise "Ardunio für den Hausgebrauch" programmieren kannst, denke
ich, dass du dir hier 100 mal leichter tust. Und dann kriegst du auch
das, was du willst.
Wie sieht eigentlich die Hardware dazu aus?
Mit dem Arduino Nano kann ich ein Taster auslesen hab damit auch erst
vor nem halben Jahr mal experimentiert. Ich würde schon gern mit dem
Atmega8 arbeiten, welcher auf dem Fahrtenregler sitzt. Die
Programmierpins sind rausgeführt und ich nutze nen USB Programmer zum
flashen des HEX.
Der Atmega8 müsste aber auch mit Arduino IDE zu programmieren gehen.
Dafür gibt es hier auch ein Projekt
http://www.kellerwerftcommunity.de/t417f173-KeMo-Projekt-ein-eigener-Regler-auf-Arduino-Basis.html
Dort wird fast das gleiche mit nem anderen Fahrtregler gemacht. Auch nen
Atmega8 allerdings mit N/N Fet Treibern. Diesen Regler habe ich auch da
und auch schon die Software ausprobiert. Dort ist auch der Regelbereich
etwas klein und die mir zu niedrige PWM wird per Software erzeugt und
nicht über die Hardwaretimer.
Andre M. schrieb:> Haben uns gerade knapp verfehlt. Die Hardware Liste ich mal auf bin> gerade unterwegs. Wow das sieht übersichtlich aus.
Genau darum gehts. Das ist alles keine Raketentechnik. Und mit Arduino
Bordmitteln schon gar nicht. Im Grunde ist es nur die Kombination aus
pulseIn und analogWrite. Wobei es nur um die Verteilung an den jeweilis
richtigen analogWrite je nach Pulslänge geht.
Sollte die PWM Frequenz nicht ausreichen, kann man immer noch so
nachhelfen
http://playground.arduino.cc/Code/PwmFrequency
und weiter mit analogWrite arbeiten oder den PWM Teil mit dem Timer
selbst übernehmen.
Mit dem normalen Arduino Nano gehen aber nur bestimmte Frequenzen, das
war ja damals mein Problem. Ich brauche wenigsten 16 bis 18 khz.
In dem von mir oben genannten Forum ist der Ansatz ziemlich gut nur das
PWM war nicht so ganz der Bringer.
Andre M. schrieb:> Mit dem normalen Arduino Nano gehen aber nur bestimmte Frequenzen, das> war ja damals mein Problem. Ich brauche wenigsten 16 bis 18 khz.> In dem von mir oben genannten Forum ist der Ansatz ziemlich gut nur das> PWM war nicht so ganz der Bringer.
Na ja.
Dann machst du eben die beiden PWM 'mit der Hand'.
Ist ja kein Beinbruch. Timer entsprechend aufsetzen und anstelle von
analogRead dann eben eine Zuweisung an entweder OCR1A oder OCR1B. Der
Rest bleibt deswegen immer noch gleich. Weder pulseIn noch map sind vom
Timer abhängig.
Abgesehen davon sehe ich noch nicht, warum beim Nano dieselbe Technik
wie im verlinkten PWM-Frequenz Einsteller nicht funktionieren sollte.
Ist ja auch nur ein Mega328 auf dem Board. Maximal die entsprechenden
Vorteiler könnten andere sein.
Im Zweifel kann man natürlich auch den Timer komplett mit einer PWM mit
variablem TOP Wert übernehmen. So wie das auch im Assembler Beispiel
gemacht wird.
Also vom Prinzip her ist es mir egal ob wir das in c oder assembler
machen. Ich werd mir die Nacht noch bissl die Assembler Lernvorlage zu
gemüte führen. Ich würde gern in beides begreifen.
Also machen wir jetzt in Assembler weiter oder Arduino IDE.
Für den 2. Regler hätte ich sogar einen Schaltplan da.
Muss mich ja bissl vorbereiten.
Karl H. schrieb:> Im Zweifel kann man natürlich auch den Timer komplett mit einer PWM mit> variablem TOP Wert übernehmen. So wie das auch im Assembler Beispiel> gemacht wird.
Edit:
Allerdings:
Wenn ich so nachrechne. Bei 16Mhz, einem 16 Bit Timer, Vorteiler 1, und
einer 10 Bit PWM, erreicht man eine PWM Frequenz von 15625Hz. Sollte
doch reichen. Dann hat man eben im map nicht 255 stehen sondern 1023.
Andre M. schrieb:> Also vom Prinzip her ist es mir egal ob wir das in c oder assembler> machen.
Im Prinzip ist es völlig wurscht.
Denn die PWM erzeugt ja sowieso der Timer, sobald man in die richtigen
Steuerregister die richtigen Werte schreibt.
FAQ: Timer
Aber das ganze drumherum ist für dich viel leichter anpassbar!
Ob du in Assembler
1
ldit,0b10100000
2
outtccr1a,t
oder in C
1
TCCR1A=0b10100000;
schreibst, ist ja Jacke wie Hose. Nur das man natürlich nicht so
bescheuert ist, da eine Binärkonstante zu schreiben, sondern die
Bitnamen benutzt.
Karl H. schrieb:> Karl H. schrieb:>>> Im Zweifel kann man natürlich auch den Timer komplett mit einer PWM mit>> variablem TOP Wert übernehmen. So wie das auch im Assembler Beispiel>> gemacht wird.>> Edit:> Allerdings:> Wenn ich so nachrechne. Bei 16Mhz, einem 16 Bit Timer, Vorteiler 1, und> einer 10 Bit PWM, erreicht man eine PWM Frequenz von 15625Hz. Sollte> doch reichen. Dann hat man eben im map nicht 255 stehen sondern 1023.
Wobei:
Da würde ich nicht lange fackeln und eine 9 Bit 'Phase and Frequency
correct' PWM nehmen. Das vermeidet den Sonderfall des Spikes in den
Extremwerten und eine 9 Bit Auflösung (512 verschiedene Stufen pro
Seite) ist immer noch gross genug.
Andre M. schrieb:> Also machen wir jetzt in Assembler weiter oder Arduino IDE.
Mit dem Karl Heinz machst Du in C weiter, da er dahingehend
missionarisch tätig ist, außerdem kennt er sich in ASM nicht richtig
aus. Mit mir machst Du nicht weiter, ich will ja hier keinen Wettbewerb
aufmachen.
@Karl Heinz: Dir ist bekannt, dass es für Deine immer wieder gerne
benutzte Vorgehensweise einen Foren-Begriff gibt: Thread-Hijacking.
Also das Kapern eines fremden Themas für eigene Interessen. Ich brauch'
jetzt nicht erklären, dass "Assemblercode Anpassung" jetzt so gar nichts
mit Arduinisch oder C zu tun hat. Warum machst Du keinen eigenen Thread
dafür auf?
Und ich will jetzt auch nicht mit Steinen werfen, bin sicher ja nicht
immer völlig Foren-konform :D
Aber der Unterschied ist: ich muss kein Vorbild sein, oder mich peinlich
genau an Regeln halten, ich bin kein Mod, ich hab' diesbezüglich mehr
Freiheiten.
Selbstverständlich werd' ich diese Vorstellung hier weiterverfolgen und
bin schon gespannt, wie weit Du alles vorgefertigt liefern wirst und
wieweit Du es schaffst, dass der TE mitzieht.
Deine 4 Posts in Folge sind schon mal ein guter Start LOL
Glück auf ;-)
MWS schrieb:> Andre M. schrieb:>> Also machen wir jetzt in Assembler weiter oder Arduino IDE.>> Mit dem Karl Heinz machst Du in C weiter, da er dahingehend> missionarisch tätig ist, außerdem kennt er sich in ASM nicht richtig> aus.
Doch kann ich.
Die Frage ist eher ob und wie sinnvoll das ist, wenn er mit dem hier
schon Schwierigkeiten hat. In einem anderen Thread hat er erwähnt, dass
er "Arduino programmieren für den Hausgebrauch" kann. Von daher macht es
für mich keinen Sinn, ihn da jetzt in Assembler durchzutragen. Der
Assembler ist hier nur deswegen aufs Tapet gekommen, weil er dafür von
irgendwo fertige Programme her bekommen hat. Und wie es dann für ihn um
Anpassen an seine persönlichen Wünsche steht, haben wir ja gesehen. Da
sehe ich in C++ mehr Chancen als ihm da jetzt einen Crashkurs in
Assembler zu geben.
D.h. für mich: der unfreiwillige Drift in Richtung Assembler bringt ihn
seinem Ziel nicht näher sondern im Gegenteil entfernt er sich davon.
Nicht weil das in Assembler zu schwierig wäre. Ist es überhaupt nicht.
Aber für ihn ist das eine völlig neue Welt in die er eigentlich gar
nicht will. Er will einfach nur einen Motorregler, der sich so verhält
wie er sich das vorstellt. Und dazu braucht es nicht Assembler. Vor
allen Dingen dann nicht, wenn er das alles erst noch lernen muss.
Karl H. schrieb:> Die Frage ist eher ob und wie sinnvoll das ist, wenn er mit dem hier> schon Schwierigkeiten hat.
Der will sich weder in ASM noch in Arduino/C verkünsteln, der will nur
einen funktionierenden Fahrtregler haben, damit er mit seinem anderem
Kram weitermachen kann. Mehr interessiert den nicht.
> In einem anderen Thread hat er erwähnt, dass> er "Arduino programmieren für den Hausgebrauch" kann. Von daher macht es> für mich keinen Sinn, ihn da jetzt in Assembler durchzutragen.
Wie gesagt, dass will er nicht, 'ne Änderung, damit das Geruckel weg ist
und gut ist's.
> Der> Assembler ist hier nur deswegen aufs Tapet gekommen, weil er dafür von> irgendwo fertige Programme her bekommen hat. Und wie es dann für ihn um> Anpassen an seine persönlichen Wünsche steht, haben wir ja gesehen. Da> sehe ich in C++ mehr Chancen als ihm da jetzt einen Crashkurs in> Assembler zu geben.
Der Thread hier dreht sich um Assembler und nicht um was Anderes. Was
warum und wieso er woanders machte und wie's zu dem hier dann kam, ist
hierfür egal.
Ansonsten dito.
> Um das Verstehen der Hardware PWM kommt er so und so nicht rum. Egal ob> in Assembler oder in C++. Denn eine PWM mit einem variablen Top Wert von> 65535 bringt ihn auch nicht auf die gewünschte Frequenz :-)
Dito II.
> Doch kann ich.
Will ich mal unbesehen glauben, gesehen hab' ich nie, dass dem so wäre.
MWS schrieb:> wie weit Du alles vorgefertigt liefern wirst und> wieweit Du es schaffst, dass der TE mitzieht.
Das ist ganz einfach.
Das Grundgerüst steht bereits, die Timer Ansteuerung 'klauen' wir aus
dem Assembler Programm von ganz oben, anstatt analogWrite kommen
Zuweisungen an die OCR1x Register und dann ist das Assembler Programm
aus dem Eröffnungsposting in einer C++ Form, die er kennt und die er
modifizieren kann. Zeitkritisch ist da ja nichts. Die Pulserkennung
könnte man besser machen, ist aber im Assembler Programm auch nicht
besser als das was ein Ardiuno pulseIn macht. Von daher sind wir da also
wieder auf gleich.
Karl H. schrieb:> Das Grundgerüst steht bereits, die Timer Ansteuerung 'klauen' wir aus> dem Assembler Programm von ganz oben, anstatt analogWrite kommen> Zuweisungen an die OCR1x Register und dann ist das Assembler Programm> aus dem Eröffnungsposting in einer C++ Form, die er kennt und die er> modifizieren kann. Zeitkritisch ist da ja nichts. Die Pulserkennung> könnte man besser machen, ist aber im Assembler Programm auch nicht> besser als das was ein Ardiuno pulseIn macht. Von daher sind wir da also> wieder auf gleich.
Lustig wird's dann, wenn ein Fehler im Arduinocode die H-Brücke grillt.
Das war der Vorteil des ASM-Codes, selbst wenn er schlecht war, er war
erprobt.
Aber wie schon gesagt: mach mal.
Mich musst Du nicht missionieren, ich halt' mich raus.
MWS schrieb:> Lustig wird's dann, wenn ein Fehler im Arduinocode die H-Brücke grillt.
Warum sollte er.
Es wird immer nur eine Halbbrücke aufgesteuert oder beide sind auf 0.
Ganz genau gleich, wie es auch der Assembler Code macht.
Und denn delay da drinnen
mit seinen 96µs, und das Umschalten der Portpins, das kriegen wir auch
noch hin :-)
Der einzige Unterschied: Zur Umrechnung der Servopulse in den Duty Cycle
benutzen wir ganz normale C_Arithmetik anstelle einer Assembler Sequenz,
die er nicht versteht und die er nicht analysieren und an seine
Fernsteuerung anpassen kann. Denn genau daran spiesst es sich seit dem
21. Dezember.
Beitrag "C-Code für Fahrtregler anpassen"
Hallo,
nicht streiten, soll ein Mod bitte die Threads Teilen in Assembler und
Arduino beides mit dem Atmega8. Ich will beides probieren Assembler und
C++. Gebt mir ne Chance und etwas Zeit zu lesen. Ne fertige Lösung ist
sicherlich schön, aber in die Schublade wollte ich eigentlich nicht
gesteckt werden. Bissl was lernen wollte ich schon.
Was ich nicht will ist einen Arduino Nano als Prozessor mit dem
Fahrtregler koppeln damit er den Atmega8 ersetzt.
Andre M. schrieb:> Was ich nicht will ist einen Arduino Nano als Prozessor mit dem> Fahrtregler koppeln damit er den Atmega8 ersetzt.
Dann musst du jetzt endlich mal sagen, wie denn deine Hardware
tatsächlich aussieht.
Und nein, es gibt keinen Grund, warum ein A-Nano das nicht können
sollte.
Wenn du einen hast, dann benutze ihn.
Schön langsam kenne ich mich auch nicht mehr aus, was du eigentlich an
Hardware wirklich hast. Ich bin halt davon ausgegangen dass ein Arduino
für dich das einfachste wäre.
Karl H. schrieb:> Öhm. Das halbe Assembler Tutorial ist von mir.
Hmm, da war ich jetzt neugierig und hab' gesucht, nachdem mir da nie
etwas auffiel. Eine Referenz zu Dir fand ich nicht, vielleicht hab' ich
falsch gesucht? Magst Du dazu einen Link posten?
Karl H. schrieb:> Warum sollte er.
Weil immer was schieflaufen kann und dann nicht Deine HW gegrillt wird.
Software ist immer zu 100% fehlerfrei, garantiert, Hand drauf ;-)
> mit seinen 96µs, und das Umschalten der Portpins, das kriegen wir auch> noch hin :-)
Na, das hoff' ich doch schwer.
> Fernsteuerung anpassen kann. Denn genau daran spiesst es sich seit dem> 21. Dezember. Beitrag "C-Code für Fahrtregler anpassen"
Und da bist Du jetzt quasi Retter in der Not geworden, indem ihm das
schreibst? Versteh' ich, wär' ohne Dich nie gegangen, völlig
ausgeschlossen. Dann mach' mal zu Ende.
MWS schrieb:> Karl H. schrieb:>> Öhm. Das halbe Assembler Tutorial ist von mir.>> Hmm, da war ich jetzt neugierig und hab' gesucht, nachdem mir da nie> etwas auffiel. Eine Referenz zu Dir fand ich nicht, vielleicht hab' ich> falsch gesucht? Magst Du dazu einen Link posten?
Dann schau mal, wer zb die erstversion des 7-Segment Multiplex
geschrieben hat. Detto für PWM, an die Porterweiterung kann ich mich
nicht mehr erinnern, ob ich sie angefangen habe, aber ein erklecklicher
Teil davon ist in der ganz frühen Version von mir.
> Weil immer was schieflaufen kann und dann nicht Deine HW gegrillt wird.> Software ist immer zu 100% fehlerfrei, garantiert, Hand drauf ;-)
:-)
Die Assemblerversion da oben ist so trivial. Das kriegen wir aus dem
Stegreif hin, die paar Sachen in C++ hin zu schreiben. Hand drauf.
> Und da bist Du jetzt quasi Retter in der Not geworden, indem ihm das> schreibst? Versteh' ich, wär' ohne Dich nie gegangen, völlig> ausgeschlossen.
Darum gehts überhaupt nicht.
Was ist dir lieber? Wenn er jedesmal dich braucht, wenn er das Deadband
vergrössern will und aber die Vollgasstellung bei Knüppelendposition
erreichen will, obwohl der Verfahrweg des Knüppels durch das größere
Deadband kleiner wurde? Bringst du ihm 16 Bit Multiplikation und
Division bei, damit er sich einen Dreisatz in Assembler programmieren
kann? Denn genau darauf läuft es hinaus. Entweder darauf oder aber eine
Verkleinerung des Top Wertes. Wobei das interessant wird, wenn das
Deadband asymetrisch werden soll. Bzw. machst du ihm die Verriegelung,
so das es eine Zeit lang nicht möglich ist, den Motor umzupolen, wenn
die Motor-aus Stellung erreicht ist?
Ich will ihm das nach Möglichkeit auch nicht machen. Aber ich möchte ihn
in die Lage versetzen, dass er sich das selber programmieren kann. Und
so komplex ist die Erstversion als Ausgangsbasis nun auch wieder nicht.
Karl H. schrieb:> MWS schrieb:>> Karl H. schrieb:>>> Öhm. Das halbe Assembler Tutorial ist von mir.>>>> Hmm, da war ich jetzt neugierig und hab' gesucht, nachdem mir da nie>> etwas auffiel. Eine Referenz zu Dir fand ich nicht, vielleicht hab' ich>> falsch gesucht? Magst Du dazu einen Link posten?>> Dann schau mal, wer zb die erstversion des 7-Segment Multiplex> geschrieben hat.
Ich hatte bereits freundlich nach einem Link zum Beleg Deiner Aussagen
gefragt, das war doch nicht zuviel verlangt?!
> Darum gehts überhaupt nicht.
Aber hallo, genau darum geht's Dir.
> Was ist dir lieber? Wenn er jedesmal dich braucht, wenn er das Deadband> vergrössern will und aber die Vollgasstellung bei Knüppelendposition> erreichen will, obwohl der Verfahrweg des Knüppels durch das größere> Deadband kleiner wurde?
Mach' keine Wissenschaft draus, bzw. Dinge, die so nie gefragt waren.
> Bringst du ihm 16 Bit Multiplikation und> Division bei, damit er sich einen Dreisatz in Assembler programmieren> kann? Denn genau darauf läuft es hinaus.
Das ist Deine ganz spezielle Sichtweise, die ich nicht teile.
> Entweder darauf oder aber eine> Verkleinerung des Duty Bereiches. Wobei das interessant wird, wenn das> Deadband asymetrisch werden soll. Bzw. machst du ihm die Verriegelung,> dass es eine Zeit lang nicht möglich ist, den Motor umzupolen, wenn die> Motor aus Stellung erreicht ist?
Nö, das machst ja jetzt alles Du.
Bzw. dann wenn Du verstanden hast, dass er eben einen fertigen
Fahrtregler hat, den er programmieren kann, dieser fertige Fahrtregler
aber nicht im Ganzen oder teilweise per uC-Transplantation in ein
Arduino-Gefrickel verwandelt werden soll.
Das ist meine Hardware der erste (Hobby King) Regler ist mit Atmega8 und
N/N Fet Treibern. Der wird in dem Forum verwendet, es gibt einen
Schaltplan und die Sourcen für die Arduino IDE.
http://www.kellerwerftcommunity.de/t417f173-KeMo-Projekt-ein-eigener-Regler-auf-Arduino-Basis.html
Der zweite Regler (RCTimer) ist mit Atmega8 und P/N Fet Treibern.
Für den war der Assembler Code.
Zum flashen nutze ich einen USBASP 2.0
Die Programmierpins (RESET, VCC, GND, SCLK, MISO, MOSI) sind bei beiden
Reglern rausgeführt.
Thread beobachten
Seitenaufteilung abschalten