Die hier angegebenen Experimente wurden mit der MCU MSP430G2553 von Texas Instruments auf deren LaunchPad gemacht. Die Experimente können aber ebenso gut mit anderen MCUs angestellt werden. Es wird aber für nichts gehaftet.

Für diese Experimente brauchte ich ein LaunchPad, ein Multimeter, ein Oszilloskop und einige Kleinteile wie Widerstände und Kondensatoren, und einen kleinen Lautsprecher. Ein Steckbrett kann nicht schaden, ebenso ein Bündel Prüfklipp-Kabel die einfach an das LaunchPad angeklemmt werden können.

Als Ersatz für einen Speicher-Oszillographen wurde zudem der Soundkarten-Oszillograph benutzt, in Verbindung mit der preiswerten externen Soundkarte (mit USB-Anschluß) von Behringer, der U-Control UCA202, die einen 48kHz Konverter enthält. Für die Beobachtung serieller Übertragungen z.B. reicht so etwas völlig aus, und gibt gute Einblicke in die Abläufe.

Die verwendete MCU erwies sich als erstaunlich robust. Wie man so eine MCU dann doch kaputt kriegt ist hier beschreiben.

Wie man an das 4e4th kommt steht auf der 4e4th.start Seite.

Auf dieser Seite werden INPUT Experiemente gezeigt. Die grundlegenden OUTPUT Experimente sind auf einer extra Seite zusammengefasst.

Ist der Taster gedrückt oder nicht? Das klingt zunächst nach einer einfachen Sache. Die Taster auf dem MSP430LaunchPad sind auch qualitativ gut, prellen praktisch nicht. Das Bild „LP-Taster“ wurde mit einem Speicheroszilloskop aufgenommen. Es zeigt, dass eine saubere fallende Flanke resultiert, wenn der Taster gedrückt wird. Es gibt einen deutlichen Druckpunkt bei der Bedienung, beim Drücken wie beim Loslassen „knackt“ es etwas. Doch das ist nicht bei allen Tastern so. Das Experiment mit einem einfachen NoName-Taster zeigt dessen Verhalten. Es gibt keinen so sauberen Druckpunkt, und der Pegel am Portpin fällt nicht nur einmal, sondern prellt. Für etwas 4.5ms gibt es immer wieder H- und L-Pegel in rascher Folge.

Um auch von solche einem Taster ein klares „gedrückt“ oder „nicht-gedrückt“ zu erhalten muss entprellt werden, was per Software gemacht wird. Das folgende kleine Forthprogramm zeigt wie. Damit ist es möglich klar zu ermitteln wann der Taster stabil gedrückt gehalten wurde. Und es wird eine Regelung gezeigt, die sicher stellt, dass nur ein einziger stabiler Tastendruck ausgewertet wird. Bei weiter gedrücktem Taster erfolgt keine weitere Reaktion mehr. Er muss erst losgelassen werden, bevor das Programm auf „neuer Tastendruck registriert“ befindet.

Die Schaltung für das Experiment ist denkbar einfach:

P1.3 --- S2 --- GND

Dazu wird der Portpin als digitaler Eingang geschaltet. Im Beispiel ist Pin3 von Port1 der MCU MSP430G2553 auf dem LaunchPad über den Taster S2 direkt mit Masse (GND) verbunden. Das geht ohne weiteres. Ein interner pullup-Widerstand liefert den positiven Spannungspegel.

S2         P1.3

offen      H
gedrückt   L

\ Hochzaehlen einer Variablen an den LEDs darstellen. 
\ Zählen jeweils auf S2-Tastendruck, pollen von S2. 

HEX
FFFF constant TRUE
DECIMAL

\ S2 -- P1.3
\ Taster S2 ist im 4e4th schon initialisiert. Es gibt das Abfragewort S2?

: S2??  \ -- f  \ Taster S2 entprellen 
  true  5 zero DO 10 ms s2? and LOOP ; \ Verzögerungszeit experimentell.

: 1SHOT \ x0 f0 -- x1 f1  \ f wird nur wahr wenn Taster erneut gedrueckt wurde.
  2dup >r >r         \ R: -- x0 f0 
  invert swap drop   \ f0 --> x1
  r> r>              \ x1 x0 f0 -- 
  2dup  and    IF 2drop true exit THEN  
  2dup  and 0= IF 2drop zero exit THEN  
  2drop zero ; 


