Producing Qwerty OtherHalf --order counter: 75/75 --ordering closed - Page 12 - maemo.org

Active Topics

Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 23 hrs, 49 mins ago
Handbook (2)
to Maemo 7 / Leste by teroyk - 1 day, 23 hrs ago
more...

Page 12 of 81

Thread Tools

dirkvl	2013-10-15 , 23:05
Posts: 1,104 \| Thanked: 5,652 times \| Joined on Feb 2010 @ Holland	#111

Okay, kind of annoying that there is still no confirmation on I2C configuration from Jolla..

However, experimenting with keyboard-building continues! I ordered some pushbuttons for a new keyboard. These 4-pin buttons have the advantage that you could design a keyboard matrix on a one-sided pcb, which makes life a lot easier!

When/if Jolla confirms an interrupt-line, I will also order the tca8424 chip. I've been reading into it and it seems like a really good option given the price and rapid prototyping possibilities. The only downside so far is the lack of affordable test-sockets for qfn40.

A single-sided pcb layout would then look something like this:

Each button rests on 4 points. The sides are connected and act as a brigde. The button connects all 4 together like this:

Last edited by dirkvl; 2013-10-16 at 13:54. Reason: Added some pics

The Following 5 Users Say Thank You to dirkvl For This Useful Post:
jalyst, juiceme, OVK, rainisto, Rauha

jalyst	2013-10-16 , 04:32
Moderator \| Posts: 5,320 \| Thanked: 4,464 times \| Joined on Oct 2009	#112

Originally Posted by dirkvl

Okay, kind of annoying that there is still no confirmation on I2C configuration from Jolla..
When/if Jolla confirms an interrupt-line, I will also order the tca8424 chip.

I've given up nudging them about it, they've ignored further nudges anyway, hopefully they'll come to their senses soon & be more helpful.

rainisto	2013-10-16 , 04:36
Posts: 1,067 \| Thanked: 2,383 times \| Joined on Jan 2012 @ Finland	#113

You will get more info soon...

__________________
IRC: jonni@freenode
Sailfish: ¤ Qt5 SailfishTouchExample ¤ Qt5 MultiPointTouchArea Example ¤ ipaddress ¤ stoken ¤ Sailbox (Dropbox client) ¤
Harmattan: ¤ Presence VNC for Harmattan ¤ Live-F1 ¤ BTinput-terminal ¤ BabyLock ¤ BabyLock Trial ¤ QML TextTV ¤
Disclaimer: all my posts in this forum are personal trolling and I never post in any official capacity on behalf of any company.

The Following 12 Users Say Thank You to rainisto For This Useful Post:
Daneel, jalyst, Jordi, juiceme, mikecomputing, Mikkosssss, minimos, OVK, Rauha, rcolistete, slender, TemeV

jalyst	2013-10-16 , 04:42
Moderator \| Posts: 5,320 \| Thanked: 4,464 times \| Joined on Oct 2009	#114

Asketh, & yee shall receive...

I hope "soon" really means soon, & not continued vagueness.

OT:
I don't suppose you can confirm that USB host-mode/OTG is implemented, or will be?

Last edited by jalyst; 2013-10-16 at 06:20.

juiceme	2013-10-16 , 05:33
Community Council \| Posts: 4,920 \| Thanked: 12,867 times \| Joined on May 2012 @ Southerrn Finland	#115

Originally Posted by dirkvl

However, experimenting with keyboard-building continues! I ordered some pushbuttons for a new keyboard.

These look pretty nice and the price's not bad

I wonder what's the mechanical feel of these buttons is like. They look really low-profile which is good when designing a kbd that is as thin as possible.
I suppose you can just make a simple keyboard with covering the button matrix with soft plastic, and have a kind of "keyless keyboard surface" with a minimal amount of tactile feedback from the buttons, however I'd like to have a bit more definitive "key-clicking" action.

mikecomputing	2013-10-16 , 17:37
Posts: 3,464 \| Thanked: 5,107 times \| Joined on Feb 2010 @ Gothenburg in Sweden	#116

Originally Posted by TemeV

Using OH as master and phone as a slave is ideologically wrong. The device which is the "brains" of the system should be master. If the phone is slave it would always need a "master chip" at the other half, since almost all peripherals act only as a slave. Doesn't sound reasonable to me.

Multimaster solution would have a same problem, there is very little chips that can act as a multimaster. Whole multimaster thing is a little hackish IMO.

IMO phone being a master with interrupt line is the only reasonable solution, since most of i2c peripherals act only as a slave. With this solution there is whole lot of chips that can be connected directly to i2c and making other halfs is simple and fun.

