[critor]

Aujourd'hui découvrons ensemble un nouveau capteur peu commun pour nos calculatrices, l'accéléromètre 25g de chez Vernier:

Il s'agit d'un appareil permettant de mesurer l'accélération selon un axe, c'est-à-dire la dérivée de la vitesse (classe de Première), elle-même dérivée de la position.

Notons bien qu'il ne mesure donc pas directement le mouvement ou sa vitesse, mais les variations de la vitesse (accélération si elle augmente ou freinage si elle diminue) ou encore les variations des variations du mouvement.

Il est possible d'obtenir vitesse et position par intégration (classe de Terminale), mais cette méthode serait imprécise et ne nous intérèssera pas ici.



Pour simplifier les choses, on peut modéliser l'élément de mesure d'un accéléromètre monoaxe par une masse montée sur un ressort. Selon l'accélération du mouvement selon l'axe du ressort, ce dernier sera au repos, compressé ou bien étiré. La position de la masse donnera la mesure de l'accélération en m/s².

Selon la 2ème loi de Newton (Première S), l'accélération selon un axe est:

• positive pour un mouvement accéléré (vitesse en augmentation)
• négative pour un mouvement décéléré (vitesse en diminution)
• nulle pour un mouvement uniforme (à vitesse constante, ce qui inclut l'immobilité avec une vitesse constante v=0)

Voyons un peu... Positionnons notre accéléromètre de façon transversale à la calculatrice:

Maintenons maintenant la calculatrice à l'horizontal, ce qui fait donc mesurer l'accélération verticale:

Nous obtenons une accélération de 9.8m/s² orientée vers le bas - c'est l'accélération due au champ de pesanteur terrestre, 1g.
La plage de mesures de +/- 25g peut alors paraître énorme, mais si le but est de mesurer l'accélération lors de chocs elle ne l'est pas du tout.


Par contre... n'y a-t-il pas contradiction puisque nous avions dit que selon la 2ème loi de Newton, l'accélération est nulle pour un objet immobile?
Effectivement: l'accéléromètre est ici soumis à 2 forces s'équilibrant:

• le poids du au champ de pesanteur terrestre
• la réaction exercée par ma main

Mais cette dernière force n'est pas mesurable par l'accéléromètre, à cause de l'interaction mécanique (3ème loi de Newton - Première S) avec le support du ressort auquel elle est transmise.

Ce n'est en fait pas bien grave, puisque si l'on veut annuler cette accélération il suffit d'un simple calibrage.
En conséquence, selon ce que l'on veut mesurer, et l'axe selon lequel on souhaite le mesurer, notre accéléromètre va nécessiter une procédure de calibrage différente.



Sans rien changer, inclinons légèrement la calculatrice.

L'accélération mesurée devient en valeur absolue inférieure à g.
En effet, le champ de pesanteur n'a plus la même direction que l'axe de l'accéléromètre, et par projection ne s'exerce donc que partiellement sur ce dernier.

En fait ici, l'accéléromètre est tout simplement calibré pour mesurer une accélération horizontale, qui sera nulle une fois la calculatrice verticale.

Pour une fois, à vous la parole!
Quelles applications faisant usage de cet accéléromètre vous sembleraient utiles ou intéressantes sur calculatrice?

[critor]

Dans deux news précédentes, nous avions récupéré deux prototypes TI-Nspire CAS P1R2-DVT1.2.

En apparence aucun des deux ne disposait de logiciel de diagnostics: les touches ne changeaient rien au démarrage.

Nous nous sommes amusés à transformer ces prototypes en modèles de production acceptant les derniers OS 3.1 et 3.2, en reprogrammant leurs Boot1 et Boot2.

Et là l'un des deux, celui qui disposait de l'OS 1.4 de debug nous a fait un truc étrange... Nous avions bien la barre de chargement du Boot1 jusqu'à 50% et puis il s'éteignait au lieu d'afficher le chargement du Boot2...

Que se passait-il? Avions nous cassé quelque chose? Grillé le Boot2? Que nenni, nous n'avons jamais cassé une seule TI-Nspire de notre vie malgré toutes nos expériences dont des 10aines de transformations de prototypes - il n'y a aucune raison!



Calmons-nous et voyons un peu ce qui se passe en écoutant ce que raconte ce prototype sur la console série RS232 du connecteur Dock:

Code: Select all

Boot Loader Stage 1 (1.1.8916)
Build: 2007/4/23, 23:37:16
Copyright (c) 2006, 2007 Texas Instruments Incorporated
Using any        keys
Last boot progress: 38731
Clocks:  CPU = 90MHz   AHB = 45MHz   APB = 22MHz
Available system memory: 37292
Checking for NAND: NAND Flash ID: ST Micro NAND256R3A
PM is turning the device OFF
PM has turned the device ON
SDRAM memory test:   Pass
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Clearing SDRAM...Done.
Boot option: Toggle Diagnostics
Loading DIAGS software...
96%
BOOT1: loading complete (96 ticks), launching image.

U-Boot 1.1.2 (Feb  2 2007 - 19:48:46)
U-Boot code: 11800000 -> 1182DC2C  BSS: -> 1183246C
RAM Configuration:
Bank #0: 10000000 32 MB
Flash: 512 kB
NAND:32 MB
*** Warning - bad CRC, using default environment
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
Starting Phoenix diagnostics...
Phoenix ASIC#

Wouah! En fait le prototype ne s'éteint pas à 50% mais lance un logiciel de diagnostics alors qu'apparemment il n'en avait pas. En effet, j'oubliais que le logiciel de diagnostics se lançait automatiquement après une reprogrammation du Boot2 via nos outils - j'aurais du y penser.

On avait l'impression avant qu'il n'y avait pas de logiciel de diagnostics car il ne se lançait pas. Et il ne se lançait pas car il était probablement signé avec les clefs RSA de production et non les clefs RSA de développement. En remplaçant le Boot1 de développement par un Boot1 de production nous l'avons débloqué!

Décidément, ce prototype venant pour une fois directement de l'équipe de développement TI-Nspire est plein de surprises!
Mais clairement, l'ingénieur ou technicien TI qui s'était donné la peine de porter et programmer ce logiciel de diagnostics, l'avait ici fait pour rien puisque ce logiciel n'était pas utilisable avec un Boot1 de développement.

Et en fait c'est un logiciel de diagnostics extrêmement étrange... L'écran reste éteint car justement il n'affiche rien dessus: le menu est directement écrit sur la console RS232. Et c'est via cette console que sont attendues les entrées et non pas via le clavier TI-Nspire!

Ce logiciel de diagnostics est constitué d'une image chargée par le lanceur U-Boot 1.1.2 (compilé le 2 février 2007), un lanceur libre entre autres célèbre dans le domaine du Linux embarqué.
Or, nous avions déjà trouvé un U-Boot 1.1.2 dans le Boot1 du TI-Phoenix 1, un prototype TI-Nspire CAS+, et effectivement lui aussi n'affichait justement rien à l'écran pendant le Boot1.

Or, le plus ancien logiciel de diagnostics pour TI-Nspire ClickPad que nous avions récupéré jusqu'à présent était le 1.1.7387 compilé quelques jours après, le 13 février 2007.
Qu'est-ce que ce logiciel de diagnostics U-Boot/RS232 sans aucun rapport avec les suivants vient donc faire là?

En fait, nous pensons qu'il s'agit d'un portage rapide vers la plate forme ASIC du logiciel de diagnostics pour TI-Nspire CAS+ et modèles compatibles (plate forme OMAP).

En effet, le logiciel de diagnostics TI-Nspire CAS+ n'a jusqu'à présent jamais été trouvé sur aucune des unités en circulation, peut-être tout simplement parce qu'il fonctionne en RS232 et n'affiche rien à l'écran - nous allons en tous cas vérifier rapidement avec sérieux cette hypothèse.

Un autre élément confortant cette hypothèse est fourni par les deux dernières lignes du bootlog, mentionnant clairement 'Phoenix', le nom de code des TI-Nspire CAS+ et compatibles.

Code: Select all

Starting Phoenix diagnostics...
Phoenix ASIC

De plus, la mention "Phoenix ASIC" sur la dernière ligne semble indiquer que la mention "Phoenix" toute seule aurait été imprécise.

Pour des raisons qui nous échappent, (peut-être les coûts de production?), il semble donc que Texas Instruments soit brutalement passé de la technologie OMAP à la technologie ASIC en passant des TI-Nspire+/TI-Nspire CAS+ encore produites en octobre 2006 aux TI-Nspire/TI-Nspire CAS dont nous voyons les premiers exemplaires en février 2007.



Bref nous sommes arrivés jusque-là, alors voyons ce que fait ce logiciel de diagnostics, sachant que s'il s'agit d'un portage rapide il est possible que nombre de fonctionnalités ne marchent pas correctement. Il a la gentillesse de lister toutes les commandes quand on tape 'help':

Code: Select all

Phoenix ASIC# help
?       - alias for 'help'
autoscr - run script from memory
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - invoke DHCP client to obtain IP/boot params
echo    - echo args to console
erase   - erase FLASH memory
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
imls    - list all images found in flash
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sleep   - delay execution for some time
tftpboot- boot image via network using TFTP protocol
tidiag  - perform Phoenix board diagnostics
version - print monitor version
Phoenix ASIC#

Ouah...
Que de trucs intéressants...
Il y a une gestion d'adresse IP via DHCP comme sur la TI-Nspire CAS+ et donc d'un réseau, il est possible de démarrer sur le réseau, et même de reprogrammer la mémoire NAND!

Allez, amusons-nous un petit peu:

Code: Select all

Phoenix ASIC# bdinfo
arch_number = 0x00000203
env_t       = 0x00000000
boot_params = 0x10000100
DRAM bank   = 0x00000000
-> start    = 0x10000000
-> size     = 0x02000000
ethaddr     = 08:00:28:32:16:FF
ip_addr     = 192.168.101.70
baudrate    = 115200 bps
Phoenix ASIC# coninfo
List of available devices:
serial   80000003 SIO stdin stdout stderr
Phoenix ASIC# demosave
Unknown command 'demosave' - try 'help'
Phoenix ASIC# dhcp
SMC91111: PHY auto-negotiate timed out
Warning: MAC addresses don't match:
        HW MAC address:  02:80:AD:20:31:B8
        "ethaddr" value: 08:00:28:32:16:FF
Using MAC Address 08:00:28:32:16:FF
BOOTP broadcast 1
Phoenix ASIC#   dir
Unknown command 'dir' - try 'help'
Phoenix ASIC# flinfo
Bank # 1: SST SST39LF/VF400 (4 Mbit, uniform sector size)
  Size: 512 KB in 16 Sectors
  Sector Start Addresses:
    20000000 (RO) 20008000 (RO) 20010000 (RO) 20018000 (RO) 20020000 (RO)
    20028000 (RO) 20030000      20038000      20040000      20048000
    20050000      20058000      20060000      20068000      20070000 (RO)
    20078000
Phoenix ASIC# imls
Phoenix ASIC# mtest
Pattern 005F8B0A  Writing...  Reading...
Phoenix ASIC# nboot
** No boot device **
Phoenix ASIC# printenv
bootargs=mem=32M console=ttyS0,19200n8 noinitrd                 root=/dev/nfs rw
nfsroot=157.87.82.48:                /home/mwd/myfs/target ip=dhcp
bootcmd=tidiag
bootdelay=0
baudrate=115200
ethaddr=08:00:28:32:16:ff
ipaddr=192.168.101.70
serverip=192.168.101.50
netmask=255.255.255.0
bootfile="uImage"
b1save= protect off all; era 1:0;  era 1:1;  era 1:2;  era 1:3; era 1:4;  era 1:
5;  era 1:6;  era 1:7; era 1:8;  era 1:9;  era 1:10; era 1:11; era 1:12; era 1:1
3; era 1:14; era 1:15;cp.b 10000000 20000000 30000
b1update=loadb; protect off all; era 1:0;  era 1:1;  era 1:2;  era 1:3; era 1:4;
  era 1:5;  era 1:6;  era 1:7; era 1:8;  era 1:9;  era 1:10; era 1:11; era 1:12;
era 1:13; era 1:14; era 1:15;cp.b 10000000 20000000 $(filesize)
b2erase=nand erase 4000 15C000
b2save=nand write 10000000 4000 $(filesize)
dgerase=nand erase 160000 A0000
dgsave=nand write 10000000 160000 $(filesize)
fserase=nand erase 200000 1E00000
up1=tftp 10000000 phoenix.raw
up1a=tftp 10000000 phoenix.raw ; g 10000000
up=tftp 10000000 grafixwt_demo.raw
up2=tftp 10000000 grafixwt_demo.raw ; g 10000000
demo=nand read 10000000 4000 480000; go 10000000
demoerase=nand erase 4000 480000
demosave=nand write 10000000 4000 $(filesize)
stdin=serial
stdout=serial
stderr=serial
Environment size: 1253/32764 bytes
Phoenix ASIC# protect
Usage:
protect - enable or disable FLASH write protection
Phoenix ASIC# tidiag
Starting Phoenix diagnostics...
Phoenix ASIC# version
U-Boot 1.1.2 (Feb  2 2007 - 19:48:46)
Phoenix ASIC#

Tiens, on obtient même des adresses IP et même des adresses réseau MAC qui si l'on vérifie leur entête sur les sites appropriés sont bien réservées par TI.

Mais au final, peu de choses intéressantes semblent fonctionnelles, ce qui appuie encore plus notre théorie d'un portage rapide du logiciel TI-Nspire CAS+, avant que le logiciel TI-Nspire ASIC ne soit enfin disponible quelques jours plus tard.


Le plus important, c'est que nous avons donc désormais une version du lanceur U-Boot compilée pour l'ASIC des TI-Nspire ClickPad!
Ce qui veut dire qu'avec quelques petites modifications, elle pourrait lancer une image Linux...
On disposerait alors d'un multi-boot sans plus aucun besoin de Ndless si jamais il est bientôt bloqué par TI: il suffirait en redémarrant sa TI-Nspire de maintenir pour démarrer Linux qui remplacerait donc le logiciel de diagnostics, et sinon par défaut ce serait l'OS Nspire qui se lancerait.

Bien évidemment, une telle chose nécessitera la modification de ce logiciel de diagnostics, qui bien évidemment sera refusée par un Boot1 normal. Le Boot1 serait donc lui aussi à reprogrammer.



Lien:
Versions TI-Nspire

TI-Planet: le site avec de vrais experts qui font de vraies découvertes historiques!

[critor]

Dans une news précédente, nous vous signalions que le manuel anglais de la station d'acquisition de données physiques TI-Nspire Lab Cradle sur le site de TI prétendait qu'elle n'était pas compatible avec les TI-Nspire CM-C commercialisées en Asie:

Important: The TI-Nspire CM-C Handheld is not compatible with the Lab Cradle and only supports the use of a single connector at a time.
Important: L'unité TI-Nspire CM-C n'est pas compatible avec la Lab Cradle et ne supporte que l'utilisation d'un seul connecteur à la fois.

Alors certes on ne peut pas connecter la TI-Nspire Lab Station Cradle via le connecteur Dock qui n'existe pas sur ces modèles, mais on peut parfaitement le faire via la prise mini-USB et nous vous montrions que ça marchait avec un capteur:

Il y avait donc déjà une première erreur dans ce manuel, mais ce n'est pas tout...



La fin de la phrase suggère que l'on ne peut utiliser qu'un seul capteur à la fois.
Nous aurions pu là aussi faire confiance au manuel, mais finalement aujourd'hui, comme nous sommes d'incorrigibles curieux, nous avons testé!

Vérifions donc ce que dit le manuel et branchons maintenant une interface TI-Nspire Lab Station Cradle munie de deux capteurs!

Ça marche parfaitement!



Bref en conclusion, contrairement à ce que vous pouvez lire dans les manuels TI ou sur les sites TI, les TI-Nspire CM-C supportent parfaitement les interfaces TI-Nspire Lab Cradle et les capteurs compatibles, ou du moins les supportent aussi bien que les autres modèles TI-Nspire!

La compatibilité avec l'interface TI-Nspire Lab Cradle est donc à rayer des inconvénients de la TI-Nspire CM-C, qui se résument finalement à:

• une mémoire SDRAM limitée à 32Mo contre 64Mo sur TI-Nspire CX (c'est gênant pour les programmes Ndless... qui n'existent pas encore sur CM )
• l'impossibilité de brancher les modules réseau TI-Nspire Navigator Cradle ou TI-Nspire CX Navigator Cradle

[critor]

Dans une news précédente, nous vous présentions un logiciel de diagnostics Nspire fort spécial trouvé sur un prototype TI-Nspire CAS P1T2-DVT1.2.

En effet, il utilisée le chargeur libre U-Boot pour se lancer, fort connu dans le monde du Linux embarqué.

De plus, il fonctionnait entièrement en RS232: les entrées et sorties s'effectuant exclusivement sur la console série du connecteur Dock. L'écran notamment reste éteint pendant l'excution de ce logiciel.

Et bien nous venons donc déjà de vous dumper (numériser) ce logiciel!

Contrairement à tous les autres logiciels de diagnostics TI-Nspire trouvés jusqu'ici, celui-ci n'est pas préfixé de l'identifiant "JDIAGS" mais d'un identifiant "JU-BOOT".


Retrouve-le dès à présent dans notre nouvelle catégorie, accompagné de tous les autres logiciels de Diagnostics qui sont notamment beaucoup plus utiles sur les TI-Nspire CX:
archives_list.php?id=ROM%20Nspire

[critor]

Dans une news précédente, nous vous présentions un capteur très rare, l'accéléromètre 25g de chez Vernier.

Il mesurant l'accélération selon un axe, et par conséquent la projection du champ de pesanteur.

Lorsque calibré pour mesurer l'accélération d'un mouvement horizontal, il est censé affiché lorsque immobile:

• -9.8m/s² lorsque orienté verticalement vers le bas
• 0m/s² lorsque horizontal
• 9.8m/s² lorsque orienté verticalement vers le haut

Ceci peut être parfaitement utilisé par trigonométrie pour retrouver l'inclinaison de la calculatrice!
Toutefois, cette inclinaison ne sera connue qu'à une symétrie axiale près, puisqu'il y a 2 solution sur le cercle trigo.

Et bien c'est plus qu'une simple hypothèse, c'est fait et ça marche - regardez!

Je vous ai donc fait une petite application Lua qui dessine une TI-Nspire CX CAS vue de profil inclinée à l'écran.

Comme il y a 2 solutions, l'appli considérera toujours par défaut que vous avez mis l'écran de la Nspire avec sa face pointant vers le haut.

On pourrait sans doute prévoir nombre d'applications dans des jeux, ou encore un réglage automatisé de la luminosité de l'écran selon l'inclinaison de la calculatrice.



Allez pour les sceptiques, preuve que ce n'est pas un truquage avec une image fixe:

Et maintenant vous allez me dire "pourquoi ça rame autant?"

J'en profite donc pour vous présenter un petit point faible du Lua que certains d'entre vous semblent ignorer, les images. Et encore ici, c'est loin d'être une image plein écran...

Ici, je n'effectue en boucle que 2 choses sur l'image:

• une rotation
• un affichage

Et c'est en fait l'affichage qui rame. Le Lua sur TI-Nspire n'est pas prévu pour affiche de grandes images, du moins pas en utilisant le format TI.Image.

Contentez-vous de miniatures pour vos prochaines applis Lua et évitez surtout les images plein écran que je vois parfois dans certaines applications Lua publiées sur certains sites. Ce n'est pas parce que ça marche de façon fluide sur le logiciel Nspire que ça marchera sur calculatrice, au contraire... Avec une TI.Image plein écran, le ramage sur calculatrice va même jusqu'à ralentir et saccader très péniblement le déplacement du curseur, dont chaque déplacement provoque, rappelons-le, un rafraîchissement total de l'écran.

Allez promis, la prochaine appli Lua utilisant l'accéléromètre, je vous la fais sans image et donc elle ne ramera pas!

Lien:
archives_voir.php?id=8868