Dienstag, 7. Juni 2016

Portfolio Komplettumbau, Teil 1

Ich habe jetzt einige Zeit nichts geschrieben, aber war nicht untätig.
Es sind einige Modifikationen für den Portfolio zusammen gekommen, die ich hier nach und nach vorstellen will. Los geht es mit:

Teil 1: RAM-Erweiterung

Schritt 1.1: Zerlegen
Den Vorgang beschreibe ich nun nicht genauer, es gibt bereits mehrere Anleitungen. Man muß jedenfalls das Mainboard komplett ausbauen.

Schritt 1.2: Auslöten
Dafür benutze ich die etwas gröbere Lötspitze. Zuerst wollte ich die Platine abkleben und jeweils eine ganze Seite des jeweiligen Chips am Stück auslöten. Das hat sich aber als sehr unpraktisch erwiesen, so das ich mich doch entschieden habe die Pins einzeln abzulöten. Dafür hat es sich als zweckmäßig erwiesen von außen nach innen vorzugehen, so das man die Pins in der Mitte des Chips zuletzt ablötet. Dadurch wird einerseits die thermische Belastung der Platine minimiert, und zudem ist das Risiko geringer das man den Chip versehentlich verdreht und dabei Lötpads beschädigt. Beim Auslöten muß man extrem vorsichtig vorgehen.


Trotz großer Sorgfalt haben sich bei mir einige Pads gelöst. Zum Glück ist jedoch keines abgerissen. Nachdem alle vier RAM Chips ausgelötet waren, habe ich festgestellt, das C20 und C21 etwas zu nah an der Position von U7 liegen, und man den Chip nicht ganz auf die Pads bekommt. Daher habe ich
diese SMD-Kondensatoren auf ihren Lötpads ein Stück verschoben um genügend Platz zu schaffen.
Nachdem man auf die gleiche Weise auch U11 (Adress-Decoder) auf der anderen Seite der Platine ausgelötet hat, ist es schon fast geschafft. Wenn man gleichzeitig noch den CF-Steckplatz einbauen will, ist es empfehlenswert gleich noch den Steckplatz für die originalen Speicherkarten zu entfernen. Die etwas längeren Pins kann man ähnlich wie die der Speicherchips auslöten, die kürzeren habe ich einfach direkt an der Platine abgezwickt.

Hinterher habe ich das jedoch bereut. Es wäre sinnvoll auch diese einzeln auszulöten, damit der Sockel weitgehend unbeschädigt bleibt. Der könnte später noch für ein anderes Projekt interessant werden.

Danach ist es Zeit die Lötspitze zu wechseln, für das einlöten und verschalten der neuen Bauteile empfiehlt sich eine möglichst feine Lötspitze. Je dünner desto besser.
In der Zwischenzeit muß man noch einige Pins des neuen RAM-Chips mit äusserster Vorsicht hoch biegen. Das sind genau Pin 1, 2, 22, 30, 31 und 32. Alle anderen Pins werden wir gleich direkt auf die Pads von U7 auflöten. Wenn man schon dabei ist, kann man auch die Pins des 1MB Chips hoch biegen. Ich nehme dafür eine kleine Flachzange, setze sie direkt am Rand des Chips an und drücke die Pins flach. Das geht recht einfach und mir ist dabei noch nie ein Pin abgebrochen.

Schritt 1.3: Einlöten
Verglichen mit dem vorherigen Schritt ist das Einlöten des neuen Chips eine Kleinigkeit. Man
muß nur sehr vorsichtig sein beim Dosieren des Lötzinns, damit man keine Kurzschlüsse verursacht. Und natürlich muss man darauf achten das die zuvor hoch gebogenen Pins keinen Kontakt zur Platine bekommen. Vom 74HC21 biegen wir dann auf der linken Seite alle Pins bis auf den untersten (GND) etwas hoch, und auf der rechten Seite den obersten (Vcc). dann befestigen wir ihn mit einem kleinen Stückchen doppelseitigem Klebeband auf der Platine. Und zwar so, das der Massepin auf dem Massepad von U5 liegt.

Nachdem dieser Pin angelötet ist, verbinden wir zuerst die Betriebsspannung mit dem Vcc-Pin von
U14 oder U15. Den Vcc Pin des neuen RAM-Chips verbinden wir mit dem Vcc-Pad von U5. Es kann nicht schaden zwischendurch die Verbindungen mit einem Durchgangsprüfer oder Widerstandsmessgerät zu überprüfen. Q1, von dem wir den mittleren Pin anzapfen müssen, befindet sich auf der anderen Seite der Platine. Es ist ein kleiner Transistor in der Nähe des PROM-Chips. Also löten wir einen Draht dort an, und führen ihn an der Spule vorbei durch die Platine. Nachdem dieser Draht am 74HC21 angelötet ist, sind noch drei Drähte am DIP-Chip anzulöten. Da die Pads an diesem Chip sehr eng liegen, empfiehlt es sich, dort zuerst einen Draht anzulöten und diesen zum 74HC21 zu ziehen. Dort hat man dann deutlich mehr Spielraum. Nun nicht ungeduldig werden, es fehlen noch vier Adressleitungen. Zwei davon nehmen wir von U3, dem PROM-Chip auf der CPU-Seite. Die anderen beiden von unserem eben verdrahteten 74HC21. Sobald diese vier Pins verbunden sind, ist es Zeit für einen ersten Test. Also bauen wir den Portfolio provisorisch wieder zusammen. Sollte der Portfolio sich mit der Fehlermeldung "Ram Test Failure 000:0BFE" melden, hat man die Adressleitungen vergessen, wie ich bei meinem ersten Versuch. Wenn alles geklappt hat, sieht man beim Einschalten ungefähr das hier:


Montag, 16. Mai 2016

ATARI Portfolio

Ich habe kürzlich einen ATARI Portfolio bekommen, und war auf Anhieb begeistert.

Es ist so ziemlich der erste PDA. Erschienen 1989, passt in eine Handtasche und ist dabei fast kompatibel zum IBM PC XT. Der Speicher ist, zumindest bei meinem Modell, mit 128 kB sehr knapp bemessen, und richtige Laufwerke fehlen komplett. Er verwendet eigentlich spezielle Speicherkarten, damals CCM (Credit Card Memory) genannt. Das waren keine Speicherkarten wie wir sie heute kennen, sondern praktisch RAM-Chips mit Batterie. Flash Speicher gab es damals noch nicht. Ein Teil des Arbeitsspeichers wird als RAM Disk für ein virtuelles Laufwerk C: verwendet.
 
