MIPI, Keymats, Batteries and Memory


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
46
Location
Ingolstadt
As promised last week, I'll make a detailed explanation how the sales price of a devices comes together.

But before that, let's start with the other things that happened.

1. MIPI steps...

Our journey through the wonderful world of MIPI continues (well, mostly Nikolaus' journey, as he is doing all the work here ;) )

The only thing I tried was finding a more in-depth datasheet of our LCD - and while doing that, we found out we received a slightly wrong datasheet from our distributor.

We had a more recent revision of the LCD than the datasheet was for, and while technically, it only has a bit higher brightness, it turned out that the initialization sequence had some different bits as well... oh well.

Well, getting the new datasheet was possible with just an eMail to our distributor, and then Nikolaus hacked in the new initialization sequence.

Of course, nothing will ever work out of the box - Nikolaus had a typo in the sequence as well, but after fixing that, the display at least did something!

It turns completely black!

While that doesn't sound so amazing, it actually is - it is another step of communication with the LCD.

Nikolaus has already continued to work on it, together with some support from TI and his oscilloscope. It seems the OMAP5 Display kernel driver also has a bug - it doesn't send a clock to the display (which is mandatory to send the actual video data...)

So the next step is clear: Find and fix the bug in the driver.

To be continued (hopefully next week...) :)

2. Keymat Meeting

While Nikolaus was hacking with MIPI, I had a meeting with a company from Munich about the keymat production.

Our keymat is a bit more complicated than the old one, as it needs to have semi-transparent key labels for the background light.

I also wish to improve the overall handling of the keymat (flat keys, slightly easier to push).

For that, we'll receive various samples in with different materials and thicknesses.

But until then, it's still a loooong way. First, the design has to be finished, then the mold has to be created, then it's time for samples.

That's still a few months away, but it seems we finally have a new company for the keymat as well!

3. Memory and Storage

If you followed the boards, you probably have seen the topic about memory and storage.

About memory: More than 2GB doesn't really make sense. You wouldn't gain much, but it would need more space, power and increase the costs.

I've run multiple things at once on my devboard (GIMP, LibreOffice, PSX Emulation, FireFox, etc.) and it never needed more than 600MB memory.

2GB should be enough for various multitasking threads for everyone.

About internal storage: This is another interesting task.

Basically, there are three possibilities:

  • eMMC (non-replaceable)
  • Micro-SD Card (user-replaceable)
  • Micro-SSD via SATA (non-replaceable)
Each possibility has advantages and disadvantages,  and we need to find out which would be best.

If we use a Micro-SSD via SATA, we should be able to include an internal Micro-SD Card slot as well.

Using Micro-SD Card is a neat solution, as the user can replace it with a bigger card if he wants.

eMMC is the standard in most devices (and there probably is a reason for it).

How do all these compare in terms of speed, power consumption, reliability and availability (also in the future)?

That's something we need to find out.

Next week is the Embedded World in Nuremburg, and we'll be there and visit various manufacturers and distributors and try to find out the one that suits the Pyra best.

4. Battery Size

You know our main idea was to keep the Pandora battery, so you can use both in both systems.

The Pyra shouldn't need more power for the same tasks as the Pandora (in fact, it should use less), but you probably also want to do things that the Pandora was too slow for. Then power consumption can go up, so a slightly larger battery would help.

That's why we've been checking on this.

Basically, to get 6000mAh (which is 2000 more than the Pandora battery has), we'd need to increase the size of the battery a bit.

4mm in width and 1,2mm in thickness.

On the Pyra, this shouldn't be a big problem, and I think it can be done without increasing the size of the unit (needs a bit more puzzling).

Also, with a frame we could offer, the normal Pandora battery can also be used.

On the Pandora, the width SHOULD be possible (as the current battery compartment is bigger than it should be, the battery moves around so we even need to pad it), and the height would need a slightly changed battery cover, but I should be able to offer that as well.

To get enough width, you might need to file off a bit in the battery compartment, so with a bit of modifying the case, you would be able to use the bigger battery in the Pandora as well... this needs to be checked though, and I will do that with samples.

All in all, we're moving forward in different directions.

Still a long way to go, but we did expect that ;)
 
Last edited by a moderator:
3. I guess we aren't going to win on this one.  :lol:   Tho, I will say that perhaps 3-4GB will be more beneficial to people who install Android.

 
4. Oh, I thought we were going for 8000mah. Um... How many people would be willing to file off the battery compartment? :lol:
 
Last edited by a moderator:
1. Good to hear that there's some progress with getting MIPI to work! I wouldn't have expected this to be that tricky, but that confirms the lesson learned from the Pandora: don't expect anything to be trivial.

2. Also good news!

3a. Yes, 2GB is probably the wisest choice. It's still 4 times as much as the Pandora (even 8 times as much as the CC model and 16 times as much as the original Pandora plan).

