Protocole USB - Page 1

Je suis en train de documenter le protocole USB utilisé pour les échanges Computer Link Software <-> TI-Nspire. Il est heureusement assez simple, mais il y a un champ qui me tracasse, peut-être que quelqu'un saurait trouver. A priori ce serait un checksum de la partie donnée (non en-tête, qui est optionnelle) de chaque paquet. Si on ne trouve pas, Je n'arrive pas à trouver l'algo de checksum utilisé. alors que ce n'est peut-être tout simplement pas ça.

Quelques exemples (à chaque fois la partie donnée, et le checksum de 16 bit correspondant).

[rien]                                        -> 00 00
00 FF                                         -> FF 00
0E 00                                         -> 00 0E
40 60                                         -> 60 40
80 01                                         -> 01 80
64 01 FF 00                                   -> 13 43 
20 00 00 00 00 00 00 00 05 01 00              -> A0 95
20 00 00 10 B1 00 00 00 06 00 00              -> 85 7F
03 01 00 00 00 00 00 00 00 00 00 00 00 10 B1  -> 3A B2
0D 45 78 61 6D 70 6C 65 73 2F 00              -> CE CA

[edit] Un autre que je trouve intéressant :
20 00 00 00 00 00 00 00 00 01 00 -> F7 38

C'est marrant qu'au début ce soit symétrique et puis pas après.

Ca ne laisse pas trop entrevoir de lien logique entre les premiers paquets et la suite.

Comment tu arrives à obtenir ce genre d'info ? Tu as un logiciel qui analyse les ports USB ?

T'as essayé un simple CRC sur 16 bits ?

Ce n'a pas l'air d'être un CRC16 tout bête, mais peut-être qu'on peut jouer sur ses paramètres ? http://www.zorc.breitbandkatze.de/crc.html

geogeo (./3) :
Comment tu arrives à obtenir ce genre d'info ? Tu as un logiciel qui analyse les ports USB ?

Oui tout simplement.

./2 Pas besoin de calculer un checksum de 16 bits pour 16 bits de données, autant dupliquer les données

J'ai fait un programme en jouant sur les paramètres avec le même algo que proposé dans ton site en ./5 Extended et rien à y faire.
TI doit forcément utiliser une librairie USB qui génère automatiquement les checksums ?

ok
Tu veux dire côté PC ou côté TI ? Le checksum est de toute façon indépendant d'USB ici.

Des deux côtés peut être. Mais disons que si les 16 bits correspondent bien à un checksum ils ne peuvent être générés qu'à partir d'un algorithme standard que TI utilise. D'une librairie qui fait le boulot.
http://www.embedded.com/story/OEG20030205S0046
http://www.mcci.com/mcci-v5/pdf/971548c.pdf

TI utilise Nucleux et donc l'OS intègre forcément un protocole USB standard permettant la communication entre une unitée embarquée et un PC... ?