Das hat den Nachteil das ein "böses" Programm ganz leicht die kompletten Daten löschen kann.
Wie es so meine Art ist, musste ich natürlich sofort probieren was ich an dem kleinen modifizieren könnte. Und es hat sich schon vor einer Ewigkeit jemand die Mühe gemacht einen Steckplatz für CF-Karten in den Portfolio einzubauen. Da ich eine solche noch da hatte und auch einen kaputten Kartenleser als Spender für den Steckplatz, habe ich sofort angefangen.
Meine Versuche einen Flash Chip direkt anzuschließen waren nicht erfolgreich, vermutlich weil der eine bestimmte Kommandosequenz braucht um den Schreibschutz aufzuheben. Aber das schaffe ich vielleicht noch irgendwann. Auch einen PIC Chip direkt einzubauen hat nicht funktioniert. Der bringt die Signale des 80C88 Prozessors durcheinander beim Starten. Aber das schaffe ich noch irgendwann. Jedenfalls hat die Modifikation mit der CF-Karte nach kleineren anfänglichen Schwierigkeiten perfekt funktioniert. Der Treiber dafür funktioniert auch problemlos, und ich habe jetzt zwei zusätzliche Laufwerke mit jeweils 32 MB. Das ist für dieses winzige System reichlich. Aber da wurde es erst interessant. Da ich nun einen festen Speicher hatte, wollte ich natürlich auch ein paar Programme. Also ging die Suche los. Onkel Google war dabei sehr hilfreich, und es hat nicht lange gedauert bis ich einiges an Software hatte. Und wie es bei mir so üblich ist, kamen auch recht schnell die ersten Ideen auf was man noch alles machen könnte. Also ging ich auch auf die Suche nach einem C-Compiler, der nicht nur Code für den Portfolio erstellen kann, sondern auch noch auf dem Portfolio selbst laufen sollte. Das war schon etwas kniffeliger, aber nach einiger Suche bin ich auf DeSmet C gestoßen. Zuerst in Form der abgespeckten Shareware von 1988 oder so, aber dann habe ich auch die inzwischen freigegebenen Vollversionen gefunden. Und siehe da, der Portfolio kann auch kompilieren. Die neueste Version ist etwas zu speicherhungrig, die werde ich wohl erst nutzen können wenn ich der Arbeitsspeicher erweitert habe. Das steht ganz oben auf meiner Liste, zusammen mit einer Hintergrundbeleuchtung für das Display. Was mich aber wirklich begeistert ist wie sparsam der kleine ist. Obwohl ich ihn relativ oft benutze und auch den Parallelport dran habe, der angeblich recht viel Strom braucht, halten die Batterien fast eine Woche. Betrieben wird er nicht mit speziellen Akkus, sondern mit drei herkömmlichen AA-Zellen.
Und heute habe ich schon das erste Stückchen Software für den Portfolio veröffentlicht. Mit Hilfe des technischen Referenzhandbuchs habe ich ein paar der speziellen BIOS-Funktionen des Pofo und einige DOS-Funktionen in eine C-Bibliothek verpackt und auf Github gestellt. Bin mal gespannt ob meine libPofo jemandem von Nutzen sein kann.



Montag, 25. April 2016

DevelOS Struktur

Ich habe mal ein Diagramm erstellt um die grundlegende Struktur von DevelOS aufzuzeigen.
Leider ist es im Moment nicht wirklich so lauffähig, wie ich es gerne hätte. Bei der erweiterung habe ich wohl einige inkompatibilitäten erzeugt, und die Performance lässt auch stark zu wünschen übrig. Teile des Systems werde ich wohl neu schreiben müssen. Aber die Struktur will ich gerne so belassen. Noch rot eingezeichnet ist das Konsolen-Modul. Das habe ich erst jetzt implementiert. Mir ist aufgefallen das der Zugriff auf den Buffer des Display-Moduls problematisch sein kann. Außerdem hätte ich die gesamten Ausgabe-Routinen für den UART nochmal neu schreiben müssen. Also habe ich mich entschloßen den Buffer und die Ausgabefunktionen aus dem Display-Modul heraus zu nehmen. Dieses Modul macht jetzt nur noch die Initialisierung und das Übertragen vom Konsolenbuffer in den Hardware-Puffer des jeweiligen Display Moduls. Allerdings ist da noch so einiges im argen. Ich glaube ich habe da noch jede Menge Speicherlöcher drin.
DevelOS Struktur
Wie man hier sieht belegt DevelOS selbst einen großen Teil der externen Schnittstellen des PIC. Es verwaltet den Taktgenerator, die AD Wandler und das EEProm. Über IO-Pins können weitere Geräte angebunden werden.
Freestyle-I2C
Im Moment habe ich an meiner Testplatine ein 4x20 Zeichen LCD Display angeschloßen, sowie zwei kleine I2C-EEproms. Eines ist ein Atmel 32kbit-EEPROM das nur eine Bus-Adresse hat, aber intern mit 16bit Adressen arbeitet. Das andere ist ein ST 8kbit, das intern mit 8 bit adressiert wird, dafür aber in 4 Bänke unterteilt ist, die jeweils über eigene Bus-Adressen angesprochen werden. Eine gute Möglichkeit, um einen wirklich universellen Treiber zu schreiben, der beide EEPROMs ansprechen und für das DevelOS einheitlich darstellen kann. Sie sind zwar etwas abenteuerlich angeschloßen, aber im Prinzip funktioniert es. Den UART habe ich auf eine Buchse heraus geführt, aber bisher funktioniert er nicht richtig. Da der PIC im Moment nur mit dem internen Oszillator läuft, ist die Baudrate wohl zu ungenau. Die Buchse habe ich von einem alten Mainboard geerntet. Eigentlich ist es ein Audio-Anschluß für ein CD oder DVD Laufwerk. Die drei belegten Pins machen ihn aber für alles mögliche einsetzbar, und die etwas besseren Kabel für diesen Port sind sogar abgeschirmt. Damit will ich später mal die
Verbindung von diesem PIC-Board zu meinem Server herstellen. Auf dem Bild hier links sieht man das Display, und die zwei Ports die ich eben beschrieben habe. Der linke, schwarze davon ist an den UART angeschloßen, der andere ist noch nicht belegt. geplant hatte ich dort den I2C-Bus heraus zu führen, um zusätzliche Chips mit anbinden zu können. Ganz am linken Rand sieht man oben den Anschlußblock für die Stromversorgung und den Anschluß der Lüfter, die der PIC einmal regeln soll. Die Stiftleiste rechts neben den Widerständen ist ein Anschluß für die Spannungen des ATX-Netzteils. Diese soll der PIC ebenfalls überwachen und dem Banana Pi über den UART mitteilen. Unter dem Anschlußblock links sieht man auch noch zwei Transistoren die ich ebenfalls von alten Mainboard habe. Für die Steuerung von Lüftern sind sie mit einer Schaltleistung von über 100 Ampere zwar völlig überdimensioniert, aber hey, was nichts kostet ist auch nicht verschwendet.


Zwischen dem Anschlußblock und dem Kabel für das Display sieht man noch den Anschluß für das Programmiergerät. Dafür verwende ich eine ehemalige PS2-Buchse. Ich wollte mein Programmiergerät nicht jedes mal wieder an eine Stiftleiste anschließen, sondern eine komfortable Möglichkeit haben ein Gerät auch von außen zu Programmieren.

Der weitere Ausbau gestaltet sich jedoch schwierig, da das Programm jetzt nur noch etwas mehr als 100 mal pro Sekunde durch läuft. Dabei wird aber schon zwei mal das Display neu geschrieben und einige Timer laufen. Es kann jedoch noch einiges optimiert werden. Zum Beispiel wird die Uhr im Moment von einem 8-bit Timer abgeleitet mithilfe eines Software-Zählers. Das ist extrem ineffizient. es wäre deutlich besser hierfür einen 16-bit Timer mit entsprechenden Preloadwerten zu verwenden.Und wenn ich mir die Zeit nehme, finde ich bestimmt noch hundert weitere Möglichkeiten zur Optimierung. Leider habe ich das Profiler-Plugin für MPLab-X nicht, und will auch keine 45 Euro dafür bezahlen. Also werde ich wohl so zurecht kommen müssen.

