Quelques informations sur la connectique avec norme I2C du Jolla

Jolla en dévoile un peu plus sur le côté matériel du smartphone avec la connectique qui se trouve sur le Jolla servant à communiquer avec une Other Half.

jolla-other-half

En effet, pour communiquer entre le smartphone et une Other Half qui comprendrait un appareil photo, un clavier physique… Jolla a choisi la norme I2C, très utilisée en électronique.

L’I2C est un bus de données série synchrone bidirectionnel half-duplex (qui peut communiquer dans les deux sens mais pas simultanément contrairement au full-duplex). Il permet de relier facilement à un microprocesseur différents circuits. Nous pouvons donc imaginer toutes sortes de coques, tant qu’elles respectent les caractéristiques ci-dessous :

  • 3,3V VDD (max 300 mA, de préférence en dessous de 150 mA pour éviter les problèmes de chaleur. [VDD pour la tension d’entrée au composant].
  • 1,8V I2C (400 kHz paramètre par défaut dans le noyau).
  • l’Other half est prévue pour fonctionner en mode esclave, le téléphone étant le maître.
  • Un port intégré INT GPIO* (1,8V).

*GPIO : Les ports GPIO (General Purpose Input/Output, c’est-à-dire entrée/sortie pour un usage général) sont des ports d’entrée/sortie très utilisés dans le monde des microcontrôleurs, en particulier dans le domaine de l’électronique embarquée. Selon la configuration, ces ports peuvent fonctionner aussi bien en entrée qu’en sortie. [Wikipedia]

Du côté de la programmation, des exemples d’API (Interface de programmation) et plus de détails seront disponibles dans une mise à jour à venir du SDK (Kit de développement logiciel) de Sailfish OS.

Vivement que les constructeurs d’accessoires s’y mettent !

Source

A propos de Nicolas SUFFYS

Co-fondateur de JollaFr.org et Nokians.fr. Linuxien de longue date et possesseur de Nokia N900, N9, N950, Jolla, Oneplus One, Lumia 830.

19 commentaires à propos de “Quelques informations sur la connectique avec norme I2C du Jolla

      • C’est pas faux comme analyse, mais il va y avoir conflit si les 2 veulent etre master et aucun slave.

        « Master
        Master
        Just call my name, `cause I’ll hear you scream »

        • Si j’ai bien suivi, la Raspberry Pi ne peut pas être esclave (son processeur ne le supporte pas, c’est pas juste une question de soft).
          Si le Jolla permet d’être esclave, ça peut marcher, mais ça irais un peu à l’envers niveau principe.
          Sinon, il y a toujours la possibilité de mettre de l’arduino ou n’importe quel micro-contrôleur. La BeagleBoardBlack supporte peut être aussi l’I2C esclave, à regarder.

  1. Salut Nicolas,

    Concernant le point « Un port intégré GPIO* (1,8V). », la partie importante était le fait que ce soit une entrée _d’interruption_ (« INT GPIO »).

    Le principe même de l’I2C fait que l’esclave (l’other half) ne peux que répondre au maître (le téléphone) mais pas initier un échange.

    Dans le cas où on veut mettre 3 leds sur l’other half (ou un écran e-ink), pas de problème : quand le téléphone veut en changer la couleur, il lui envoie un message et c’est réglé.
    Si on veut mesurer la pression ambiante toutes les minutes, pas de problème non plus, on aura une tempo dans le téléphone qui ira à chaque fois lire la valeur dans l’other half « mesure de pression » (ça marche pour n’importe quel capteur bien sur, tant que c’est periodique).

    Le principal problème vient des other half qui doivent signaler un événement au téléphone, et que l’on ne sait pas à l’avance quand ça va arriver. L’exemple le plus simple est le clavier : il est impossible de savoir quand l’utilisateur va appuyer sur une touche. Donc soit on fait du « polling », c’est à dire que l’on interroge constamment l’other half pour savoir si il s’est passé quelque chose, mais c’est gourmand en ressources et mauvais en temps de réponse. Si je veux un temps de réponse de 100ms max, alors je dois scruter toutes les 100ms. Si maintenant je veux maxi 1ms pour voir l’événement, alors je dois interroger le capteur 1000 fois par secondes, alors qu’il ne se passe pratiquement jamais rien.

    La solution à ce problème, que Jolla a heureusement choisi, consiste à utiliser une entrée d’interruption (Entrée pour le téléphone, c’est une sortie de l’other half).
    L’idée est que l’on ne fait plus de polling, mais qu’on permet à l’other half de signaler qu’il s’est passé quelque chose, en passant la ligne d’interruption de 0V à 1.8V. En interne du processeur du Jolla, cela déclenche la tâche chargée de traiter le clavier, qui va donc interroger le clavier pour savoir ce qu’il s’est passé (et donc récupérer quelle touche à été pressée/relâchée), puis une fois fait l’other half relâche le signal d’interruption (retour à 0V), et le processeur repart à ses occupations. Et ainsi de suite.
    L’avantage est double : meilleur temps de réponse (le processeur réagit dès qu’il peut à l’interruption, et pas seulement de temps en temps comme en polling), et en performances (si il y a 3 appuis de touches en 10 secondes, on n’aura que 3 lecture du clavier, et pas des milliers comme en polling).

    C’est donc un très bon point que Jolla ait suivi ce « standard » en permettant d’utiliser les interruptions. A vérifier si il est aussi possible de l’utiliser en sortie (sinon c’est pas vraiment une GPIO, juste GPI) ?

    Et sinon, je ne suis pas sur que ce soit une bonne idée de toujours parler de l’other half photo, car niveau technique c’est vraiment juste par l’I2C (ça pourrait le faire en wifi, mais dans ce cas c’est plus vraiment une other half…). Pour exemple, si tu veux afficher sur l’interface l’image que tu essayes de prendre en photo pour cadrer, tu vas vouloir afficher au moins du 10 images par secondes (5 ça commence à saccader), et avec une résolution correcte. Avec un débit théorique à 400kbps, c’est vraiment chaud d’avoir ça (où alors avec une compression de malade). Et une fois la photo prise, pour peu que tu y ailles avec une bonne résolution et une bonne qualité (compression JPEG pas trop forte), tu as vite 2 ou 3 Mo à transférer, soit plusieurs secondes. Par rapport à prendre des photos avec l’appareil natif, avec un 808, ou n’importe quel autre appareil du commerce, ça fera pale figure. Et je ne parles même pas de faire de la capture vidéo FullHD à 30fps… Avec le wifi en revanche ça passerait niveau débit (c’est pas Sony qui en a fait un ?), mais c’est plus vraiment du spécifique other half, car tu pourrais l’utiliser sur n’importe quel appareil (tablette et pc inclus), et si c’est pour monopoliser le wifi pendant ce temps… Marc Dillon a toujours pris comme exemple le flash et le clavier, il y a sûrement une raison qu’il n’ait pas été plus loin dans les exemples…

    • Voila qui s’appelle une contribution. Bravo Zeta! Malgré l’exclusion de l’appareil photo (hors utilisation du WIFI) et de l’ajout de mémoire/stockage, il reste des milliers de possibilités de capteurs et de « diffuseurs » (sons, paramètres de l’air, lumière, toucher, « odorat », affichage, clavier/pad, crypto…).

      Si ce smartphone n’avait pas quelques limites esthétiques (absence d’un écran incurvé sans cadre plastique), l’absence d’une mémoire de 2GB et d’une résolution HD 720 x 1280, il serait quasi idéal. Cela dit, avec les caractéristiques de Sailfish et de l’I2C, il conserve de forts atouts. Wait & see!

    • j’ai pas tout lu (la dernière partie). JE me suis fais un schéma dans ma tête

      En aucun cas il peut y avoir OH>>>Jolla dès le premier contact si je comprends bien ? Mais l’option Jolla>>>OH>>>Jolla c’est ce qu’il se fera lorsqu’on connecte l’OH.

      Si je comprends bien pour changer un paramètre d’ambiance ou charger un profil quelconque, automatiquement le Jolla ira chercher dans l’OH sans que ce dernier lui dit  » hey oh je suis collé à toi, je t’envoie mes paramètres  » ?

      Si personne ne me comprend tant pis :p

      • « En aucun cas il peut y avoir OH>>>Jolla dès le premier contact si je comprends bien ? Mais l’option Jolla>>>OH>>>Jolla c’est ce qu’il se fera lorsqu’on connecte l’OH.  »
        si par « OH>>>Jolla », tu représentes un message échangé entre les deux à l’initiative de l’OH, alors il faut distinguer le signal d’interruption et le bus I2C. ça donnerais ça :
        OH >(INT)> Jolla => l’OH signale qu’il y a du nouveau
        Jolla >(I2C)> OH => le Jolla fait une demande de lecture à l’OH
        OH >(I2C)> Jolla => l’OH réponds avec les données

        Donc l’OH ne peut pas initier directement une communication par I2C, mais peut la demander au Jolla grace au signal d’interruption. Je ne sais pas si c’est plus clair comme ça ?

        Concernant la détection des other half, je ne suis pas encore trop sûr de ce que ça va donner…
        Déjà pour commencer, le bus I2C est branchable à chaud, donc pas besoin d’arrêter pour changer l’other half. Par contre, pour la détection, on ne peux pas vraiment dire que c’est plug&play comme un port USB, où le périphérique donne son fabricant et modèle pour que le téléphone charge le pilote qui va bien. La seul chose que l’on ait c’est l’adresse du périphérique (128 ou 1024 max selon le mode choisi : 7 ou 10 bits), ce qui ne permet pas de différencier à coup sur tout les composants existants sur le marché.

        Le plus simple est d’ajouter une petite eeprom I2C qui contient ces données et qui est à une adresse fixe (spécifiée par Jolla eux même) donc que le Jolla ira interroger pour avoir les infos de l’other half quand il détecte un changement (c’est ce qui est fait sur les cartes d’extension « capes » de la beagle bone, ou pour les infos des écrans en HDMI). L’autre solution est d’utiliser le NFC (comme dans le cas de l’appairage bluetooth), mais c’est moins facile pour une other half bricolée maison.

        Dans le pire des cas, il y a juste un fichier de conf à modifier pour charger les drivers qui vont bien (et ça peut être fait à travers une interface graphique listant toutes les other half)…

        • Ah oui tu es passionné par cette techno Zeta :-). Cela dit tu es loin d’être le seul. A vue de nez, j’ai l’impression que les puces NFC programmables se multiplient. On peut imaginer que la bidouille sera possible. Et qui sait si cette fois Jolla ne nous fera pas une agréable surprise en intégrant d’emblée ces manips dans le tel ou son terminal?

  2. J’aimerai bien voir une other half intégrant une manette de jeu. Ca me semble tout a fait adapté. On pourrait en plus utiliser des émulateurs comme ppsspp (le hardware, même limité du Jolla Phone peut faire tourner cet émulateur sans problème).
    Je suis pas un gros joueur, loin de là, mais rien que pour la bidouille, ça m’intéresse. J’ai bien envie de rejouer aux jeux psp pour le plaisir.
    Techniquement, je pense que c’est largement faisable 🙂

    Je pense aussi que certains vont bricoler quelque chose avec des imprimantes 3D. L’idée de l’other half est pas mal, comme dit au dessus, faut espérer que certains constructeurs se lancent.

  3. Other Half avec écran E-Ink pour écran de notification ultra basse consommation.
    fusionner le meilleur de yotaphone avec Jolla, l’union fait la force.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*