Table de "saut" en C

[flolarajasse]

Il faudrait donc que je déclare mon tableau comme ceci?

const unsigned char valeur_tableau[256] = ...

Afin qu'il ne soit pas dans la RAM?
-----

[luc_1049]

Bonjour

Mettez le tableau en constante dans le programme, il sera dans la section en flash.
Pour allez vite vous pouvez trés bien recopier ce tableau en ram au démarrage du logiciel.
Il suffit ensuite de pointer sur cette adresse de tableau en ram.
Bien entendu comme dit si vous voulez que ce soit très rapide il faudra voir le code assembleur généré.
Si vous voulez modifier une valeur dui tableau, n'oubliez pas de la recopier dans le tableau d'origine de la mémoire morte. En l'occurence ce sera alors soit un secteur particulier de la flash programme pour des facilités de reprogrammation (ne pas toucher au secteur comportant le logiciel) ou un tableau dans l'eeprom pour faciliter d'accès.
Si c'est très contraint il va falloir regarder de près les instructions, sinon peut être qu vous vous focalisez sur un problème qui n'en est pas un. Ou alors s'il y a un goulot d'étranglement en temps réel il faut peut être revoir en amont le principe de codage.

cdlt luc_1049

[DAUDET78]

en déclarant ton tableau static, il ne sera pas rechargé en re-rentrant dans la fonction qui l'a déclaré.
Cela implique intrinsèquement que le tableau restera en RAM.

je ne connais pas les PICs ....
Mais tu sous-entendrais que le tableau en Flash serait recopié en RAM ????? C'est débile !

Faut rester les pieds sur terre ! On a un tableau de 256 octets en constante en Flash. Et on vient lire le énième octet avec un index. c'est tout !

[terriblement]

je ne connais pas les PICs ....
Mais tu sous-entendrais que le tableau en Flash serait recopié en RAM ????? C'est débile !

Tout à fait, c'est pour cela qu'il faut enlever la commande "static" pour éviter cela.

Mais encore une fois,
aller chercher la valeur dans la memoire flash, la copier en ram et l'utiliser
sera plus lent que
alle chercher la valeur dans la ram et l'utiliser.

A voir quelle vitesse d'accès est nécessaire.

[DAUDET78]

la copier en ram et l'utiliser sera plus lent que alle chercher la valeur dans la ram et l'utiliser.

Sur tous les µC, µP que j'ai programmé, on copiait le contenu indexé de la table en ROM (la Flash) dans un registre et on transférait ce registre sur le port de sortie

Et si il est si pressé que ça, il gagne un peu de temps avec une routine d'interruption écrite en assembleur

[flolarajasse]

A voir quelle vitesse d'accès est nécessaire.

Je rentre dans mon interruption, donc je change (ou pas) de valeur toutes les 13ms.

[DAUDET78]

Donc en Flash ...... pour la troisième fois !

[terriblement]

Sur tous les µC, µP que j'ai programmé, on copiait le contenu indexé de la table en ROM (la Flash) dans un registre et on transférait ce registre sur le port de sortie

Qui implique un passage obligatoire par la RAM.
Et dans son cas, on ne sait pas ce qu'il fait de sa variable une fois lue.
Je n'arrive pas à trouver le temps nécessaire à un accès à la mémoire flash, si quelqu'un a une info pour son PIC, ce serait intéréssant.

Et si il est si pressé que ça, il gagne un peu de temps avec une routine d'interruption écrite en assembleur

C'est sur.

[DAUDET78]

Qui implique un passage obligatoire par la RAM.

Non ... du tout !

je dois affecter une valeur à ma variable de sortie.

[flolarajasse]

Donc en Flash ...... pour la troisième fois !

Mais j'ai bien compris, même avant la 3ème fois. Je répondais simplement à :

A voir quelle vitesse d'accès est nécessaire.

[terriblement]

Non ... du tout !

Je lis ceci dans la doc:
"Table read operations retrieve data from program
memory and place it into TABLAT in the data RAM
space."

Peut etre que c'est spécifique aux PIC (je n'ai jamais utilisé autre chose), mais il sera obligé de faire "variable sortie = TABLAT"

[DAUDET78]

Sur un TMS9995 je faisais MOVB @Table(R1),@Output
Evidemment, c'est un µP qui date des années 1980 et il était peut être trop moderne !

[terriblement]

On arrête pas le progrès

[bobflux]

Le uC en question exécute le code depuis la flash donc il fait au minimum un accès flash par instruction, et la flash n'a pas l'air de le ralentir... c'est pas comme si c'était une eeprom i2c...

Après bon, c'est une architecture pourrie (je viens de regarder les instructions à utiliser pour lire un octet en flash, c'est ridicule), mais il n'y a pas de raison que ce soit excessivement lent... le nombre de cycles pour l'instruction est dans le manuel, probablement. C'est genre 3 ou 4 instructions... que le compilateur générera gentiment.