Sonntag, 21. September 2014

Nachtrag: 6. Überraschung (Bugfix verschlimmbessert die Bildqualität)

Die Beseitigung dieses Problem hat die Fertigstellung des Gehäuseeinbaus maßgeblich verzögert.

Begonnen hatte es mit diesem Fehlerbild: Wurde der TFT-Maximite mit einer normgerechten Versorgungsspannung von 5V betrieben fing das Bild an zu springen oder zu zittern. Die Sprünge traten unregelmäßig ca. 2-20 mal in 10 Sekunden auf, aber immer exakt um eine Zeile nach unten. Bei 4,5V oder weniger war das Bild dagegen einwandfrei. Betroffen waren einige aber nicht alle TFT-Maximite der rev. 1.3.

Bei segor bin ich auf einen Bugfix von Carsten Meyer gestoßen, der das Problem beheben sollte. Dazu musste man ein paar Bauteile (natürlich SMD) auslöten und mit einem neuen Bauteil anders wieder einlöten. Auf der Platine sieht das dann so aus:

Ausgangssituation, Platine rev. 1.3

Bugfix durchgeführt

Leider hat der Bugfix das Problem aber dahin gehend verändert, dass das Bild dauerhaft um eine Pixel-Zeile verschoben war, eine ziemliche Katastrophe!


Verschlimmbesserung durch den Bugfix: Die letzte Bildzeile fehlt dauerhaft!


Nach längeren Messungen und Diskussionen im Forum habe ich den zusätzlichen 1kOhm Widerstand durch ein 500Ohm Poti ersetzt.

R23 ersetzt durch ein 500Ohm Pot


Der folgende Abgleich war zwar etwas frickelig, führte aber zum Erfolg:

  • Erst mit R6 (das Poti, das schon vorhanden war) das Bild horizontal verschieben bis alle Pixelspalten ohne Farbränder zu sehen sind.
  • Dann mit R23 (das neue Poti) die vertikale Lage nachstellen.
  • Da dabei aber die horizontale Bildlage beeinflusst wird muss diese wieder nachgestellt werden, was wiederum zu einer vertikal-Korrektur führt und so weiter … 
kurz: Man muss geduldig optimieren. Bei mir hat's ca. 1/4h Dafür hat man am Ende aber ein dauerhaft stabiles Bild mit allen Zeilen und Spalten.

Betroffen von dem Problem sind einige TFT-Maximite der rev. 1.3, aber nicht alle. Ob der Fehler auch bei rev. 1.4 auftritt kann ich nicht sagen. Da dort der Bugfix aber standardmäßig verbaut ist, ist es aber durchaus möglich.


Der Originalpost findet sich hier: 6. Überraschung: Bugfix verschlimmbessert die Bildqualität

Sonntag, 14. September 2014

Änderung der Einstellungen dieses Blogs

Nachdem mich über Umwege konstruktive Kritik erreicht hat, habe ich die Einstellungen für diesen Blog angepasst:

Ab sofort ist es auch tatsächlich möglich Kommentare zu schreiben.

Weiterhin habe ich mein Profil korrigiert. Jetzt wird dort auch meine E-Mail-Adresse angezeigt.

Wer also Kritik, Fragen oder Anregung hat kann sie jetzt ohne Umwege loswerden.

Der Gehäuseeinbau – Teil 2 : Die Seitenteile

Nachdem ich endlich wieder Zeit und Gelegenheit hatte mechanische Arbeiten auszuführen habe ich endlich die Seitenteile in Angriff genommen.

Zwischenzeitlich sind mir natürlich noch ein paar Idee gekommen, die mit eingearbeitet wurden.

Seitenteil links

Auf der linken Seite ist noch ein Anschluss für PL7 hinzugekommen. Ursprünglich ist der Anschluss als Schnittstelle zum c't-Lab vorgesehen. Ich verwende ihn aber um auf einem relativ schlanken (und damit auch leichtgewichtigen) Stecker die verschiedenen Bus-System (z.B. I2C) herauszuführen.

Seitenteil rechts

Auf der rechten Seite sind noch die beiden LEDs hinzugekommen sowie der Anschluss für die Stromversorgung.