3b. I'm glad to hear that eMMC-only is not the only option that is being considered. Something upgradeable would be really nice. If µSSD over SATA is feasible, together with µSD for upgradeable internal storage, that would be extremely cool.

4. Not sure if 6000 instead of 4200mAh is worth the trouble, although it is cool if it can be made to work on the Pandora too (imagine the battery life on a Pandora then!). Maybe going for an even bigger capacity (e.g. 8000mAh), which cannot be put in the Pandora but still the Pandora battery can be put in the Pyra, would be also a good idea. Because then it may still be worthwhile for a Pyra owner (who doesn't have a Pandora) to actually use a Pandora battery to reduce the total weight -- if the Pyra is anything like the Pandora, a lot of its weight will come from the battery.
 
Everything sounds good to me. 

1. LCD is almost in working order? Great. I hope we will finally do away with that blasted LCD cable. I guess you will have the chance to test out the new touch screen after this is all settled. 

2. New keymat that's easier to press and is flat? Brilliant. This is the biggest problem I had with all my pandoras. Good to hear it's not some last minute change. 

3. Already start shopping around for some information? Wonderful. That's something you have to do on your own, I hope you will get some pleasant surprises. 

4. Half increase in power, but only 1/20 increase in size? That's amazing. Pandora is almost on the edge of Portable. Even though I would totally buy an extra juice backup battery of the size of a small car, this is better than I've ever wished for. I hope we can charge those batteries without having them inside the pyra, no, I don't trust those multi-purpose cellphone battery chargers. 

This is going so well, ED. I'm more than happy.  :wub:
 
Last edited by a moderator:
3. I doubt it is possible to put a micro SSD in there. At least it will be very hard to fit such a "huge" device into the small Pyra. I guess eMMC would need the least space.
 
3. I doubt it is possible to put a micro SSD in there. At least it will be very hard to fit such a "huge" device into the small Pyra. I guess eMMC would need the least space.
I don't think so. That SSD is propably just another chip that's soldered on the mainboard. But I think it would be great if it's going to be on a small daughter-board, so that it would be replacable - maybe not replacable with standard components, but being replacable at all would be great.
 
Thanks for the update Ed!

To the other commenters:

- 2GB RAM is plenty! As Ed said, it is enough to run multiple apps at once, more would eat battery power, and individual android apps dont require that much. It is 8 times as much RAM as the original Pandora had.

- 6000mAh battery is plenty! Pyra will run Pandora emulators at the same speed with significantly less power use.

- Internal storage: It is good that Ed has an open mind and is investigating all possibilities. Reliability is a key factor he must consider. If he chooses eMMC there is still the option to put the OS on SD for more space.
 
3. I doubt it is possible to put a micro SSD in there. At least it will be very hard to fit such a "huge" device into the small Pyra. I guess eMMC would need the least space.
I don't think so. That SSD is propably just another chip that's soldered on the mainboard. But I think it would be great if it's going to be on a small daughter-board, so that it would be replacable - maybe not replacable with standard components, but being replacable at all would be great.
I was actually about to say that with regards to eMMC.

If eMMC ends up being chosen, could we at least get it on a proprietary but replaceable daughterboard like the ODROID-U3 uses?


I can't help but fear that I'll botch something and wind up killing my flash memory so I always boot my Pandora off the SD because keeping a replacement SD card in the closet is a lot easier than sending a Pandora in for repair.
 
Oh, I thought we were going for 8000mah. 
I would prefer that.

But if it would make the device a lot bigger then 6000 is fine as well.

I don't care much about size but a lot others do.
4. Not sure if 6000 instead of 4200mAh is worth the trouble, although it is cool if it can be made to work on the Pandora too (imagine the battery life on a Pandora then!). Maybe going for an even bigger capacity (e.g. 8000mAh), which cannot be put in the Pandora but still the Pandora battery can be put in the Pyra, would be also a good idea. Because then it may still be worthwhile for a Pyra owner (who doesn't have a Pandora) to actually use a Pandora battery to reduce the total weight -- if the Pyra is anything like the Pandora, a lot of its weight will come from the battery.
I thought we were going for 8000mah too, which is much better.

I prefer to have a 4200mah thiner and lighter Pyra, carrying another 4200 battery without frame, than a 6000mah.
 
Last edited by a moderator:
3. I doubt it is possible to put a micro SSD in there. At least it will be very hard to fit such a "huge" device into the small Pyra. I guess eMMC would need the least space.
I don't think so. That SSD is propably just another chip that's soldered on the mainboard. But I think it would be great if it's going to be on a small daughter-board, so that it would be replacable - maybe not replacable with standard components, but being replacable at all would be great.
Micro SSD is always a daughter board. That's why you can replace it, as ED mentioned. It's formfactor and connector is mini PCIE, with additional channels for SATA. That's called mSATA.
DSC_9366sm.jpg
 
Last edited by a moderator:
Tho, I will say that perhaps 3-4GB will be more beneficial to people who install Android
Android uses a lot of RAM because it's designed to keep as many things in memory as possible (especially the apps you use often) so that they will start fast. It doesn't actually require all that memory, it's just convenient so you can shave three or four seconds off startup times. Most apps run just fine in well under 512MB, and only the most intense games are going to exceed that. 2GB should be more than enough for Android. If there's going to be a memory problem, it'll be from someone running multiple apps in Linux; Android would just start killing off old running programs you haven't used in a while to free up memory.
 
3. I doubt it is possible to put a micro SSD in there. At least it will be very hard to fit such a "huge" device into the small Pyra. I guess eMMC would need the least space.
I don't think so. That SSD is propably just another chip that's soldered on the mainboard. But I think it would be great if it's going to be on a small daughter-board, so that it would be replacable - maybe not replacable with standard components, but being replacable at all would be great.
Micro SSD is always a daughter board. That's why you can replace it, as ED mentioned. It's formfactor and connector is mini PCIE, with additional channels for SATA. That's called mSATA.
DSC_9366sm.jpg
No.
https://www.sata-io.org/sata-microssd

The specification defines a new electrical pin-out that allows SATA to be delivered using a single ball grid array (BGA) package. The BGA package sits directly on the motherboard, supporting the SATA interface without a connecting module.
 
Last edited by a moderator:
1. MIPI steps...

Our journey through the wonderful world of MIPI continues (well, mostly Nikolaus' journey, as he is doing all the work here ;) )

The only thing I tried was finding a more in-depth datasheet of our LCD - and while doing that, we found out we received a slightly wrong datasheet from our distributor.

We had a more recent revision of the LCD than the datasheet was for, and while technically, it only has a bit higher brightness, it turned out that the initialization sequence had some different bits as well... oh well.

Well, getting the new datasheet was possible with just an eMail to our distributor, and then Nikolaus hacked in the new initialization sequence.

Of course, nothing will ever work out of the box - Nikolaus had a typo in the sequence as well, but after fixing that, the display at least did something!

It turns completely black!

While that doesn't sound so amazing, it actually is - it is another step of communication with the LCD.

Nikolaus has already continued to work on it, together with some support from TI and his oscilloscope. It seems the OMAP5 Display kernel driver also has a bug - it doesn't send a clock to the display (which is mandatory to send the actual video data...)

So the next step is clear: Find and fix the bug in the driver.

To be continued (hopefully next week...) :)
I still don't get this "MIPI" thing. If it is so complicated to get an LCD working on an SoC, how the hell do all the gazillion Mobile Devices out there solve these issues? They pop out so fast, I can't imagine they have to deal alot with such issues at all. :-||" Does really every single one uses custom, "dirty" hacks just to get every LCD/SoC combo working? And if the OMAP5 has a (general?) bug that prevents it from communicating properly with an LCD, how do other OMAP5 mobile devices (if tere are any) get an image on screen? If they have solutions, it could help to just ask them for the workaround.
 
These gazillions of mobile devices usually are based on the same hardware. They have drivers for all of that.

We have to code our own drivers and don't even have all the documentation for the display and display driver chip avaialable.

Most companies only provide finished Android drivers, which do not help a lot (except for maybe reverse engineering).

That's what I tried to tell everyone with the different SoCs - unless we know what we get, we can't blindly buy one, even if we could theoretically buy it.
 
Someone stated that you are worried about space for a full SD card.

Is an interal SD card totally impossible or is there still some chance for it?
 
eMMC is the standard in most devices (and there probably is a reason for it)
 
Easy: Manufacturer controls memory speed so people won't complain about it (because user installed the cheapest microSD they could buy and expected miracles) and have additional profit from selling devices with higher capacity storage (just compare prices of identical devices with different storage capacity). 

Cheaper too as you don't need additional slot.

And let's not forget about copy protection as you can't easily read data from soldered eMMC elsewhere. There should be a reason for Google to allow to download movies from play store into internal storage only.

So manufacturer makes good user experience, reaps additional profit and protects user's data from the user. What's not to like about this?
 
Android uses a lot of RAM because it's designed to keep as many things in memory as possible (especially the apps you use often) so that they will start fast. It doesn't actually require all that memory, it's just convenient so you can shave three or four seconds off startup times. Most apps run just fine in well under 512MB, and only the most intense games are going to exceed that. 2GB should be more than enough for Android. If there's going to be a memory problem, it'll be from someone running multiple apps in Linux; Android would just start killing off old running programs you haven't used in a while to free up memory.
+ Android needs a lot of free RAM for efficient garbage collection

yes, 2GB are more than enough

4. wow! 6000mAh! battery life could become a killer feature ; )
 
Back
Top