Of boards and displays


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
46
Location
Ingolstadt
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 :)
 
What about the telephony chip? Will there be a US version of the Pyra for US phone networks? Sorry for off topic, but I really need to know, since I want to replace my phone.
 
What about the telephony chip? Will there be a US version of the Pyra for US phone networks? Sorry for off topic, but I really need to know, since I want to replace my phone.
Well, I first need to find out what's so special about US - but we can use all of the 3G/4G chips available from the same manufacturer - they're pin compatible.
 
What about the telephony chip? Will there be a US version of the Pyra for US phone networks? Sorry for off topic, but I really need to know, since I want to replace my phone.
Well, I first need to find out what's so special about US - but we can use all of the 3G/4G chips available from the same manufacturer - they're pin compatible.
THANKS! This makes me feel a lot better. All you really need to know, is the US uses a different set of frequencies for some backwards reason, so US customers need their Pyras to have the PLS8-US or the PHS8 chip. We can't use the PLS8-E one for anything.

And congratulations getting the rotator working!
 
Last edited by a moderator:
good morning and wooohoooooooo... for progress!


ps.


down with murphy!


;)
 
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.
So its settled that the Pyra will get the BOE Display ?
 
The bypass mode can be enabled or disabled with a command sequence. The sequence starts with 0xFF
Surely the bypass mode should have been a MIPI command in it's own right - ie. send 0xFFFEEEEF to enable bypass, then the rotator redirects all commands onwards, except another bypass command, which switches it back.

That would have been the sensible, and easy thing to do IMO
 
Gread News, hopefully this tiny little coil will be delivered soon.., everytime it lacks on this little things..

Looking forward to End February, mybe then whe will see the first real prototypes who dosnt need the Devboard....

Whit Monster Hunter 4 and Majoras Maks i will have enought to play this month, and i have learned to wait because the Pandora, so this 2 Months whe will get also down..
 
Anyway, i have to wait for my the Money from Dividend (according how much the Pyra will be..)

As long it want not be 4 Yeahrs like whit the Pandora..

This Thime i have a Pandora, and Monster Hunter 4, so no booring for me,,
 
The bypass mode can be enabled or disabled with a command sequence. The sequence starts with 0xFF
Surely the bypass mode should have been a MIPI command in it's own right - ie. send 0xFFFEEEEF to enable bypass, then the rotator redirects all commands onwards, except another bypass command, which switches it back.

That would have been the sensible, and easy thing to do IMO
In theory, yes. But the chip doesn't have a memory for that, so with any command that starts with 0xFF, it thinks the command is for itself.
 
Tnx for the update :) , still got high hopes we will be able to purchase a Pyra soon, hopefully April is realistic!

Ps, this is not a 2 month phun.....
 
Last edited by a moderator:
Back
Top