Le protocole utilisé semble être du spécifique TI, et entre ce que propose Nucleus en tant que modules et ce que TI utilise effectivement, la limite n'est aujourd'hui pas très claire (d'autant plus que Nucleus est vendu en tant que code source et est donc entièrement personnalisable).

J'ai un nouveau test intéressant :
05 00 00 -> 57 AD
Je peux fournir facilement le checksum de n'importe quelle séquence commençant par 05 si besoin.

> Je peux fournir facilement le checksum de n'importe quelle séquence commençant par 05 si besoin.

C'est bien du CRC ou autre chose ? Bref, comment arrives tu à calculer le checksum ?

Bah je laisse calculer Computer Link Software pour l'instant C'était pour proposer d'autres exemples.

Finalement je suis en train de regarder directement ce que fait la routine côté PC. Y'a du xor et du shift dans tous les sens, ça pourrait être du CRC.

Tu a décompilé le soft PC?

J'ai dit ça ? C'est illégal.

Bon moi de mon côté j'ai pris :

20 00 00 00 00 00 00 00 05 01 00 -> A0 95
20 00 00 00 00 00 00 00 00 01 00 -> F7 38

J'essayes les paramètres polynom, crcinit, crcxor, direct avec un programme. En espérant que j'ai des paramètres identiques qui me donne les checksums corrects pour les 2 paquets de données que j'ai cité ci-dessus.

Ca y est, je le tiens. Un bout de code de test en Python :

def checksum(data):
    acc = 0
    for byte in data:
        first = (ord(byte) << 8) | acc >> 8
        acc = acc & 0xFF
        second = (((acc & 0xF) << 4) ^ acc) << 8
        third = second >> 5
        acc = third >> 7
        acc = (acc ^ first ^ second ^ third) & 0xFFFF
    return acc

assert checksum('\x00\xFF') == 0xFF00
assert checksum('\x05\x00\x00') == 0x57AD
assert checksum('\x20\x00\x00\x00\x00\x00\x00\x00\x05\x01\x00') == 0xA095
assert checksum('\x20\x00\x00\x10\xB1\x00\x00\x00\x06\x00\x00') == 0x857F
assert checksum('\x0D\x45\x78\x61\x6D\x70\x6C\x65\x73\x2F\x00') == 0xCECA

Si quelqu'un reconnait un petit cousin CRC...

[edit] optimisé

Ca semble être un CRC made in TI.

Intéressant ça, je sens qu'on va bientôt avoir de quoi gérer la Nspire dans TiLP.

Bravo Olivier

Bien joué

Quelques nouveaux trucs intéressant : Une série de commandes du protocole USB permettent d'avoir plusieurs infos sur la calc, pas toutes affichées par Computer Link. Il y a notamment :

- La RAM disponible et celle utilisée (cf plus loin). Computer Link n'affichant que le "storage" (la mémoire flash).
- La taille de l'écran, des coordonnées (x=y=0 ??), bitsPerPixel=4 (donc plusieurs bits par pixel plutôt que plusieurs plane pour les niveaux de gris, comme le suggérait Pollux ailleurs)
- Un flag "charging" (puisque le dock vendu séparemment permettrait de la charger)
- Une info intéressante : clockSpeed = 90 !
- runLevel : à 1 en mode recovery (i.e. sans OS), à 2 dans l'OS.
- hardwareVersion = 0 (pour une Nspire standard en tout cas - le test sur une CAS serait intéressant)

Concernant l'utilisation de la RAM et de la storage memory, après quelques tests (certaines remarques peuvent être faussées) :
- La storage memory travaille par blocs de 512 octets (en tout cas la mémoire disponible est arrondie là dessus)
- Après suppression d'un document, la storage memory diminue, mais la RAM aussi ! à peu près d'autant.
- La RAM fluctue régulièrement quand on utilise la calc (l'éteindre, ouvrir un doc, ...), de quelques ko à quelques centaines de ko, donc ce qu'on peut constater n'est pas forcément très précis.
- Entre 2000 et 4000ko de RAM sont couramment utilisés sur les 24792ko disponibles sur une Nspire non CAS (pour rappel 28544ko de storage memory est disponible)
- En mode recovery, seuls 5124ko de RAM sont disponibles ! Environ 1000ko sont utilisés.
- Les transferts (OS ou documents) se font appararemment directement en storage memory (i.e. pas de gros stockage temporaire en RAM)
- Le passage en émulation 84+, ainsi que le vidage de la mémoire flash de la 84+ émulée par reset n'impact par la storage memory disponible de la Nspire (pour rappel l'USB ne fonctionne qu'en mode Nspire, pas d'interrogation de ces infos possibles en mode 84+). Donc l'image de la mémoire archive de la 84+ semble être préparée à l'installation de l'OS, et est dez taille fixe.

D'autres idées de test d'utilisation de la mémoire, qui permettrait d'y voir un peu plus clair sur son utilisation ?

Comment je peux tester sur ma Nspire CAS ?

Où peut-on trouver le CAS Software ?

geogeo : je t'envoie ça par mail.
tikau : Computer Link Software ? topics/101615-computer-link-software#0 Computer CAS Software ? C'est payant, et la version d'évaluation n'est pas encore publique.

ok

J'ai ceci:

storageAvailable=25594880
storage=29229056
ramAvailable=20889632
ram=23353276

screen:
x=0
y=0
width=320
height=240
bitsPerPixel=4
sampleModel=0

battery=127
charging=0
clockSpeed=90
runLevel=2
version=1 1 9170
boot1Version=1 1 8916
boot2Version=1 1 8981
hardwareVersion=1
name=TI-Nspire CAS
fileExtensions=.tns
osExtensions==.tnc
deviceCode=14

En gras ce qui diffère.

Il y a quand même 2 Mo de RAM en moins.

deviceCode=30 sur une Nspire.

geogeo (./27) :
hardwareVersion=1

Pas bon ça

Les clones demeurent interdits, surtout quand on en a déjà au moins quatre de bannis...

geogeo (./27) :
hardwareVersion=1

Pas bon ça

En fait c'est peut-être tout simplement à cause du clavier interchangeable et de la position des piles qui diffèrent.