Bei meinem Basteleien ergibt sich gelegentlich die Aufgabe, den zeitlichen Verlauf eines oder mehrerer Messwerte (meist Spannungen) anzuzeigen/aufzuzeichnen. Sind die Verläufe der Messwerte periodisch, und der zeitliche Messbereich liegt im Bereich von Milli- bis Mikrosekunden, lässt sich das recht einfach mit einem –bei jedem (einigermassen ausgestatteten) Elektronikbastler vorhandenen– Oszilloskop bewerkstelligen. Bei einmaligen Vorgängen wird jedoch schon ein Speicheroszilloskop benötigt... Aber wie sieht es denn aus, wenn es sich um sehr langsame Verläufe und damit um Aufzeichnungbereiche von Minuten (oder gar Stunden) handelt? In Ermangelung eines DSOs (Digitales Speicher Oszilloskop) oder eines entsprechenden "Datenloggers" habe ich somit die ersten Entladungskennlinien von Akkus (mein zu der Zeit aktuelles Experimentiergebiet) mit Hilfe von Multimeter, "Küchentimer", Bleistift und Papier aufgenommen, die aufgezeichneten Daten in den PC übertragen, und mir dann die entsprechenden Kurvenverläufe darstellen lassen -> Ein mühseliges, zeitraubendes, fehleranfälliges, und nicht besonders effektives/genaues Verfahren... Diese stumpfsinnige Tätigkeit lässt sich doch bestimmt auch einem PIC mit A/D-Wandler übertragen...

Die Datenübertragung

Wie sollen die Messdaten (die hier vorhandenen PICs enthalten A/D-Wandler mit einer Auflösung von 10 Bit) zum PC übertragen werden? USB wäre ja "modern" (und würde eine Stromversorgung bieten), aber die von mir hauptsächlich verwendeten (8beinigen) PICs haben kein direktes Interface zu USB. Ausserdem verfügen diese Chips nur über einen kleinen Speicherbereich (maximal 200 Byte). "Dickere" PICs haben zwar mehr Speicher, fressen aber auch mehr Platz und Strom. Ausserdem müsste ich bei einer "Langzeiterfassung" dauernd den PC laufen lassen -> Ineffektiv, zu hoher (und unnötiger) Energiekonsum. Also: "Klassisch seriell", denn dann kann ich statt des ständig laufenden PCs auch meinen guten alten "seriellen Druckerpuffer" (256kByte, Energieverbrauch ca. 5W) zur Zwischenspeicherung der Messdaten verwenden.

Die Stromversorgung