\ LED1 -- P1.0 red
\ LED2 -- P1.6 green
\ Die LEDs sind im 4e4th schon initialisiert. 

BIN
: SETLEDS  \ n -- \ Binaerwert an den LEDs darstellen.
  >r  \ Als lokale variable sichern. 
  r@ 00000001 and IF green cset ELSE green cclr THEN   \ Bit0 auswerten.
  r> 00000010 and IF red   cset ELSE red   cclr THEN ; \ Bit1 auswerten.
HEX

variable OUT
: OUT>     \ Wert aus der Variablen an den LEDs anzeigen. 
  out @  setleds ; 

: INC     \ Ein Binaerzaehler fuer die beiden LEDs am LaunchPad. 
  zero BEGIN 
  s2?? 1shot    \ Tastendruck abfragen. 
  IF 1 out +! THEN out>  \ Binaer zaehlen und Display aktuell halten. 
  key? UNTIL drop  key drop ; \ Ende und Stack aufraeumen.  

: ?? ( adr -- ) @ u. ; \ Helfer um den Inhalt einer Variablen zu sehen.

( finis)

Pin P2.3 der MCU wird als Eingang geschaltet, d.h sein direction register bit wird auf logisch null gesetzt. Dann kann man an diesem Eingang ablesen, ob außen ein high- oder low-Pegel anliegt. Der Eingang schaltet per Schmidttrigger abhängig von der anliegenden Spannung in den einen oder anderen Zustand. Um das sichtbar zu machen, wird ein sehr langsames Auf und Ab des Spannungspegels an einem genügend großen RC-Glied erzeugt. Laden und Entladen des Kondensators übernimmt ebenfalls die MCU. Dazu arbeitet Pin P1.7 als Ausgang über einen Widerstand auf einen Elektrolytkondensator. Die grüne LED auf dem LaunchPad dient als Anzeige des Ladezustandes. Das kleine Forth-Programm dafür ist nachstehend wiedergegeben. Man kann alle allgemeinen I/O Pins vom Eingang zum Ausgang machen, wie, das ist MCU-spezifisch. Bitte im User Manual deiner MCU nachsehen.

Man kann den Pegel an P2.3 zusätzlich mit dem Oszilloskop, oder mit einem Multimeter anzeigen. In meinem Aufbau war beides angeschlossen. Mit dem Multimeter wurde die Spannung fortlaufend im MIN/MAX Modus gemessen. Dabei wurde folgendes beobachtet:

• Spannung an P2.3 variiert zwischen 1.498V (MIN) und 2.146V (MAX)
• P2.3in schaltet zwischen H (high) und L (low) um.
• Bei MIN wird der Eingang L und bei MAX wird er H.
• Am Oszilloskkop steigt der Pegel an P2.3 wenn der Kondensator von Pin P1.7 geladen wird. Und er fällt wenn darüber entladen wird.
• Dabei war eine 0,648V breite Hysterese zu beobachten. Der H-Zustand wird erst bei MIN wieder verlassen. Und der L-Zustand kippt erst bei MAX wieder in den H-Zustand. Zweipunktregler
• Diese Werte liegen im Bereich der Angaben im Datenblatt.

Das Ganze geht natürlich auch mit winzigen Kapazitäten und hohen Widerständen. Oder mit Kapazitätsänderungen von Folien, Oberflächen usw. Dieses Verhalten lässt sich dann z.B. dazu benutzen einen ADC-Wandler ohne ADC-Wandler aufzubauen; Prinzip: Per Programm die Takte bis zur Umschaltschwelle zählen (Dank an Jürgen Pintaske für den Artikel).

\  Kondensator laden und entladen als Analog Signal für den Eingang.

hex
80 P1 2constant P1.7out
08 P2 2constant P2.3out
80 P1 1+ 2constant P1.7dir
08 P2 1+ 2constant P2.3dir
08 P2 1- 2constant p2.3in

: init   
   P1.7dir cset            \ make P1.7 output
   P2.3dir cclr            \ make P2.3 input
   red cclr  green cclr ;  \ LEDs aus

: C+     P1.7out cset ; \ Kondensator laden
: C-     P1.7out cclr ; \ Kondensator entladen

: warte-auf-voll  ( -- ) 
   begin p2.3in cget until  ;
: warte-auf-leer  ( -- ) 
   begin p2.3in cget invert until  ;

