Januar | 2017 | www.dreimeisen.de

Zum schnellen Debuggen von Controllerprojekten habe ich auf o.g. Entwicklungsbrett vor einiger Zeit mal eine Anwendung programmiert, um über ein serielles Protokoll (1 Leitung und Masse) verschiedenste Daten während der Programmerstellung oder für Tests sichtbar machen zu können. Hierbei können selbst kleinste Controller mit kleinem Programmspeicher und wenig oder gar keinem RAM (ATTiny13, ATTiny10…) ohne viel Aufwand an einem beliebigen I/O-Pin Daten senden und das XMINILAB macht diese auf seinem OLED sichtbar. Die Routinen zur Ausgabe sind beispielsweise in diesem Projekt enthalten:

Ladegerät-Tuning für Motorola T80/T81

Infos über das XMINILAB gibt es hier:

http://www.gabotronics.com/development-boards/xmeg…

Die Einspeisung des Signal findet an Pin „EXT“ des XMINILAB statt, der gegenüber Masse positiv sein muss.

Auf dem Foto ist eine Beispielausgabe zu sehen.

Die Datenübergabe kann HEX, DEZIMAL und ASCII sein, außerdem kann man auf die UART des XMINILAB routen und den Bargraf am rechten Rand mit 8 Bit füllen, um schnelle Signale eines einzelnen Bytes zu sehen. Vielleicht hat jemand Lust, sich das Ganze auf sein angestaubtes XMINILAB zu spielen… 😉

Ich benutze den Sniffer so gut wie jeden Tag, beruflich und auch privat.

Hier die Spezifikation zur Erzeugung des Datensignals beim sendenden Controller:

1. Displaypin Spezifikation:

– 0->1->0->1 – Pulsbreite: jeweils >=1µs bis maximal 30µs, symmetrisch!
– Startbit: 3 Flankenwechsel -> Pause
– Logisch 1: 2 Flankenwechsel -> Pause
– Logisch 0: 1 Flankenwechsel -> Pause

Pause zwischen Bits: >=5µs, jedoch mindestens 2,5-fache Pulsbreite
Pause zwischen Bytes: >=30µs

Die Pulse eines Bits dürfen nicht wesentlich jittern.
Pausen zwischen den Bits sind unkritisch und können vom Sender gestreckt werden. Gleiches gilt für Pausen zwischen Bytes.

Laufzeit für ein komplettes Zeichen inklusive Header und Adresse bei Minimal-Timing: ~180µs

Die Polarität der Daten ist irrelevant.
Der Pegel bleibt auf dem letzten Pegel eines Datenframes stehen, bis ein neuer Frame kommt.
Man kann hier wunderbar die Pin-Toggle-Funktion nutzen, die viele Controller von Haus aus bieten.

2. Datenformat:

2.1. Header

0000 LCD, HEX Daten
0001 LCD, DEZ Daten
0010 LCD, ASC Daten
0011 reserviert

0100 LED
0101 reserviert
0110 reserviert
0111 reserviert

1000 RS232, HEX Daten
1001 RS232, DEZ Daten
1010 RS232, ASC Daten
1011 reserviert

1100 reserviert
1101 reserviert
1110 reserviert
1111 reserviert

2.2. Adresse

xxxx xxxx absolute Position auf dem LCD oder in der UART-Zeile

2.3. Datenbyte

xxxx xxxx Nutzdaten, die dargestellt werden sollen

2.4. Aufbau Datenframe

LCD: Startbit, Header (4Bit), Adresse (8Bit, 0x00-0xFF), Datenbyte (8Bit)
RS232: Startbit, Header (4Bit), Adresse (8Bit, 0x00-0x27), Datenbyte (8Bit)
LED: Startbit, Header (4Bit), Adresse (8Bit, 0x00), DatenByte (8Bit, LLLLLLLL, 1 Bit pro LED)

Download:

Firmware für das XMINILAB:

Xminilab_Sniffer_XM32A4U_ATM6

Vor einiger Zeit habe ich mir einen Satz PMR-Funken T80 Extreme von Motorola zugelegt. Mit den Teilen bin ich für meine Anwendungen voll zufrieden. Die mitgelieferten Ladegeräte mit je 2 Ladeschalen sind allerdings etwas old-school und besitzen weder eine Abschaltung noch eine Anzeige dafür, wenn die Akkus voll geladen sind.

Das war mir zu wenig und so habe ich mich daran gemacht, die originale „Ladeschaltung“, die aus 2 60mA-Konstantstromquellen besteht, durch etwas mehr Intelligenz zu ersetzen. Herausgekommen ist eine Schaltung, die in das originale Ladegerät passt (nur kleine Modifikationen am Kunststoff-Innenleben sind nötig) und mit dem originalen Stecker-Schaltnetzteil verwendet werden kann. Die Features sind im Moment:

– Einzelschachtüberwachung
– Automatischer Ladestart beim Einsetzen des Funkgerätes in den Ladeschacht
– Δ-U Abschaltautomatik mit Timer, Konstantstromladung
– Ladezustandsanzeige mit 1 RGB-LED pro Ladeschacht (rot: Slot leer, blau: Laden, grün: Akku voll)
– Ladestrom 100mA statt 60mA original, schnelleres Aufladen bei besserer Ausnutzung des Steckernetzteils
– Schaltreglerprinzip anstelle Linearkonstantstromquelle, besserer Wirkungsgrad
– Echtzeitdebugging über MOSI-Pin (proprietäres Protokoll), default abgeschaltet

Als Rechen- und Messknecht kommt ein Tiny44A zum Einsatz, der genügend Speicherreserven für künftige Erweiterungen bietet. Ein Tiny24A oder -84A kann ebenfalls verwendet werden. Die Weichware ist in ASM und momentan noch recht rudimentär (weil ich das Zeug gerade dringend brauche).

Schaltplan