Morse-Übungsgenerator mit Mikroprozessor

Günter,

bitte starte hier:

http://www.qrpforum.de/index.p…ad&postID=49587#post49587

Danke, dachte das wäre eine vorläufige Version.

Ich will ja nicht unverschämt sein (oder doch?) aber könnte man die erforderlichen Fuse Bits anstatt als Hex-Wert auch namentlich benennen, damit man als nicht C-Programmierer, der nicht mit AVRDude brennt, seine Häkchen in einem AVR-Programmer mit graphischer Oberfläche setzen kann? Wäre eine große Erleichterung.

tnx. Günter

Hallo Günter,

ja das ist ein Testversion, ich sende Dir dein HEX-File zu, wenn ich den µP von Dir kenne.

Siehe das Bild im Anhang.

Zitat von de0508

Die Software läuft nur auf atTiny45 oder atTiny85, deshalb ist die Betrachtung anderer nicht relevanter µP unbrauchbar.

Die angehängten Bilder zeigen die realen max. Ströme und Spannungen des tiny85, nur als Info, ich will darüber nicht diskutieren.

Hallo Uwe, der von mir angebrachte Punkt der Portüberlastung hat nichts mit dem µP zu tun, daher ist die Betrachtung anderer µP doch relevant
Die angehängten Kurven hören bei 20 mA auf, und das hat seinen Grund, genau genommen viele Gründe.

Wenn ich den Strom höher als erlaubt wähle, kann, speziell bei statischer Ansteuerung, die lokale Verlustleistung auf dem Chip überschritten werden.
Zusätzlich können noch Migrationseffekte auftauchen. Die Metallisierung innerhalb des Chips ist für bestimmte Maximalströme ausgelegt, üblicherweise per Pin,
per Port und für die Summe von allen. Verletze ich diese langfristig kann die Metallisierung sich verändern. Hier gibt es zwischen Kurzschluss und hochohmig werden
alle möglichen Varianten.

Bei dynamischer Ansteuerung tauchen andere "Schmutzeffekte" auf. Wenn der Strom durch den Pin, und damit durch den gesamten Prozessor, nur noch durch den Widerstand des Ausgangstransistors beschränkt wird belaste ich meine Versorgung mit dem Laststrom. Das kann man natürlich durch entsprechend gute Abblockung der Versorgung nach außen hin in den Griff kriegen. Spannend ist aber was im Chip passiert: Die höhen Ströme können zu einer lokalen Verschiebung der Versorgungsspannung führen, mit dem unerwünschten Effekt dass irgendwelche Gatter oder Flip-Flops nicht mehr so recht wissen was sie eigentlich sind.

Unvermeidbar ist auch eine kapazitve Kopplung, die intern weitere lustige Effekte verursachen kann. Wenn die Logik die meine Ausgangstransistoren treibt nicht mehr so recht weiß was sie eigentlich ist dann können auch mal beide Transistoren gleichzeitig eingeschaltet werden.

Diese Liste kann man noch beliebig fortsetzen.

Das fiese bei dieser Art von Fehlern ist dass sie meist sproradisch auftreten, da abhängig von Temperatur, Versorgungsspannung, Prozess bei der Fertigung...
Die Migrationseffekte werden durch höhere Temperaturen verstärkt, und sind natürlich auch zeitabhängig. So kann es z.B. passieren dass ein Prozessor bei Raumtemperatur niemals einen Ausfall zeigt, bei Betrieb mit höherer Temperatur aber relativ schnell dauerhaft ausfällt.

Gruß aus Wuppertal

Dieter DD5DD

Hallo QRPForum,

die letzte und fehlerfreie Firmware für den Morse-Übungsgenerator mit Mikroprozessor ist fertig.

Nach vielen Tagen debuggen, bin ich gestern Nacht auf die Lösung gestoßen:

Ich dachte der Prozessortakt von 8Mhz, reicht für die Ausgabe der 128-PWM-Sinus Tabellenwerte aus, leider war das nicht so. Somit stimmte die Ausgabefrequenz nicht mit der kalkulierten überein !
Problem es wurden einige PWM-Sinus Werte ausgelassen und insgesamt war der Ton dann höher.

Abhilfe schaffte heute das Neuschreiben der Timer0 Interrupt Service Routine (ISR), die Umstellung der Programmlogik und das anheben des Prozessortakt auf 16Mhz.

