Active Topics

 



Notices


Closed Thread
Thread Tools
Posts: 1,094 | Thanked: 5,605 times | Joined on Feb 2010 @ Holland
#101
Originally Posted by onethreealpha View Post
TI ship TCA8424 which pushes HID over I2C at 1mhz.
The chip is preprogrammed for standard laptop keyboards but supports up to 128 key/function inputs including multiple simultaneous key entry (great for all those function/ctl commands)
while it is built to support Win8, there is a lkddb entry for HID_I2C which may be possible to build into the Mer kernel adaption by default.
using this chip would only require physical hardware construction of the KB using the pin/wire connections as defined by the TCA8424.
i'm waiting on word back form lbt and Jolla and if they are good to go, I'll by e TCA8424 dev kit and start trialling.
I need to see if the HID_I2C driver can also push input directly into Malit.
stay tuned as more info comes to hand....

edit: if the kids give me break this arvo, I'll try a kernel build with HID_I2C and see if I can get it up on my Raspberry Pi with Mer. if this works, we'll take it form there...
I was wondering, why not go for the TCA8418? It is specifically designed for mobile phones I believe. It is only a 16bit chip -what should be enough- but has no evalution board.
 

The Following 3 Users Say Thank You to dirkvl For This Useful Post:
mikecomputing's Avatar
Posts: 3,327 | Thanked: 4,447 times | Joined on Feb 2010 @ Gothenburg in Sweden
#102
Originally Posted by dirkvl View Post
You got confirmation from Jolla?
http://i41.tinypic.com/2jcavpl.jpg

That chip looks awesome! Does this mean that your proposed chip will work for a keyboard OH?
for more details about drivers etc I think
you better ask on #mer #sailfish channels on irc the coders are there not on twitter.

and if "I dont know about IRC" well then its time to learn it...
__________________
Sweden means democracy terrorists go **** yourself we will never give up our freedom!

telegram @mike7b4
mastodon.social @mike7b4
 

The Following User Says Thank You to mikecomputing For This Useful Post:
mikecomputing's Avatar
Posts: 3,327 | Thanked: 4,447 times | Joined on Feb 2010 @ Gothenburg in Sweden
#103
Originally Posted by jalyst View Post
How so?
Isn't a interrupt lane still important, if not, why not?
No need for dedicated IRQ pin if run OTH peripheral as master but...
__________________
Sweden means democracy terrorists go **** yourself we will never give up our freedom!

telegram @mike7b4
mastodon.social @mike7b4
 

The Following User Says Thank You to mikecomputing For This Useful Post:
onethreealpha's Avatar
Posts: 434 | Thanked: 990 times | Joined on May 2010 @ Australia
#104
Originally Posted by dirkvl View Post
I was wondering, why not go for the TCA8418? It is specifically designed for mobile phones I believe. It is only a 16bit chip -what should be enough- but has no evalution board.
Didn't check the 8418... 8424 is also lv and designed for mobiles. It was both the register and eval board that got me interested in the 8424..
Will check the 8418 out
__________________
Always remember you're unique, just like everyone else.
 

The Following User Says Thank You to onethreealpha For This Useful Post:
onethreealpha's Avatar
Posts: 434 | Thanked: 990 times | Joined on May 2010 @ Australia
#105
Originally Posted by mikecomputing View Post
for more details about drivers etc I think
you better ask on #mer #sailfish channels on irc the coders are there not on twitter.

and if "I dont know about IRC" well then its time to learn it...
Already been in touch with mer.
Know about irc, just couldn't get on last night at work.
__________________
Always remember you're unique, just like everyone else.
 

The Following User Says Thank You to onethreealpha For This Useful Post:
Moderator | Posts: 5,319 | Thanked: 4,455 times | Joined on Oct 2009
#106
Originally Posted by mikecomputing View Post
No need for dedicated IRQ pin if run OTH peripheral as master but...
What are the downsides/upsides to this approach versus other one?
 
Posts: 1,094 | Thanked: 5,605 times | Joined on Feb 2010 @ Holland
#107
Okay... Good and bad news.

My keyboard pcb performs as planned! The i2c i/o expander does not. It has a lot of trouble staying connected to my RPi, which makes it impossible for any communication between the two.

However, I am very interested in the chip onethreealpha suggested. And after having a crack at it and looking around on the internet, I decided future prototype-pcb's will be outsourced!

Edit: the more I learn about this whole I2C, the more I come to realize they MUST include an interrupt line. Polling for every single OH would make it useless. Polling for OH with camera shutter? Forget it! If the TCA8424 works with MER and de Mallit-keyboard, I say we go for it!

Last edited by dirkvl; 2013-10-13 at 08:39.
 

The Following 7 Users Say Thank You to dirkvl For This Useful Post:
mikecomputing's Avatar
Posts: 3,327 | Thanked: 4,447 times | Joined on Feb 2010 @ Gothenburg in Sweden
#108
Originally Posted by dirkvl View Post
Edit: the more I learn about this whole I2C, the more I come to realize they MUST include an interrupt line. Polling for every single OH would make it useless. Polling for OH with camera shutter? Forget it! If the TCA8424 works with MER and de Mallit-keyboard, I say we go for it!
No need for IRQ for this kind of peripheral better let OH be master. See my post below.


Originally Posted by jalyst View Post
What are the downsides/upsides to this approach versus other one?
not an expert only has used it on low end embedded but i2c allow more than one device to be master. Not sure what is best except the later save one pin...

Most the time "mainboard CPU" (means Phone SoC in this case) is master.

But if no IRQ the solution would be to set the OH as master when line is idle and it want to send data and when OH has pulses the adress the SoC on phone would get interrupt as a slave.

But question still remains how Jolla has implemented the I2C kerneldriver and so on.

hmm when thinking of it there should not be a reason for SoC to be master in this case. Better let the OH be master...

But it would be another way around if connected for example an eeprom module or similar...
__________________
Sweden means democracy terrorists go **** yourself we will never give up our freedom!

telegram @mike7b4
mastodon.social @mike7b4

Last edited by mikecomputing; 2013-10-13 at 10:41.
 

The Following 4 Users Say Thank You to mikecomputing For This Useful Post:
Posts: 1,094 | Thanked: 5,605 times | Joined on Feb 2010 @ Holland
#109
Okay crazy. I2C has some additional rules

The OH could act as master and phone as slave, or -new possibility!- both could act as MultiMaster (I like how this sounds very much!) But as you said, this totally depends on the phone and its kernel.

If the phone can act as slave and/or multimaster, we are done! Interrupt lines are for noobs anyway

If the phone can act as multimaster, we can start looking for a multi-master keyboard controller. If the phone can act as a slave, it will still work with multi-master keyboard.

Please correct me if I am wrong, this is new territory!
 
Posts: 121 | Thanked: 231 times | Joined on Oct 2013
#110
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.

Last edited by TemeV; 2013-10-13 at 20:51. Reason: typo
 

The Following 5 Users Say Thank You to TemeV For This Useful Post:
Closed Thread

Tags
keyboard, limited-edition, otherhalf, qwerty

Thread Tools

 
Forum Jump


All times are GMT. The time now is 13:36.