: TEST ( -- )
  init begin
    c+  warte-auf-voll  green cset 
    c-  warte-auf-leer  green cclr 
  key? until red cset ;

\ finis

Die blaue Kurve zeigt den Pegel an P2.3 und die rote Kurve den resultierenden Puls, der an P1.7 ausgegeben wird. Das Bild täuscht auf den ersten Blick! Der Pegel am RC-Glied bestimmt die Frequenz des Rechtecksignals, und nicht umgekehrt. Hier macht es sich schon bemerkbar, dass der Oszillator von einem high level Programm erzeugt wird.

Wenn die ansteigende Schaltschwelle erreicht ist, wird ausgeschaltet. Aber der Vorgang das zu tun dauert etwas. Während dessen lädt der Kondensator weiter auf. Wenn die MCU-Logik endlich fertig ist, schaltet sie den Treiber-Port ab, der Kondensator wird entladen. Wenn dann die absteigende Schaltschwelle erreicht ist, wird wieder angeschaltet. Aber auch das hat eine Latenz die hier bemerkbar wird. Der Kondensator wird noch weiter entladen, bis endlich wieder umgeschaltet wird. Die Hysterese ist daher gar nicht zu erkennen. Sie ist besser zu erkennen, wenn das RC-Glied eine sehr langsame Frequenz liefert, also R und C relativ groß gewählt werden - was hiermit gezeigt werden sollte.

Besser sieht man was geschieht, wenn ein sinusförmiges analoges Signal an den Eingangspin anlegt wird. MIt einem Tongenerator ist das schnell gemacht. Testtöne gibt es aber auch im Internet, und vom lineout der Soundkarte lässt sich das Testsignal dann genauso gewinnen. Ist die Frequenz des Tones nicht zu hoch, ist die Hysterese um die Schaltschwellen herum wieder gut zu erkennen.

Um das Audiosignal einzukoppeln ohne das die negative Halbwelle abgeschnitten wird, ist eine Beschaltung erforderlich. Der Kondensator C entkoppelt das Signal von Gleichspannungsanteilen, und die beiden Widerstände schieben das Signal mittig zwischen Vcc und Vss. Täte man das nicht, würde der negative Anteil der Welle von der Schutzdiode am Einganspin geschluckt, die in der MCU schon integriert ist. Alle R=10K und als C eine kleine Tantal-Perle, das sollte genügen.

Dann kommt es zu clipping, der MCU passiert nichts. Jedenfalls solange der Strom für die Schutzdioden des Ports nicht zu groß wird, 2mA kann sie schlucken. Der Sachverhalt ist in den Bildern gezeigt, diesmal aufgenommen mit dem Audio-Scope. Mit einem 10K Vorwiderstand vor dem Eingang dürfte also bis 10V nichts passieren. Mein Tongenerator schafft einen Hub von 6,5V (Spitze-Tal-Wert) und das wurde anstandslos vertragen.

Ein optische Datenübertragung über eine kurze Strecke kann man äußerst simple mit nichts weiter als zwei superhellen roten LEDs aufbauen.

Das Prinzip: Erst wird die winzige Kapazität in einer LED aufgeladen. Dann wird die Zeit gemessen die sie braucht um sich wieder zu entladen.

Dazu muss man wissen, das eine LED, die in Sperrichtung betrieben wird, eine kleine Menge elektrischer Ladung im Subststrat speichert. Und deren Abfluss ist abbhängig von der Lichtmenge welche auf die LED fällt. Im Dunklen bleibt die Ladung länger bestehen als im Hellen. Diesen Effekt kann man ausnutzen für die Datenübertragung. Man läd LED-II auf und leuchtet sie dann mit der gleichartigen LED-I an, oder eben nicht. Und an der Entladezeit kann man dann erkennen, ob die LED-II angeleuchtet worden ist oder nicht. Und in der anderen Richtung funktioniert es ebenso.

Matthias Koch hat in seinem gleichnamigen Beitrag im Forth-Magazin "Vierte Dimension" gezeigt wie das geht. Die Einzelheiten und sein Forth-Programm-Beispiel bitte dort nachlesen. Man braucht wirklich nicht mehr als die beiden LEDs und zwei LaunchPads! Und natürlich das Programm:
mecrisp-ledcomm-winxp.zip
mecrisp-ledcomm.tar.gz

