Als ich die erste Speicherbelegung von Christian sah fiel mir auf dass der Speicher des EEPROMs schon ziemlich voll war. Und da wir gerade so fröhlich am entwickeln waren wurde mir gesagt dass man das sicherlich noch optimieren kann. Ja, und das wurde dann auch immer mal wieder gemacht.
Und ich sach noch: “Der Speicher reicht nicht!”
Und zwar immer genau in dem Moment in dem ich mit dem anpassen fertig war. Sorry Christian, aber das muss jetzt raus. Ja, und dann war es soweit. Der Speicher des Mikroprozessors reichte wirklich nicht mehr, vor allem deswegen weil wir immer wieder neue Ideen hatten die auch gespeichert werden wollten.
Nils und Christian waren aber so vorausschauend einen Prozessor zu nehmen den es in verschiedenen Ausführungen gibt. Die Pinbelegung war bei allen gleich so dass nur noch die Firmware neu kompiliert werden musste. Wir nahmen nicht den nächst größeren sondern den übernächst größeren, jetzt hatten wir 4-mal soviel Speicher. Tja, cool dachte sich Christian, jetzt kann ich ja die Doppelbelegungen wieder entfernen. Gedacht (natürlich nicht abgesprochen) und getan! Und was ist mit mir? Ich hatte mal wieder die Hosen unten und musste erneut mein Konzept überarbeiten. Diesmal war es aber wirklich das letzte Mal.
Es blieb mir nichts anderes übrig als alle Einstellungen in einer Datenbank zu verwalten denn es sind mittlerweile über 650 Einstellpunkte! Ist aber so eine Datenbank inkl. Suchroutinen erst mal programmiert, wird alles sehr einfach und übersichtlich. Desweiteren habe ich eine mks Klasse programmiert die alles Einstellungen quasi als Objekt darstellt. Neuerungen und/oder Änderungen können jetzt sehr schnell implementiert werden. Irgendwann war der Zeitpunkt gekommen in dem wir alle auf einem Nenner waren und alles wurde im Vorfeld abgesprochen.
Als die erste Version funktionierte wurde uns erst einmal das ganze Potential bewusst. Es ist ein großer Unterschied ob man Einstellungen per HEX-Editor im Speicher macht oder einfach per Pull-Down-Box einstellt. Das testen der Funktionen ging ab diesem Zeitpunkt schnell von der Hand. In der Testphase am Anfang war auch abzusehen dass es sehr gut wäre ein paar Situationen aufzuzeichnen. Z.B. einen Failsafezähler der einem nach der Fahrt Rückschlüsse über die Funkverbindung gibt. Auch ein Zähler, der jedesmal erhöht wird wenn die Bordspannung unter den unteren Schwellwert rutscht, wurde eingebaut.
Übersicht im Vordergrund
Wenn man 6 Eingänge und 22 Ausgänge hat wird einem recht schnell klar dass wahrscheinlich die Übersicht leidet. Dies wollte ich vermeiden, deswegen habe ich editier bare Bezeichnungen eingebaut die auch auf den Buttons zu lesen sind. Ich wollte nicht dass man immer in einer Liste nachschauen muss auf welchem Ausgang (Button) das Schnorchelkopfventil liegt. Und dies ist nicht nur bei den Ausgängen sondern auch noch bei den Eingängen und Funktionen.
Diagnose muss sein!
Ich habe beim Testen schnell gemerkt dass es nicht immer möglich ist auf die bunten Lichter des mks zu schauen. Wenn das Boot zu ist geht das nicht. Deswegen hab ich eine Diagnose eingebaut die den Status der Ein- und Ausgänge anzeigt. Dazu muss allerdings noch ein Kabel aus dem Boot führen, bei einem Pressluftboot Mentzscher Bauart ist das leicht möglich. Gleichzeitig werden auch die Spannungen an den Eingängen angezeigt, sowie Failsafe- und Unterspannungszähler.
Allerdings war es immer noch schwierig die Hysterese der Eingänge zu testen, dies lag daran dass die aufgeschriebenen Schwellwerte recht geschrieben aussehen. Ich wollte was grafisches, sowas hatte ich noch nicht gemacht. Ich entschloss mich eine Art Monitor zu programmieren, ähnlich wie bei einem Oszilloskop. Auf diesem Monitor sollten man Schwellwerte und die aktuelle Spannung ablesen können. Es war gar nicht mal so schwer die Routinen dazu zu schreiben. Und ich glaube das Ergebnis kann ich sehen lassen. Das Testen der Eingänge, Schwellwerte und Hysterese war hiermit sehr viel einfacher. Auch wurden noch kleinere Fehler entdeckt und so manches doch noch mal umgeworfen weil es mehr Sinn machte.
Die Daten
Natürlich lässt sich jede Konfiguration abspeichern und laden. Man kann zwar auch die Daten aus dem mks auslesen, die Anschlussbeschreibungen werden allerdings nicht übermittelt. Dafür ist im Mikroprozessor beim besten Willen kein Platz. Beim einspielen der Konfiguration in dem mks werden die Daten sofort wieder ausgelesen und byteweise verglichen. Danach werden nochmals die berechnete Checksumme des mks und die des Programms verglichen. Erst wenn alle Vergleiche erfolgreich sind bekommt man eine positive Meldung angezeigt. Den Datenvergleich kann man jederzeit auch einzeln durchführen.
Funktionsumfang
- 5 analoge Eingänge mit denen man Spannungen von 0-35V messen kann
- 1 analoger Eingang, gekoppelt mit der Versorgungsspannung
- 16 direkt schaltbare Ausgänge
- 5 Ausgänge die programmgesteuert schaltbar sind
- 1 Flip-Flop Ausgang
- Alle Ausgänge können mit 1 Ampere belegt werden.
Dies ist die kleine Geschichte hinter der Entwicklung eines anpassbaren Mehrkanalschalters für U-Boote mit Presslufttechnik. Wir kombinierten unsere Fähigkeiten und schafften eine wunderbare Elektronik. Nils Canditt war für das Hardware-Layout verantwortlich. Christian Feldmann programmierte die Firmware für den Mikroprozessor und ich schrieb die PC Software mit der man den MKS programmieren kann. Sascha Amberger testete den MKS auf Herz und Nieren in seinem U-Boot mit dem Risiko es wegen eines Softwarefehlers zu verlieren. Aber alles lief reibungslos und funktionierte von Anfang an unglaublich Zuverlässig. Dieses Projekt brauchte gerade mal eine Wintersaison um sieben Prototypen nebst Software funktionsfähig zu bauen.
Nachdem sich der MKS in vielen Booten bewährt hat wurde es Zeit dieser Hardware einen Namen zu verpassen. MKS war eigentlich nur interne Name. Wir entschlossen uns den Namen an die Software anzupassen:
- Zentrale Software
- Zentrale RX
- Zentrale Mini RX
- Zentrale TX