Hier nochmal ein Link zum Projekt auf Github: https://github.com/Stefanie80/DevelOS.X/tree/experimental

Samstag, 23. April 2016

DevelOS auf github

Ich habe mein DevelOS jetzt auf github veröffentlicht.
Am Anfang war es noch etwas gewöhnungsbedürftig, aber ich hab die Bedienung hin bekommen.

Leider läuft das System so wie es gerade ist nicht richtig. Vermutlich wird irgendwo eine Variable überschritten oder so, aber das habe ich auf die schnelle nicht gefunden. Es tritt interessanter Weise nur im production Image auf, das Debug Image läuft gut.

Die Sources sind hier zu finden: https://github.com/Stefanie80/DevelOS.X

Hoffe das es noch jemandem was bringt ...

Dienstag, 12. April 2016

Download-Server im Einsatz

Ich hatte ja schon angekündigt, das ich in absehbarer Zeit ein Howto erstellen will, wie man einen Homeserver selbst konfiguriert. Dafür werde ich dann natürlich meinen vorhandenen Banana Pi einsetzen. Aber noch ist es nicht so weit. Ich habe den Server ja erst kürzlich zerlegt, und bevor ich das nochmal mache, möchte ich ein bisschen was vorbereiten. Auf jeden Fall will ich dann gleich das aktuellste Betriebssystem verwenden, und die Einrichtung dann Schritt für Schritt dokumentieren. Und auch an der Hardware will ich noch ein bisschen was verändern. Heute soll es aber erstmal um die Vorbereitung gehen. Und dabei kann ich auch gleich zeigen, wie und wofür man so einen Server sehr gut einsetzen kann. Einer der wichtigsten Punkte ist für mich die Downloadverwaltung. Und die wird heute zum Einsatz kommen.Die aktuellste Version von Bananian gibt es hier: https://www.bananian.org/download

Im Moment ist das Debian 8 Jessie. Die Datei ist zwar "nur" 158 MB groß, das wäre noch an der Grenze dessen was ich lokal auf dem Desktop runter laden würde. Aber heute mache ich es gleich über Torrent, um den Vorgang mal zu zeigen.
Wie man auf dem Screenshot sehen kann, gibt es auf der Seite von Bananian nur einen direkten Link auf die ZIP-Datei. Man kann aber trotzdem Torrent verwenden, dafür gibt es die Seite http://burnbit.com/. Man klickt auf einen beliebigen Download-Link mit der rechten Maustaste, und wählt dann den Punkt "Link-Adresse kopieren".
Dann geht man auf die Seite von Burnbit, und fügt den Link in die Zeile oben ein.

Hier muß man ein bisschen aufpassen, denn es werden nur reine http-Links unterstüzt. In diesem Fall ist es ein https-Link, der würde so nicht funktionieren. Aber in den meisten Fällen klappt es trotzdem, wenn man das 's' einfach löscht.
So klappt es auch hier. Danach öffnet sich die Download-Seite mit einigen Infos zur Datei.
Hier finde ich den Punkt "Added:7 months ago" besonders interessant. Das heist ich bin nicht die erste, die Burnbit verwendet um diese Datei zu laden, jemand hat sie schon vor 7 Monaten hinzugefügt.
Ein klick auf "Download Torrent" startet dann den Download. Falls die Datei noch nicht bei Burnbit registriert ist, erscheint in diesem Fenster oben ein Forstschrittsbalken, während die Datei verarbeitet wird. Dabei wird sie in viele kleine Teile unterteilt und für jedes Teil wird eine Prüfsumme berechnet, so das man sie von mehreren Quellen gleichzeitig herunterladen kann, aber trotzdem die Integrität der Datei sichergestellt ist. Warum das wichtig ist, werdet ihr gleich noch sehen. Jetzt geht es aber erstmal ans runterladen:
Ich wähle hier direkt "Öffnen mit ...". Wie man sieht wird nun eine Größe von nur knapp 50kb angezeigt. Was man hier herunter lädt, ist nur eine sogenannte Metadatei. Sie enthält Prüfsummen der Datei und Angaben dazu, wo sie zu finden ist. Nach dem Klick auf OK öffnet sich Deluge mit dem Dialog zum Hinzufügen eines neuen Torrents. Hier kann man auch gleich ein paar Einstellungen vornehmen, wie zum Beispiel den Zielordner. Sobald man die Datei hinzugefügt hat, legt Deluge direkt mit dem Download los.

 Allerdings läuft der Download selbst auf dem Server, nicht auf meinem PC. Den könnte ich jetzt auch ausschalten.
Wozu der Umweg? Naja, bei dieser Datei ist die geschätzte Downoaldzeit nur gut 10 Minuten, da lohnt es sich kaum. Es sei denn man will in der Zeit etwas anderes Nebenbei machen. Deluge bietet nämlich unter anderem die Möglichkeit, die Up- und Downloadgeschwindigkeit zu bestimmen. Ich habe hier nur eine 6000er DSL Leitung, also kann ich im besten Fall mit etwa 700 kb/s laden.

Das ist nicht viel, und selbt ein einzelner Download kann dazu führen, das nebenher nichts anderes mehr funktioniert, oder YouTube die Videoqualität auf 144p drosselt. Ich habe den Deluge allerdings auf 230 kb/s gedrosselt, so das mir immer noch zwei Drittel der Leitung frei bleiben. Ich könnte jetzt auch noch beliebig viele weitere Torrents hinzufügen, Deluge erledigt die dann gleichzeitig. Man muß sich nicht darum kümmern, das läuft alles wie von selbst. Man kann die Geschwindigkeit auch zeitabhängig einstellen, so wie ich. Tagsüber, von morgens um 7 bis Nachts um 12 ist die Geschwindigkeit gedrosselt, so das ich immer problemlos surfen und Videos schauen kann, und von 0 Uhr bis 7 Uhr morgens darf dann Deluge die Leitung komplett ausnutzen.

Das kann man im Scheduler-Plugin auch noch für jeden Tag der Woche einzeln genau konfigurieren, und man kann auch einzelne Stunden komplett verbieten, dann ist das Feld rot. Das ist zum Beispiel sinnvoll, wenn man regelmäßig zeitgesteuerte Updates durchführen lässt. So kann man sicherstellen, das die immer mit der höchsten Geschwindigkeit laufen. Hat man mehrere Rechner, so wie ich, dann legt man die Updates am besten auf jedem Rechner auf einen anderen Wochentag, aber in die gleiche Stunde, und stellt dann die entsprechenden Stunden im Deluge auf rot. Sobald der Download abgeschloßen ist, steht im Fortschrittsbalken "Seeding". Das heißt das mein Rechner jetzt dabei mithilft, die Datei zu verteilen.
 Lädt jemand anders jetzt die gleiche Datei, so verbindet sich sein Rechner nicht nur mit dem Original-Server, sondern zusätzlich auch mit meinem Rechner. Er bekommt dann von mir ein paar Kilobyte pro Sekunde zusätzlich. Wenn es nur einen sogenannten Seed gibt, bringt das natürlich nicht viel, aber bei populären Dateien gibt es auch mal hunderte Seeds, so das man mit Torrent auch deutlich höhere Geschwindigkeiten erzielen kann. Diese Technik setzen zum Beipsiel die meisten Online-Spiel ein, um ihre regelmäßigen Updates zu verteilen. 
 
