luten a écrit 14 commentaires

Sur certains décodeurs avec un disque le contenu est aussi protégé au niveau ATA, il faut connaître le "master password" pour pouvoir lire le disque sur un PC par exemple (à vérifier avec hdparm).

Pour des projets à base de Cortex M3 j'utilise la ToolChain Sourcery CodeBench la libC utilisée est newlib , ils fournissent aussi une ToolChain arm-linux-*.
Par contre ils ne fournissent pas de package pour distribution, c'est un script d'installation.

La communauté STM32 est relativement développée il est plutôt facile de trouver des infos sur le net, même s'il est vrai que les STM32F4 sont récents ils restent compatibles au niveau binaire avec les STM32F2. ( les différences viennent de la fréquence max qui est plus élevée et la présence d'unités FPU et "DSP" ).

Oui à cause du wear-leveling on efface les secteurs logiques, non les secteurs physiques qui suivant les types d'algo utilisés par le controleur peuvent très bien conserver les data ( un effacement d'un secteur n'est qu'une réallocation d'un secteur vierge le plus souvant).
Comme mentionné plus haut même en ayant accès à la mémoire en bypassant le controleur et en connaissant l'algo utilisé cela ne doit pas être évidant de retrouvé ses petits.

Si les 2 PC sont branchés en direct ( sant hub ou switch ) assurez vous que le câble est bien de type croisé, la communication n'est pas possible avec un câble droit.

Avec 366 par ans il n'y a pas de problèmes , même si tu ecris au même endroit car c'est le même endroit logique, le controleur va écrire a des endroits physiques différents ( des pages différentes de la NAND).
Une NAND SLC par exemple supporte 10 000 cycles d'effacements par blocks sachant que les écriture se font par page.
Par exemple pour une NAND SLC de 4Go (avec des blocks de 128k et des pages de 2k) tu peux faire en théorie au maximum:
4G/2k*10 000 = 20E9 écritures
En pratique le nombre est bien sur inférieur car il y aussi les écritures effectuées par le FS et les écritures dues au wear leveling, mais cela donne un ordre d'idée.

Oui une compact flash est vue comme une disque physique avec ses secteurs, il faut donc utiliser un file system "normal".
UBIFS et autres utilisent par exemple les flash NAND en direct pour avoir accès aux pages et blocs de la flash ainsi qu'aux zones de contrôle ( les spares area ) ce qui n'est pas possible au travers d'un contrôleur qui émule une disque et ne permet que les accès secteurs.
La gestion de l'usure des blocks est effectuée dans le contrôleur de la CF, c'est lui qui égalise cette usure ( "wear leveling" en anglais), dans un FFS c'est la couche FTL qui s'en occupe puisqu'il n'y a pas de contrôleur physique.
Au final, si le contrôleur de ta CF est suffisamment efficace, ce qui compte c'est le nombre total d'accès pas l'endroit ( au sens adresse logique donc secteur) où tu les fait. Le souci est donc que l'on est, dans ce cas, dépendant du travail effectué par le contrôleur de la carte, si le firmware est pourrit tu risques de cramer ta carte prématurément.

Oui mais sur une carte compact flash tu ne peux pas accéder directement à la flash tu doit passer par le contrôleur, UBIFS comme les autres FFS sont conçus pour fonctionner sur des "RAW Flash"..
A voir sur le site UBIFS [1]:

Big red note

One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash. Please, make sure you understand the differences between raw flash and, say, MMC flash before dealing with UBIFS. This section should help.

1: [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_rednote]

La mini2440 c'est une carte à base de Samsung S3C2440A (ARM9). Tu peux la trouver sur ebay pour moins de 100€ avec un écran LCD tactile de 3,5'' (il y a aussi des kits avec un écran 7''). Tu peux faire tourner dessus OpenEmbedded ou Emdebian, la communauté est relativement réactive même si les drivers ne sont pas toujours tiptop ( comme celui de la module CCD en option).
Pour plus d'info:
[http://www.friendlyarm.net]

Sur ebay il y a des cartes à base de arm9 plutôt complètes, les tarifs avec frais de port commencent à 80€, il faut chercher mini2440.
Ce sont des cartes à base Samsung S3C2440A , pour ce prix là il y a en plus un écran lcd tactile. Tu peux faire tourner dessus OpenEmbedded ou Emdebian, la communauté est relativement réactive même si les drivers ne sont pas toujours tiptop ( comme celui de la module CCD en option).
Pour plus d'info: [http://www.friendlyarm.net/]

Cela dépend de tes besoins mais tu peux regarder du coté de Free Type [http://www.freetype.org/] . Ce n'est pas trop compliqué à utiliser et le rendu est irréprochable.

En général les disques internes des STB ( ou pour les graveurs de salon) sont protégés par des mots de passe au niveau ATA ( un master et un slave) ce qui empêche leur utilisation autre part. De plus les constructeurs chiffrent les fichiers enregistrés, tu as donc très peut de chance de retrouver les fichiers.

C'est plutôt l'inverse, si tu sautes en parachute l'accélération mesurée se rapproche de 0 G ( chute libre dans le vide)!
Parcontre l'accéléromètre mesure 1 G sur l'axe vertical si le téléphone est immobile.

le GPRS ne permet pas de connexion PPP comme sur un GSM car lorsque la connexion GPRS est activée le téléphone est directement sur le réseau de l'opérateur