Réalisation de connecteurs Dock à partir des Docking Station

[critor]

Les TI-Nspire disposent sur leur tranche inférieure d'un port Dock. Outre le branchement de périphériques rares et chers, il permet :

• de diagnostiquer les TI-Nspire qui ne s'allument pas ou ne démarrent pas, grâce à la sortie console série sur sa broche 4
• et même des opérations de maintenance grâce à son entrée série sur la broche 3, comme la reprogrammation des Boot2 et Diags ou encore l'envoi d'un OS, seule méthode pour mettre à jour certains prototypes TI-Nspire de début 2007 qui venaient préchargés avec des versions ne gérant pas encore le port USB

La connexion Dock des TI-Nspire fut un véritable cauchemar pour la communauté depuis maintenant une décennie. Le connecteur n'est pas standard, et aucune solution proposée n'a su s'imposer. Nous en étions réduits à coincer les 3 fils nécessaires (en comptant la masse) sous le cache du connecteur, avec éventuellement bouts de scotch et gouttes de soudure qui cassaient facilement pour éviter qu'ils ne bougent et fassent des bêtises lors des manipulations, le clavier et l'écran étant de l'autre côté. C'était particulièrement embêtant lors des opérations longues, comme les numérisation (dumping) ou reprogrammation des Boot1/Boot2/Diags/OS.

Le connecteur Dock officiel adapté existe même si on ne le trouve pas en vente séparément. On le trouve en deux versions différentes :

• une version très solide avec des broches saillantes recourbées sur elles-mêmes, dans les périphériques TI-Nspire Lab Cradle et TI-Nspire Navigator Cradle
• une version un peu plus malheureuse avec des broches saillantes droites dans les stations d'accueil TI-Nspire Docking Station et TI-Nspire CX Docking Station, permettant à la fois de ranger, recharger et remplir simultanément un lot de 10 calculatrices

Leur vulnérabilité, comme pour les connecteurs cartouches de Nintendo NES, est particulièrement élevée pour la station TI-Nspire Docking Station.

On peut en effet y mettre aussi bien des TI-Nspire CX que des TI-Nspire monochromes plus épaisses. Or, les TI-Nspire antérieures à 2010 et donc aux TI-Nspire TouchPad n'ont pas tout-à-fait la même épaisseur que ces dernières. On s'en rend compte aisément à la résistance très différente lorsqu'on les glisse dans le berceau d'un des périphériques officiels. Le morceau de plastique présent en bas du port Dock a tendance à accrocher et plier les broches, détruisant ainsi le connecteur.

En pratique, même si ça fait très mal au prix de la station, c'est un mal pour un bien. On trouve de temps en temps sur les sites d'occasion des stations d'accueil TI-Nspire Docking Station ainsi abîmées à des prix raisonnables, surtout que nombre d'enseignants nord-américains ont tendance à se séparer de leur matériel dédié aux TI-Nspire monochromes depuis déjà quelques années. Si les broches 3, 4 et 5/22 n'ont pas été abîmées, que dirais-tu de récuperer pour en faire notre propre connecteur Dock ?

Sur la carte CTB_CONNECTOR board_2430 ici utilisée par la TI-Nspire Docking Station, les broches 3 et 4 ne sont hélas pas connectées. Rien de surprenant puisque la nappe n'a que 16 pistes et le connecteur 26 broches. Mais on peut par exemple glisser un câble monobrin sous la partie saillante des broches.

Par réutilisation du berceau accompagnant la carte, nous obtenus enfin un connecteur Dock fiable et sécurisée.

Et comme la TI-Nspire Docking Station vient avec 10 connecteurs, tu pourras toujours revendre les autres après t'en être gardé un ou deux...

[critor]

Une fois que l'on s'est fabriqué 2 connecteurs Dock, on peut enfin les connecter entre eux pour réaliser un TI-Nspire DockLink.
Connexions effectuées :

• RX <-> TX
• TX <-> RX
• GND <-> GND

Plus besoin d'ordi et d'interface TTL/USB, on peut diagnostiquer une TI-Nspire en obtenant son bootlog directement avec une autre TI-Nspire que l'on connecte en seulement 2 mouvements :


Toutefois ici, même si cela reste lisible et exploitable, le programme Ndless de réception saute un pourcentage non négligeable de caractères.
Le programme ignore aussi volontairement les caractères identiques à la suite, parce que la fonction uart_getchar() utilisée continue à renvoyer en boucle le dernier caractère reçu même quand il n'y a plus de donnée. D'où les Bot à la place de Boot notamment.

Voici le code principal, si quelqu'un voit ce qui cloche :

Code: Select all

#include <os.h>

#define BUFSIZE   128*1024

void main(void) {
   char input[BUFSIZE], oldc=0;
   memset(input,0,BUFSIZE);
   char* inptr=input;
   initScreen();
   startScreen();
   uint8_t* screen = getScreen();
   setCurColorRGB(255,255,255);
   memset(screen,0,SCREEN_WIDTH*SCREEN_HEIGHT*2);
   resetConsole();
   while(!isKeyPressed(KEY_NSPIRE_ESC)) {
      *inptr=uart_getchar();
      if(*inptr!=oldc) {
         oldc=*inptr;
         if(!oldc) *inptr=' ';
         disp(inptr,1,0);
      }
   }
}