Nur das man dort nichts davon sieht, und den Vorgang auch kaum beeinflussen kann. Man braucht übrigens nicht immer Burnbit dazu. Viele Anbieter haben die Vorteile von Torrents inzwischen erkannt, und bieten gleich selbst entsprechende Downloads an.Dazu zählen etwa die Raspberry Foundation oder auch OpenSUSE. Ich möchte bei Gelegenheit auch noch das neueste SuSE Linux als Zweitsystem auf meinem Desktop installieren, dafür gibt es wie ihr seht direkt den Link auf BitTorrent.

Und hier sieht das Bild jetzt etwas anders aus: mein Rechner hat sich mit 94 anderen verbunden, und bekommt von jedem ein paar Kilobyte pro Sekunde. Die einzelnen Benutzer bemerken die wenigen kb gar nicht, aber ich kann die Datei trotzdem mit voller Geschwindigkeit laden. Bei der momentanen Geschwindigkeit wird das wohl über 5,5 Stunden dauern. Aber wie gesagt, das läuft auf dem Server, und ich muß meinen Rechner nicht die ganze Zeit laufen lassen.

Montag, 11. April 2016

DevelOS

Neben meiner Bastelei an PCs und meinem lokalen Netzwerk, beschäftige ich mich seit ein paar Jahren auch immer wieder mit der Programmierung von Microchip PIC Microcontrollern. Was ich daran besonders faszinierend finde ist die direkte verschmelzung von Code und Hardware, und das man damit quasi jedes Stückchen Elektronik irgendwie nutzen und ansprechen kann.
Inzwischen habe ich auch schon eine Menge kleinere Projekte umgesetzt, leider sind meine, teilweise sehr ausführlichen, Posts dazu verloren gegangen als blog.de abgeschaltet wurde.

Heute möchte ich etwas vorstellen was eigentlich eher ein Meta-Projekt ist. Wer sich mit PICs beschäftigt wird meistens recht schnell merken, das man bestimmte Funktionen immer wieder braucht, und dank der Programmierbarkeit in C kann man das meiste auch wiederverwenden. Aber dann muss man es immer wieder in ein neues Projekt kopieren, und mit neuen Funktionen zusammenbringen. Natürlich geht das, aber ich fand nach einiger Zeit ziemlich umständlich.

Daher habe ich irgendwann mal eine Art minimales Betriebssystem gebastelt, das beinahe beliebige Aufgaben erfüllen kann. Der Kern davon ist eine Pipeline, in die Nachrichten gesetzt werden können, die dann der Reihe nach abgearbeitet werden. Das passiert in einem einzigen langen switch()-Statement, das für jedes definierte Event ein Stückchen Code enthält.

Ein Beispiel:

Man verwendet einen AD-Kanal und möchte diesen periodisch auslesen. Am effektivsten geht das, indem man die Konvertierung startet, und dann auf den Interrupt wartet das der AD fertig ist. Dann bekommt man die Rohdaten zurück, die man dann umrechnen muß, um den tatsächlichen Wert zu erhalten. In meinem System sind das mehrere Events.

1. Das RTC-Modul meldet, das eine bestimmte Zeitspanne abgelaufen ist.
2. Dies löst ein Event aus um eine neue Konvertierung zu starten
3. Der AD konvertiert, die Rückgabe erfolgt per Interrupt
4. Im Interrupthandler wird nur ein neues Event erstellt, das die Rohdaten enthält
5. Die Rohdaten werden konvertiert, das Ergebnis wird wieder als Event in die Pipeline geschrieben
6. Je nach Funktion kann dieses Event wieder neue Events triggern, die Ausgabe auf ein Display z.B.

Das sieht auf den ersten Blick vielleicht etwas kompliziert aus, und mancher wird sich denken "Aber ein PIC hat doch gar keine RTC!". Nun, die RTC war eine der ersten Funktionen die ich auf diese Weise implementiert habe. Ein 16bit-Timer löst einen Interrupt aus, das wird als Event in die Pipeline geschrieben, und löst das hochzählen der RTC aus. Dort können wiederum andere Events ausgelöst werden. So kann man zum Beispiel angeben, das die Refresh-Routine für ein Display in einem bestimmten Intervall aufgerufen werden soll.

Das ist der Kern des DevelOS. Darum herum habe ich dann einige Module gebaut, z.B. das RTC-Modul, mehrere Module um Displays anzusprechen, ein Modul zur Verwaltung des internen EEProm und ähnliches. Um nicht jedes mal unnötig viel Speicher im PIC zu belegen, habe ich das ganze mit #define-Statements und #ifdef-Blöcken organisiert, so das man nur wenige Zeilen verändern muß um ganze Codeblöcke zu aktivieren, die über ettliche Dateien verteilt sein können.

Neben dieser rudimentären Modularisierung erreicht man auf diese Weise auch noch ein relativ gut funktionierendes Pseudo-Multitasking. Weil alles über die Pipeline läuft, können mehrere Aufgaben quasi nebeneinander laufen. Man muß nur aufpassen das man sie in möglichst kleine Stückchen zerlegt, so das der Chip mit einem einzelnen Event nicht zu lange hängen bleibt. In dem obigen Beispiel könnte man ja auch die Umrechnung des AD-Wertes direkt in der Interrupt-Routine unterbringen, aber das könnte eventuell die RTC aus dem Takt bringen.

Vielleicht erstelle ich dafür auch irgendwann ein Github-Projekt, mal sehen. Falls jemand Interesse an dem Code hat, darf mich gerne per Kommentar o.ä. kontaktieren, prinzipiell bin ich gerne bereit den Code zu teilen, unter der Bedingung, das darauf aufbauender Code wieder dem Gesamtprojekt zugute kommt.

Samstag, 9. April 2016

Vinculum II