Die fertigen Seitenteile sehen so aus:

die beiden Seitenteile, oben das linke, unten das rechte

Beim rechten Seitenteil ist mir ein Malheur passiert. Ich habe die Bohrungen für LED und Strombuchse verwechselt und das Ganze natürlich erst bemerkt, als alles fertig war. Was macht man in so einem Fall? Man stopft das irrtümlich raus gebohrte Material wieder rein und bohrt noch einmal.

Auch wenn es auf dem Bild so aussieht, ganz so einfach war es dann doch nicht. Letztendlich habe ich aus einem Ausschnitt aus dem linken Seitenteil eine Stück zugeschnitten bzw. zugefeilt und eingepasst.

Fertig bestückt und eingebaut sieht das dann so aus:

Die Seitenteile montiert

Blick in das Gehäuse ohne Deckel

alles zusammengebaut

Was noch fehlt:
  • eine vernünftige Displayschutzfolie anbringen (momentan klebt noch die Schutzfolie von der Auslieferung drauf)
  • Reset- und Bootloader-Taster einbauen
  • Akku einbauen

Samstag, 19. Juli 2014

Üble Überraschung: Irgendwas hat auf der SD-Karte randaliert

Das Problem

Da schaltet man den TFT-Maximite ein, lädt ein Programm von der SD-Karte, lässt ihn schöne Grafiken auf das Display mahlen (ohne irgendeinen Zugriff auf die SD-Karte) und nach dem Neustart (Stromversorgung kurz abgeklemmt) startet die AUTORUN.BAS nicht mehr. Nach mehreren vergeblichen Resets und Karte-raus-Karte-wieder-rein-Aktionen findet diese dann den Weg in einen Kartenleser und ein Blick auf den Computermonitor lässt einem das Herz in die Hose rutschen:

Auf der Karte befinden sich nur noch ein paar einzelne Dateien im Hauptverzeichnis. Alle Unterverzeichnisse und v.a. alle Basic-Dateien aus dem Hauptverzeichnis fehlen!

Ein erster Versuch mit „testdisk“ die gelöschten Dateien wieder herzustellen schlägt unerwartet fehl, es werden keine gelöschten Dateien gefunden.

Ein genauerer Blick mit dem Hexeditor offenbart das gesamte Ausmaß der Katastrophe:
  • Die FATs stimmen nicht mehr überein, einzelne Bereiche sind mit Nullen überschrieben.
  • Das gleiche Bild im Hauptverzeichnis, auch hier stehen Nullen wo keine sein sollten.
  • Im Datenbereich gibt es aber viele Sektoren die nicht nur Nullen enthalten.

Vorsichtige Entwarnung, allerdings mit sofortiger Ernüchterung

Das heißt also, die eigentlichen Daten sind höchst wahrscheinlich noch vorhanden, es fehlt aber die Zuordnung welche Cluster eine Datei bilden, wo auf dem Speichermedium sie liegt und wie sie heißt. Wenn die Dateien nicht zu stark fragmentiert waren (am Besten natürlich gar nicht) bestehen noch Chancen die Daten zusammen zu kratzen. Man müsste doch blos, ...

Im Prinzip ja, aber berücksichtigt man die Größe der SD-Karte wird einem sehr schnell schwindelig: Die SD-Karte ist mit 2GB zwar relativ klein, das heißt aber trotzdem, dass es ca. 4.000.000 Sektoren gibt die zu 65.000 clustern zusammen gefasst sind!

Selbst wenn man schnell ist und nach durchschnittlich 10 Sekunden ein cluster zuordnen könnte (neue Datei oder Fortführung der alten Datei) bräuchte man bei 4h täglich 1,5 Monate! Sobald allerdings die kleinsten Komplikationen auftreten explodiert die nötige Zeit. Es reicht schon, wenn in einem Cluster noch die Reste von alten Daten enthalten sind. Und bei fragmentierten Binärdateien wird es sowieso zu einem Ding der Unmöglichkeit die von Hand wieder zusammen zu setzen!!!

Also doch alles im Eimer??????

Die Lösung

Zum Glück gibt es tools die einem helfen. Außerdem hilft es ungemein, wenn man genau weiß, nach was man sucht.