Many MCUs can operate in all of the mentioned modes (master/slave/multimaster) so I'd guess phone SoCs can also do that. If the SoC handles all three modes it would be possible to leave out the interrupt line. I still think that if Jolla has done that, they have made a huge mistake.

Basically without knowing more it is not possible to choose what chip should be used. Though, no matter what the chip is going be the PCB will be about the same size, and changing the PCB for the new chip is quite simple and quick operation.

The hard part of the project is the mechanics. Since neither mechanical details aren't yet published, I don't know if there is much that can be done on that area either.

For now you can of course test different chips and their drivers, so that their strengths and weaknesses are known, when Jolla decides to publish the details.

hmm hakish? Hmm... most "example codes" I have seen on those CPU:s I have worked with (CortexMx and ATXMega) takes care of multimaster mode so to me it this seems its often used that way? But I could be wrong I have not used it in any application cause as u say most time mainCPU is master but in this case it MAY be where it (should) be used. But again I could be wrong...

__________________
Keep safe and healthy

rainisto	2013-10-16 , 19:12
Posts: 1,067 \| Thanked: 2,383 times \| Joined on Jan 2012 @ Finland	#117

I'm breaking my normal signature disclaimer for this post.

dirkvl: Good work that you have done. We have been following your progress with high interest and we don't want to slow down your progress. I asked around for permission what details I can reveal to make your work easier. So hopefully following details will help you to continue your development.

- 3,3V VDD (max 300mA, preferrably < 150mA to avoid thermal issues)
- 1,8V I2C (400kHz default setting in kernel)
- Other half expected to work in slave mode, phone is master
- Dedicated INT GPIO (1,8V) for interrupts

Further details and API examples will be published at later phase on coming SDK releases.

We are quite busy making the magic to happen, so even though sometimes our answers might sound vague, we are trying be as open as possible and try not to give out wrong information. Having said that, don't shoot me, if I make typoes... I'm hoping to see nicely working hardware keyboard as end result of this project

The Following 86 Users Say Thank You to rainisto For This Useful Post:
48GX, aironeous, ajalkane, almamo, Android_808, aperles, ARJWright, Artopal, B3Punch3D, benny1967, BonoNL, Boxeri, Daneel, DeeGee, dirkvl, dizzy, DJJonosound, dommau, edgar2, ffha, ggabriel, harrihakulinen, helihyv, Hurrian, iKneaDough, isto, jalomann, jalyst, javispedro, Jordi, juiceme, Kaacz, Kabouik, kinggo, kjmackey, kulve, latency, localhost, MartinK, mattaustin, mattiviljanen, max_power, mece, mikecomputing, Mikkosssss, minimos, MINKIN2, miqu, Mitrigol, mrsellout, MSameer, nodevel, NokiaFanatic, Oblomow, OVK, P@t, pichlo, pycage, qwazix, Rauha, rcolistete, rentze, Roth, sada11, shanttu, Silwer, slender, smoothc, sponka, student4life, szopin, TemeV, thedead1440, thp, Tujutzki, v2px, vitaminj, Wallace, wnt, wolke, wred_e, xkkkx, ymb, zlatko, zlatokosi, zwer

Egon	2013-10-16 , 21:09
Posts: 65 \| Thanked: 56 times \| Joined on Oct 2013	#118

Originally Posted by juiceme

These look pretty nice and the price's not bad
I wonder what's the mechanical feel of these buttons is like. They look really low-profile which is good when designing a kbd that is as thin as possible.
I suppose you can just make a simple keyboard with covering the button matrix with soft plastic, and have a kind of "keyless keyboard surface" with a minimal amount of tactile feedback from the buttons, however I'd like to have a bit more definitive "key-clicking" action.

Yes, the key-clicking action is important, but so is the shape of the keys. For optimum text entry, one of the most important features is: you should feel with your fingertips where are the key tops (the centers of the keys) prior to pressing the key. Even if a virtual keyboard had a good haptic feedback (like N9 has), it is not enough. An interesting innovation is the Tactus keyboad: key domes which are filled with a liquid when you activate the keyboard; see the picture on top of http://www.tactustechnology.com/technology.html . Here I'm not suggesting that solution for an OH keyboard, I mention it only as a reference of the correct shape of the keys, which can be applied also to HW keyboards. Nokia has applied the same shape. Their switching elements are water and dust proof domes, on which there is a flexible keymat onto which are mounted rigid, outbowing keys. Or, if the keymat it not flexible, the film around the switching dome is flexible, so that the rigid key can move freely, when you press it against the switching dome, making it click. Of course for experiments also flat keyboards can be built, but for finished products please use the best HW keyboards of smartphones as references.
I mention this, because IMHO it does not make sense to add only a flat membrane on the switching domes. But if the dome is sufficiently outbowing and the membrane soft enough, so that you can feel where the tops of the domes are, perhaps only a thin film on the keyboard might work well enough.