Ihr werdet sicher eine Anwendung finden für so eine kabellose Datenübertragung. Anmerkung: Nicht jede MCU kann das so. Das hängt von der Art und Weise ab wie so ein Portpin gemacht ist. Hast Du Ledcomm auch schonmal auf dem TI Stellaris Launchpad ausprobiert? Der Quelltext liegt auch dem Mecrisp-Stellaris Paket bei, und trägt zur Völkerverständigung zwischen MSP430 und ARM Cortex bei.

Darin ist das Prinzip zu sehen. Beim „Strahlen“ wird die Anode und die Kathode der LED anders herum betrieben als beim „Lauschen“.

...
1 constant Anode
2 constant Kathode

: Strahle ( -- )
  Anode   P2OUT cbis!
  Kathode P2OUT cbic!
  Anode Kathode or P2DIR cbis!   
;  
 
: Lauschen-Vorbereitung ( -- )
  Anode   P2OUT cbic!            \ SperrschichtkapazitŠt
  Kathode P2OUT cbis!            \ durch Verpolung laden
  Anode Kathode or P2DIR cbis!
  begin Kathode P2IN cbit@ until \ Warten, bis die Kathode geladen ist
  Kathode P2DIR cbic!
;

: Lauschen-Nachbearbeitung ( -- Flag )
  Kathode P2IN cbit@ not        \ Ist die Kathode entladen, ist es hell
; 
...

Im Rest des Codes wird dann das Timing gemacht.

• Dejustieren – keine Übertragung mehr (down). Beide roten LauchPad LEDs gehen aus.
• Was lichtundurchlässiges dazwischen halten – keine Übertragung mehr (down).
• Spiegel – Auch um die Ecke geht die Übertragung; (up).
• In sich zurück spiegeln – keine Reaktion (down).
• Dunkler Keller mit oder ohne leuchtende Leuchtstoffröhre – (up); das Kellerlicht machte keinen Unterschied! Größter erreichter Abstand = 20 cm.
• Sammellinse – Abstandsvergrößerung (up). Bei 40cm gings immer noch, aber da war meine provisorische optische Bank zu Ende.
• Fluten mit weißem LED Licht (Taschenlampe, hell, 12 LEDs) – stört nicht! (up).
• Gezielt beleuchten einer Übertragungs-LED mit gelblichem LED Licht (kleine Taschenlampe, nur ein LED) – zugehörige rote LaunchPad LEDs geht aus. (Aber wenn ich es geschickt anstelle, bleibt die gegenüberliegende an!)
• Anleuchten mit Taschen-Laser (25mA, 630-680 nm) – stört nicht! (up)
• Einkoppeln (dranhalten) in Plexiglasscheibe (60cm lang, 6mm dick, halbwegs polierte Kannten) – (up) Übertragung!
• Hohlwellenleiter aus Aluminiumfolie (blanke Seite innen, Durchmesser 4mm, geformt aus Küchenfolie um ein Stöckchen) – Die Übertragung war gut, auch ohne die LEDs besonders auszurichten, Hauptsache sie strahlen etwas in das Röhrchen.
• Messingröhrchen (Durchmesser 5mm, LEDs passen genau hinein, Länge 70cm; was man halt so rumliegen hat) – Gute Übertragung (up).
• Transparente Antistatikfolie dazwischen halten – stört nicht. (up)
• Verschiedene transparente Plastikdeckel stören nicht.

Will man prüfen und nachmessen wie die LEDCOMM-Verbindung arbeitet, ist etwas mehr Aufwanf nötig. Denn die Kapazität an so einer LED ist so winzig, das schon die Messleitung zum Oszilloskop deren Wert so verändert, dass die Schaltung nicht mehr funktioniert. Die Beobachtung muss also ebenfalls optisch erfolgen, ohne einen elektrischen Kontakt. Mit dem Phototransistor BPW40 in einfacher Schaltung ging das; beide R=10K. Die Fotos zeigen den Aufbau. Die Phototransistoren sitzen unter dem weißen Plastikstück das die Zimmerbeleuchtung abschirmte.