Hier die Einstellungen für meinen ISP-Programmer avrdude:

# set fuse-bit
# 16MHz PLL
#avrdude -c usbasp -p attiny85 -P usb -U lfuse:w:0xc1:m -U hfuse:w:0xdc:m
# Programm
avrdude -c usbasp -p attiny85 -P usb -B 25 -U flash:w:main.hex:i

Das Programm benötigt nun 3953 Byte Flashspeicher (tiny45 max. 4096 Byte) und somit kann nur ein atTiny45 oder atTiny85 verwendet werden.

Das HEX-File für beide µP Versionen findet ihr im Anhang.

Über PB4|B3 ist weiterhin die Auswahl der Tonfrequenz möglich:

PB4|B3 = 11 : 660Hz
PB4|B3 = 10 : 570Hz
PB4|B3 = 01 : 750Hz
PB4|B3 = 00 : 840Hz

Der Schaltplan hat sich nicht verändert und kann hier

- http://www.qrpforum.de/index.p…0110138ae53f705a9e078888f

geladen werden.

.

Hallo Daniel,

das Entprellen und die Auswertung der Taste (AN / AUS) finden in drei verschiedenen Task statt.

Siehe "main.h" in dem Quellcode:

#define DEBOUNCETICK				5
#define ADD_SCHEDULER_DEBOUNCE()		timeradd( task_debounce, SECONDS( (double)DEBOUNCETICK/1000.0 ) )
#define ADD_SCHEDULER_PRESS_PADDLE()		timeradd( task_press_paddle, SECONDS( 0.02 ) )
#define ADD_SCHEDULER_RELEASE_PADDLE()		timeradd( task_release_paddle, SECONDS( 0.02 ) )

Alle 20ms wird überprüft, ob sich der Status der Taste geändert hat, da erst nach 4 Durchläufen der Entprellroutine task_debounce ein Ergebnis anliegt.

Evtl. kann ich hier noch etwas anpassen und den Task task_debounce auslagern und wieder in der ISR ausführen.

Aber es ist auch wichtig, das alles was in einer ISR steht, sollte so schnell als möglich abgearbeitet wird !

Dort verbraucht diese Routine dann evtl. wichtige Rechenzeit, die sonst vom Programmteil der PWM-Sinus Erzeugung gebraucht wird.

Alles was außerhalb einer ISR läuft - also in einem Task - kann jederzeit von einem Interrupt unterbrochen werden.

Reichen Dir DEBOUNCETICK 1ms und task_press_paddle, task_release_paddle 5ms ?

-- Vielleicht fällt mir da noch etwas anderes ein. --

CW-Kurs mit DG4FDQ
Reinhard, DG4FDQ fängt nächste Woche wieder einen CW-Kurs an, da möchte ich ihm den kleinen Morse-Übungsgenerator mit Mikroprozessor vorstellen und hoffe er gefällt ihm.
Falls die OMs aus dem Kurs auch gefallen daran finden, könnte man wir im OV ein kleines Bauprojekt daraus machen.

Ein Platine ist bei den wenigen Bauteilen schnell geroutet.

Ausblick
Michael, DF2OK hat mir in seinem Beitrag Tonqualität noch eine schöne Anregung gegeben.
Ich habe mir eben beim Radtraining schon eine Umsetzung der tönenden Telegrafie überlegt und werde dazu den zweiten PWM an PB4 aktivieren.
Der PWM an PB4 erzeugt dann die zur PWM an PB1 gehörenden "Oberwellen", die wir dann mit OPA aktiv mischen können. Danach kann danach kann dann keiner Verstärker alias LM386 kommen. Ich habe noch Analog Device SSM2211 da.

Mit einem Poti können wir auch den Mischfaktor, also die Oberwellenlautstärke beeinflussen.

.

Hallo Daniel,

vor Deinen bzw. Euren Programmierkenntnissen ziehe ich meinen Hut, darin habe ich mich noch nie eingearbeitet. Vielleicht mal, wenn ich das Rentenalter erreichen sollte. Habe früher (C64) mal ein wenig mit Basic gespielt, vorhandene Programme etwas angepaßt oder später ein paar einfache ! Progrämmchen in Turbo-Pascal getippt. Aber das ist laaaange her, hi. Und nicht vergleichbar mit den ganzen modernen Sachen hier im AFU.