Da der Messadapter möglichst unabhängig von einer externen Stromversorgung arbeiten soll, und der vorgesehene PIC-12F675 recht sparsam im Stromverbrauch ist, bietet sich Batteriebetrieb an. Jedoch eine serielle Schnittstelle nach RS-232 benötigt eine negative Spannung. Ein üblicher Interface-Chip vom Typ MAX232 (der diese Spannung aus +5V erzeugt) verbraucht aber mindestens 4mA, das wäre das Doppelte des Stromverbrauchs des PICs. Bestimmt existieren auch ähnliche Chips, die den Pegel nur eines seriellen Kanals wandeln und weniger Strom verbrauchen, nur die sind dann wieder schwer zu beschaffen... Also entwickle ich mir lieber selbst einen Pegelwandler. Die ganze Schaltung soll sowieso "recht klein" ausfallen, somit bietet sich eine 9V-Blockbatterie (oder ein entsprechender Akku) an. Da der PIC (incl. A/D-Wandler) bei der Verwendung des internen Oszillators ab 3V arbeitet, und für die Referenz des A/D-Wandlers auf jeden Fall eine stabilisierte Betriebsspannung benötigt, liegt es doch nahe, die "restliche" Spannung zu den 9V als negative Spannung für die serielle Schnittstelle zu verwenden. Damit liegt zwar der Minuspol der Batterie nicht mehr auf "Masse", aber bei Batteriebetrieb ist das ja auch nicht notwendig... Die nebenstehende Schaltung erzeugt ein "passendes Massepotential", indem sie den Pluspol der Batterie genau so weit verschiebt, daß sich eine stabilisierte Spannung von ca. 4.5V (abhängig von den Kennlinien des FET) für den PIC ergibt. Der "Rest" der 9V dient zur Erzeugung der negativen Spannung für die serielle Schnittstelle (und schwankt ggf. abhängig von der Batteriespannung). Das Ganze funktioniert natürlich nur, wenn ein Stromverbraucher (der PIC) an der positiven Betriebsspannung (gegen "Masse") angeschlossen ist... Der PIC benötigt (je nach "Aktivität") 1-2mA, diese Stabilisierung etwa 200µA, und der "serielle Treiber" (beim Senden von Daten) nochmal etwa 1mA. Im Mittel sollte der Stromverbrauch also bei weniger als 2mA liegen, womit ein 9V-Akku mit 150mAh mindestens 3 Tage lang "halten" sollte, eine Batterie vermutlich sogar noch länger. Achtung: Der für R9 (und/oder auch R3) zu verwendende Wert ist abhängig von der Kennlinie von T2 und muss ggf. angepasst werden: Die Spannung über R9 sollte knapp 2V betragen, die Spannung über R3 etwa 5.1V.

Das Steuerungsprogramm

Der erste Ansatz zu diesem Messadapter ergab sich aus einer Problemstellung, bei der es darum ging, einige Messwerte in Intervallen von einer Sekunde aufzuzeichnen und davon Kurven in einem Diagramm zu erstellen. Da zwischen den Messungen mehr als genügend "Rechenzeit" vorhanden war, entschloß ich mich (im Gegensatz zu dem Verfahren bei meinem Solarwandler), die Daten gleich im PIC in dezimale ASCII-Ziffern umzurechnen. Das ersparte mir ein zusätzliches Skript/Programm zur Datenumwandlung. So konnte ich die mit einem Terminalprogramm aufgezeichneten/gepeicherten seriellen Daten direkt an Gnuplot "verfüttern", welches mir (mit Hilfe einiger weniger Skriptzeilen) daraufhin die gewünschten, "fast präsentierbaren" Diagramme erzeugte. Danach wanderte die Konstruktion (wie viele der von mir enwickelten "temporären Problemlösungen") in den Karton mit der Aufschrift "Zum Ausschlachten". Da sich bei einem der folgenden Projekte eine ähnliche Aufgabe ergab, kramte ich die Schaltung wieder hervor, passte das "hartcodierte" Progamm auf die neue Anforderung an, erledigte damit die notwendigen Messungen, und packte den Prototypen wieder zurück in den Karton. Nachdem ich den Adapter das dritte Mal "wiederbelebt" hatte, fiel mir mir auf, daß diese kleine Schaltung anscheinend doch ein sehr nützliches Hilfsmittel ist, welches durchaus mehrfach verwendbar ist. Nur das Umprogrammieren auf die jeweils neuen Anforderungen war dabei ziemlich lästig. Also war es notwendig, die hartcodierten Parameter (das Messintervall und die Anzahl der zu messenden Kanäle) irgendwie "einstellbar" zu machen. Wie soll das denn gehen, wenn sämtliche I/O-Pins des verwendeten PICs bereits mit A/D-Eingängen, serieller Ausgabe und Reset belegt sind? Nach intensiven Lesens des Datenblatts des PICs fiel mir auf, daß ein separates Reset-Signal nicht unbedingt notwendig ist, falls die Betriebsspannung einigermassen stabil ist. Ok, mit der (in diesem Fall wohl zulässigen) "Zweckentfremdung" des Reset-Pins ergab sich ich die Möglichkeit einer "Benutzereingabe" mittels eines Tasters. Und für die Informationen, die vom Programm zum Anwender gehen sollten, konnte ich ja die bereits vorhandene serielle Schnittstelle verwenden.