Am Oszilloskop kann dann das Verhalten des Phototransistor sichtbar gemacht werden. Doch mein altes Oszilloskop speichert nichts. Immerhin konnte ich so schon mal schätzen, dass da eine Übertragung von Pulsen mit einer niedrigen Frequenz so um die 100 und 300 Hz in Gange war, also im Audiobereich. So einen Frequenzbereich kann man noch bequem mit einem Soundcard-Oszilloskop ansehen. Eine preiswerte externe 2-Kanal Soundkarte diente als AD-Wandler (Behringer, U-Control UCA202; 48kHz Konverter). Auf diese Weise erhält man auswertbare Bilder.

Allerdings war die gute Empfindlichkeit des Phototransistors gleichzeitig das Problem. Er sieht jede Lichtquelle die in der Nähe ist, auch wenn diese seitlich oder von hinten in das klare Gehäuse kommt. Weil dieses Fremdlicht störte, war zunächst das Wechselspiel der LEDs auch damit nicht klar darzustellen.

Nach einigen Versuchen wurde dann aber eine Anordnung gefunden, in der die LEDCOMM-LEDs sich einerseits noch gut „sehen“ konnten, andererseits aber auch genug Licht an „ihren“ Phototransistor abgaben. Und der Phototransistor abgeschirmt genug war, um nur „seine“ LED zu sehen. Der Trick bestand darin die LEDs ganz knapp über eine weiße Wand hinweg sich anblinzeln zu lassen, während eine gute Portion ihres Lichtes von dieser Wand zurück in den Phototransistor geworfen wurde, der abgeschirmt in einem Messingröhrchen saß.

Es wurden die verschiedenen Zustände der ledcom registriert. Der Verbindungsaufbau, der DOWN- und UP-Zustand, und die Zeichenübertragung im UP-Zustand. Mit dem Scope war es leicht Ausschnitte im Signal zu finden die zeigen was da tatsächlich geschieht.

Wie dann ein Zeichen übertragen wird zeigt das nebenstehende Bild. Hier wurde ein großes U gesendet. Dazu wurde im Terminalfenster des sendenden LaunchPads einfach das U festgeklemmt. Von der Gegenseite wurde dies empfangen, man sieht deren Synchronisation in die Lücken des Zeichens. Auch hier wird die Zeit von rechts nach links gelesen, rechts die zeitlich älteren Pulse, links die jüngeren. Man sieht einen breitern Startpuls, dann die Abfolge schmal, breit, schmal, breit, schmal, breit, schmal. Es werden 7Bit übertragen.

Das U liest sich binär also so: Startbit, 1010101

Dieses Experiment verdanke ich ebenfalls Matthias Koch.

Das eine LED auch etwas Spannung erzeugt wenn sie beleuchtet wird, kann man am LaunchPad recht einfach zeigen. Auf der Platine ist eine kleine rote LED schon vorhanden, angeschlossen an Pin P1.0, der Vorwiderstand stört da nicht weiter. Macht man diesen Pin zum Eingang, kann man im Kanal-0 mit dem ADC10-Wandler dort nachschauen was passiert, wenn die kleine rote LED im Hellen oder Dunklen ist. Hier ein kleines Forthprogramm dazu: Rotauge. - das Forthwort ADC@ liefert den Messwert. Um den Hell-Dunkel-Effekt deutlich zu erkennen, kann man die superhelle rote LED, die im klaren Gehäuse aus dem Ledcomm-Experiment, gleich auch hier als Beleuchtung verwenden - das Bild zeigt den simplen Aufbau. Die Forthworte HELL und DUNKEL schalten die LED ein und aus.

Wie der Analog-Digital-Umsetzter ADC10 konfiguriert wird, bitte dem User Manual des MSP430G2553 entnehmen. Im Prinzip geht das so: Die gewünschten Eigenschaften des ADC einstellen, und dann per Software eine einzelne Conversion anstoßen. Dann das Ergebnis aus dem Register des ADC auf den Datenstack holen. Die kleine rote LED braucht etwas Zeit bis sich die Spannung am Eingang so aufbaut, dass deutliche Unterschiede erkennbar werden. Bei meinem Exemplar taten es 200ms.

Mehrere der Port-pins können zu Eingängen für die ADC-Kanäle gemacht werden, ein Pin je Kanal. Die MCU hat einen ADC10, d.h. die Spannung am Pin kann in 10Bit=1024 Stufen abgebildet werden. Für den Test wurde das ADC-Test-Programm in Forth benutzt. Es konfiguriert Pin P1.4 als Eingang für den 4. Kanal des ADC10, initialisiert ihn, und stellt das Wort ADC bereit, mit dem eine einzelne Konversion gestartet und ausgelesen werden kann.