Last edited by Egon; 2013-10-17 at 12:52. Reason: Added the green text about rigid keymats and link to domes (I copied its target address from dirkvl's comment in another thread, thanks)

Zeta	2013-10-16 , 21:57
Posts: 339 \| Thanked: 1,623 times \| Joined on Oct 2013 @ France	#119

Hello rainisto,

Thanks for the details !
This will be really helpful as everything we were wondering is there now !

Originally Posted by rainisto

- Other half expected to work in slave mode, phone is master
- Dedicated INT GPIO (1,8V) for interrupts

So we can do the thing the "right way", with the phone as master, all peripherals as slaves (we may have several I2C chips in one other half, like an eeprom or a bus expanders for leds or backlight along a keyboard), and an interrupt line to wake the system when something happens, without having to poll, perfect for battery usage and response time !

From the kernel config (a RaspberryPi one I have lying here...) under Driver/Input/Keyboard, I found the following supported chips (they may not be compiled yet for mer, but it would be easy to do) :
- ADP5588/5587
- ADP5585/5589
- Atmel AT42QT1070
- Atmel AT42QT2160
- TCA6416/6408A
- TCA8418
- LM8323
- LM8333
- Maxim MAX7359
- Freescale MRP121

I may miss some of them, but it is already a good start. And here is a quick survey of their capability (I already excluded BGA packages when several are availlable, only the LM8323 as only BGA) :

Code:

		Cost($)	Package			Voltage	Max Num key	led output		other capabilities
ADP5588		3.11	24-VFQFN + Pad		1.8 / 3 V	8x10	through unused GPIO	light sensor
ADP5587		2.98	24-WFQFN + Pad		1.65 / 3.6 V	8x10	through unused GPIO	light sensor
ADP5585		2.15	16-WFQFN + Pad		1.65 / 3.6 V	5x5	through unused GPIO	pwm output if not used by keypad
ADP5589		3.11	24-WFQFN + Pad		1.65 / 3.6 V	8x11	through unused GPIO	pwm output if not used by keypad
AT42QT1070	1.42	14-SOIC / 20-VFQFN+Pad	1.8 / 5.5 V	6	no			Capacitive touch input
AT42QT2160	3.2	28-VFQFN +Pad		1.8 / 5.5 V	16	no			Capacitive touch input
TCA6416		2.44	24-TSSOP / 24-WFQFN	1.65 / 5.5 V	16/7x7	through unused GPIO	not sure there is the keypad logic in the chip...
TCA6408A	2.15	16-TSSOP / 16-VFQFN+Pad	1.65 / 5.5 V	8/?x?	through unused GPIO	not sure there is the keypad logic in the chip...
TCA8418		3.11	24-WFQFN + Pad		1.65 / 3.6 V	8x10	through unused GPIO	
LM8323		?	36-BGA			1.8 V		8x13	3 pwm	
LM8333		2.91	32-WFQFN  + Pad		2.25 / 2.9 V	8x9	4 + 1 pwm		
MAX7359		7.04	24-WFQFN + Pad		1.65 / 3.6 V	8x8	through unused GPIO	rotary encoder interface
MRP121		?	20-QFN			1.71 / 3.6 V	12	through unused GPIO	Capacitive touch input

(Sorry for the look, HTML formatting is not availlable..., copy this into a text editor app if it is not readable there)

The cost is based on DigiKey for a single unit.

So removing all that don't accept 3.3V, the BGA packages, and the one that have not enough keys to make a QWERTY keyboard, there remains: ADP5587, ADP5589, TCA8418, MAX7359.
They all cost aroung 3€, except the MAX7359 which cost more than the double.
I didn't checked yet if they support a 1.8V I2C bus and their power consumption.

So ADP5589 seems a good choice as it has a lot of inputs, so we can easily use less and put the unused columns to drive leds. The pwm output allows to have a backlight with control of its intensity.

There is also the TCA8424 that some mentionned here, which I didn't see in the kernel at a first look (maybe I should look for HID over I2C ?). It supports 8x16 matrix, and led outputs (without pwm), for 2.3$, on a 40QFN package.

Hope this will help, and that you can continue to add some data about which chips are possible or not, and feedback on the kernel drivers if some of you already used one of them.

The Following 12 Users Say Thank You to Zeta For This Useful Post:
almamo, Daneel, jalyst, MartinK, mikecomputing, minimos, miqu, mrsellout, OVK, rainisto, Rauha, Tujutzki