Das "Konfigurationsmenü"

Damit der Messadapter auch ohne "Interaktion mit dem Benutzer" (z.B. angeschlossen an einem Datenpuffer) einsetzbar bleibt, wird der Programmteil zur Konfiguration nur ausgeführt, wenn beim Einschalten der Betriebsspannung der Taster gedrückt ist. Andernfalls beginnt sofort die Messung mit den zuletzt eingestellten (und gepeicherten) Parametern. Das minimale Menü zeigt nacheinander die aktuell eingestellten Werte für die serielle Geschwindigkeit, die Anzahl der zu messenden Kanäle, und das Messintervall an. Ein kurzer Tastendruck (<300ms) wird als Bestätigung ("ja") angesehen, und es geht mit dem nächsten Menüpunkt weiter. Ein langer Tastendruck (>300ms, "nein") fordert das Programm zu einem anderen Vorschlag für den aktuell einzustellenden Wert auf. Wurden alle auf diese Weise einstellbaren Werte bestätigt, erscheint noch die Frage "OK?". Wird auch diese Frage bestätigt, werden die evtl. geänderten Werte gespeichert und zur Programmausführung gesetzt (ggf. wird auch die serielle Geschwindigkeit geändert). Danach beginnt der Messvorgang. Wird die letzte Frage nicht bestätigt (langer Tastendruck), beginnt das Menü wieder von vorne. Wird vor der Bestätigung der Frage "OK?" die Spannungsversorgung der Schaltung unterbrochen, bleiben die urspünglichen Einstellungen erhalten. Da bestimmte Kombinationen von Geschwindigkeit, Kanalanzahl und Messintervall nicht möglich sind (-> Die serielle Ausgabe der Daten dauert länger als das Messintervall), werden diese Intervalle mit der Angabe "too short" angzeigt, und sofort der nächstmögliche Wert vorgeschlagen. Um die Anzahl der zu übertragenden Daten zu reduzieren, habe ich im Zuge des Einbaus dieses Menüs auch gleich die Begrenzung eines Messwertes auf drei Stellen (also max. "999") vorgenommen. Der A/D-Wandler kann zwar Werte bis 1023 erzeugen, jedoch wäre dafür für jeden Messwert ein weiteres (meist ungenutztes) Zeichen zu übertragen. Die dadurch entstehende Einschränkung des Messbereichs beträgt ausserdem nur etwa 2%.

Bei diesem Beispiel sind die Tastenbetätigungen als farbige Balken eingefügt: Rot = lang Grün = kurz Die aktuelle Einstellung war 19200Bd, 1 Kanal, 5ms Intervall. Die neue Einstellung ist 9600Bd, 4 Kanäle, 1s Intervall.

Das "OSCCAL"-Problem