Was an dem offenen Inputpin P1.4 passiert zeigt das Diargamm. Es werden schwankende Spanungswerte gefunden, die scheinbar wahllos auftreten - Rauschen. Ein Draht an diesem Pin erhöht die Schwankungen, besonders wenn man das blanke Ende anfasst. Die Stichproben wurden im Sekundentakt genommen. Schließt man den Draht an GND (Vss) an, misst man den Wert 0 . An Vcc findet man 1023 . Der Eingang arbeitet also korrekt. Die stark schwankenden Werte dazwischen sind also tatsächlich Rauschen auf der Leitung. Der Draht wirkt als Antenne.

Das Ganze in Zahlen.

Das Bild ändert sich wenn man einen Spannungsteiler anschließt. Der ADC-Wert stellt sich auf den Wert am Spannungsteiler ein, und die Schwankungsbreite der Werte wurde etwas geringer. Ein Tantal-Kondensator zwischen dem Eingang und Vss (Tiefpass) glättet das Rauschen noch weiter.

Es wurde R=10K gewählt. Ein Draht an P1.4 wurde abwechseln an Punkt x1 und Punkt x2 gehalten. Dabei wurden nachstehende Werte abgelesen.

Für die Konversion der Spannung am P1.4 in einen relativen digitalen Wert war der ADC10 so eingestellt, dass die interne Referenzspannung Vref = 2,5V als Bezug diente, und nicht Vcc ! Der ADC-Messwerte muss also auf 2,5V bezogen umgerechnet werden (Vadc). Das ergibt gegenüber dem Messwert eine lineare Abweichung nach unten, und man müsste einen Korrekturfaktor hinzunehmen, um den echten Wert zu erhalten. Da Vcc je nach Last an der MCU schwanken kann, wird auch der Messwert mitschwanken. Sodass statt Vcc eine stabilisierte und geeichte Referenzspannung nachmal besser wäre. Daher gibt es die Möglichkeit, die Referenzspannung der MCU auf einen Portpin nach außen zu schalten, und den Spannungsteiler mit Vref statt Vcc zu treiben. Das wurde hier jedoch weggelassen um das Prinzip zu zeigen.

Aus dem vorherigen Versuch lässt sich leicht ein Weiterer machen, mit dem ein Fotowiderstand (LDR) beobachtet werden kann. Ein Laserpointer diente als schaltbare punktgenaue Beleuchtung direkt auf den LDR. Der kleine Fotowiderstand stammte aus einer Grabbelkiste, no-name, billig. Seine Widerstandswerte bei verschiedener Beleuchtung waren:

Er spricht also gut auf Licht an. Damit lassen sich helligkeitsbezogene Anwendungen realisieren, wenn diese langsam genug erfolgen. Dieser LDR war gegenüber einem Fototransistor träge. Ein Versuch mit einer 220V-Glühbirne und Oszilloskop zeigte, das er den Helligkeitsveränderungen (Strahlungsveränderungen!) durch den 50Hz Wechselstrom eher ohmsch folgte. Birne näher ran, sinkender Pegel im Spannungsteiler; weiter weg, steigender Pegel. Aufgelagert war eine leichte Welligkeit mit 10ms Periode und 0,1V Amplitude, an der der Wechselstrom im Lichtsignal noch zu erkennen war. Also schon recht träge, aber in „Helligkeit“ über die Zeit ok. Ganz langsame Helligkeitsänderungen brauchen dann noch weitere Maßnahmen damit diese sicher erfasst werden - Richard S. LaBarbera, Intelligent Dusk/Dawn Light Sensor, Oktober 2006. 19 Seiten PDF - Freundlicherweise bereitgestellt von Matthias Koch.

Ersetzt man den Fotowiederstand durch eine https://de.wikipedia.org/wiki/ElektretmikrofonElektret-Mikrofonkapsel erhält man eine einfache Möglichkeit Schall aufzuzeichnen. Der Feldeffekt-Transistor der Mikrofonkapsel wirkt dabei wie ein schallempfindlicher Widerstand. Die Spannungsschwankungen können direkt mit dem ADC-Eingang erfasst werden. Es ist bei diesem Aufbau nicht nötig einen Kondensator dazwischen zu geben. Die Mikrofonkapsel stammte aus einem ausgemustertem USB headset, war also für die niedrige Spannung von 5V geeignet.

