Seems like you don't grasp the many, many, many puns you can do with Cellphone/Chenphone Youyota OTA...

Can't agree more.

I'd only add in a few hints:

- sanitize power input (example: you won't fry a Ruggeduino by inverting +5V and GND)

- I2C and (highly desirable) GPIOs should be 3.3V and 5V-tolerant

- access to these pins should be easy (maybe at most a small rubber cover).

I agree with power and USB, but not on I2C.

It has not a sufficient (in my mind) cost/benefit ratio:

• It is the slowest bus available (400kHz in fast mode. Higher throughput modes are quite specific in only supported in some specific chips, but around 3MB also exists), and that's without removing headers overhead and clock stretching on some devices.
• Devices can't initiate an exchange (like if a key is pressed on a keyboard), so if you don't want to do polling, you need an additional interrupt line.
• A lot of devices exists for I2C, but not much of them add anything to a phone : accelerometers/magnetometers/gyroscopes are already there, eeproms are not useful compared to the loads of flash in the phone, keyboard input doesn't matter in a phone with a hardware keyboard. This leaves only some useful chips like pressure sensors, ADC, IO expanders or small OLED displays...
• It is not plug&play : there is no auto-discovery mechanisms in this, so you either need to manually configure the addresses and types of device you put there, or need to resort to add an additional eeprom with the details (like done in Jolla OH, Raspberry PI's hat, BeagleBone's capes, ...)

Other interesting bus like SPI offer more throughput, but with a lot of pins (usually 4) and the same shortcomings as I2C regarding plug&play. Then there are more specialised bus like I2S for sound, some bus for camera or display, sata for drives, sdio for sdcards and some peripherals, ...

On the other hand is the USB bus. It only needs 2 pins of data (and the same 2 pins of power as the other ones), but allows about anything possible:

• high speed : may not be capable of handling a 4k@60Hz stream, but can be quite fast for about all things we can do on with a phone, especially if USB3 is supported
• Can be used as device or host (with OTG functionality) : so can power hard drive or be connected has a device to say a Raspberry Pi zero in a back cover (don't know you would do that, but it can ! )
• about all devices are possible : from serial bus, joystick/mouse/keyboard, ethernet/wifi/bt adapters, hard drives, cameras (even thermal ones like the Lepton), display, SDR, printers, audio...
• Plug&Play : if the given USB profile is supported on the phone, just plug it, and it will appear right on as the correct device.
• easily accessible to hackers/commercial products : greybus needs specific and costly interface chips, USB is found in all microcontrollers ranges (from Lower Atmel 8 bits, to high range STM 32 bits).
• can be extended to multiple devices using a hub on the extension board or with composite USB devices (several profiles at the same time in the same chip)

So for effectiveness, I would go for only bidirectional power pins with USB OTG (so 4 pins), to cover all usages.
If you can put anything, then UART+I2C+SPI+Gpio for interrupts/PWM+PciE+Sata+... can find its use too.

I think the reason why there was not much Other Half created (except the well-know keyboard) is mainly because I2C was too limited. At the time, I had to add CAN-bus support, but it was not possible through I2C, so I did it with a CAN-to-wifi interface (which had the benefit to be compatible with any phone). If I had USB available, I would have done an other-half for that.


And about the company name for the phone, I understand that Youyota is Michael's brand, not Chen's. Chen did the Motorola keyboard Mod under the Livermorium brand, which I think he owns (or is a part of) ?

Thank you for refreshing my mind :
Yes, of course, in case of I2C, we would need a separate interrupt, exactly as the Jolla does it (for this specific purpose. That's how the keyboard handles keypresses).


And some RGB-LED controllers. Don't forget them. They come is I2C 3 wires, SPI 4wires or some simple bit-banging 2 wires.
(+ power)


I would suggest a separate 5v input (with some power controller, just like the regular micro-USB charger port), so that it could handle variation around 5v (might happen with wireless)

and a separate 5v output (for the accessories).

Thus you could still charge and use your accessory.


Otherwise I also agree that giving USB is the best part : one could then use an embed arduino to basically do anything.


Which as you mention, up to the PWM part could entirely be covered by a chip on the USB pogopins.

For PciE / SATA : most current ARM phone chipset don't feature it (it's more often found on low-power servers and infotainment ARM SoCs : AMD Opteron 1110, Nvidia Tegra, etc.)

Though one might dream. Maybe, by the time of this potential future "ChenPhone", SATA will get popular on tons of other SoC.





Also regarding non-hacker oriented ports :

dual USB:
I've seen (mostly on Lenovo tablet) tablets featuring two USB ports, so you can charge on 1 port, and use the other port for OTG accessories. (in Lenovo, the second port is hidden behind the same cover as the microSD card)

dual microSD:
(See things as old as the tapwave zodiac, other handheld consoles like Pandora and Pyra, or some of Nokia's Nxxx Maemo/Meego internet tablets)
- the first microSD under the battery cover, for more permanent use (like on most modern phones) to store users' data.
- the second microSD external, so you can quickly and easily pop a card in for copying photos from a photo camera.

Though you have to admit that the function can easily be accomplished with an OTG reader (e.g.: meenova)
Or by straight plugging the whole camera into a powered USB hub, and optionnally implement MTP or whatever the camera uses instead of straight exposing the block-device.

Or maybe, by the time you design your own PCB, most devices will support wireless transfer (Bluetooth or Wifi) so simultaneous dual *Wifi* would be the desirable feature (like being able to connect the 5Ghz antenna to the home network, and use the 2.4Ghz antenna to copy photos over the camera's private wifi peer).

I disagree, for exactly the same reason . USB is a PITA and unnecessary overhead for adding simple hardware to a device.
Strapping a computer to the back of my computer so I can add a simple sensor takes space, costs in components, and most importantly takes time messing about with unnecessary (and usually poorly documented) code. I hold my hands up here as a simple minded hardware designer, I hate writing code and do it only where needed.

USB in addition to i2c (or SPI, or even rs232@3v3 if you wish) by all means, but not to the exclusion of a simple interface please!

I think there were limited TOH produced because the software and documentation never encouraged experimentation without spending a lot of time digging around looking for information.

It took me days of searching just to figure out how to get a GPS fix in a python script when the Jolla screen is off FFS!

That is all relative to your knowledge and usage of course.
Yes, that adds some overhead for the smallest things, but in that regard, if all you want to do is to light a led, then I2C is overhead compared to a simple GPIO...
About the cost, a simple STM32F042 which can do USB crystal less is less than 3$ by single unit from digikey, and it can play the role of several I2C components (like IO expander, ADC, DAC, PWM UART at the same time...) which would add a lot of overhead if done through several I2C components. Again, it depends on what you want to use it to.

May I ask what kind of usage you have in mind ? (Remembering that is for a "relatively costly" phone, and not a "relatively cheap" arduino or raspberry pi that you can bury in anything you want and forget about it)

So we have to agree to disagree here, as I would be for USB first class (as it can do ALL I think about), and if that really doesn't cost more to add pogo-pins (which I think is not the case), then add all you can, like I2C. SPI without I2C is not always useful, as a lot of SPI devices need I2C for configuration (like the lepton camera).

We'll see what Chen thinks of this, as he usually have great ideas regarding what is possible and cost-effective to produce.

I actually found they did a good work on this, as can be seen in the PDF from the archive downloadable there: https://sailfishos.org/develop/the-o...developer-kit/
The website has been updated since then, but the docs are the originals from February 2014.

Respectfully, it is NOT relative to my knowledge or usage. If a simple device does not *require* including a micro to be done as simply as possible, then what is the point of adding one?

If you want to make several thousand TOH, you can absorb the cost of software development (good luck finding the volume of customers to make the economics hang together). If you want to make 1 of something, then writing two sets of software, learning yet another new device, sdk and environment, is an overhead I can't afford. I will simply use that rpi or STM32 directly and leave the 'chenphone' un-purchased.

Yes, I could design in your STM32F0, I already use them in several of my commercial products. It's just not going to happen, it's unnecessary for simple devices and I don't see enough of a reason to invest my time on complex ones.

Within some huge error bars, component costs are largely only relevant in higher volume products. Development time (hardware and software) is similarly only relevant in low volume ones.

Chenphone would be useful to me as a simple(ish) portable linux box with decent connectivity, useful for prototyping and one-off sensors/controllers.
For anything commercial (ie anything I might sell as a product) I wouldn't start from here.

As you suggest, if there's an (ideally otherwise uncommited) i2c bus available, then providing landings for pogo pins is nearly free, it's just a mechanical consideration. The cost of providing connection on the TOH side is irrelevant. Likewise for an interrupt pin.

Frankly, I would probably buy Chens Lauta concept sight unseen just for the 2017 N900-ness of it, regardless of the wired connectivity. No point wishing for features I never stated a case for though, is there?

jolla are a small company, they have enough trouble keeping [their] stack up to date (GCC, QT, BlueZ), and they don't have to worry too much about the kernel (android) or the middle-layer (MER).

asking them to create and support niche interest little additions seems like a big ask, to negligible commercial gain.

This "Lauta" device will be branded as Livermorium (Or simply L-Device) But Chenphone is also nice, could be our internal code name between Maemians

I don't want to call it a "Phone" - It is meant to be a pocket computer - as the "Internet Tablet" series that we loved.

I also don't want to copycat Lauta's design, but it will have it's spiritual feeling and some improvement over original design (like being slimmer, and part using metal)

Can't wait to see the mock-ups and decisions about the questions in the other thread.