Active Topics
-
Paths (0)
to Maemo 7 / Leste by teroyk - 7 hrs, 9 mins ago -
Is there a section to talk about Java ME? Apps, etc. (4)
to General by teroyk - 8 hrs, 18 mins ago - more...
|
2013-10-17
, 15:43
|
|
Posts: 121 |
Thanked: 231 times |
Joined on Oct 2013
|
#122
|
Originally Posted by mikecomputing
Yes, most CPUs can handle the multimaster mode, but basically none of the peripherals can. Keyboard acting as master would sound a bit weird to me, but if interrupt line is not possible, multimaster mode could be a solution. Well now that Rainisto gave us some more info we don't have to speculate on this.
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...
1.8V i2c with interrupt line makes it quite simple to make a keyboard. Electrically I mean. Mechanics is quite a different story, and about that I know nothing about
| The Following 3 Users Say Thank You to TemeV For This Useful Post: | ||
 |
|
2013-10-18
, 03:27
|
|
Posts: 819 |
Thanked: 806 times |
Joined on Jun 2009
@ Oxnard, Ca.
|
#124
|
Originally Posted by zimon
Didnt quite get it why contradicting, but
N900 with Mugen battery was not too thick,and SGS3 with 7000 mAh battery is not too thick, but thicker than those start to be too much.
Integrating extra battery feature to qwerty Otherhalf would make it thinner than having the two Otherhalfs stacked.
Originally Posted by zimon
If they put a wysips on the screen then this will be unnecessary and any battery in the other half would just be gravy. You can see that company has already signed up some Chinese companies to use their see through solar panel underneath the screen.
Didnt quite get it why contradicting, but
N900 with Mugen battery was not too thick,and SGS3 with 7000 mAh battery is not too thick, but thicker than those start to be too much.
Integrating extra battery feature to qwerty Otherhalf would make it thinner than having the two Otherhalfs stacked.
Other options for a KB other half would be to have the keyboard characters painted with litroenergy paint or if that is too taboo for you you could just use their regular strong stuff to paint the characters (on top of a transparent plastic) and have the keyboard backlight come on for 1.5 minutes only before it turns off letting the characters glow themselves and have a kb shortcut to refresh the backlight to reenergize them if needed.
As far as small batteries are concerned the x-mini max 2 speakers that magnetically connect and collapse and expand to create fake bass last a very long time. They get very good reviews on battery life and each one is the size of a "now or later" candy. I see a flatter wider one in a other half as being totally adequate.
Related topics Solepower
and Scottevest
__________________
On duh count uh tree
On duh count uh tree
| The Following User Says Thank You to aironeous For This Useful Post: | ||
|
|
2013-10-18
, 08:10
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#125
|
Originally Posted by aironeous
Nice, but keyboard design talk and battery discussins are here!
If they put a wysips on the screen then this will be unnecessary and any battery in the other half would just be gravy. You can see that company has already signed up some Chinese companies to use their see through solar panel underneath the screen.[/URL]
Originally Posted by TemeV
Good thing I'm a mechanical engineer
1.8V i2c with interrupt line makes it quite simple to make a keyboard. Electrically I mean. Mechanics is quite a different story, and about that I know nothing about
However, the software part is totally new for me. Can people provide me with some links for a crash course in I2C-HID? What kind of info does a microcontroller send and what need to be done on the phone-half in terms of software? Or will the Mer I2C_HID kernel make the whole thing kind of plug and play?
| The Following User Says Thank You to dirkvl For This Useful Post: | ||
|
|
2013-10-18
, 10:03
|
|
Posts: 59 |
Thanked: 66 times |
Joined on May 2007
|
#126
|
Originally Posted by dirkvl
I'm not a kernel developer so I'm a bit guessing here.
What kind of info does a microcontroller send and what need to be done on the phone-half in terms of software?
To my understanding many peripherals need a kernel driver and a configuration for the hardware connection. ADP5589 was mentioned in this thread earlier and there is a kernel driver for it. But in addition to that the kernel needs to know how the ADP5589 is connected to the main CPU on the device (e.g. on the RPi).
E.g. I2C devices are usually static so everything is hardcoded to kernel's board files or nowadays to Device Tree files.
To use ADP5589 with RPi you need to probably tell in which I2C bus it is, what's the I2C slave address (7 or 10bit) and what are the possible interrupt lines. I tried quickly googling for some devices using the ADP5589 for an example but couldn't find any (but I'm sure there are such).
So, the actual I2C communication between CPU and ADP5589 should be covered by the driver and as such is plug'n'play but a hardware connection configuration is still needed. Some sort of user-space keymapping is probably needed as well.
EDIT: related to that particular driver I found an interesting PDF, google for "ADP5589 Input Keyboard and GPIO Linux Driver".
Last edited by kulve; 2013-10-18 at 10:26.
|
|
2013-10-19
, 09:16
|
|
Posts: 3,464 |
Thanked: 5,107 times |
Joined on Feb 2010
@ Gothenburg in Sweden
|
#127
|
Originally Posted by kulve
The ADP5589 manual says slave address is 0x34 (page 19)
I'm not a kernel developer so I'm a bit guessing here.
To my understanding many peripherals need a kernel driver and a configuration for the hardware connection. ADP5589 was mentioned in this thread earlier and there is a kernel driver for it. But in addition to that the kernel needs to know how the ADP5589 is connected to the main CPU on the device (e.g. on the RPi).
E.g. I2C devices are usually static so everything is hardcoded to kernel's board files or nowadays to Device Tree files.
To use ADP5589 with RPi you need to probably tell in which I2C bus it is, what's the I2C slave address (7 or 10bit) and what are the possible interrupt lines. I tried quickly googling for some devices using the ADP5589 for an example but couldn't find any (but I'm sure there are such).
So, the actual I2C communication between CPU and ADP5589 should be covered by the driver and as such is plug'n'play but a hardware connection configuration is still needed. Some sort of user-space keymapping is probably needed as well.
EDIT: related to that particular driver I found an interesting PDF, google for "ADP5589 Input Keyboard and GPIO Linux Driver".
__________________
Keep safe and healthy
Keep safe and healthy
|
|
2013-10-19
, 10:10
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#128
|
My TCA8424 with evaluation module and launchpad are currently being shipped. So, the rest of my development will focus around this chip.
Since we know the Jolla device has the interrupt-line and uses the Mer I2C_HID driver, what needs to be done on the software side to make this work? (And is there a way to emulate this in the SDK??)
Since we know the Jolla device has the interrupt-line and uses the Mer I2C_HID driver, what needs to be done on the software side to make this work? (And is there a way to emulate this in the SDK??)
| The Following 4 Users Say Thank You to dirkvl For This Useful Post: | ||
|
|
2013-10-19
, 11:48
|
|
Posts: 1,067 |
Thanked: 2,383 times |
Joined on Jan 2012
@ Finland
|
#129
|
Originally Posted by dirkvl
There still exists this small issue, that someone would need to backport I2C_HID driver as current SDK and target device kernel version is lower than where I2C_HID driver was introduced to kernel tree. Hopefully someone from community would be up for that task...
My TCA8424 with evaluation module and launchpad are currently being shipped. So, the rest of my development will focus around this chip.
Since we know the Jolla device has the interrupt-line and uses the Mer I2C_HID driver, what needs to be done on the software side to make this work? (And is there a way to emulate this in the SDK??)
__________________
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.
|
|
2013-10-19
, 23:03
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#130
|
Not directly related, but as on the other topic we were discussing color backlight, which would need driving RGB leds with control of each channel, I searched quickly a solution to do that.
The TCA8424 has no pwm output, but 4 on/off outputs for leds. This allows 8 colors (all combination of RGB leds on and off) : black (=no light), blue, red, green, yellow, magenta, cyan, white.
The ADP5589 has one pwm output which is great to dim a one color backlight, but not enough to control the color. Combined with its outputs (if they are not used by the key matrix), we can have 8 colors with luminosity control.
If we want to fully follow the device ambiance or case color, then we can use a separate I2C chip to do it, as I2C allow having a lot of chips on the same bus.
For example the NxP PCA9633 (1,30€ only from RS) comes in a small SO8 package and provides 4 x 8 bits channels (Only 3 are needed here), so 24 bits colors are "theoretically" possible on the led. However leds intensity response from pwm is non linear, so this is not really true and has to be tuned, but a lot of colors are possible.
The good point is that the driver for this chip already exist in the kernel under the name "CONFIG_LEDS_PCA9633".
There are probably a lot of other chips that can do that, it was only the first one I found. There also are 16 channels version if someone wants to make a 5 colors backlight (like a color gradient)
.
Then, to be able to have something smooth across the whole keyboard, several surface mounted RGB led (3?) can be connected in parrallel to the chip outputs (as a backlight doesn't need to produce a lot of light, and we want a low consumption). Some material that conduct light under the keys would help too.
The TCA8424 has no pwm output, but 4 on/off outputs for leds. This allows 8 colors (all combination of RGB leds on and off) : black (=no light), blue, red, green, yellow, magenta, cyan, white.
The ADP5589 has one pwm output which is great to dim a one color backlight, but not enough to control the color. Combined with its outputs (if they are not used by the key matrix), we can have 8 colors with luminosity control.
If we want to fully follow the device ambiance or case color, then we can use a separate I2C chip to do it, as I2C allow having a lot of chips on the same bus.
For example the NxP PCA9633 (1,30€ only from RS) comes in a small SO8 package and provides 4 x 8 bits channels (Only 3 are needed here), so 24 bits colors are "theoretically" possible on the led. However leds intensity response from pwm is non linear, so this is not really true and has to be tuned, but a lot of colors are possible.
The good point is that the driver for this chip already exist in the kernel under the name "CONFIG_LEDS_PCA9633".
There are probably a lot of other chips that can do that, it was only the first one I found. There also are 16 channels version if someone wants to make a 5 colors backlight (like a color gradient)
.Then, to be able to have something smooth across the whole keyboard, several surface mounted RGB led (3?) can be connected in parrallel to the chip outputs (as a backlight doesn't need to produce a lot of light, and we want a low consumption). Some material that conduct light under the keys would help too.
| The Following 5 Users Say Thank You to Zeta For This Useful Post: | ||
TCA8424 chips and evalution-module is coming my way!