Hi
Ich versuche mich soeben, erfolglos, darin, eine LED per Hardware
blinken zu lassen.
Der Code ist auf nur diesen Snipped reduziert:
(out_ ist ein Macro zur Automatisierung von out und sts)
rjmp PC ;Endlosschleife (Sprung an ProgrammCounter)
Ich erwarte, daß der Timer1 mit 1MHz zählt,
bei OCR1B den Ausgang PB4 toggelt,
bei OCR1C den Zählerwert auf 0 setzt.
Laut Simulation klappt Das auch.
Laut Oszi bekomme ich aber eine PWM mit 11,5Hz mit einer ON-Time von
18.3ms zu Off-Time von 68.6ms - Periodendauer 86,9ms.
Soweit, immerhin ein PWM.
Wenn ich jetzt aber die Zeitachse 'zoome' und mir das ON-Signal ansehe,
besteht Dieses selber bereits aus einem PWM mit einer Periodendauer von
~67µs und 50/50 On/Off-Zeit.
Also einem Toogle ca. alle 33µs, was ziemlich genau dem OCR1C-Wert
entspricht.
Wo habe ich das Datenblatt zum ATtiny25/45/85 (2586Q-AVR-08/2013) falsch
interpretiert oder wie bringe ich dem Steinchen bei, mit variabler
Frequenz (dachte da an CTC) und variablem Duty (CompareMatch B, Pin
toggeln)?
Die Fotos sind nachgestellt und leider 'etwas' verwackelt bzw. sieht man
den Elektronenstrahl nicht immer sehr deutlich.
205446: Hier der PWM im ON-Anteil des PWM-Signal
205545: Die ON-Time des resutierenden PWM
205634: Die Periodendauer des resultierenden PWM
205702: die OFF-Time des resultierenden PWM (links oben ist ganz leicht
der ON-Teil zu erahnen)
.... eigentlich wollte ich nur während der Einlernphase des Fahrweg
diese Phase separat erkennbar machen, die eigentliche Aufgabe (Fahrweg
erlernen und dann Zwischenpositionen anfahren mit Anzeige, wo Diese ist
(Blink-Code 6-4-2 wäre z.B. 642) funktioniert, nur ab und zu bekomme ich
ein TimeOut - Motordrehung wird nicht erkannt und Chip startet die
Einlernphase neu - Diese wollte ich halt erkennen können und bekomme
nicht Mal ne LED zum Blinken (zumindest nicht, wie geplant).
MfG
MfG
Pardon, das war's nicht, im tiny15-Modus toggelt gar nichts mehr.
Aber ich kann das Problem nicht nachvollziehen, ich sehe bei mir ein
Rechteck mit ca. 64 us und einem Tastverhältnis von ca. 50 %.
Hi
CKSEL 0010 (ProgISP v1.72, lag dem USBISP bei)
LowValue 0x62 (ändert sich auf 0x60 bei 0000)
Weiter sollte sich dann doch 'nur' die Geschwindigkeit ändern (6,4MHz
statt 8MHz bzw. durch ckl/8 statt 1MHz 'was weniger').
MfG
Edit:
Dann werde ich Morgen Mal das Steinchen austauschen.
Es sollte sich aber schon das von mir gedachte/oben beschriebene Signal
ergeben?
PPS:
Ich verwende das AVR-Studio 4.19, da sich eine aktuellere Version nicht
im virtuellen Windows 7 installieren ließ.
Wobei Das, gerade bei Assembler, eigentlich egal sein dürfte, da die
Anwendungen 1:1 im Chip ankommen sollten.
out_ GTCCR,temp
sollte da noch drunter
> 'nur' die Geschwindigkeit ändern
Wenn ich es richtig verstanden habe, ändert sich im tiny15-Modus das
Verhalten von Timer1 grundlegend.
Hi
S. Landolt schrieb:> ldi temp,(1<<COM1B0)|(1<<PWM1B)
Scheint keinerlei Auswirkung zu haben, ob ich PWM1B setze, oder nicht.
Das Signal sieht identisch aus.
Die 33µs (bzw. 66µs Periodendauer) des 'ON-PWM-Signal' passen ja zu dem
Zählerwert OCR1C und den 1MHz (8MHz ckDIV/8) - nur verstehe ich den 11Hz
(ca. 10x die Sekunde) PWM nicht, Dessen ON-Zeiten ebenfalls per PWM
generiert werden.
Irgendwie scheint es, daß ich zwei Timer ver-UND-et betreibe, kann ich
mir aber nicht erklären.
Timer 0 ist aus und Mehr ist nicht drin, im ATtiny45.
MfG
> .. Das Signal sieht identisch aus.
Auch wenn Sie OCR1B auf z.B. 10 setzen?
Tja, dann weiß ich auch nicht weiter.
Ich übernehme Ihr Programm mit copy&paste, ergänze das |(1<<PWM1B)
und stecke es in meinen ATtiny85 (Fuses auf Werkseinstellung), das
Oszilloskop hängt an PB4 und zeigt ein Rechtecksignal mit ca. 64.5 us.
Wie gewünscht lässt sich Letzteres mit OCR1C einstellen sowie das
Tastverhältnis mit OCR1B.
Dass ich ddrb, pb4 und PC umschreiben muss sei nur am Rande erwähnt, ich
arbeite grundsätzlich mit der Option -c.
Patrick J. schrieb:> Irgendwie scheint es, daß ich zwei Timer ver-UND-et betreibe, kann ich> mir aber nicht erklären.>
Die AVR-ASM-Experten sicherlich auch nicht, wenn die Glaskugel gerade
mal wieder nicht will ;-)
Also - den Programmteil, den man als entscheidend hält, einmal hier
richtig Formatiert wiederzugeben ist sicher ein guter Ansatz. Ein
besserer wäre aber, zusätzlich das komplette Programm als Datei
anzuhängen.
Ansonsten finde ich es gut, das du dir so viel Mühe gibst uns dein
Problem darzustellen. Deshalb nimm die folgenden Sätze nicht persönlich.
Wahrscheinlich hast du es nur vergessen.
Habt ihr Angst ein patentwürdiges Programm geschrieben zu haben ?
Dann solltet ihr eure Probleme auch selber lösen.
Bernd_Stein
Hi
Danke der vielen Antworten.
Bernd S. schrieb:> Habt ihr Angst ein patentwürdiges Programm geschrieben zu haben ?> Dann solltet ihr eure Probleme auch selber lösen.
Zu Viel des Guten, Sire, Ihr müsset mich nicht so hoch tragend anreden,
werter Herr, bin auch nur ein kleiner Krauter :)
Bernd S. schrieb:> zusätzlich das komplette Programm als Datei> anzuhängen.
Ich gelobe Besserung!
Soeben das Steinchen neu 'besaftet' - gleiches Ergebnis.
Sowohl die 66µs (15,2kHz) wie die 11Hz kamen zum Vorschein.
Das .lss-File zum Vorzeigen angedacht, dort werden aber ebenfalls die
unbenutzten Macros gelistet (da im .LIST .LISTMAC - Bereich) - also
hoffnungslos aufgequollen.
Wieder den Original-Fehler-Zustand hergestellt, aufgespielt, auf dem
Oszi keine Änderung - dachte ich - hier ebenfalls die 66µs (also
eigentlich 33+33), aber die 11Hz gibt es nicht mehr, ich habe jetzt
einen sauberen PWM.
Der hoch geheime Code enthält hier für, bis auf die Definitionen des
Studio4 (unter Anderem ddrb), zwei Include-Files, aus Denen aber Nichts
benutzt wird, da der Code ab Adresse 0 (Reset-Vektor) angesprungen wird.
In den Include-Files sind Macros enthalten, teils im WWW Gefundene, wie
auch selbst aus diversen Vorlagen Abgeleitete.
Die 'tn45def.inc' bleibe ich schuldig, da ich Diese 'aus der virtuellen
Win-7-Maschine extrahieren müsste' - ist aber Bestandteil des Studio4
und sollte sich, wenn benötigt, bei Atmel finden lassen (bzw. bringt der
Installer zum Studio Diese mit).
Zu dem (hoch hochgeheimem) Programm:
Ein DC-Motor wird über eine H-Brücke in beide Richtungen angesteuert.
Dieser wird untersetzt (Kraft erhöht), dabei wird die Drehrichtung des
ersten Zahnrad überwacht (und gezählt).
Wenn der Motor hier nicht 'rückwärts' dreht, wird die Drehrichtung im
Programm invertiert und die Lern-Phase neu gestartet.
Die Lichtschranken überlappen sich, womit die Richtung erkannt und ein
Zähler entsprechend hoch/runter gezählt werden kann - ein Richtungsflag
wird gesetzt, Welches tunlichst mit der Wunsch-Richtung übereinstimmen
sollte - zumindest in der Einlern-Phase.
Bei 'ganz zu' blockiert der Motor und die Zahnrad-Drehung wird nicht
erkannt - nach einer Sekunde beißt der WatchDog zu und setzt ein Flag
(Interrupt).
Darauf hin wird der Zählerstand genullt, die Richtung umgekehrt und die
Fahrt beginnt von Neuem.
Bei jeder Änderung der Lichtschranken (zwei CNY70) wird der WatchDog
resettet, somit habe ich 'bis zu einer Sekunde Zeit', bis sich eine der
Lichtschranken melden muß.
In der Stellung 'voll auf' passiert das Gleiche, der WatchDog beißt, das
Flag wird erkannt, der WatchDog beendet, die Einlernphase verlassen.
Im eigentlichen Programm wird nun (wir sind ja ganz oben/ganz auf)
einige Male einige Schritte zu gefahren.
Bei jeder angefahrenen Position wird Diese 'vorgeblinkt'.
Dazu wird die Schritt-Anzahl in 10er-Ziffern geteilt (ja, etwas
umständlich, Platz ist aber noch Massig da).
Eine 604 wird zu ...... (6) - (0) .... (4) (eine Null wird laaang
gegeben, vorangestellte Nullen werden übersprungen).
Dann wird 'zur Mitte' gefahren, dann einige Male in AUF-Richtung, dann
wieder zur Mitte.
Das war jetzt das 'eigentliche Programm nach dem Einlernen' und
wiederholt sich ab hier.
Bei den Fahrten wird der WatchDog aktiviert, ein Biss beendet die
aktuelle Fahrt wie auch ein Erreichen der Soll-Position die aktuelle
Fahrt beendet - wieder mit 'Zahl vorblinken'.
Wenn der WatchDog 255x 'gebissen hat' - also nach 255 'Laufzeit-Fehlern'
(mechanisches Ende oder Wackler in den CNY70, oder ...) wird neu
eingelernt.
Beim Einlernen wollte ich eigentlich ein verschieden schnelles
Dauer-Blinken, damit ich sehe, daß der µC gerade 'in ZU' oder 'in AUF'
Lern-Richtung unterwegs ist, wo ich die Probleme zu diesem Thread dann
bekam.
Im Anhang das Programm noch mit dem 'Nur-PWM-Programm'.
Wenn Das draußen ist, seid Ihr so weit, wie ich jetzt auch ;)
Vll. fällt's ja dem Einen oder Anderen auf ... bin ASM-selbst-Beibringer
-
also nicht Lachen ;)
MfG
PS: mit dem Patent ist jetzt wohl Essig, wo's hier geschrieben steht :/
PPS: ein Video zum Download gibt es hier:
https://www.file-upload.net/download-12551610/VID_20170611_221034.3gp.html
War der einzige/erste Hoster, bei Dem ich mich nicht anmelden musste,
leider nicht zum 'direkt angucken' - 107MB vll. etwas übertrieben, nur
um zu 'Spannen' :)
(wenn Wer nen Uploader 'für nebenher und direkt angugge' hat, gerne Link
zu mir)
> Zu Viel des Guten, Sire, Ihr müsset mich ...
Zum Sachthema kann ich nichts mehr, aber vielleicht zur Erheiterung
beitragen: das mit der Anrede ist immer so eine Sache, wandelt sich im
Laufe der Zeit, wie derzeit ja zu beobachten ist an Sie und Du (oder
gleich kleingeschrieben du), auch das Ihr war einmal zweifelhaft:
»Wohlwend, Ihr könnt hier nicht mit uns von Euren Sachen reden ...«
...
Wohlwends Idylle war durch die Frau entschieden gestört, und er packte
zusammen, doch schlug er einen andern Weg ein, als die Salanderleute
gegangen.
Diese stiegen wieder in die Höhe und sprachen einige Minuten nichts,
bis Martin über die kurze Rede seiner Frau lachen mußte.
»Du hast ihn scharf behandelt!« sagte er zu ihr, »wie zum Teufel
gerätst du auf den Einfall, per Wohlwend und per Ihr mit ihm zu reden?«
»Ich denke, man spricht so mit den Sträflingen in den Zuchthäusern; in
meinen Augen ist er aber nichts Besseres!«
aus Martin Salander von Gottfried Keller
Hi
S. Landolt schrieb:>> ldi temp,(1<<COM1B0)|(1<PWM1B)>> Also das haben Sie (pardon) nicht von mir, ich schrieb |(1<<PWM1B).
Das fällt mir eben gerade erst auf, daß bei mir nur 1 < drin ist - wie
konnte mir Das passieren??
mit << sieht das Signal ganz passabel aus - fehlte also nur das PWM1B -
habe mir gerade die Timer-Sektion ausgedruckt, im PDF verlief ich mich
irgendwie.
Danke für den Wink!
Carl D. schrieb:> Ich würde einfach mal kurz nach dem Label "Reset" mit einem Pin wackeln> und vermute stark, daß das mit 11Hz passiert.
Dann wäre aber die Frage, was die LOW-Zeit im 11Hz-PWM veranlasst.
Irgendwie schade, daß der Fehler jetzt weg ist :/
Nichts desto Trotz:
Das Video ist 'oben' - der Video-Download-Link hier drüber kann also
vergessen werden.
Auch ich habe wohl ein YT-Konto - dann nutzen Wir Das doch Mal:
https://www.youtube.com/watch?v=jEgOslWK5MM
MfG
Patrick J. schrieb:> Wieder den Original-Fehler-Zustand hergestellt, aufgespielt, auf dem> Oszi keine Änderung - dachte ich - hier ebenfalls die 66µs (also> eigentlich 33+33), aber die 11Hz gibt es nicht mehr, ich habe jetzt> einen sauberen PWM.
Jetzt mußt Du nur noch den Code zeigen, wo der Fehler auftritt.
Ein einmal angeschalteter WD übersteht einen Reset, sowie neu
Programmieren.
Erst nach VCC = 0V ist er wieder aus.
Und Dein Setzen des WD auf 1s funktioniert nicht, siehe:
"8.4.1 Timed Sequences for Changing the Configuration of the Watchdog
Timer"
Thread beobachten
Seitenaufteilung abschalten