Die Abfrage des ADC10-Eingangs kann mit Forth einfach durchgeführt werden. Das kleine Testprogramm registriert den Spannungspegel als ganzzahligen Wert. Minimum und Maximum werden gespeichert. So kann die Amplitude, die eine Schallwelle am Spannungsteiler auslöst, ermittelt werden. Der verwendete Mikroprozessor wäre schnell genug die Schallwelle feiner abzutasten, hat aber nicht genug RAM um die Werte alle zu speichern. Hier ging es ja auch nur um das Prinzip, und das kann man schon erkennen wenn die Extremwerte registriert werden.

Im Beispiel „Händeklatschen“ ist schön zu erkennen wie die Amplitude sich mit dem Schalldruck ändert. Am ADC10 wurden dabei registriert:

test3
81 435 981 900 ok

Die Pegel lagen zwischen 81 und 981 was eine Differenz von 900 ergibt, der Messbereich war 0…1024. Es lässt sich also ein sehr deutliches großes Signal einfach finden. (Die Mikrofonkapsel war recht unempfindlich, man musste schon laut klatschen und auch ganz in der Nähe. Aber so ist es wohl gewollt bei solchen Mikrofonen aus einem headset.) Das Bild am Oszilloskop zeigt welche Pegel beim Händeklatschen entstanden sind. Die starken Ausschläge dauerten 6.95mS mit einer Spanungsschwankung von 2.72V.

\ mikrofon test  4e4th

\ ADC input Versuche

hex
01B0 CONSTANT ADC10CTL0
01B2 CONSTANT ADC10CTL1
01B4 CONSTANT ADC10MEM
004A CONSTANT ADC10AE0

0020 constant p1in
0021 constant p1out
0022 constant p1dir
0027 constant p1ren

bin
\ FEDCBA9876543210
\   1               SREF_1      1*0x2000 VREF+ and VR- 
\    1              ADC10SHT_2  2*0x800  16 x ADC10CLKs
\          1        REF2_5V     0x040    ADC10 Ref 0:1.5V / 1:2.5V 
\           1       REFON       0x020    Reference on
\            1      ADC10ON     0x010    ADC10 On/Enable 
0011000001110000  CONSTANT ADCSETUP

0000000000000010  CONSTANT ENC      \ Enable Conversion.
0000000000000001  CONSTANT ADC10SC  \ sample-and-conversion start.
0000000000000100  CONSTANT ADC10IFG
0100000000000000  CONSTANT INCH4    \ input chanel 4 <------------
00000001 CONSTANT BIT0
00000010 CONSTANT BIT1
00000100 CONSTANT BIT2
00001000 CONSTANT BIT3
00010000 CONSTANT BIT4
00100000 CONSTANT BIT5
01000000 CONSTANT BIT6
10000000 CONSTANT BIT7

: ADC-INIT
  adcsetup ADC10CTL0 !
  inch4 ADC10CTL1 !        \ input channel 4
  bit4  ADC10AE0  c! ;     \ Analog Input Enable P1.4 = CA4
: ADC+   1 ADC10CTL0 cset ;  \ Start ADC10  
: ADC-   1 ADC10CTL0 cclr ;  \ STOP ADC10 
: ADC \  -- adcmem       sample & convert once
  ENC ADC10SC +  ADC10CTL0 cset  
  BEGIN ADC10IFG ADC10CTL0 cget UNTIL adc10mem ;

hex  variable MINIMUM   variable MAXIMUM 

: INIT     
  bit4  p1dir cclr  \ P1.4 is input
  bit4  p1ren cclr  \ resistor disable
  bit4  p1out cset
  adc- adc-init adc+ 
  FFFF minimum !   0 maximum !  ;

decimal  
: range   ( n -- )
  dup minimum @ umin minimum !
  maximum @ umax maximum ! ;

: .adc
  minimum @ u. 
  adc @ dup u. range 
  maximum @ u. 
  maximum @ minimum @ - u. ;

: TEST      init page BEGIN  1000 ms page .adc  key? UNTIL ;
: TEST2     init page BEGIN          page .adc  key? UNTIL ;
: TEST3     init begin adc @ range key? until cr .adc ;

: .DATA   init 50 0  DO cr adc @ u. LOOP ;
: .DATA2  init 50 0  DO cr 100 ms adc @ u. LOOP ;

( finis )