Tools

Ein sehr gutes tool kommt zusammen mit „testdisk“ und heißt „photorec“. Ursprünglich entwickelt um verschwundene Photos auf Speicherkarten wieder aufzuspüren kann es mittlerweile auch andere Dateien aufstöbern. Es nimmt sich hierzu z.B. das FAT vor, hangelt sich durch die noch vorhanden Verweise und setzt auf diese Art die Dateien wieder zusammen. Das funktioniert auch wenn das Hauptverzeichnis korrumpiert ist, setzt allerdings ein intaktes FAT voraus. Es kann aber auch das Speichermedium komplett abklappern und raten, was mal was war (Bild, Text, etc.) und was mit wem zusammen gehört. Allerdings kommt hierbei je nach Zustand des Speichermediums (viele gelöschte Dateien, fortgeschrittene Fragmentierung) viel Müll heraus.

Bei mir hat das Durcharbeiten des FAT schon mal ca. 90% der Dateien wieder hergestellt. Dummerweise haben aber einige wichtige Dateien gefehlt.

A priori-Wissen

An diesem Punkt kommt das Wissen um die fehlenden Daten ins Spiel. Bei mir waren es ausschließlich BASIC-Dateien die noch fehlten. Quellcode kann man mit einem hex-Editor sehr einfach aufspüren, wenn man nach den entsprechenden Schlüsselwörtern sucht. Bei MMBasic für einen TFT-Maximite sind das z.B. „touch“. Hinzukommen noch „print“ und z.B. „cls“. Außerdem sind die Dateien sehr selten größer als 32kB und somit immer in einem einzelnen cluster enthalten und nicht über mehrere verteilt.

Wenn man dann noch einen halbwegs vernünftigen Editor hat, bei dem man z.B. den dargestellten Bereich auf Sektor-Größe oder ein Vielfaches davon einstellen kann hilft das ungemein. Auch eine Volltextsuchfunktion die Groß- und Kleinschreibung ignorieren kann ist extrem hilfreich.

khexedit mit den ersten 1024Byte (zwei Sektoren bzw. 1/32-Cluster) des Programms „COLRDEMO.BAS“

Damit konnte ich dann auch noch die restlichen Basic-Dateien deren FAT-Einträge korrumpiert waren aufspüren und sichern. Das hat dann zwar knapp. 3 Stunden gedauert, dafür hatte ich aber auch wirklich alle Dateien wieder.

Fazit

Was genau warum auf meiner SD-Karte passiert ist kann ich nicht mehr nachvollziehen. Ich werde aber in Zukunft darauf achten, die Programme auch noch anderswo zu speichern. Denn obwohl ich diesmal mit einem blauen Auge und ohne Datenverlust davon gekommen bin will ich soetwas nicht noch einmal erleben, einmal reicht!!!

Sonntag, 22. Juni 2014

6. Überraschung: Bugfix verschlimmbessert die Bildqualität

Der Gehäuseeinbau ist immer noch nicht abgeschlossen. Grund dafür ist, dass ich, wie im letzten Post kurz angesprochen, Probleme mit dem Display hatte. Da ich hierfür ständig am Messen war war ein Gehäuse nur hinderlich.

Das Fehlerbild war Folgendes: Wurde der TFT-Maximite mit einer normgerechten Versorgungssapnnung von 5V betrieben fing das Bild an zu springen oder zu zittern. Die Sprünge traten unregelmäßig ca. 2-20 mal in 10 Sekunden auf, aber immer exakt um eine Zeile nach unten. Bei 4,5V oder weniger war das Bild dagegen einwandfrei.

Das Problem war seit der ersten Inbetriebnahme vorhanden. Da ich anfangs aber eine geringere Versorgungsspannung auf der Platine hatte (siehe 2. Überraschung: USB-Verbindung funktioniert nicht) trat das Problem nicht in Erscheinung. Seit Verwendung der neuen Stromversorgung störte es aber massiv.

