Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 23 hrs, 37 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 19 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 3 hrs ago - more...
juiceme |
2013-10-24
, 19:41
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#141
|
Originally Posted by rainisto
3.10 nice...!
|
|
2013-10-24
, 21:02
|
|
Posts: 1,067 |
Thanked: 2,383 times |
Joined on Jan 2012
@ Finland
|
#142
|
Not commenting on target kernel version number, just giving sha which is close enough.
| The Following 3 Users Say Thank You to rainisto For This Useful Post: | ||
|
|
2013-10-24
, 21:36
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#143
|
So the launchpad I ordered to connect the tca8424evm to my computer has left china, so if it is in a plane I can start programming next week. Or they might strap it on the back of a ricksjaw, that will take a bit longer 
Either way, whenever that arrives I can start experimenting with some simple keyboard layout (3x3 grid with modifiers?!?). When that is done and everyone that follows this thread is up to snuff about microprocessors, things are getting serious!
Mainly, either the first batch is delivered -crazy!- and we can start experimenting connecting a simple grid to the phone, or it has not and there is time to build a full grid and program the chips accordingly.
I take it you guys are aware of the updates from jolla and their site? Things are happening! So for this thread to become a real success it would be nice to have a full keyboard grid and programmed chips ready to plug-and-play with the phone! For that to happen we need:
-a final keyboard design, some very good ideas lately!
-i2c_hid mer driver? does it need modifications?
-buttons (on the way)
-pcb desgn (where is connector? OH CAD? will probably come available as the phone releases)
Crazy stuff!
Either way, whenever that arrives I can start experimenting with some simple keyboard layout (3x3 grid with modifiers?!?). When that is done and everyone that follows this thread is up to snuff about microprocessors, things are getting serious!
Mainly, either the first batch is delivered -crazy!- and we can start experimenting connecting a simple grid to the phone, or it has not and there is time to build a full grid and program the chips accordingly.
I take it you guys are aware of the updates from jolla and their site? Things are happening! So for this thread to become a real success it would be nice to have a full keyboard grid and programmed chips ready to plug-and-play with the phone! For that to happen we need:
-a final keyboard design, some very good ideas lately!
-i2c_hid mer driver? does it need modifications?
-buttons (on the way)
-pcb desgn (where is connector? OH CAD? will probably come available as the phone releases)
Crazy stuff!
|
|
2013-10-26
, 15:14
|
|
Posts: 20 |
Thanked: 18 times |
Joined on Sep 2009
@ Valencia (Spain)
|
#144
|
Originally Posted by TemeV
Yes, I agree with the statement that a microcontroller requires more power. But I prepared some numbers and the results are interesting.
Even the most low power microcontroller doesn't match even near the current consumption of the TCA8424 and like. With mobile devices energy preservation means everything.
And if I understand correctly, you don't have to use TCA8424 as I2C HID device, you can use it like any other I2C device. Just read the data after the interrupt line goes up.
I don't actually understand how using a microcontroller would be easier. You'd then have to write a custom driver for sailfish, which would be a same amount of trouble as writing a driver for TCA8424.
If the I2C HID driver appears to be too difficult task and custom driver is not tempting, e.g. ADP5588 has a linux driver available.
IMO using a microcontroller for this kind of task does not make sense.
TCxxx requires only up to 70uA @ 3.3V 1 MHz. Very good.
Now, we can elect some ultra-low power microcontroller of the ARM Corte-M family.
For example, a bit old ST's STM32L100C6 that has 32KB of flash ROM and 4 KB of RAM, 2 I2C, DAC, ADC, USB, SPI, UART, RTC, LCD DRIVER, TOUCH SENSING, ...
http://www.st.com/web/en/catalog/mmc/FM141/SC1544
-Run mode @0.5MHz, 150 uA
-Assuming a well designed firmware, you can sleep the micro and awake for scanning the keyboard. I estimated around a rough 500 instructions for scanning completely the kbd.
-This is around 2 ms of work, including awake and return to sleep.
-Now, assume that you scan the kbd at 50 Hz rate. That is, every 20 ms.
-The remaining 18 ms (20-2), you can maintain the microcontroller in low-power mode.
-Low-power mode: 9 uA
-In average the requirements are: (2*150) + (18*9) = 23 uA
These numbers are only for the CPU. You need to add the current drain of the powered peripherals: I2C, GPIO, ... so I estimated around 200 uA of draining in the worst case. Excellent for the kind of power supply of a smartphone.
But you can do better thing. Put the micro in Stop mode and awake it when the keyboard is opened:
-Stop mode: 0.6 uA far better than the TCA.
So, numbers shine for microcontrollers. And possibilities also: 2 I2C, DAC, ADC, USB, SPI, UART, RTC, LCD DRIVER, TOUCH SENSING, ...
I have experience with USB-HID on microcontrollers, so I2C HID should be easy.
In any case, I think the ST's micro is not adequate here, it'a a hell soldering it by hand.
An interesting thing using a microcontroller, the M7 coprocessor inside the iPhone 5S is a simple Cortex-M3 from NXP.
The only problem for putting this working is that I have no money for buying a Jolla.
I will continue with my belowed N900.Regards,
Àngel
| The Following 4 Users Say Thank You to aperles For This Useful Post: | ||
|
|
2013-10-26
, 19:14
|
|
Posts: 986 |
Thanked: 1,526 times |
Joined on Jul 2010
|
#145
|
so ive been thinking about the n9's low-power-screen and seriously considering exploring an arduino lcd TOH, but i forgot that im obviously never going to use anything other than a keyboard other half.
which led me to thinking about a kb+lcd OH pipe dream. can anyone here comment on the feasibility of:
1) making an lcd OH at all, preferably 16x4 with backlight control. {i2c is way faster than LCD refresh rates, right?}
2) making a kb OH which when closed, would be disconnected, fully exposing the i2c interface and power for a generic addtl OH.
3) actually making a combined kb+lcd OH. is there sufficient bandwidth on i2c, sufficient power, etc? is it extremely unlikely that a microcontroller exists that can handle this? will the thickness be ridiculous? etc.
which led me to thinking about a kb+lcd OH pipe dream. can anyone here comment on the feasibility of:
1) making an lcd OH at all, preferably 16x4 with backlight control. {i2c is way faster than LCD refresh rates, right?}
2) making a kb OH which when closed, would be disconnected, fully exposing the i2c interface and power for a generic addtl OH.
3) actually making a combined kb+lcd OH. is there sufficient bandwidth on i2c, sufficient power, etc? is it extremely unlikely that a microcontroller exists that can handle this? will the thickness be ridiculous? etc.
__________________
~ teleshoes ~
~ teleshoes ~
| The Following User Says Thank You to wolke For This Useful Post: | ||
|
|
2013-10-26
, 20:32
|
|
Posts: 65 |
Thanked: 56 times |
Joined on Oct 2013
|
#146
|
Originally Posted by wolke
Although I have not followed this discussion about the OH keyboard, I got interested i the "LCD OH".
so ive been thinking about the n9's low-power-screen and seriously considering exploring an arduino lcd TOH, but i forgot that im obviously never going to use anything other than a keyboard other half.
which led me to thinking about a kb+lcd OH pipe dream. can anyone here comment on the feasibility of:
1) making an lcd OH at all, preferably 16x4 with backlight control. {i2c is way faster than LCD refresh rates, right?}
2) making a kb OH which when closed, would be disconnected, fully exposing the i2c interface and power for a generic addtl OH.
3) actually making a combined kb+lcd OH. is there sufficient bandwidth on i2c, sufficient power, etc? is it extremely unlikely that a microcontroller exists that can handle this? will the thickness be ridiculous? etc.
- What does an lcd OH comprise? Is there a 16-column / 4-row keyboard? (a virtual one?). What would its added value be?
- Why would an extra lcd be required in the OH, in addition to the touch screen of the Jolla phone? Do you mean that the lcd would display the text you enter (perhaps in a small frame like those which some Symbian smartphones of Nokia have)?
Last edited by Egon; 2013-10-26 at 20:36.
|
|
2013-10-26
, 21:51
|
|
Posts: 121 |
Thanked: 231 times |
Joined on Oct 2013
|
#147
|
Originally Posted by aperles
Interesting numbers indeed. That power consumtion is pretty low, I have to admit. You just forgot that TCA8424 also has a low power mode, in which it spends most of the time. It only starts the oscillator when there is a key pressed or I2C communication going on. In low power mode the consumption is only 0.27uA @ 1.8V or 0.54 uA @ 3.3V.
Yes, I agree with the statement that a microcontroller requires more power. But I prepared some numbers and the results are interesting.
TCxxx requires only up to 70uA @ 3.3V 1 MHz. Very good.
Now, we can elect some ultra-low power microcontroller of the ARM Corte-M family.
For example, a bit old ST's STM32L100C6 that has 32KB of flash ROM and 4 KB of RAM, 2 I2C, DAC, ADC, USB, SPI, UART, RTC, LCD DRIVER, TOUCH SENSING, ...
http://www.st.com/web/en/catalog/mmc/FM141/SC1544
-Run mode @0.5MHz, 150 uA
-Assuming a well designed firmware, you can sleep the micro and awake for scanning the keyboard. I estimated around a rough 500 instructions for scanning completely the kbd.
-This is around 2 ms of work, including awake and return to sleep.
-Now, assume that you scan the kbd at 50 Hz rate. That is, every 20 ms.
-The remaining 18 ms (20-2), you can maintain the microcontroller in low-power mode.
-Low-power mode: 9 uA
-In average the requirements are: (2*150) + (18*9) = 23 uA
These numbers are only for the CPU. You need to add the current drain of the powered peripherals: I2C, GPIO, ... so I estimated around 200 uA of draining in the worst case. Excellent for the kind of power supply of a smartphone.
But you can do better thing. Put the micro in Stop mode and awake it when the keyboard is opened:
-Stop mode: 0.6 uA far better than the TCA.
And you didn't answer my question. How does using a microcontroller ease the driver issue with Sailfish?
In any case, I think the ST's micro is not adequate here, it'a a hell soldering it by hand.
Good luck trying to find a low power device in a bigger package. Those are quite uncommon in modern ICs and old ICs tend to consume more power.
Last edited by TemeV; 2013-10-26 at 22:01.
| The Following User Says Thank You to TemeV For This Useful Post: | ||
|
|
2013-10-26
, 22:13
|
|
Posts: 20 |
Thanked: 18 times |
Joined on Sep 2009
@ Valencia (Spain)
|
#148
|
Originally Posted by TemeV
You don't need I2C HID anymore. Only simple /dev/i2c
And you didn't answer my question. How does using a microcontroller ease the driver issue with Sailfish?
http://www.lm-sensors.org/wiki/I2CTools
MER kernel for omap has /dev/i2c. I supose that for Sailfish it is also included for accesing internal chips.
Regards,
Àngel
| The Following User Says Thank You to aperles For This Useful Post: | ||
|
|
2013-10-26
, 22:21
|
|
Posts: 20 |
Thanked: 18 times |
Joined on Sep 2009
@ Valencia (Spain)
|
#149
|
Originally Posted by TemeV
Ah. No problem.
Good luck trying to find a low power device in a bigger package. Those are quite uncommon in modern ICs and old ICs tend to consume more power.
http://www.nxp.com/products/microcon....html#products
| The Following 2 Users Say Thank You to aperles For This Useful Post: | ||
|
|
2013-10-26
, 22:26
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#150
|
Originally Posted by Egon
What Wolke here is after, is something that would act like the "low power mode" screen that N9 has. You know, the really dim display mode that consumes very little power and can display your messages, battery status, clock... whatever.
Originally Posted by wolkeso ive been thinking about the n9's low-power-screen and seriously considering exploring an arduino lcd TOH, but i forgot that im obviously never going to use anything other than a keyboard other half.
which led me to thinking about a kb+lcd OH pipe dream. can anyone here comment on the feasibility of:
1) making an lcd OH at all, preferably 16x4 with backlight control. {i2c is way faster than LCD refresh rates, right?}
2) making a kb OH which when closed, would be disconnected, fully exposing the i2c interface and power for a generic addtl OH.
3) actually making a combined kb+lcd OH. is there sufficient bandwidth on i2c, sufficient power, etc? is it extremely unlikely that a microcontroller exists that can handle this? will the thickness be ridiculous? etc.
Although I have not followed this discussion about the OH keyboard, I got interested i the "LCD OH".
- What does an lcd OH comprise? Is there a 16-column / 4-row keyboard? (a virtual one?). What would its added value be?
- Why would an extra lcd be required in the OH, in addition to the touch screen of the Jolla phone? Do you mean that the lcd would display the text you enter (perhaps in a small frame like those which some Symbian smartphones of Nokia have)?
The way I understand this is, it is not about the keyboard other half at all, it's about what you put underneath it, on the underside.
Basically it would be a display of really low power, on the bottom of the keyboard other half, so when the keyboard is closed and the phone is laying on the table face down, you can see all the notifications on the display.
I'd like to have something like that too, but instead of LCD I would like it to be an E-Ink display. Granted, that'd need a backlight to be seen in the darkness but on normal lighting conditions the contrast and current consumption would be unbeatable.
So, here my answers to the questions above:
1.) Very feasible, no problem at all making somethong like this.
2.) There's no need to do anything so complicated like that, i2c bus is addressable so you can control several devices with it concurrently.
3.) Both bandwidth and power requirements are OK, no problem with that. There are several microcontrollers you could use, if you want to use programmable devices. There are also several single-solution dedicated chips for that. There's no problem with thickness, all of these can be made as thin as you like it
