ISP mit der Soundkarte

Video: http://youtu.be/pJwOz8BUwt0

Nach einer Entwicklung von Thomas Baum: http://tiny.systems/article/soundProgrammer.html

Als mir Thomas Baum zum ersten Mal von seiner Idee erzählt hat war ich gleich begeistert: Die Soundkarte als ISP-Programmer verwenden! Jeder Kopfhörerausgang kann verwendet werden, egal ob am PC, am Smartphone oder am Tablet. Wenn das funktioniert, ist es ein Hammer! Kein Bootloader, kein Programmer, einfach nur das Stereosignal an den Controller legen. Also gleich mal ausprobieren! Für den ersten Versuch habe ich diese Schaltung verwendet:

Mach einigen Versuchen hat es funktioniert! Das Problem war nur, dass die AC-Kopplung am Kopfhörerausgang keinen ganz eindeutigen Ruhepegel hat. Nach einigen Ladeversuchen schiebt er sich dann selbst in den passenden Bereich. Kann sein, dass die Variante von Thomas mit zwei Koppelkondensatoren von 100 nF schneller zu Ziel führt. Wichtig ist, dass die Batteriespannung nur 3 V beträgt. Jedenfalls konnte ich am Ende erfolgreich das Blinkprogramm von Thomas übertragen.

Wie kann das überhaupt funktionieren, hat nicht die ISP-Schnittstelle immer sechs Leitungen? Stimmt, aber drei davon, GND, VCC und Reset fallen schon mal weg, jedenfalls wenn man Reset selbst betätigt. Und MISO ist ein Rückkanal, auf dem der Programmer sehen kann ob alles funktioniert. Da reicht auch eine LED. Wenn sie flackert weiß man, dass es klappt. Bleibt also die Taktleitung SCK und die Datenleitung MOSI. Ihre Daten werden direkt von der Soundkarte abgespielt.

Das Signal hört sich an wie Vogelgezwitscher. Links singt ein Rotkehlchen den Takt, rechts krächzt eine Elster die Daten. Man könnte ja mal zwei solche Vögel mit Mikrofonen ausstatten und in den Controller singen lassen. Nach ca. 10.000 Jahren wird zum ersten Mal ganz zufällig ein sinnvolles Programm dabei rauskommen. So funktioniert das mit der Evolution. Nach weiteren 10 Millionen Jahren haben die Vögel den Controller voll im Griff. Bei uns geht das schneller, weil die Signale per Software berechnet werden. Mit der richtigen Schaltung funktioniert es sofort.

In einer zweiten Schaltungsvariante habe ich die Eingangspegel mit Spannungsteilern auf 1/3 der Betriebsspannung gezogen. Wichtig ist, dass die Clock-Leitung bei einem Reset schon einen Low-Pegel sieht, sonst verzählt sich der Controller mit den Taktimpulsen. Bei VCC = 3 V liegt die Schaltschwelle bei 1,5 V. Mit 1 V liegt man dann sicher auf der Low-Seite. Wenn die Soundkarte in beide Richtungen mindestens ca. 1 V aussteuert, sollte es passen. Und tatsächlich, mit dieser Schaltung funktioniert das Programmieren auf Anhieb in einem Spannungsbereich von 2,7 V bis 3,7 V.

Die Schaltung habe ich fliegend auf der Platine zum Lernpaket Mikrocontroller aufgebaut. Wenn die serielle Schnittstelle nicht angeschlossen ist liegen alle Anschlüsse des Tiny13 frei. Ein Steckboard tut es genauso, aber diese Platine liegt hier immer schon rum und trägt eine deutliche Beschriftung der Tiny13-Pins. Die Spannungsversorgung übernimmt ein Batteriefach. Bei diesem Aufbau kann man relativ leicht Links und Rechts vertauschen, was auch immer wieder passiert. Ich schaue dann mit dem Oszilloskop nach. Das Taktsignal erkennt man an seinen regelmäßigen Impulsen. Wenn es an PB2 liegt ist alles richtig.

Und hier kommt ein weiteres Programm zum Testen. Es stammt aus dem Lernpaket Mikrocontroller und ist in Assembler geschrieben. Wie man sieht ist es ein Wechselblinker an den Ports B3 und B4.

;Blink2.asm Blinker mit Unterprogramm

      .include "tn13def.inc"

rjmp Anfang
Anfang:
      ldi   r16,0x18    ;PB4 und PB4
      out   ddrb,r16    ;Datenrichtung
Schleife:
      ldi   r16,8       ;8 = 0x08
      out   portb,r16   ;PB3 = 1, PB4 = 0
      rcall Warten      ;Unterprogrammaufruf
      ldi   r16,16      ;16 = 0x10
      out   portb,r16   ;PB3 = 0, PB4 = 1
      rcall Warten      ;Unterprogrammaufruf
