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 don't want to know exactly what's going on, skip the next section.

--------------- START OF TECHNICAL DETAILS ---------------

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.

------------------- END OF TECHNICAL DETAILS --------------------

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 :)

Discuss about that post on the webboards: http://boards.openpandora.org/topic/17697-of-boards-and-displays/

Follow me on twitter for short news inbetween: https://twitter.com/EvilDragon1717