Da der PIC mit seinem eingebauten 4MHz-Oszillator betrieben wird, sind alle Intervalle (u.a. auch die Taktrate der seriellen Daten) von dieser Oszillatorfrequenz abhängig. Diese Frequenz ist jedoch u.a. von der Betriebsspannung und der Temperatur abhängig. Um Toleranzen bei der Chipfertigung kompensieren zu können, hat der Hersteller der PICs eine Möglichkeit vorgesehen, die Oszillatorfrequenz mit Hilfe des Inhalts einer Speicherstelle (eines Registers names "OSCCAL") "abzugleichen". Nach der Fertigung der Chips wird eine spezielle Funktion in den Programmspeicher "gebrannt", die beim Aufruf aus dem PIC-Programm den chipspezifischen Abgleichwert (für 5V Betriebsspannung und 20° Umgebungstemperatur) als Ergebnis liefert. Ein PIC-Programm, welches "zeitkritisch" arbeitet, sollte daher beim Start diese Funktion aufrufen, und das Ergebnis in das OSCCAL-Register schreiben. Danach ist davon auszugehen, daß der interne Oszillator "abgeglichen" ist. Wird der PIC jedoch mit einer anderen Spannung als 5V betrieben (und/oder bei einer anderen Temperatur als 20°), muss dieser Wert nicht mehr unbedingt "richtig" sein... Ausserdem überschreiben viele Programmer (Hard- und Software zum "Brennen" eines Programms in den PIC) die spezielle Funktion zur Ermittlung des Abgleichwertes... Mir fiel bei einer Messung mit vielen Messintervallen auf, daß das Produkt aus der Anzahl und der Dauer der Messintervalle doch etwas von der Gesamtzeit der Messung differierte. Also musste ich in meinem Konfigurationsmenü noch eine Möglichkeit zur Kalibrierung des internen Oszillators des PICs schaffen. Nur wo sollte ich denn das dazu notwendige Kalibrierungssignal ausgeben? Nach einigem Überlegen habe ich mich dazu entschlossen, dafür ebenfalls den Pin, der die serielle Schnittstelle ansteuert, zu verwenden (der zweckentfremdete Reset-Pin könnte durch die Taste kurzgeschlossen sein, und die analogen Eingänge könnten ebenfalls "irgendwie verschaltet" sein). Die Ausgabe eines 1kHz-Signals für fünf Sekunden erzeugt zwar ggf. eine Menge "seltsamer Zeichen" in dem zum Abgleich verwendeten Terminalprogramm, aber es kann dabei "nichts kaputtgehen". Da der Abgleichwert aus sechs Bits besteht, und ein "Durchprobieren" der sich daraus ergebenden 64 Möglichkeiten ein ziemlich langwieriges Verfahren darstellen würde, habe ich mich entschlossen, diese Einstellmöglichkeit auf zwei mal drei Bit (jeweils acht Möglichkeiten) aufzuteilen (->OscH und OscL), wobei erst eine Grob- und dann die Feineinstellung erfolgt.

Der Kalibrierungsvorgang

Auch in diesem Beispiel sind die Tastenbetätigungen als farbige Balken eingefügt: Rot = lang Grün = kurz Deutlich erkennbar sind die durch das Kalibrierungsignal verursachten "seltsamen Zeichen".

Um den korrekten OSCCAL-Wert zu ermitteln (und einzustellen), ist an Pin 2 des PICs (oder an dem entsprechenden Signal an R8) ein Zähler (oder auch ein Oszilloskop) anzuschliessen. Nach dem Einschalten (Taste dabei gedrückt halten) des Messadapters sollte im Terminalprogramm der Text "OscH" und ein Wert zwischen null und sieben angezeigt werden. Erscheinen nur "seltsame Zeichen", stimmt entweder die serielle Geschwindigkeit des Terminalprogramms nicht mit der Geschwindigkeit des Messadapters überein (der Standardwert ist 9600Bd), oder die Kalibrierung "liegt völlig daneben". In einem solchen Fall ist es zu empfehlen, die Taste "lange" zu drücken, und das (nach Loslassen der Taste) für fünf Sekunden erzeugte Kalibrierungssignal (sollte 1kHz betragen) zu messen, und dabei die Ausgabe im Terminalprogramm einfach zu ignorieren. Nach jedem langen Tastendruck ändert sich die ausgegebene Frequenz ein wenig. Bei mindestens einer der acht möglichen Einstellungen sollte am Ende des angezeigten "Datenmülls" der Text "OscH" und eine Ziffer lesbar sein. Ist das nicht der Fall, stimmt die Einstellung der Datengeschwindigkeit am Terminalprogramm nicht. Der "lesbare" Wert (ggf. ±1) ist der richtige Wert für die Einstellung "OscH". Nach einem kurzen Tastendruck erfolgt nun die Feineinstellung, bei der der Text "OscL" (und eine Ziffer) fast immer lesbar bleiben sollte. Auch hierbei sind wieder acht verschiedene Einstellungen möglich, wobei die Einstellung gewählt werden sollte, bei der das Kalibrierungssignal möglichst genau 1kHz beträgt. Nach einem kurzen Tastendruck ist die Kalibrierung abgeschlossen (jedoch noch nicht gespeichert), und das Menü bietet die Einstellmöglichkeiten für serielle Geschwindigkeit, Kanalzahl, und Messintervall an. Nach Bestätigung der Frage "OK?" mit einem kurzen Tastendruck werden alle konfigurierten Werte (also auch die Werte der Frequenzkalibrierung) gespeichert und dieser etwas umständliche (und hoffentlich einmalige) Abgleich ist abgeschlossen. Bei einer gewünschten Änderung der Messparameter (Einschalten, während die Taste gedrückt ist) sind die beiden ersten Parameter ("OscH" und "OscL") einfach mit einem kurzem Tastendruck zu bestätigen, und die weiteren Parameter können ohne Änderung der Kalibrierung verstellt werden.

