You'll hate this post. And you'll love this post.

[Grench]

So, with a few more weeks of case production and getting a few more of the prototype boards working - roughly 2 Months then?

*dives for cover

 

[Christoph.Krn]

@christoph: seems like my english isnt that good to understand your question,
(Was bedeutet deine Frage nochmal?? )

English:

I have a question to anyone who knows more about the Pyra hardware than I do:

Would the Pyra hardware permit persistent storage of information about the case color/design upon factory installation?

I'm asking for... reasons.

Deutsch:

Eine Frage an alle, die sich mit der Hardware der Pyra besser auskennen als ich:

Könnte man im Herstellungsprozess der Pyra das jeweilige Gehäuseaussehen in der Hardware hinterlegen (so dass es eine Neuinstallation überlebt)?

Ich frage aus... Gründen.

...to allow Pyra software to use the case color of the Pyra that it's running on.
...damit könnte Pyra-Software die jeweilige Gehäusefarbe nutzen.

 

[PowerGod]

Bulletproof Pyra FTW !!

 

[matzesu]

Thanks for the answer christoph,
This reminds me a bit on my Ipod Nano: the available color of the menü is according to the case collor , if you have a blue ipod, you only get blue menü designs..
I ditnt think this should be something whe wants for the Pyra, i wants my Green Pyra whit blue desctop design or something..
And diverent OS for every collors, i dotnt know..

 

[ible]

i'm not sure we should allow software to know the color of the pyra... think of what evil uses this could be put to. a blue pyra only BSODs, a red pyra overheats, a transparent pyra gets all the optimizations, etc.

 

[_wb_]

I suppose we could put a color code in /etc/pyra/case_color or something like that, which could give a hint to software that cares about it (but you can modify it if you want).

 

[Wrath Of Khan]

Glad to see that it progresses steadily and methodically. When every detail is just right then we hit mass production.
I't's interesting to hear about the mould process.

 

[directive0]

I can't wait for this forum to devolve into class wars and sectarian violence over which colour Pyra you have/want.

BETTER RED THAN DEAD

PURPLE RAIN, F****R!

MY CONSCIENCE IS CLEAR!

 

[Link]

The samples I get will be dark transparent which helps finding out any issues, as you can see if some parts don't fit properly.

Look forward to seeing these, as I think this could be a very good color choice vs. clear transparent that may let too much light leak.

 

[Christoph.Krn]

I suppose we could put a color code in /etc/pyra/case_color or something like that, which could give a hint to software that cares about it (but you can modify it if you want).

...sure, that's always possible. Then it has to be set again after reflashing/reinstallation.

That doesn't help this first-boot setup that would like to use the case color early, like so (Pyra render by fusion_power):

A (semi-)persistent "case" integer or so (there may be complex designs) in hardware storage would be neat-o there. I have no idea whether the Pyra hardware is giving a non-dirty way to do this.

 

[TrashyMG]

I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.

 

[directive0]

And wouldn't something like that just lead to more headaches? You'd need to make sure the boards you are assembling match the case colour? Or reflash them with whatever identification needed. So in a scenario where ED has a whack of boards sitting around set for Pink and he only has Red cases he'd need to reflash all of them instead of just assembling and shipping.

I can see that getting way out of hand.

 

[EvilDragon]

I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.

Actually, there is. The display PCB, for example, has a model number included on the PCB which can be read out.
This is necessary for future upgrades, if we want one OS for all the units.
The system needs to know what display driver to initialize, for example, so it needs to know which display PCB there is.

However, that's being done during PCB production, and when the PCBs are being produced, nobody knows which color they get in.

What's possible would be to create three different testing and flashing cards that could be used during production.
But that would only work for the initial flash, not if a customer reflashes.

I doubt anyone would have a problem if the unit in the picture has a different color than his own one, though

 

[TeDaDeS]

At least ED learned a lot about case production, so thanks for sharing that experience on the boards.

When production is finished, will ED also get the molds (or will they keep it in case you need more produced)?

You might not have case colors influence the model, but a model could probably read its version and have your desktop auto-themed.
If the PCB wasn't finished you could have a contact-strip on the back where the case could have some pins to indicate what type it is (but that is a pretty expensive way to do this compared to do it manually).

 

[Christoph.Krn]

[...] So in a scenario where ED has a whack of boards sitting around set for Pink and he only has Red cases he'd need to reflash all of them instead of just assembling and shipping.


I can see that getting way out of hand.

...except if end-of-line testing is being done (which I don't know, but as far as I know that's why there is an input tester on the Pandora), then that means that the devices have to be booted after assembly anyway (to test buttons, screen connection, etc.). You don't have to touch the OS block device to set a variable that's stored elsewhere in the hardware, you can handle it the same way that applying a serial number sticker can be used to signify an end-of-line quality check pass.

I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.

By design, such electronic components have to be (mostly) software-identifiable as what they are. That's not the case with case color...

 

[Yerffej]

Here's an informative video on plastic injection molding if you want to learn more (Expand Spoiler)

Spoiler

 

[TrashyMG]

By design, such electronic components have to be (mostly) software-identifiable as what they are. That's not the case with case color...

Not really, there may be ways of identifying which model you have by seeing which cell module is present or not. But I doubt there will be anything like an eFUSE blow, or discrete PROM that will identify model type and what not.

 

[elvissteinjr]

I can see how a stored case color accessible from software can be handy sometimes, but I'd trust the average user to be able to select the right color in the first startup wizard for example.
That could also cater for custom color selection for modded cases or just random preference.
It may be cool to have it automated, but it's not worth the effort imo.

But in the end, in Nintendo games/manuals it's always the white version of the device shown, I haven't heard anyone being confused from that yet (reminds me of the lettered game button "issue").

 

[mclien]

To all the software/ case color ideas, I would say: That only would be worth bothering, if the software could CHANGE the case color

@directive0
As for the custom color runs: That will be difficult/ expensive. As far as I know, you have to run a minimum amount of parts to be cost efficient. To get the injection running, there is some waste involved (like mold not headed up, plastic not in perfect flow yet and such), while starting the process.
So there is a minimum amount of cases necessary per color. You are perhaps free to choose a minimum run and buy all the cases that will be produced in that run. But I guess that will be close to 5 digits in cost. Or there have to be enough people wanting the same color.

The other question is, if my assumption about the "change color in production run" (and get mixxed colored cases inbetween) will work... (I perhaps want one of the mixed color cases...)

 

[Christoph.Krn]

@elvissteinjr , it's not about solving an issue, it's about improving the experience. User experience is one area where open handhelds are often lacking (significantly).