Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 16 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 17 hrs ago -
Maemo repository (3)
to Community by torsen - 2 days, 9 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 3 days, 6 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 13 hrs ago - more...
|
2013-10-16
, 04:32
|
|
Moderator |
Posts: 5,320 |
Thanked: 4,464 times |
Joined on Oct 2009
|
#112
|
Originally Posted by dirkvl
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.
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.
|
|
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.
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 | ||
|
|
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.
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.
|
|
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
These look pretty nice and the price's not bad
However, experimenting with keyboard-building continues! I ordered some pushbuttons for a new keyboard.
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.
|
|
2013-10-16
, 17:37
|
|
Posts: 3,464 |
Thanked: 5,107 times |
Joined on Feb 2010
@ Gothenburg in Sweden
|
#116
|
Originally Posted by TemeV
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...
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.
__________________
Keep safe and healthy
Keep safe and healthy
|
|
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
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 | ||
|
|
2013-10-16
, 21:09
|
|
Posts: 65 |
Thanked: 56 times |
Joined on Oct 2013
|
#118
|
Originally Posted by juiceme
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.
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.
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)
|
|
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 !
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) :
(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.
Thanks for the details !
This will be really helpful as everything we were wondering is there now !
Originally Posted by rainisto
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 !
- Other half expected to work in slave mode, phone is master
- Dedicated INT GPIO (1,8V) for interrupts
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
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.
|
|
2013-10-17
, 09:23
|
|
Posts: 59 |
Thanked: 66 times |
Joined on May 2007
|
#120
|
Anybody up to drawing a Kicad component for the N900 keyboard?
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