microcontroller.net

  1. Schaltregler verursachen in der Praxis leider am meisten Probleme in elektrischen Schaltungen. Und zwar sowohl aus EMV-Sicht als auch innerhalb der Schaltung. Die folgenden Tipps können auf keinen Fall die einschlägige Literatur zu diesem Thema ersetzen, haben sich aber oft als sehr hilfreich erwiesen. Es handelt sich jedoch nicht um eine Einführung in die Funktionsweise oder gar um eine konkrete Auswahlhilfe für den „besten“ Schaltregler. Natürlich ist mir bewusst, dass bei einem Hobbyprojekt und leider auch bei vielen kommerziellen Lösungen kaum Wert auf ein sauberes Design gelegt wird, aber man kann die wichtigen Punkte trotzdem mal ansprechen:

    • Schaltregler haben prinzipbedingt eine schlechtere Transient Response als Linearregler. Die Ausgangsspannung schwankt also stärker bei Laständerungen. Daher auch aufpassen was beim Aufwachen eines leistungsfähigeren Mikrocontrollers aus dem Sleepzustand passiert ( = sprunghafte Änderung der Stromaufnahme).
    • Stepdownkonverter benötigen richtig dimensionierte und platzierte Eingangskondensatoren / Filter. Bei Aufwärtswandlern sind eher die Ausgangskondensatoren kritisch.
    • Bei Stepupkonvertern gibt es keinen Schutz des Eingangsspannungskreises gegen Kurzschlüsse am Ausgang. SEPIC, Ćuk und Zeta-Wandler haben dieses Problem nicht, brauchen aber zwei (einzelne oder, oft vorteilhafter, gekoppelte) Induktivitäten.
    • SEPIC, Ćuk und Zeta-Wandler sind sehr hilfreich bei Batterieanwendungen, weil die Ausgangsspannung über und unter der Eingangsspannung liegen kann. Zudem haben sie einen kontinuierlichen Eingangsstrom, also keine für die Batterie schädliche pulsförmige Stromaufnahme. Einen SEPIC-Wandler kann man einfach mit nahezu jedem Boost-IC und einer gekoppelten Induktivität aufbauen. ZETA-Wandler haben eine noch sauberere Ausgangsspannung.
    • Es ist empfehlenswert, am Ein- und Ausgang von Schaltreglern zusätzliche Plätze für zunächst nicht bestückte (SMD) Kerkos in verschiedenen Baugrößen bereitzuhalten. Damit können Störfrequenzen (mit schnellem Oszilloskop und einer sauberen Masseverbidung messen!) effektiv bekämpft werden.
    • Bei Buck-Boostkonvertern kann es kleinere Unstetigkeiten beim Übergang vom Buck (Stepdown) in den Boostbetrieb (Stepup) geben.
    • Die Wahl der Diode(n) bei Schaltreglern (schnell oder „weich“ schaltend) kann den entscheidenden Unterschied bei der EMV-Thematik bewirken.
    • Induktivitäten können einen harten Übergang in den Sättigungsbereich (i.A. feste Kerne) oder eine weiche Sättigungskennline mit sanften Übergang (i.A. Pulverkerne) haben. Die Sättigungskurven sind temperaturabhängig und der Abfall der Induktivität in der Sättigung kann zu Stabilitätsproblemen bei Schaltreglern führen.
    • Bis ca. 400kHz sind Eisenpulverkerne einsetzbar, darüber eher MnZn bzw. NiZn für sehr hohe Frequenzen (bis GHz-Bereich) verwenden
    • Induktivitäten haben oft einen spezifizierten Wicklungsanfang (mit Punkt gekennzeichnet). Diesen mit der elektrisch unruhigeren Spannung (z.b. Switch bei Spannungsreglern) verbinden, da die äußeren Lagen dann die Störungen potenziell besser abschirmen können.
    • Bei geschalteten Induktvitäten geschirmte Ausführungen bevorzugen. Eine Schirmung ist aber natürlich nie perfekt / vollständig.
    • Mehrere Schaltregler auf einer Platine sollten entweder synchronisiert (nicht bei allen Typen möglich) oder zumindest getrennt befiltert werden. Ansonsten kann es Probleme mit Mischfrequenzen (Beat Frequency) geben.
    • „Spread Spektrum“ Schaltregler verteilen ihre Störungen (oft leider auf Kosten der Effizienz) über einen breiteren Frequenzbereich, was die Einhaltung von Limits vereinfacht. Unterm Strich produzieren sie aber mehr Störungen und bei schlechter Ausführung sieht man die Modulationsfrequenz deutlich im Spektrum.
    • Schaltregler mit integriertem FET(s) sind i.A. "ruhiger", aber nur bis zu einer gewissen Stromstärke lieferbar. Bei externen FETs kann mit einem Gatewiderstand die Anstiegszeit eingestellt werden, um die Emissionen (auf Kosten der Effizienz) zu verringern.
    • Switched Capacitor Schaltregler (keine Induktivität) sind bei geringen benötigten Strömen (<100mA) aus EMV-Sicht eine sehr gute Alternative und sehr oft auch kompakter. Bei High-K Kerkos als schaltendem Element sollte man aber auf mögliche hörbare Töne aufpassen (Lautsprechereffekt).
  2. Das XTRX setzt, wie schon LimeSDR und LimeSDR mini, ebenfalls auf den LMS7002M. Davon abgesehen grenzt sich das XTRX durch mehr als nur die Schnittstelle von den beiden anderen Modellen ab.

    Software Defined Radios erlauben es, verschiedenste Aufgaben im Hochfrequenzbereich zu übernehmen und erfreuen sich nicht nur im Funkamateurbereich zunehmender Beliebtheit. Im Gegensatz zu klassischen Empfangs- und Sendekonzepten erfolgt hier der Großteil der Signalverarbeitung softwareseitig. Auf einen kleinen Frequenzbereich abgestimmte Analoghardware ist nicht vorhanden, wodurch die Geräte nicht auf einen Funkstandard beschränkt sind und so flexibel eingesetzt werden können.

    Beim XTRX kommt der LMS7002M in Kombination mit dem Xilinx Artix 7 35T zum Einsatz, wobei je zwei Empfangs- und Sendekanäle zur Verfügung stehen. Der Frequenzbereich erstreckt sich von 10 MHz bis 3,7 GHz. Sofern man Pegeleinbrüche in Kauf nehmen kann, sind es 100 kHz bis 3,8 GHz. Die Abtastrate liegt dabei zwischen 0,2 und 120 MSPS. Falls die vorhandenen Kanäle nicht reichen, lassen sich mehrere Module synchronisieren. Das ermöglicht etwa MIMO Anwendungen mit einer Vielzahl gleichzeitig genutzter Kanäle.

    Verbauen lässt sich das XTRX als PCIe-Erweiterung in fast jedem aktuellen Notebook, sofern genügend Platz vorhanden ist. Bedeutender ist aber sicher die Verwendungsmöglichkeit in eingebetteten Systemen. So gibt es vergleichsweise leistungsstarke Mainboards mit PCI-Schnittstelle bereits in pico-ITX Ausführung. PCIe Hubs sind als Nebenprodukt des Crypto-Minings ebenfalls leicht erhältlich, was besonders aufgrund der möglichen Synchronisation mehrere Module interessant ist.

    Als zusätzliche Besonderheit besitzt das XTRX einen eigenen GPS-Empfänger. Dieser ermöglicht es, das Referenztaktsignal anhand der hochpräzisen Zeitsignale des Ortungssystems nachzuführen. Hierdurch kann laut Projekt eine Frequenzstabilität der Referenz von weniger als 10 ppb[1] erreicht werden. Das Verfahren ist nicht neu und bei Frequenznormalen für die Laborausstattung durchaus etabliert. Bei üblichen SDR-Lösungen ist man aber auf die Verwendung eines solchen externen Frequenznormals angewiesen, falls man eine entsprechend hohe Stabilität benötigt.

    Interessenten können das Projekt auf Crowdsupply unterstützen, dabei werden 199 $ für ein Modul fällig, für den Versand nach Deutschland kommen weitere 10 $ dazu. Die Early-Bird-Variante für 179 $ war bereits in den ersten 10 Stunden nach Projektstart vergriffen.

    1. ^ parts per billion, also eine Abweichung um Miliardstel-Bruchteile der Frequenz
  3. Der FreeRTOS Kernel ist nun in der Version 10 verfügbar, gleichzeitig wurde das um IoT-Funktionalität erweiterte Amazon FreeRTOS vorgestellt. Mit Letzterem soll die Entwicklung von sicheren, auf Mikrocontroller basierenden Endgeräten erleichtert werden.

    Bei Amazon FreeRTOS handelt es sich um ein auf dem beliebten FreeRTOS-Kernel basierendes Betriebssystem, das Bibliotheken für vernetzte Geräte und deren sichere Internetanbindung bereitstellt. Unter anderem sollen so die Verschlüsselung und das Verwalten von Schlüsseln auf einfache Weise möglich sein. Weiter sind Bibliotheken zur Verwaltung von WLAN-Verbindungen vorhanden, in den kommenden Wochen soll noch ein Code-Signing-Feature hinzugefügt werden.

    Den Schritt, sich unter die Obhut von Amazon Web Services (AWS) zu begeben, begründet FreeRTOS-Gründer Richard Barry mit dem gestiegenen Aufwand, das vor 15 Jahren gegründete Projekt aufrechtzuerhalten. So sei es zuletzt immer schwerergefallen, den Wünschen der Nutzer bezüglich Support und Funktionsumfang nachzukommen. Mit AWS sei es möglich, dem Open-Source-Gedanken weiterhin gerecht zu werden und das Projekt auch für kommerzielle Nutzung kostenlos bereitstellen zu können.

    Der Kernel selbst wurde ebenfalls erweitert, so wurden in der aktuellen Version Stream und Message Buffer hinzugefügt. Neu ist auch die Lizenz, diese ändert sich von einer angepassten GPLv2 auf die MIT-Lizenz. Diese soll die Verwendung für Firmennutzer und OSH-Projekte vereinfachen. Der Kernel wird laut Projektgründer auch weiterhin ohne Zwang zur Nutzung von Amazon Web Services quelloffen verfügbar bleiben.

    Durch die Zusammenarbeit zwischen AWS und Chipherstellern stehen bereits Bibliotheken für verschiedene Entwicklungskits zur Verfügung. So eignen sich etwa das B-L475E-IOT01A Discovery Kit von ST, das CC3220SF-LAUNCHXL von TI und das LPC54018 IoT Module von NXP für den schnellen Einstieg.

  4. Kommenden Dienstag ist es so weit, der von Orbital entwickelte CubeSat startet von Wostotschny aus ins All. An Bord befinden sich vier Funkmodule, wobei zwei davon Funkamateuren weltweit zur Verfügung stehen werden.

    Amateurfunksatelliten dienen Funkamateuren als Brücke zur Kommunikation, können aber auch wissenschaftliche Experimente mit sich führen oder zu Testzwecken verwendet werden. In den vergangenen Jahren ist die Anzahl solcher Satelliten, oft in Form von miniaturisierten CubeSats, weiter gestiegen. Bei D-Star One handelt es sich um einen solchen CubeSat, der auf den digitalen Übertragungsstandard D-STAR (Digital Smart Technologies for Amateur Radio) setzt.

    Damit ist D-Star One der erste Satellit, der den Standard nutzt. Dieser erlaubt es, sowohl Sprache als auch Daten digital zu übertragen. Zwei der vier im Halbduplex-Modus betriebenen Funkmodule werden zur Telemetrie und Fernsteuerung genutzt, die beiden weiteren Module dienen dem Amateurfunk. Hier ist jeweils nur ein Modul aktiv, sollte es zu Ausfällen kommen, steht aus Redundanzgründen ein weiteres Modul zur Verfügung.

    Die Telemetriedaten können auf 435,7 MHz empfangen werden, die Downlink-Frequenz beträgt 435,525 MHz, die Uplink-Frequenz 437,325 MHz. Im Normalbetrieb befindet sich der Satellit in einem Energiesparmodus und ist so pro Minute 20 Sekunden empfangsbereit. Falls in diesem Fenster ein Signal detektiert wird, bleibt der Satellit für weitere 5 Minuten aktiv.

    Nähere Informationen zu D-Star One sind auf der Seite des Herstellers verfügbar, zudem gibt es ein Preisausschreiben. Hier muss eine ausgesendete Sprachnachricht empfangen und per eMail an den Hersteller gesendet werden, wobei die erste Mail gewinnt.

    Weitere Informationen:

  5. Clementine war ein Satellit der NASA, mit dem Sensoren und andere Komponenten einem Dauertest im Weltall unterzogen werden sollten. Der Satellit wurde am 25. Januar 1994 gestartet und ging aufgrund technischer Schwierigkeiten am 7. May 1994 verloren. Wie sich später herausstellte, hätten ein paar Zeilen Code für einen Watchdog die Mission retten können.

    Clementine hatte für rund zwei Monate erfolgreich den Mond vermessen. Sie verließ den Mondorbit, um zum nächsten Ziel, dem erdnahen Asteroiden Geopgraphos zu navigieren. Kurz darauf trat ein Fehler in einem der Boardcomputer auf, der die Steuerung des Satelliten behinderte, während eines der Triebwerke aktiv war. Die NASA versuchte 20 Minuten lang, die Kontrolle wieder zu erlangen, was aber erst durch einen Hardware-Reset erreicht wurde. Aber es war zu spät: Der Satellit hatte bereits seinen ganzen Treibstoff verbraucht und die Mission konnte nicht weitergeführt werden.

    Wie hätte ein Watchdog helfen können?

    Ein Watchdog ist ein Stück Hardware, welches entweder direkt in den Mikrocontroller integriert oder als eigenständiges Bauteil extern mit dem Mikrocontroller verbunden ist. Seine Aufgabe ist die Fehlerbehandlung (üblicherweise ein Hardware-Reset) wenn sicher angenommen werden kann, dass das System nicht mehr wie gewünscht ausgeführt wird. Die Hauptkomponente eines Watchdogs ist ein Zähler, der mit einem bestimmten Wert initialisiert wird und in Richtung 0 zählt. Anschließend ist die Software dafür verantwortlich, diesen Zähler immer wieder auf den Startwert zurückzusetzen. Sobald der Zähler den Wert 0 erreicht, wird ein Fehlerzustand angenommen und üblicherweise ein Reset durchgeführt. Der Watchdog ist damit die letzte Rettung wenn alles andere schief gelaufen ist. Es wäre auch die Rettung für Clementine gewesen.

    Wie wird der Watchdog gefüttert?

    Es ist nicht immer einfach, zu entscheiden, an welchen Stellen in der eigenen Software der Zähler zurückgesetzt werden muss (oft auch "Watchdog füttern" genannt). Entwickler müssen den Startwert des Watchdog-Zählers sehr genau wählen, damit der Watchdog bereits zuschlagen kann, bevor das System Schaden nimmt. In einfachen Applikationen ohne RTOS füttern Entwickler den Watchdog gerne in der main() Schleife. Das setzt voraus, dass der initiale Watchdog-Zählerwert größer ist, als die maximale Ausführungszeit der main() Schleife. Das ist meistens ausreichend: Während es für manche Systeme wichtig ist, dass sie sich sofort von einer Fehlersituation erholen, reicht es für andere System aus, dass sie nicht unendlich lang in dem Fehlerzustand verharren - und dieser Ansatz erfüllt die Aufgabe.

    Und wie funktioniert das mit einem RTOS?

    In einer komplexen Applikation mit einem RTOS kann es passieren, dass einzelne Threads nicht mehr ordnungsgemäß ausgeführt werden, während andere Threads noch laufen. Es kann aber auch Threads geben, für die es korrekt ist, wenn sie für längere Zeit nicht ausgeführt werden. Ein Netzwerk-Thread könnte z.B. für längere Zeit auf neue Nachrichten warten und bis zu deren Eintreffen nicht ausgeführt werden. Die Herausforderung besteht darin, eine Methode zu entwickeln, mit welcher der Watchdog gefüttert wird, sodass sichergestellt ist, dass jeder einzelne Thread noch korrekt ausgeführt wird. Dabei müssen die folgenden Anforderungen erfüllt werden:

    1. Wird das RTOS noch korrekt ausgeführt?
    2. Gibt es hochpriore Threads, die zuviel Rechenzeit verbrauchen und damit verhindern, dass niedrigpriore Threads ausgeführt werden?
    3. Verhindert ein Deadlock die Ausführung einzelner Threads?
    4. Werden alle Threads vollständig und korrekt ausgeführt?
    5. Die Implementierung und die nötigen Änderungen an der Applikation müssen Ressourcen sparend und möglichst wenig intrusiv sein.

    Eine Methode zur Lösung dieser Aufgabe muss also jeden Thread einzeln überwachen. Wird festgestellt, dass ein Thread nicht mehr korrekt ausgeführt wird, können verschiedene Aktionen ausgeführt werden: Manche Applikation müssen, bevor ein Reset durchgeführt wird, das System in einen sicheren Zustand bringen. Das kann z.B. bedeuten, dass ein Ausgang gesetzt wird, um ein Ventil zu schließen. Anschließend kann der eigentliche Reset durchgeführt werden, der durch das Ablaufen des Watchdog-Zählers oder manuell ausgelöst werden kann. Für Letzteres besitzen viele Mikrocontroller ein dediziertes Register.

    Eine einfache Implementierung könnte ein Bitarray vorsehen, mit je einem Bit für jeden Thread. In einem festen Zeitintervall wird geprüft, ob alle Bits gesetzt sind. Falls ja, werden alle Bits gelöscht und der Watchdog gefüttert. Andernfalls wird ein Reset durchgeführt. Ein laufender Thread setzt hierzu sein Bit in dem Bitarray. Damit weiß das System, ob in einem Zeitintervall alle Threads mindestens einmal ausgeführt worden sind.

    #define THREAD1     (1u << 0)
    #define THREAD2     (1u << 1)
    #define THREAD_ALL  (THREAD1 | THREAD2)
    
    char WatchdogFlag;
    
    void Thread1(void) {
      while (1) {
        WatchdogFlag |= THREAD1;
        DoSomething()
        Delay(50);
      }
    }
    
    void Thread2(void) {
      while (1) {
        WatchdogFlag |= THREAD2;
        DoSomethingElse()
        Delay(200);
      }
    }
    
    __interrupt void TimerInt(void) {
      if (WatchdogFlag != THREAD_ALL) {
        PerformCPUReset();
      } else {
        WatchdogFlag = 0u;
        FeedWatchdog();
      }
    }
    

    Diese Methode hat den Nachteil, dass das Zeitintervall auf die maximale Ausführungszeit des längsten Threads eingestellt werden muss. Aus diesem Grund bieten moderne Betriebsysteme, wie etwa SEGGER RTOS embOS, die Möglichkeit, über eine einfache Watchdog-API für jeden Thread eine spezifische Ausführungszeit zu definieren.

    void Thread1(void) {
      OS_WD_Add(&WatchdogHP, 50);
      while (1) {
        OS_WD_Trigger(&WatchdogHP);
        DoSomething()
        OS_Delay(50);
      }
    }
    
    void Thread2(void) {
      OS_WD_Add(&WatchdogLP, 200);
      while (1) {
        OS_WD_Trigger(&WatchdogLP);
        DoSomethingElse()
        OS_Delay(200);
      }
    }
    
    __interrupt void TimerInt(void) {
       OS_WD_Check();
    }
    

    Schlussfolgerung

    Schon in der Anfangsphase eines Projektes sollte ein Watchdog in Betracht gezogen werden - und die Werkzeuge, die einem bei dieser Aufgabe helfen können. Denn wer will schon im Weltall verloren gehen?