Das, was Ihr entwickelt, liest sich gut und sieht auch so aus. So ein richtig guter ! Morsegenerator als Einzelgerät fehlt mir auch noch.

Hallo Daniel,

ich habe noch die Firmware angepasst: die Entprellfunktion wird nun alle 1ms angesprungen, alle 5ms wird die Taste überprüft und noch einen Bug entfernt.

Das Programm benötigt nun 3952 byte Flashspeicher.

Viel Spaß beim testen.

Zitat von DM3DA

Der Schalter, den Du abliest, ist ein Präzisionsinstrument, dass neu 100 Euro und mehr kosten kann. Für einen einzigen Druckschalter! Du kannst also davon ausgehen, dass die Mechanik des Schalters (Morsetaste) weitgehend prellfrei ist.

Bitte doch im Auge zu behalten: Es ist ein Morse-Übungsgenerator.
Will heißen, derjenige, der einen Morseübungsgenerator braucht, hat oft keine Präzisionsmorsetaste, sondern nur eine Billigtaste zum Üben. Und ein CW High-Speeder braucht sicher keinen Übungsgenerator mehr. Also sollte doch die Konstruktion nicht so an der Grenze liegen, dass dabei ein zwar genial einfacher Generator herauskommt, der aber nur an teuerer Präzisions-Mechanik zufriedenstellend funktioniert.

Hat vielleicht jemand ein Speicherscope und kann den Prellvorgang ( Batteriestromkreis über Vorwiderstand schalten) einfach mal kurz testen und dokumentieren, so dass man - anstatt im Dunkeln zu tappen - für die Prellzeiten einer guten Taste und eines einfachen Drucktasters einen aussagekräftigen Hinweis bekommt? Ein simples RC-Glied als Deglitcher zwischen Taster und Tiny muss nicht auf Polling oder einen Interrupt warten und hilft zur Unterstützung der Entprellung sicher ein Stück weiter.

73, Günter

Guten morgen Daniel,

da hast du mir ja eine schöne Aufgabe geben.

Ich will es mir mal einfach machen, die Entprellroutine (debounce) wird sicherlich für den Übungsbetrieb ausreichen schnell sein.