Es ist Zeit, mal den Aufbau meines Servers zu zeigen. Ich habe ihn vor ein paar Tagen mal wieder abgeschaltet und aufgemacht, vor allem um die Kabel etwas ordentlicher zu verlegen und ein XBee-Funkmodul anzuschließen. Dabei habe ich dann auch einige Fotos gemacht, so das ich jetzt hier ein bisschen was zeigen kann.
Hier sieht man das Herz des Servers, den Banana Pi. Links befinden sich die beiden USB-Ports und der Netzwerkanschluß, rechts sieht man die SD-Karte auf der sich das Betriebssystem befindet. Das war vorher eine 4 GB Karte, die eigentlich auch ausreicht. Nur habe ich inzwischen viele zusätzliche Funktionen eingebaut, es kommen auch immer wieder Updates, und so waren nur noch rund 800 MB frei. Das hätte noch lange ausgereicht. Jetzt gab es aber hier bei einem örtlichen Elektronikhändler eine 32 GB Karte für gerade mal 10 Euro im Angebot, und die war auch noch deutlich schneller als die ursprüngliche. Da habe ich natürlich sofort zugeschlagen und habe jetzt wieder reichlich Reserve.
Ganz vorne im Bild sieht man ein buntes Kabel, das ist eine der drei seriellen Schnittstellen des Banana, an die ich das XBee-Modul angeschloßen habe. Praktischerweise sind hier die beiden Datenleitungen, eine 3,3V und eine Masseleitung direkt nebeneinander, so das ich das Modul komplett mit diesem einen Kabel betreiben kann. Hinten sieht man noch das weiße µUSB-Kabel, das nur zur Stromversorgung dient, und daneben das rote SATA-Kabel. Darüber hinaus hat der Banana noch einen HDMI, einen Composite Videoausgang und einen Soundausgang, die ich aber nich verwende. Vielleicht werde ich irgendwann noch einen Lautsprecher einbauen für Fehler- und Statusmeldungen, aber das ist eine andere Geschichte.
Ganz rechts oberhalb der SD-Karte sieht man noch einen µUSB-Port, das ist auch nochmal ein vollwertiger USB2.0-Port den ich später nutzen könnte, wenn ich ihn denn brauche.

Und hier seht ihr den Server im Überblick. auf den ersten Blick wirkt das sehr chaotisch, vor allem wegen der Kabel. Links unten ist die ganze Stromverkabelung. Ich habe hier eine ATX-Buchse aus einem alten Netzwerk verwendet, und daran alle Kabel angelötet die ich so brauche. Einige Spannungen habe ich auf eine Schraubklemme geführt, das macht es etwas einfacher das System zu erweitern. Das grüne was man unten sieht, ist ein 8-Port Netzwerk Switch, und darüber sieht man einen der beiden USB2.0-Hubs. Dieser ist mit vier Festplatten bereits voll belegt, der zweite rechts unten steht für die nächsten Platten zur Verfügung. Es wäre vermutlich effizienter die Platten auf beide Hubs zu verteilen, aber ich bin mir nicht ganz sicher ob das nicht mein LVM-Setup durcheinander bringen würde. Doch dazu später mehr. Unten rechts sind auch zwei 3,5"-Festplatten montiert, jeweils 1 TB. Beide habe ich als USB-Festplatten gekauft und dann aus dem jeweiligen Gehäuse ausgebaut. Das war billiger als die Platten und USB-Adapter einzeln zu kaufen. Die Stromversorgung kommt dabei jeweil direkt aus dem ATX-Netzteil oben links. 
Und hier ein Blick in den oberen Laufwerkskäfig. Man sieht unten die 3,5" SATA-Platte mit 2TB, darüber sind zwei Montagerahmen eingebaut die jeweils vier 2,5"-Laufwerke aufnehmen können. Zwei Stück mit jeweils 1TB sind bereits vorhanden. In Einzelhandels-Byte sind somit 6TB verbaut, allerdings bleiben davon nach der Umrechnung nur noch etwa 950 Gigabyte bei den 1TB Platten und 1900 Gigabyte bei der 2TB Platte übrig, also zusammen ca. 5722 Gigabyte. Ein bisschen ist für das System selbst reserviert (gemountet als /var) und ein bisschen geht noch für das Dateisystem drauf, so das am Ende 5,35 "echte" TB als Netzlaufwerk zur Verfügung stehen.
Ich habe hier noch 6 Monatgeplätze für weitere Festplatten frei, und im Laufe der Zeit werde ich die auch sicher bestücken. Allerdings ist das immer eine Geldfrage, auf so eine Platte muß ich schon eine Weile sparen. Außerdem will ich auch den Netzwerk-Switch durch einen mit Gigabit-Ethernet ersetzen, damit ich den Banana wirklich mal ausreizen kann. Im Moment wird die Leistung eigentlich nur durch das 100MBit-Netzwerk begrenzt. Ich erreiche mit diesem System sowohl beim Lesen als auch beim Schreiben konstant 11-12 MB/s, also wirklich das Maximum was das Netzwerk hergeben kann. 
Hier rechts nochmal der Server im endgültigen Zustand mit der FritzBox oben drauf. Vom unteren USB-Hub habe ich ein Kabel nach außen gelegt, das ist aber im Moment nicht belegt. Ich möchte einfach die Möglichkeit haben eine externe Festplatte anzuschließen, falls mal ein Freund etwas größeres kopieren möchte. Das geht über WLAN nur sehr langsam, und extra Kabel legen ist mir zu nervig.
Das aufgerollte Netzwerkkabel links unten verbindet die FritzBox mit dem Switch, ich habe nur die überschüssige Länge im Gehäuse versteckt, damit es von außen etwas ordentlicher wirkt. Und wenn man genau hin schaut, sieht man oben rechts das kleine XBee-Funkmodul. Darüber werde ich irgendwann noch einen eigenen Post schreiben.

Hier noch die Front- und Rückansicht. Vorne habe ich zwei Lüfter angebracht, vor allem um die Festplatten zu kühlen. Die erreichen vor allem im Sommer schon recht bedenkliche Temperaturen. Hinten sieht man die beiden Netzwerkkabel rot ist der Server und weiß die Fritzbox. Und hier sieht man auch nochmal das Funkmodul, das ich einfach mit Panzertape am Gehäuse befestigt habe. Simpel aber effektiv. Man sieht auch das ich (fast) sämtliche Öffnungen des Gehäuses mit Paketband abgeklebt habe. Dadurch will ich einen kontrollierten Luftstrom sicherstellen. Die beiden Lüfter in der Front versorgen die Festplatten mit Frischluft, und das Netzteil hinten zieht die Luft wieder aus dem Gehäuse. Der Banana ist dabei so Montiert, das sein Kühlhörper direkt im Luftstrom des Netzteils liegt.
So, das wars vorerst mal. Aber es kommt sicher irgendwann noch mehr dazu.

Freitag, 8. April 2016

Banana Pi vs. Raspberry Pi


