Re: Building OtherHalf keyboard prototype
 

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.

Re: Building OtherHalf keyboard prototype
 

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...

Re: Building OtherHalf keyboard prototype
 

No need for dedicated IRQ pin if run OTH peripheral as master but...

Re: Building OtherHalf keyboard prototype
 

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 :)

Re: Building OtherHalf keyboard prototype
 

Already been in touch with mer.
Know about irc, just couldn't get on last night at work.
:)

Re: Building OtherHalf keyboard prototype
 

What are the downsides/upsides to this approach versus other one?

Re: Building OtherHalf keyboard prototype
 

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!

Re: Building OtherHalf keyboard prototype
 

No need for IRQ for this kind of peripheral better let OH be master. See my post below.


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...

Re: Building OtherHalf keyboard prototype
 

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!:D) 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 :p

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!

Re: Building OtherHalf keyboard prototype
 

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.