• Ich gehe davon aus, dass Anfänger nicht so teuren und guten Tasten haben. Also eher etwas einfacheres.
• Bisher habe wir auch keine Praxisrückmeldungen, ob es überhaupt ein Problem, bei zu schnellem Tempo/ Geben, gibt.
• Diese neue Anforderung hätte man ganz am Anfang des Programmdesign berücksichtigen sollen, so müsste ich einen Großteil der Programmlogik umschreiben. Lust habe ich jetzt keine
• Aber eine Idee wie es trotzdem gehen könnte, habe ich mir schon überlegt -wäre aber mit zusätzlichem Hardwareaufwand verbunden.
  Siehe Artikel: Hardwareentprellung
  [Blockierte Grafik: http://www.mikrocontroller.net…s/b/b0/NAND_debouncer.png]

Zu Deiner Ausführung Programmablauf versuche ich einiges klar zu stellen, siehe auch das Mindmap-Bild.

• Das Programm wartet generell nicht, alles ist im "Fluss" über den Taskmanager.
• Der Taskmanager stellt das Benutzerinterface dar, über ihn sind Interaktionen mit Programmkern möglich: die LED blinkt (Out), die Frequenzauswahl (In) und, das Paddel/ Taster abfrage (In).
• Die gesamte Tonerzeugung findet über die beiden Timer1 PWM-Signal und Timer0 Sinusschwingung statt.
• Timer0 hat auch noch andere Aufgabe und ist u.a. der Kern die alle zeitkritischen Aufgaben zuständig
• Timer1 ist eine Hardware PWM Generator der läuft immer auch ohne Einfluss von außen, Timer0 verändert nur das Tastverhältnis des PWM Signals.
• Angenommen wir es liegt keine Ton an und wir befinden uns am Anfang - der aus drei teilen bestehenden - Tonerzeugung:
  
  
  • Warte (T0_IDLE),
  • Anschwingen (T0_SWEEP_ON),
  • Ton halten (T0_TON_HOLD) und
  • Ausschwingen (T0_SWEEP_OFF)

Der Übergang von 1. --> 2. erfolgt durch das Signal (T0_TON_ON), das der Task task_press_paddle setzt.
Der Übergang von 2. --> 3. ist eine "epsilon transition" mit Signal (T0_TON_HOLD) und wird nach Ausgabe aller Anschwingperioden gesetzt.
Legende: eine "epsilon transition" wird hier erklärt: Finite State Machine.
Der Übergang von 3. --> 4. erfolgt durch das Signal (T0_TON_OFF), das der Task task_release_paddle setzt. Nach einer weiteren "epsilon transition" befinden wir uns wieder im Warte-Zustand (T0_IDLE).

[*]Eine Sinusschwingung besteht aus 128 Stützstellen, z.B. bei 660Hz müssen wir alle
11,84µs = 1/( 660Hz * 128 ) Sekunden den Wert des PWM Generators ändern. Jede Sinusschwingung wird komplett ausgegeben, erst danach ist ein Zustandswechsel möglich.

[*]Ich verweise auf das Bild und hoffe es erklärt sich selbst ?
Man beachte was links und rechts zu sehen ist !.

Hallo QRPGemeinde,

so das erste Video von Testaufbau auf einem Steckbrett ist gemacht und steht bei Youtube zur Verfügung:

Edit: Wurde leider gelöscht.

Es soll euch den Klang verdeutlichen und einen Eindruck über die Funktion vermitteln.

Ich habe das Audiosignal aus dem Video extrahiert und auf den Teil der automatischen Begrüßung begrenzt, das Rauschen wurde abgesenkt und der Pegel auf -6dB normiert.

Frage: Was gibt der Übungsgenerator als Begrüßungstext aus ?

Guten Morgen QRPForum,

wie es so ist, mache ich mir Gedanken um den Code auf der µP Familie atTiny861 zum laufen zu bekommen. Das ist mir gestern Nacht gelungen.

Der atTiny861 ist der großen Bruder des atTiny85 und besitzen noch mehr I/O Ports und insgesamt 3 Hardware-PWM. Darüber hinaus besitzt er auch die notwendige PLL um die Hardware-PWM mit 64MHz betreiben zu können !

Das Programm im Anhang benötigt nun folgenden Flashspeicher:

3945 Byte t85/t45
3955 Byte t861/t461

Hans-Peter, DL6FAP hat mir noch diesen Link zu gesendet und damit eine Erweiterung für seinen TRX eingebaut.

ATtiny13-Elbug von Ralf Beesner, DK5BU, ELO Mikrocontroller

So kam bei mir auch die Idee auf eine Paddle Unterstützung müsste noch realisiert werden. Mit einem atTiny861 wäre noch genügend Platz für weiteren Code sowie weitere PWM-Sinus Tabelle !

Ausblick
Das könnte man mit einem atTiny861 noch alles anstellen:

• erzeugen von Brummen erzeugen: f0:50Hz, f2:100Hz, f3:150Hz über PWM 2
• erzeugen von Rauschen über PWM 3
• Paddelbetrieb implementieren und
• die Geschwindigkeit für dit und dah Regelbar (ADC) machen.

Je mehr ich darüber nachdenke, um so spannender finde ich das Thema CW.

.

Zitat von de0508

Das könnte man mit einem atTiny861 noch alles anstellen

Die Gedanken sind frei und vielleicht gibt es ja in denTiefen des Web schon C-libs, die man für diese Zwecke recyclen kann:

• Automatisches Geben von Übungs-Fünfergruppen nach dem Zufallsprinzip (nur Buchstaben, oder Buchstaben und Zahlen)
• Einstellbare Wort-Geschwindigkeit ( Lernpsychologisch ist es angeblich günstiger, die Zeichen schneller zu geben, und dafür die Zeichenabstände zu verlängern - Koch Methode )
• Serielle Verbindung zu einem PC zur Morseausgabe von Texten aus einer Textfile oder direkt vom Keyboard.
• Zur Gebekontrolle: Decodierung von Morsezeichen, die mit der Taste gegeben werden und Ausgabe auf einem Industriestandard LCD Display oder über ser. Schnittstelle zum PC

Zitat von de0508

Je mehr ich darüber nachdenke, um so spannender finde ich das Thema CW

Ja, so lange man nur darüber nachdenkt und es nicht selber lernen muss "Morsen Lernen - Methoden und Softwarehilfen pdf"
CW ist, wie wenn man sich freiwillig ein Bein amputiert, um sich fortan auf Krücken fortzubewegen

73, Günter
nach Diktat schnell verreist