In meinem letzten Post dazu habe ich ja schon geschrieben das ich zeitweise einen Raspberry Pi für meinen Homeserver benutzt habe. Und das ich jetzt einen Banana Pi verwende, der deutlich mehr Leistung hat. Aber warum das so ist, das habe ich nicht genau erklärt. Das will ich jetzt nachholen, weil es da oft ein Mißverständnis gibt.
Natürlich ist der Prozessor immer ein Faktor, und der Raspberry hat nur einen Singlecore mit maximal 1000 MHz. Von Hause aus läuft er sogar nur mit 700 MHz. Der Banana Pi dagegen hat einen Dualcore mit bis zu 1200 MHz. Das ist aber nur die halbe Wahrheit. Denn wenn es nur darum geht, Daten im Netzwerk herum zu kopieren, spielt die Prozessorleistung nur eine untergeordnete Rolle. Aber was ist dann der Grund, das der Raspberry nur gut 2 MB/s schafft, der Banana aber ganz locker 12 MB/s durch das 100 MBit Netzwerk schiebt?
Dazu muß man sich vor Augen halten, das beide Rechner auf einem sogenannten SoC beruhen. SoC steht für "System on a Chip", das bedeutet das hier ein ganzes System in einem einzelnen Chip steckt. Bei einem PC hat man einen Prozessor, und einen Chipsatz, oder auch Northbridge genannt. Diese Northbridge stellt alle Verbindungen innerhalb des Systems bereit, also heutzutage vor allem USB-Ports, SATA-Ports, PCI-Express-Anschlüsse, Netzwerkport, eben alles was man so braucht. Früher gab es auch noch eine sogenannte Southbridge, die den Arbeitsspeicher angesteuert hat. Diese Funktion ist aber inzwischen fast immer im Prozessor integriert.
Nun, bei einem SoC sind alle Komponenten in einem einzelnen Chip integriert. Nach aussen haben diese Chips meist einige spezielle Ports, wie z.B. HDMI, einige serielle Schnittstellen wie I2C und SPI, über die man andere Chips ansteuern kann, und insbesondere USB-Ports. Letztere sind für uns interessant, da wir hier unsere Festplatten und so weiter anschließen. Und auch der Netzwerk-Anschluß ist bei den beiden von mir betrachteten Systemen jeweils per USB angebunden. Wenn man weiß, das quasi alle Geräte bei einem Raspberry oder Banana per USB angesprochen werden, dann stellt sich unweigerlich die Frage, wieviele Ports hat denn das jeweilige SoC eigentlich, und wie sind die aufgeteilt?
Der Raspberry Pi basiert auf einem Broadcom BCM2835 SoC, das nach außen hin nur einen einzigen USB-Port hat. Dieser wird auf einen Chip geführt, der den Netzwerkanschluß und die externen USB-Ports bereit stellt. Wie man hier nachlesen kann, ist das bei allen Modellen des Raspberry bis heute genau gleich geblieben. Alle externen USB-Ports und das Netzwerk teilen sich also einen einzigen USB-Port.
Beim Banana Pi kommt dagegen ein Allwinner A20 SoC zum Einsatz, das nach außen über drei USB-Ports verfügt. Zusätzlich hat dieses SoC auch direkt einen Netzwerkanschluß und einen SATA-Port. Nachzulesen hier. Das heißt, beim Banana Pi sind alle USB-Ports eigenständig und bieten die volle Bandbreite, unabhängig von den anderen Anschlüssen.
Und genau das macht den großen Unterschied aus.

Freitag, 1. April 2016

Vinculum

Wer mich persönlich kennt, der weiß das ich schon seit ca. 10 Jahren immer einen eigenen Homeserver betrieben habe.
Dafür kam im Lauf der Jahre immer wieder andere Hardware und Software zum Einsatz. Da ich meinen aktuellen Server in der nächsten Zeit mal wieder überarbeiten werde, will ich hier erstmal einen Überblick geben warum und wie ich den Server betreibe.

Zuerst mal das "Warum?". Natürlich eine berechtigte Frage. Für die Verwaltung des eigenen Heimnetzwerkes gibt es jede Menge verschiedene Router die ihren Job meistens recht zufriedenstellend erledigen. Will man Dateien für mehrere Geräte verfügbar machen, z.B. für den PC, das Smartphone und das Tablet, gibt es dafür wirklich gute und einfache NAS-Geräte, NAS steht für Network Attached Storage, zu deutsch grob "(ans) Netzwerk Angeschlossener Speicher". Also eigentlich könnte man auf einen Server ja verzichten. Ja, im Prinzip schon.

Aber aus mehreren Gründen will ich das nicht:

1. Kontrolle
Ich habe gerne die totale Kontrolle über alles, was in meinem Netzwerk passiert. Das ist mit einem herkömmlichen Router meist nur eingeschränkt möglich. Zum einen hat man auf einem dedizierten Server mehr Kontrolle über die Einstellungen, zum anderen hat man dort meistens viel ausführlichere Logfiles, so das man eventuelle Fehler leichter zurück verfolgen kann.

2. Spielraum
Ein Router in Kombination mit einem NAS gibt einem zwar auch die grundlegenden Funktionen eines Servers, aber man ist auf den Funktionsumfang festgelegt, den der jeweilige Hersteller vorgesehen hat. Auf einem Router kann man keine zusätzliche Software installieren, und ein NAS kann nur eine begrenzte Anzahl von Festplatten aufnehmen.

3. Effizienz
Für einen Router, ein NAS, eventuell noch einen Netzwerk-Switch oder eine externe USB-Festplatte braucht man jeweils ein eigenes Netzteil. Die haben dann jeweils eine Verlustleistung, und die addiert sich natürlich bei mehreren Geräten. In einem dedizierten Server hat man dagegen nur ein einziges Netzteil, so das Verluste nur an einer Stelle anfallen und bei geeigneter Wahl des Netzteils sehr gering ausfallen.

4. Ordnung
Wie schon erwähnt, für jedes einzelne Gerät braucht man ein eigenes Netzteil, und dann wollen ja alle Geräte untereinander auch noch eine Datenverbindung haben. Das ufert ganz schnell in einen regelrechten Kabelsalat aus. Und der ist nicht nur sehr unschön, sondern kann auch extrem nervig sein wenn man etwas ändern oder erweitern möchte.

Fazit: Ein Homeserver macht irgenwie doch Sinn.

Meine Server habe ich die meiste Zeit mit Linux als Betriebssystem betrieben. Namentlich SuSE Linux und Debian. SuSE lief auf meinen ersten Servern. Einer der ersten war ein Celeron 400 in einem Booksize-Gehäuse. Die Wahl fiel damals auf SuSE weil ich damit schon auf dem Desktop etwas Erfahrung hatte, und sich die damals aktuelle SuSE noch auf wenige 100 MB "eindampfen" ließ. Eine grafische Oberfläche brauchte ich nicht, das System sollte nur stabil und zuverlässig laufen. Damals hatte ich noch keine großen Festplatten, so hatte der Server nur etwa 20 GB Speicher. Davon wollte ich möglichst viel frei haben, um Daten auszutauschen. Und ein schlankes System bedeutet auch weniger Updates und weniger Fehlerquellen. Lange Zeit war ich damit wirklich zufrieden, allerdings hat das Mainboard nach einem Umzug nicht mehr funktioniert, und ein neuer Server musste her.
Da habe ich dann einen Minitower mit einem älteren Pentium Rechner bestückt. Die genauen Spezifikationen weiß ich inzwischen gar nicht mehr. Nachdem ich den lange Zeit wieder mit Linux betrieben habe, wollte ich irgendwann man Bitcoins minen, und das habe ich beim besten Willen nicht zum laufen bekommen. Und da auf meinen Rechnern sowieso die meiste Zeit Windows lief, habe ich dann mal einen Windows-Server betrieben. Dafür kam ein Windows Small Business Server 2003 zum Einsatz, für das ich die Lizenz schon einige Zeit herum liegen hatte. Was mir gut gefallen hat war die Verwaltung mehrerer Windows PC's in einer Domäne. Dabei kann man wirklich auf praktisch alle Funktionen und Einstellungen der angeschloßenen Rechner zugreifen, bis hin zu Einstellungen in der Registry. Und man kann auch viele Einstellungen für alle Rechner gemeinsam festlegen und Verwalten. Aber, die Einstellungen sind oft tief im System vergraben, und wenn man sich nicht wirklich auskennt, muß man viele Optionen sehr mühsam suchen. Und, damit man vernünftig mit dem System arbeiten kann, ist man auf die Remote-Desktop Steuerung angewiesen. Die funktioniert zwar wirklich gut, aber man braucht eben immer ein volles grafisches Windows System, um darauf zugreifen zu können. Ich habe meine SSH vermisst. Zudem hat der PC als Server wirklich viel Strom verbraucht, was mich irgendwann echt in Schwierigkeiten gebracht hat.