Durch Zufall bin ich bei segor auf die Beschreibung eines Bugfixes zum Thema Bildzittern gestoßen (http://www.segor.de/#/bauteilesaetze-a-module/bauteilesaetze/269-tft-maximite-bugfix). Das Phänomen wird dort nur diffus als „Bildzittern bei verschiedenen Stellungen des Abgleichreglers“ beschrieben. Meine Frage ob mit „Bildzittern“ „Bildsprünge um eine Zeile nach unten“ gemeint ist und ob das durch den Bugfix behoben werden würde wurde ich von segor an Carsten Meyer verwiesen. Dessen Antwort war kurz und knapp „Ja.“ kam allerdings erst auf ausdrückliches Nachhaken.

Der Bugfix ist ähnlich delikat in der Umsetzung wie die Reparatur von Pin 20 (siehe 3. Überraschung: Pin 20 funktioniert nicht). Wirken tut er auch. Das Bild springt nicht mehr ständig um eine Zeile nach unten, es ist dauerhaft um eine Zeile nach unten verschoben. So war das nicht geplant!!!

Da Nachfragen bei Carsten Meyer bis heute unbeantwortet blieben und in den einschlägigen Foren auch nichts Brauchbares zu finden war musst ich selbst kreativ werden. Anscheinend werden durch die Entlastung des Vsync-Pins die Flanken der Signale so weit verschliffen, so dass die Synchronisation nicht mehr sauber funktioniert.

Ein der möglichen Gegenmaßnahmen ist den neu eingefügten 1k Widerstand durch ein Poti zu ersetzen. Alternativ könnte man auch versuchen C6 zu verkleinern. Da ich kein Sortiment an SMD-Kondensatoren habe, habe ich erst einmal die erste Möglichkeit gewählt. Durch den zusätzlichen Freiheitsgrad wird die Justage nicht einfacher, letztendlich war sie aber von Erfolg gekrönt: Ein dauerhaft einwandfreies Bild, ohne temporär oder dauerhaft fehlende Bereiche, und das unabhängig von der Versorgungsspannung.

Bilder von der Lötaktion gibt es demnächst.

Leider konnte ich nicht klären, ob das Problem durch fehlerhafte Ansteuerung des Displays oder durch mangelhafte Auswertung der Signal vom Display verursacht wird.

Donnerstag, 12. Juni 2014

Kleiner Einschub: Spannungsversorgung

Ursprünglich wollte ich in dem Gehäuse noch 4 Mignon-Akkus unterbringen, um auch mal einen Betrieb abseits der Steckdose zu ermöglichen. Allerdings hat sich schon recht bald gezeigt, dass das wegen des beschränkten Platzes wohl nichts wird. Eine Alternative wäre ein LiPo-Akku gewesen, allerdings hätte der eine Reihe von Nachteilen mit sich gebracht (sehr empfindlich gegenüber Tiefentladung, aufwändige Überwachungs-Elektronik, ...). Außerdem wollte ich nicht ständig auf das Labornetzteil bzw. auf meine einzige Wandwarze mit 5V-Ausgang angewiesen sein. Also musste ein Spannungsregler her.

Da die Schaltung einen möglichst hohen Wirkungsgrad haben sollte (Akku-Betrieb!) wäre eigentlich ein Schaltregler das Mittel der Wahl gewesen. Allerdings sind die nicht unkompliziert aufzubauen. Und ein Fertigmodul hatte ich nicht zur Hand.

Normale Linearregler (78xx) benötigen nur sehr wenige Bauteile, verursachen aber von sich aus schon einen relativ hohen Spannungsabfall (2-3V) und verheizen dementsprechend unnötig viel Leistung. Und je höher die Eingangsspannung, desto schlechter der Wirkungsgrad.

Einen Kompromiss bieten die sogenannten lowdrop-Regler. Als Linearregler benötigen sie nur sehr wenige weitere Bauteile (meistens nur 2 Kondensatoren). Darüber hinaus liegt der von ihnen verursachte Spannungsabfall deutlich unter 1V, d.h. man erhält schon mit weniger als 8V saubere 5V. Aber die Spannungsdifferenz wird natürlich trotzdem vollständig in Wärme umgesetzt.

Meine Wahl fiel auf den L4940V5. Er verträgt bis zu 2A und bei 500mA reichen 5,2V um stabile 5V zu erhalten. Bei 300mA sind es sogar nur 0,14V Spannungsabfall. D.h. wenn man 5,0V als Eingangsspannung anlegt liegen am Ausgang immer noch 4,86V an. Das reicht für den TFT-Maximite noch aus um fehlerfrei zu arbeiten.

Beschaltung des L4940V5

Mit nur zwei zusätzlichen Bauteilen hält sich der nötige Aufwand sehr in Grenzen. Dadurch kann die Schaltung auch schnell auf einem Stück Lochrasterplatine aufgebaut werden.

Beschaltung des L4940V5

Sonntag, 1. Juni 2014

Firmware Update - V4.5

Vor drei Tagen hat Geoff Graham eine neue Version von MMBasic veröffentlicht. Die Version 4.5 bringt einige Neuerung und Bugfixes mit sich. Das zugehörige Changelog ist volle 1,5 Din A4 Seiten lang. Die meisten Neuerungen sind dem Micromite geschuldet.

Hier die wichtigsten Neuerungen in Kürze:
  • Unterstützung für neue Hardware (z.B. Sony-kompatible IR-Signale decodieren und codieren, Ultraschall-Entfernungssensors HC-SR04, LC-Displays, einfache Matrix-Tastaturen, Drehencoder, ..)
  • Syntax-Änderung der I2C- und 1wire-Befehle
  • zahlreiche Bugfixe für den TFT-Maximite, darunter die Aktivierung der Pins jenseits der 20
Der letzte Punkt dürfte wohl alle TFT-Maximite-Besitzer freuen. Es ist jetzt möglich die Pins 21 aufwärts bzw. D1 aufwärts zu verwenden. Das war bisher nur mit einer selbst gebauten MMBasic-Version möglich. Darüber hinaus wurde die letzte Version der Touch-Funktionen implementiert, welche aber leider uralt und fehlerbehaftet sind (siehe z.B. http://raketenbuggy.blogspot.de/2014/02/4-uberraschung-touch-objekte-konnen-tft.html). Aber da diese von Carsten Meyer erstellt wurden kann sich Geoff da nichts aus dem Ärmel schütteln, sprich: Wenn's kein update gibt kann er auch Keins einbauen.

Der wichtigste Punkt ist wahrscheinlich die Syntax-Änderung bei den I2C- und 1wire-Befehlen. Die Änderungen sind so umfangreich, dass alte Programme, die I2C oder 1wire verwenden nicht mehr funktionieren. Geoff schreibt hierzu im Changelog ausdrücklich:

"If you have an existing program that makes heavy use of the I2C protocol it might be worth not upgrading if you do not need any of the other features that this version offers."
„Wenn man Programme hat, die oft das I2C-Protokoll verwenden, kann es sich lohnen auf das Update zu verzichten wenn man nicht die eine oder andere neue Funktion braucht, die diese Version bietet.“

Das hört sich jetzt schlimm an, ist aber in der Realität nicht ganz so wild. Es haben sich größtenteils nur die Namen der Kommandos geändert, die Struktur ist gleich geblieben. Z.B heißt das Kommando um I2C zu aktivieren jetzt „I2C OPEN “ statt „I2CEN“ und „I2C WRITE“ ersetzt „I2CSEND“, d.h. größtenteils lässt sich das durch suchen-und-ersetzen anpassen.

Allerdings gibt es Ausnahmen:
  • Im Master-Mode kann man keine Interrupts mehr definieren
  • Das Empfangs-Kommando im Master-Mode erlaubt es nicht mehr vorher mit dem gleichen Kommando Daten zu senden. Dafür ist jetzt ein extra Sende-Kommando erforderlich.
Ansonsten läuft die neue Version bei mir problemlos. Leider bin ich mit dem Gehäuse-Einbau noch nicht weiter gekommen. Ich kämpfe noch mit einem Problem (das Display spinnt ab und an), bei dem ich noch nicht weiß woher es kommt (vom Display oder vom Board) und was man dagegen machen kann.

Das update für den TFT-Maximite kann man übrigens hier herunterladen:
http://geoffg.net/tft-maximite.html

Gebraucht wird die Version ohne Bootloader, die im oberen Teil der Seite verlinkt ist.