Terran
Active Member
- Joined
- Oct 30, 2009
- Messages
- 527
- Age
- 32
EvilDragon [Englischer Beitrag] said:Sorry for the loooooong time without an official blog update - it's not the case that so little happened that there was nothing to post... the problem was, that I had so much work to do because so many things moved forward, that I didn't find the time to actually post an update.
Additionally, end of the year always means you need to do your bookings and stocktaking... so that needed quite a bit of time as well.
Well, as so many things have happened, I'll spread those over multiple blog posts once again.
Let's start with...
1. The PCBs
As mentioned last time, the layout for the main PCB has been finished and the PCBs and all parts except for one coil are already here with us.
Yep, it's a simple coil that's out of stock right now, but it's ordered and will arrive early February, which means it's prototype time!
Nikolaus is working on the CPU PCB right now and about half-way through, which means he should be finished roughly middle to late February.
The ordered OMAP5 are already on the way to us, so it looks like CPU PCBs we'll see a prototype release in February as well (except one other part will get a delay, which is something you never know when doing prototypes).
Well - these PCBs will most probably be the last revisions before the mass production (unless there are some serious errors), so we're moving forward here.
2. The display and the rotator
Thanks to the awesome help of the BOE team, we were able to include the correct initialization sequence in our driver and the display is now working perfectly.
We need a bit more work to use the rotator chip though.
It should be easy - but once again we are able to proof that Murphys Law is always true!
Now things get a bit technical - if you want to know what exactly is going on, read the spoiler
So, let me explain how it should work in theory:
The routing of the Video signal is:
OMAP5 -> Rotator Chip -> Display
The signal is being sent via MIPI. MIPI is a digital standard that allows to send commands (like enable / disable rotation, change backlight, change powersaving settings, etc.) as well as a video signal.
The first thing to do to make a display work at all is to send an initialization command, so that it switches on, configures itself and accepts the MIPI Video signal.
This is what I mentioned above which is already working fine.
Then we got the rotator chip inbetween. We need to be able to send commands both to the rotator chip and the the display.
To be able to do that, Solomon (the manufacturer of the chip) implemented an easy way to do that:
There's a bypass mode, so that all commands will be directly sent to the display.
To to initialize our display, we need to switch the rotator chip to bypass mode, send the initialization sequence, disable bypass mode and enable the rotation.
The bypass mode can be enabled or disabled with a command sequence. The sequence starts with 0xFF.
This would in theory work perfectly fine - but the initialization of the display ALSO starts with 0xFF.
Solomon also thought of that. In order to send a MIPI command sequence that starts with 0xFF, you simply send 0xFF twice.
So far no problem. However: MIPI command sequences have a maximum length of four bytes. And the initialization command sequence of our display uses the full four bytes.
Now THAT'S a problem: As we need to send 0xFF twice to tell the Solomon chip to pass through, we can only send a sequence of three bytes.
So... Murphys Law has fully struck us.
By chance we got the worst combination possible:
If the initialization command sequence of the display wouldn't start with 0xFF (or the Solomon chip would use a different byte for the bypass command), it would work without issues.
And even then - if the sequence would only be 2 or 3 bytes long, it would STILL work. A start with 0xFF and 4 bytes long however is the ONLY combination that doesn't work!
So, yay for this! I should really start playing the lottery!
But don't be afraid - there's a solution for this.. it just means a bit of more work for us: We can flash the display driver IC so that it initializes the panel automatically as soon as it is connected.
In order to use the Solomon chip, we need to flash the driver IC of the LCD.
This is no problem in mass production, as BOE will do it for us - however, for our prototype panels, we need to do that ourselves.
It's not that complicated, but we need to modify one of our display PCBs for that.
We decided to do that AFTER the CPU PCB is finished, so we can't test the rotation chip before end of February (probably).
Both BOE and Solomon are giving us GREAT support here, that's awesome
3. The touchscreen
Upon testing, we found that the first touchscreen we received for our displays was not responsive enough.
It's similar to a batch of Pandora touchscreens we had: It works fine with the stylus, but doesn't really react to your fingers (unless you press really hard).
It took about only two weeks to get new samples of a different touchscreen - and it works a lot better.
Nikolaus tested it and according to him, it works a LOT better (and reacts to your finger gestures as well).
I'll pay him a visit this week to check it out myself and make sure it works fine.
So, today's newspost gave you the current information about the PCBs, the display including the rotator chip and the touchscreen.
Coming soon: The case, the battery and the LCD Cable.
Feel free to ask any questions here, as usual
Übersetzung said:Entschuldigung für diese laaaaaange Wartezeit, ohne ein Blog-Update - es ist nicht so, als ob nichts passiert wäre..., das Problem war, dass ich so viel zu tun hatte, da vieles Vorangeschritten ist, dass ich keine Zeit gefunden habe etwas zu posten.
Hinzu kommt, dass das Ende des Jahres Inventur und Verbuchungen bedeuten... das hat also auch Zeit in Anspruch genommen.
Da so viel geschehen ist werde ich das wieder auf mehrere Posts aufteilen.
Last uns starten...
1.) Die PCBs
Wie letztens angemerkt ist das Layout des Main-PCBs fertig, alle Bauteile und das PCB, bis auf eine Spule, sind bei uns.
Jep, es ist eine einfache Spule die ausverkauft war, aber sie ist bereits bestellt und wird anfangs Februar ankommen, das heißt es ist Prototyp-Zeit!
Nikolaus arbeitet momentan am CPU-PCB und ist ca. zur hälfte fertig, das bedeutet wir sollten ungefähr Mitte bis Ende Februar fertig sein.
Die bestellten OMAP5 sind schon auf dem Weg zu uns, es sieht so aus, als ob das CPU-PCB ebenfalls im Februar einen Prototypen bekommt (außer ein anderes Bauteil verspätet sich, das ist etwas, das kann man nicht wissen).
Diese PCBs werden wohl die letzte Revision sein, bevor es in die Massenproduktion geht (außer es gibt grobe Fehler), wir kommen hier also voran.
Das Display und der Rotations-Chip
Dank der sehr guten Hilfe des BOE-Teams haben wir es geschafft die korrekte Initialisierungssequenz in unseren Treiber zu integrieren und unser Display nun perfekt funktioniert.
Beim Rotations-Chip benötigen wir noch etwas Arbeit.
Es sollte einfach sein - aber wieder einmal zeigt sich Murphys Gesetzt als wahr!
Nun wird es etwas technisch - wenn ihr es genauer wissen wollt, lest den Spoiler
Lasst mich erklären, wie das Ganze in der Theorie funktioniert:
Das Videosignal sollte folgenden Weg gehen:
OMAP5 -> Rotations-Chip -> Display
Das Signal wird über MIPI gesendet. MIPI ist ein Standard der es erlaubt Kommandos (wie Rotation ein-/ausschalten, Hintergrundbeleuchtung ändern, Sparmodus einstellen, usw.), als auch das Videosignal zu senden.
Als erstes, damit das Display funktioniert, muss man ein Kommando zur Initialisierung senden, damit es sich einschaltet, sich konfiguriert und das MIPI Videosignal annimmt.
Das ist das, was ich oben angesprochen habe und bereits funktioniert.
Nun haben wir einen Rotations-Chip dazwischen. Wir müssen beide Kommandos zusenden können, dem Rotations-Chip und dem Display.
Um das zu machen hat Solomon (der Hersteller des Chips) einen einfachen Weg implementiert:
Es gibt einen Bypass-Mode, damit können alle Kommandos direkt zum Display gesendet werden.
Um unser Display zu initialisieren müssen wir den Rotations-Chip ins Bypass-Mode schalten, das Kommando zur Initialisierung senden und den Bypass-Mode ausschalten und die Rotation einschalten.
Der Bypass-Mode kann mit einem Kommando ein-/ausgeschaltet werden. Diese Sequenz startet mit 0xFF.
Das würde in der Theorie perfekt funktionieren - aber die Initialisierung des Displays startet EBENFALLS mit 0xFF.
Solomon hat das bedacht. Bei MIPI Kommandos, die mit 0xFF starten, wird einfach zweimal 0xFF gesendet.
Bis jetzt kein Problem. Wie auch immer: MIPI Kommandos haben eine Maximale länge von vier Bytes. Das Kommando zur Initialisierung von unserem Display verwendet alle vier Bytes.
DAS ist nun ein Problem: Da wir 0xFF zweimal senden müssen, um dem Solomon Chip zu sagen, dass er durchschalten soll, können wir nur drei Bytes senden.
So... Murphys Gesetz hat eingeschlagen.
Wir haben die schlechteste mögliche Kombination:
Wenn das Kommando für das Display doch nicht mit 0xFF (oder der Solomon Chip ein anderes Kommando hätte) starten würde, hätte das ohne Probleme geklappt.
Selbst dann - wenn die Sequenz nur zwei oder drei Bytes lang wäre, es hätte DENNOCH funktioniert. Ein beginn mit 0xFF und vier Bytes lang ist die EINZIGE Kombination, die nicht funktioniert!
Juhu! Ich sollte wirklich Lotto spielen!
Aber keine Angst - es gibt dafür eine Lösung. Es bedeutet nur mehr Arbeit für uns: Wir können den Displaytreiber IC flashen, damit sie das Panel automatisch bei Verbindung initialisiert.
Um den Solomon Chip verwenden zu können, müssen wir den Treiber IC vom LCD flashen.
Das ist in der Massenproduktion kein Problem, da BOE das für uns macht - für unsere Prototypen müssen wir das selbst machen.
Es ist nicht so kompliziert, aber wir müssen ein Display PCB modifizieren.
Wir haben beschlossen, das NACH der Fertigstellung des CPU-PCBs zu machen, wir können den Rotations-Chip nicht vor ende Februar (wahrscheinlich) testen.
BOE und Solomon geben uns einen großartigen Support
3.) Der Touchscreen
Durch testen haben wir herausgefunden, dass der erste Touchscreen den wir bekommen, nicht gut genug reagiert.
Es war so ähnlich, wie bei einer Lieferung bei der Pandora: Es hat mit dem Stylus gut funktioniert, aber nicht wirklich auf Finger (außer man drückt sehr fest).
Es dauerte nur zwei Wochen, bis wir ein neues Muster eines anderen Touchscreens bekommen haben - der funktioniert viel besser.
Nikolaus hat ihn getestet und laut ihm ist der viel besser (und reagiert auch auf Fingergesten).
Ich werde ihn diese Wochen besuchen und mir selbst einen Eindruck verschaffen.
So, heute gab es neue Informationen zu den PCBs, dem Display mit Rotations-Chip und Touchscreen..
Bald: Das Gehäuse, der Akku und das LCD-Kabel.
Wie immer, nur her mit den Fragen
Blog
Quelle