[parrotgeek1]

Are you using these functions? https://github.com/compujuckel/nspire-i ... ire-uart.c

[critor]

I'm using the uart_getchar function coming with the Ndless SDK. It may be the same one.

I've also pasted its code from https://github.com/compujuckel/nspire-i ... ire-uart.c without seeing any improvement.

[critor]

Après échanges dans viewtopic.php?t=20611 , il se trouve que le bug vient de Ndless.

En attendant une mise à jour, les fonctions uart impactées sont à dupliquer et corriger :

Code: Select all

#include <os.h>

#define BUFSIZE   128*1024

BOOL myuart_ready(void)
{
   volatile unsigned *line_status_reg = IO(0x90020014,0x90020018);
   return is_classic ? *line_status_reg & 0b1 : !(*line_status_reg & 0b10000);
   //return is_classic ? *line_status_reg & 0b1 : !(*line_status_reg & 0b10);
}

char myuart_getchar(void)
{
   volatile unsigned *recv_buffer_reg = (unsigned*)0x90020000;
   while(!uart_ready())
      idle();
   char tmp = *recv_buffer_reg;
   uart_putchar(tmp);
   return tmp;
}

void main(void) {
   char input[BUFSIZE];
   memset(input,0,BUFSIZE);
   char* inptr=input;
   initScreen();
   startScreen();
   uint8_t* screen = getScreen();
   setCurColorRGB(255,255,255);
   memset(screen,0,SCREEN_WIDTH*SCREEN_HEIGHT*2);
   resetConsole();
   while(!isKeyPressed(KEY_NSPIRE_ESC)) {
      if(myuart_ready()) {
         *inptr=myuart_getchar();
         if(!*inptr) *inptr=' ';
         disp(inptr,1,0);
         inptr++;
      }
   }
}

Marche maintenant parfaitement avec une autre CX !


Pour la première fois au monde, on peut même observer le mode "fastboot" du Boot1 CR4+, non reproduisible sur émulateur !


Resterait maintenant à coder une 'vraie' console défilable et remontable.

Ici une TI-Nspire CAS malade. Elle s'amorce bien comme on constate dans le bootlog, mais l'écran reste éteint :

On remarque également plusieurs mauvais caractères... la communication avec les TI-Nspire monochromes semble problématique.

Ici un prototype TI-Nspire CAS DVT1.2 très malade. Se plaint de l'absence de clavier :

On constate là encore quelques mauvais caractères, et donc les mêmes problèmes de communication.
En pratique sur les modèles monochromes, ce message d'erreur n'a rien à voir et est symptomatique d'un problème lors de la lecture de la partition Manuf (partition effacée/corrompue, voir même puce Flash défectueuse).

Enfin, ici un prototype TI-Nspire CAS+ PVT1.1 qui marche très bien. Mais alors niveau communication ça ne va plus du tout, c'est complètement illlisible :

[Bisam]

As-tu essayé la communication dans l'autre sens, je veux dire d'une CX (CAS) vers une Touchpad (munie d'un OS et d'une version de Ndless suffisamment récents, bien entendu), par exemple ?

[critor]

Ce sera un des prochains tests, merci à toi.

Mais avant, il faut que je prenne le temps de faire évoluer le programme, histoire déjà qu'il tourne sur écran monochrome (absolument pas testé ni même pris en compte à date sur cette version de test et à juste titre non publiée en archives), et si possible que l'on ait une console défilable.

[parrotgeek1]

Ce sera un des prochains tests, merci à toi.

Mais avant, il faut que je prenne le temps de faire évoluer le programme, histoire déjà qu'il tourne sur écran monochrome (absolument pas testé ni même pris en compte à date sur cette version de test et à juste titre non publiée en archives), et si possible que l'on ait une console défilable.

maybe you could use the display code from
http://martin.poupe.org/casio/fxterm/index.html

[critor]

Finalement, ce n'est pas une idée si géniale que ça que de partir de connecteurs Dock fragiles et déjà fragilisés, surtout quand ça va être pour les brancher+débrancher sans arrêt.

Voici un reboot du projet en partant d'un TI-Nspire Navigator Cradle :

Avantages :

• connecteur Dock sur carte fille séparée
• carte fille reliée par une nappe 40-pins au pas de 0.5mm standard
• les contacts Tx/Rx sont cette fois-ci bien présents sur la nappe
• le connecteur Dock ici à contacts recourbés est beaucoup plus solide

Je remplace ici la carte mère par un adaptateur FPC 40 0.5mm <-> DIP 40, aisément manipulable.
Donc à priori, plus rien de dangereux pour le soudeur du dimanche !

Si besoin, l'adaptateur vient d'ici :
http://www.ebay.fr/itm/172583278407

[critor]

Tested only with the multimeter for now, but the v2 looks much more robust :


Moreover, I now have easy access to most Dock/J01 pins, not only Tx/Rx/GND, should I need them someday.
Pins available : 1-5 + 9-22 + 24-26.