Und irgendwann habe ich dann den Raspberry Pi entdeckt. Ein Linux-Rechner in Scheckkartengröße, mit stromsparender ARM-Architektur. Zwar nicht besonders leistungsstark, aber für meine Zwecke fast perfekt. Zwar entstand daraus das übelste Kabelchaos aller Zeiten, aber das war für mich erträglich, weil ich alles zusammen in einer kleinen Abstellkammer unterbringen konnte, so das es quasi unsichtbar war. Der Rapberry mit eigenem Netzteil, eine USB-Festplatte mit eigenem Netzteil, ein Netzwerk-Switch mit eigenem Netzteil, eine Fritzbox mit eigenem Netzteil. Und ein paar Netzwerkkabel. Wirklich ziemliches Chaos, bei dem ich selbst zeitweise den Überblick verloren habe. Aber es hat gut funktioniert, obwohl die Datenraten immer relativ schlecht waren. Mehr als 2MB/s ging nicht beim Zugriff auf die USB-Platte über das Netzwerk. Das hatte mehrere Gründe, aber es war für mich soweit eigentlich genug. Ausreichend um Videos über das NJetzwerk zu schauen, was für mich bis heute eine der wichtigsten Funktionen des Servers darstellt. Damals noch mit einer modifizierten X-Box als MediaCenter. Und ein weiterer Einsatzzweck kam dazu, nämlich das abwickeln größerer Downloads. Ich habe eine relativ langsame Internetverbindung mit nur knapp 7 Mbit, und da dauert es schon eine kleine Ewigkeit wenn man ein größeres Linux-Image für den Raspberry laden will, oder gar ein DVD-Image für ein Desktop-Linux. Auch habe ich irgendwann angefangen eine Sammlung von Vorlesungen anzulegen, da sind wirklich viele auf archive.org verfügbar. Alle diese Sachen sind per Torrent verfügbar, da lag es nahe einen Torrent direkt auf dem Raspberry laufen zu lassen. Dadurch musste ich nichtmehr meinen großen Desktop PC dauernd laufen lassen, und große Downloads konnten über Nacht laufen wo sie mich nicht gestört haben.

Das führte dazu, das jemand anderes gerne auch eine solche "Seedbox" haben wollte, wie man einen Torrent-Server auch manchmal nennt. Allerdings hatte er keinen Raspberry, sondern einen Banana Pi, ein sehr ähnliches aber deutlich leistungsstärkeres System. Das Board für die Entwicklung eines passenden Images wurde mir großzügigerweise zur Verfügung gestellt, und verrichtet bis heute seinen Dienst in meinem aktuellen Server. Und irgendwann habe ich auch das Kabelchaos endgültig beseitigt. Dafür habe ich ein ATX-Netzteil verwendet, in einem normalen Minitower Gehäuse. Allerdings mit einem selbstgelöteten Kabelbaum, an einem ATX-Stecker aus einem alten Mainboard. Dadurch konnte ich nicht nur den Banana Pi, sondern auch die inzwischen 5 Festplatten, die Fritzbox und einen zusätzlichen Switch an einem einzigen Netzteil betreiben, das noch reichlich Reserve für weitere Festplatten oder sonstige Erweiterungen bietet. Und es ist alles zusammen in einem einzigen Gehäuse untergebracht, nimmt nur wenig Platz weg und kommt mit einer einzigen Steckdose aus. Die Geschwindigkeit ist für mein 100MBit-Netzwerk bei weitem ausreichend, ich erreiche sowohl beim Lesen als auch beim Schreiben rund 11-12 MB/s, also das Maximum was das Netzwerk hergibt. Der Banana selbst hat einen Gigabit Port, so das hier auch noch deutlich mehr möglich wäre. Da ich aber keinen Gigabit Switch besitze, kann er bisher gar nicht seine volle Leistung entfalten.

So weit, so gut. Und weiter?

Ich werde auch in Zukunft die Speicherkapazität Stück für Stück ausbauen. Inzwischen sind es mehr als 5 Terabyte. Irgendwann werde ich auch den Switch durch ein Gigabit Modell ersetzen, und die Fritzbox ist auch schon ziemlich in die Jahre gekommen. Sie bietet leider nur ein 54MBit WLAN, was mir inzwischen doch zu langsam ist. Außerdem möchte ich gerne die Spannungen des Netzteils genau überwachen können, dafür werde ich einen PIC Mikrocontroller verwenden, der mit dem Banana verbunden wird. Eventuell kommt auch noch ein Display dazu, das dann drahtlos per XBee mit dem Server verbunden wird. Aber da bin ich mir noch nicht ganz sicher. Auch eine Überwachung der Lastströme auf den einzelnen Spannungen wäre denkbar, oder die temperaturabhängige Regelung der Lüfter. Die Abstellkammer in der mein Server steht ist direkt unter dem Dach, und im Sommer wird es da sehr heiß. Teile des Systems haben da schon mal 60 Grad erreicht, was für Festplatten schon ungesund ist.

Sobald ich den Server wieder umbaue, werde ich natürlich hier ausführlich berichten. Dann auch wieder mit Bildern und Details.

Mittwoch, 30. März 2016

Spannungsregler aus China eingetroffen

Für mein Boxy-Projekt brauchte ich eine 9V-Spannung, die ich so leider nicht zur Verfügung hatte. Natürlich gibt es passende Festspannungsregler, aber die sind meistens relativ ineffizient, und auch nicht variabel. Heute brauche ich 9V, morgen vielleicht 7,5V oder irgendeine andere Spannung für ein Projekt.
Es gibt auch einstellbare Spannungsregler, die dann aber immer auch zusätzliche Bauteile brauchen. Viele Projekte möchte ich aber aufbauen können, ohne dafür extra eine Schaltung zu bauen. Genau da kommen diese Module ins Spiel. Darauf gestoßen bin ich durch ein Video im Computer Club 2, der Nachfolgesendung des legendären WDR Computer Club.

Tatsächlich habe ich die Module sehr billig auf ebay gefunden und gleich zehn Stück bestellt. Ich habe selbst kein ebay-Konto, und das ist mir auch einfach zu nervig. Da müsste ich mich aufwändig registrieren, und dazu kommt noch die Paypal-Nerverei, die ich mir wirklich nicht antun will. Aber zum Glück gibt es den Dienst all4btc, der es ermöglicht bei ebay oder anderen Onlineshops zu bestellen ohne das man sich überall extra registrieren muß. Dabei bezahlt man einfach mit Bitcoins an all4btc, und die übernehmen den kompletten Bestellvorgang. Sehr einfach und komfortabel, wie ich finde.