Bekannte Eigenarten ("Known Bugs") des Prototypen

Der nachträglich eingefügte Taster ist an R1 angeschlossen worden. Unterhalb der Platine wurden ein Batteriehalter und ein Schalter für die Betriebsspannung angeklebt.

Daß der Prototyp einer neuen Schaltung meist einige "Eigentümlichkeiten" aufweist, wird bestimmt jedem Entwickler bekannt sein. Hier die mir bekannten "unschönen Effekte" dieser Schaltung, die mir beim Betrieb aufgefallen sind: Da aufgrund der Nutzung des Reset-Eingangs für die Eingabetaste keine "ordentliche" Reset-Schaltung mehr existiert, bewirkt ein kurzes Aus- und Einschalten nicht immer einen "sauberen" Neustart des Steuerungsprogramms. Die Ausschaltdauer sollte lang genug (>10s?) sein, um ein sicheres Entladen der beiden Elektrolytkondensatoren zu ermöglichen. Im ausgeschaltetem Zustand besteht bei beschalteten Messeingängen die Möglichkeit, daß sich C1 über die Schutzdioden an den Eingängen aufläd. Dadurch entsteht eine unerwünschte (und schlecht kontrollierbare) "Betriebsspannung" des PIC, die einen "definierten" Reset beim Einschalten verhindert. Daher sollten die Messeingänge erst nach Einschalten des Messadapters angeschlossen werden. Eine zu hohe Spannung (>5V) a einem der Messeingänge während des Betriebs kann ebenfalls zu einer zu hohen Betriebsspannung des PICs führen, und diesen ggf. sogar zerstören.

Das "Material"

Schaltplan (V0.1) im Eagle-Format
Layout (V0.1) im Eagle-Format
Quellcode (V0.2) des Steuerungsprogramms (unter GPL2)
Hexcode (V0.2) des Steuerungsprogramms (unter GPL2)

Hinweise für Nachbauwillige

Um den Prototypen dieses Adapters nachzubauen, sind Möglichkeiten der Herstellung einseitiger Leiterplatten und Programmierung des verwendeten Microcontrollers notwendig. Es handelt sich hierbei nicht einen Bausatz, sondern eher um eine Anregung zu eigenen Konstruktionen. Alles, was ich dazu anbieten kann, befindet sich auf dieser Seite, d.h. Nachfragen nach Bausätzen, fertigen Leiterplatten oder programmierten PIC-Controllern sind zwecklos → Ich "produziere" ausschliesslich für Eigenbedarf.

Für der Funktionalität und Nachbausicherheit dieser Schaltung kann ich keinerlei Verantwortung übernehmen. Eine kommerzielle Verwendung des Schaltplans oder des Layouts ist nur mit meiner ausdrücklichen Genehmigung zulässig. Das PIC-Programm unterliegt der GNU Public License Version 2.

Startseite  Hardware  Rechtliches  Kontakt  Darstellung