rjmp  Schleife

Warten:	
      Ldi   r16,250      
Warten1:                ;äußere Schleife
      Ldi   r17,250
Warten2:                ;innere Schleife
      dec   r17
      brne  Warten2
      dec   r16
      brne  Warten1 
      ret               ;Rücksprung

Übersetzt kommt folgendes Hexfile dabei heraus:

:020000020000FC
:1000000000C008E107BB08E008BB04D000E108BB62
:1000100001D0F9CF0AEF1AEF1A95F1F70A95D9F73F
:02002000089541
:00000001FF

Und das nun von Thomas übersetzt ergibt dieses Sound-File, anklicken, reinspielen, fertig: Blink2.wav

Soundkarten und Signale

So sieht das Signal der Soundkarte in meinem Windows-PC aus. Aus dem programmierten Rechtecksignal macht das nachfolgende Tiefpassfilter ein angenähertes Rechteck mit runden Flanken und Überschwingern. Entscheidend ist aber, dass ein digitaler Eingang immer noch ein eindeutiges Rechtecksignal sieht. Wie zu erwarten war funktioniert die Programmierung damit einwandfrei. Das Signal auf dem Oszilloskop von Thomas Baum sieht zwar deutlich anders aus, ist aber ebenfalls digital gesehen eindeutig. Die spannende Frage ist nun, welche Überraschungen sind da noch zu erwarten.

Die ist das gleiche Signal, abgespielt auf meinem Nexus 7 Tablet. Da sieht man sofort, das Filter ist ganz ungünstig. Der digitale Eingang könnte bis zu vier Impulse statt nur einen sehen. Das kann eigentlich nicht funktionieren. Und tatsächlich, alle Programmierversuche sind fehlgeschlagen.
(Nachtrag: Inzwischen ist klar, dass diese schlechten Signale durch Übersteuerung der Ausgangsstufe entstehen. Bei 80% Lautstärke ist alles sauber.)

Die relativ kurzen Störimpulse müsste man eigentlich mit dem passenden Tiefpassfilter beseitigen können. Mit 100 Ohm und 100 nF ergibt sich laut Online-Rechner eine Grenzfrequenz von 15,9 kHz. Und tatsächlich, das Signal sieht schon viel besser aus.

Tatsächlich funktioniert die Programmierung nun auch mit dem Nexus 7. Über Versuche mit anderen Geräten und entsprechende Rückmeldungen würde ich mich sehr freuen.

NRZ-Modulation, von Heinz D.

Vorschlag: Abhilfe durch NRZ-Modulation (Never Return to Zero) und Reduzierung der Geschwindigkeit Faktor 4

NRZ-Prinzip am Beispiel '1010110'

Um die äußere Beschaltung auf ein Minimum zu reduzieren habe ich die .wav's untersucht. Nachdem das Signal den DA-Wandler mit seinem Tiefpass (<22050Hz) und den Hochpass, Koppel-C (>20Hz) durchlaufen hat, sieht es (siehe andere Scope-Aufnahmen) schlimm aus. Es müsste doch möglich sein, fast alle Probleme auf der Softwareseite zu lösen.

'10101100' am Line-Ausgang, erstes Byte von Prog-Enable

Das NRZ-Signal kann am Hochpass nicht mehr scheitern! Mit Vervierfachung der Samples (Sck=1378Hz, 698Hz..1378Hz) kann der DA-Wandler-TP besser durchlaufen werden.

'10' am Line-Ausgang, 32+32-Samples

Für das Lead-In, Lead-Out und die Pausen kann auf dem rechten Kanal schadlos permanent '000000...' gesendet werden (voller Spannungshub), während Sck auf 0V ! nicht auf Minus bleibt!

Die (ISP-) Signale habe ich, ganz primitiv, mit einem anderen T13 erzeugt, aufgezeichnet und abgespielt. Der empfangende T13 hat, wie in Ihrem allerersten Vorschlag 100k/200k oder wie in meinem Vorschlag, einen Ruhepegel leicht unter Vcc/2, sonst nichts! Ab Vcc/4 = 0,75Vss - 1,25Vss (= 0,25Veff - 0,4Veff) bis zu einer leichten Übersteuerung funktioniert es tadellos.

Zusatzinfo: Durch die Umstellung des Sound-Konverters werden nun tatsächlich Signale nach diesem Prinzip erzeugt. Es ist kein mittlerer DC-Pegel mehr vorhanden, was Probleme mit einem Tiefpass ausschließt.

Elektronik-Labor Projekte AVR Spa rrow