Jetzt sind die Module eingetroffen, und ich bin ziemlich begeistert. Erstmal sind sie wirklich sehr kompakt, 43x20 mm misst die Platine. Die Höhe beträgt mit den Elkos etwa 15mm, und das ist alles. Man braucht keine zusätzlichen Bauteile, nur noch Leitungen am Eingang und Ausgang anlöten, Spannung einstellen und fertig. Zum einstellen der Spannung dient ein Spindelpotentiometer, das blaue Bauteil das im Bild zu sehen ist. Mit der kleinen Schraube lässt sich die Ausgangsspannung wirklich sehr genau einstellen, und bleibt auch bei sich ändernder Eingangsspannung oder Ausgangsbelastung stabil.

Die Basis für das Modul bildet ein LM2596S, ein integrierter Schaltregler der laut Datenblatt bis zu 3A Dauerstrom liefern kann. Man bekommt also praktisch ein Miniatur-Schaltnetzteil mit 150kHz Schaltfrequenz, fertig aufgebaut und variabel einsetzbar. Bezahlt habe ich für die 10 Module inklusive Versand und Gebühr für all4btc knapp 20€, also weniger als 2€ pro Modul. Ein wirkliches Schnäppchen, das sich jeder Bastler mal anschauen sollte. Damit werde ich noch viele "ausgediente" Steckernetzteile umfunktionieren und weiterverwenden können.

Mittwoch, 23. März 2016

Boxy Teil 2

Wie versprochen, hier noch ein paar weitere Details zu meinem UMTS-Proxy-Router. Obwohl das Gerät später wohl kaum geöffnet werden wird, habe ich mich (wie üblich) bemüht, alles möglichst ordentlich aufzubauen.
Man sieht hier links das Netzteil, das von einer defekten externen Festplatte stammt. Es liefert (laut Aufdruck) +5V und +12V mit jeweils 2 Ampere, was eigentlich locker reichen sollte. Die 5V speise ich über die Stiftleiste in den Raspberry, weil ich einerseits kein USB-Kabel dafür opfern wollte, und ich wollte die Sicherungen auf dem Raspberry absichtlich umgehen. Denn der UMTS Stick wird später direkt am Raspberry angeschloßen. Sollte das im späteren Testlauf noch Probleme machen, kann ich noch eine Überbrückung mit einbauen und die 5V nochmal direkt an den USB-Port weitergeben. Die 12V wird noch nicht verwendet, da kommt noch eine kleine Platine dran um die 9V für den WLAN-Router zu erzeugen. Hinten sieht man noch das LAN-Kabel das vom Raspberry an den Router geht. Was mir wirklich wichtig war, das die SD-Karte von außen zugänglich sein sollte. Denn es kann immer mal vorkommen, das es dort Fehler im Dateisystem gibt. Für diesen Fall sollte man das Gerät nicht komplett zerlegen müssen, sondern die Karte einfach nur austauschen können. Mein Gedanke ist, das ich mit dem Gerät zwei Karten übergebe. Sollte dann etwas schief laufen, kann der spätere Benutzer das Gerät ausstecken, die Karte tauschen und wieder einstecken, dann sollte alles wieder klappen.
Um das halbwegs schön zu machen, habe ich in die Front einen Schlitz gefeilt. Für sowas habe ich mehrere Sätze von Schlüsselfeilen. Das Ergebnis sieht man hier rechts. Ich glaube das ist mir ganz gut gelungen. Die Tasten im Gehäuse habe ich nicht verwendet. Auch das Fenster, hinter dem früher ein Display saß, bleibt hier unbenutzt. Natürlich hätte ich hier ein LCD mit einbauen können, aber das hätte den Aufwand deutlich in die Höhe getrieben und die Fertigstellung noch weiter verzögert. Das war eigentlich schon die ganze Hardware. Es wäre auch möglich, das WLAN ohne Router mit einem geeigneten Stick direkt vom Raspberry machen zu lassen, aber damit habe ich keine Erfahrung und ich wollte hier einfach auf Nummer sicher gehen und eine mögliche Fehlerquelle ausschließen. Auch hätte ich das mitgelieferte Netzteil des Routers mit hier verbauen können, aber dafür hätte ich es aus seinem Gehäuse entfernen müssen. Das wollte ich vermeiden, weil es ein neu gekauftes Gerät mit Garantie ist. So kann man es eventuell umtauschen, sollte es doch mal ausfallen.
Soviel mal zur Hardware, auf die Software gehe ich dann in einem späteren Post noch getrennt ein.

Dienstag, 22. März 2016

Boxy der Proxy

Mein aktuelles Projekt steht kurz vor der Fertigstellung, und bevor ich es ausliefere, möchte ich es hier noch vorstellen.
Jeder der etwas Erfahrung mit dem mobilen Internet hat, kennt auch die Nachteile. Es ist meistens deutlich langsamer als DSL, die Latenzen sind höher und man hat nur ein begrenztes Datenvolumen zur Verfügung. Das alles macht es als Ersatz für einen Festnetzanschluß fast unbrauchbar. Und genau hier setzt mein Projekt an. Ich nenne es spaßeshalber "Boxy der Proxy".
Das ganze basiert auf einem Raspberry Pi, der als Proxy-Server, UMTS-Router und DNS-Cache fungiert. Dazu kommt noch ein WiFi-Router für das lokale WLAN. Durch den Proxy verringert sich die übertragene Datenmenge teilweise ganz erheblich, und der DNS-Cache verringert die gefühlte Latenz enorm. Der WiFi-Router verteilt die Verbindung dann drahtlos an Handy, PC und Tablet. Damit es auch halbwegs nach etwas aussieht, habe ich das ganze in das Gehäuse eines alten SAT-Recievers eingebaut. Der Router ist oben auf das Gehäuse aufgeklebt, damit es etwas stabil ist. Der UMTS- Stick steckt in einer beweglichen Halterung, damit man ihn bei Bedarf so platzieren kann, das man den besten Empfang hat.
Jetzt fehlt mir nur noch ein kleines Spannungswandler-Modul. Die genaue Konfiguration und den Aufbau der Hardware beschreibe ich dann in einem anderen Post.


Intro

Ich hatte schonmal einen Blog, und hatte dort eine Serie gestartet mit meinen ganzen Elektronik-Projekten. Diese Serie nannte ich Freestyle Electronics, weil ich mich bei meinen Basteleien oftmals nicht an konventionelle Regeln halte. Leider habe ich die gesamten Inhalte verloren als die Plattform blog.de abgeschaltet wurde.
Darum wage ich jetzt hier einen Neuanfang, denn ich werde auch weiterhin Projekte machen und diese mit der Welt teilen. Dabei hoffe ich, das ich vielleicht den einen oder anderen zum nachmachen oder selbst machen anregen kann. Aber vor allem hoffe ich auf Rückmeldungen, Anregungen und Kritik, die mir helfen immer besser zu werden.

Dieser Blog wird in mehrere Kategorien eingeteilt sein, die aber jetzt noch nicht feststehen. Ich werde ziemlich unregelmäßig posten, wann immer ich eben Zeit habe an einem Projekt zu arbeiten. Vielleicht mache ich auch mal das eine oder andere Video, wenn es mir sinnvoll erscheint. Hauptsächlich setze ich aber auf Text und Bilder. Soweit mal zur Planung.

Jetzt hoffe ich das ich bald die Zeit habe mein aktuelles Projekt vorzustellen ...