Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 6 hrs, 45 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 10 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 22 hrs ago - more...
dirkvl |
2013-10-12
, 09:22
|
|
Posts: 1,104 |
Thanked: 5,652 times |
Joined on Feb 2010
@ Holland
|
#101
|
Originally Posted by onethreealpha
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: | ||
|
|
2013-10-12
, 09:49
|
|
Posts: 3,464 |
Thanked: 5,107 times |
Joined on Feb 2010
@ Gothenburg in Sweden
|
#102
|
Originally Posted by dirkvl
for more details about drivers etc I think
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?
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...
__________________
Keep safe and healthy
Keep safe and healthy
| The Following User Says Thank You to mikecomputing For This Useful Post: | ||
|
|
2013-10-12
, 09:58
|
|
Posts: 3,464 |
Thanked: 5,107 times |
Joined on Feb 2010
@ Gothenburg in Sweden
|
#103
|
Originally Posted by jalyst
No need for dedicated IRQ pin if run OTH peripheral as master but...
How so?
Isn't a interrupt lane still important, if not, why not?
__________________
Keep safe and healthy
Keep safe and healthy
| The Following User Says Thank You to mikecomputing For This Useful Post: | ||
 |
|
2013-10-12
, 10:01
|
|
Posts: 434 |
Thanked: 990 times |
Joined on May 2010
@ Australia
|
#104
|
Originally Posted by dirkvl
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..
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.
Will check the 8418 out
__________________
Always remember you're unique, just like everyone else.
Always remember you're unique, just like everyone else.
| The Following User Says Thank You to onethreealpha For This Useful Post: | ||
|
|
2013-10-12
, 10:03
|
|
Posts: 434 |
Thanked: 990 times |
Joined on May 2010
@ Australia
|
#105
|
Originally Posted by mikecomputing
Already been in touch with mer.
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...
Know about irc, just couldn't get on last night at work.
__________________
Always remember you're unique, just like everyone else.
Always remember you're unique, just like everyone else.
| The Following User Says Thank You to onethreealpha For This Useful Post: | ||
|
|
2013-10-12
, 10:34
|
|
Moderator |
Posts: 5,320 |
Thanked: 4,464 times |
Joined on Oct 2009
|
#106
|
Originally Posted by mikecomputing
What are the downsides/upsides to this approach versus other one?
No need for dedicated IRQ pin if run OTH peripheral as master but...
|
|
2013-10-12
, 17:05
|
|
Posts: 1,104 |
Thanked: 5,652 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.
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.
|
|
2013-10-13
, 10:38
|
|
Posts: 3,464 |
Thanked: 5,107 times |
Joined on Feb 2010
@ Gothenburg in Sweden
|
#108
|
Originally Posted by dirkvl
No need for IRQ for this kind of peripheral better let OH be master. See my post below.
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!
Originally Posted by jalyst
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...
What are the downsides/upsides to this approach versus other one?
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...
__________________
Keep safe and healthy
Keep safe and healthy
Last edited by mikecomputing; 2013-10-13 at 10:41.
| The Following 4 Users Say Thank You to mikecomputing For This Useful Post: | ||
|
|
2013-10-13
, 19:40
|
|
Posts: 1,104 |
Thanked: 5,652 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!
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!
|
|
2013-10-13
, 20:48
|
|
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
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: | ||
