Saturation du 18f877a

[mr.ester]

Bonjour,

Je travaille sur un projet a base du pic 16F877A (40 pin )
Et a qui j ai confié plusieur taches
Detecteur de couleur toujours actif

Guidage de 4 Servomoteur
Detecteur infrarouge
Ultra son .......

Bref j ai utilisé tout les 40 pin

Ma question et la suivente :est ce la memoire RAM que mon microcontroleur risque de se saturé et ainci redure la fitesse d execution des tache

MERCI D AVANCE POUR TOUTE LES REPONSES

[ymasquel]

Bonjour "Mr.Ester",

Le risque ne vient pas de la mémoire qui sature, si tu as la place pour y loger toutes tes variables tout va bien... à part que sur cette gamme de micro-contrôleurs de MICROCHIP la mémoire est divisée en pages et que le compilateur (ou toi, en assembleur) place les instructions qui permettent de basculer d'une page à l'autre (y compris pour les registres SFR). Donc des cycles machine "perdus".

Le vrai risque vient plutôt du programme et de la façon dont les différentes fonctions doivent s'enchaîner (ou s'imbriquer) avec les temps et les priorités de traitement d'interruptions (si tu les utilises) par rapport à la fréquence des évènements qui doivent être pris en compte. Ceci évidemment est à moduler en fonction de la fréquence de l'oscillateur donc du cycle machine qui en découle.

Amicalement, Yves.

[gérard]

L'occupation de la RAM dépend du nombre de variables que tu as déclaré et, si tu utilises un compilateur, du nombre de variables que le compilateur utilise.
Il y a quand même 368 octet de RAM.
Comme dit par Yves, attention à la gestion des pages.

[mr.ester]

Serait il mieu de utiliser 2 pic 16f877a et de diviser les taches?

[jeanpierre]

Bonjour,
je suis toujours étonné quand je constate les impasses dans lesquels se fichent certaines personnes:
Quand on démarre un projet :
on analyse sur papier certains critères
- le nombre d'I/O logiques
- le nombre d' I analogiques (O le cas échéant)
- il faut aussi penser à réserver de broches pour le débogage (soit rx-tx soit un afficheur soit des diodes)
- bien penser les répartitions de broches pour ne pas se retrouver dans un nouvel impasse (broches spi et I2C communes par exemple)
- puis la taille du programme sachant que sans prendre un marteau pour écraser une mouche il faut être confortable en
EEPROM, en RAM et en vitesse de µP (attention plus un µP tournent vite plus il consomme d'énergie.

Je travaille avec ATMEL, je tourne avec 3µP
Attiny 45 (8 broches), atmega168(28 broches) et atmega644 (40 broches) ce dernier possède 64ko 4Kram et j'utilise beaucoup le bus I2C.
la différence de coût est minime d'un µP à l'autre à la louche de 2€, 5€ à 10€
le développement c'est d’abord de la réflexion !
Bon courage
JP

[ymasquel]

Bonjour "Mr.Ester",

Si les tâches confiées sont totalement indépendantes pourquoi pas mais l'emploi d'un micro-contrôleur est généralement dévolu à un ensemble cohérent. Le partage de tâches suppose alors communication et les temps de communication sont souvent dans une autre fourchette (plus lente) que les temps de réactions d'un micro-contrôleur.

Le 16F877A peut fonctionner avec un quartz de 20MHz soit un cycle d'instruction de 200nS ce qui permet de gérer pas mal de choses.

Fournis-nous un synoptique de ton application et l'objectif, ça aidera dans l'orientation des réponses.

Amicalement, Yves.

[ymasquel]

Bonjour "Mr.Ester",

J'oubliais, dans quel langage tu développes ? C'est aussi un critère.

Amicalement, Yves.

[obdh]

Quand je vois qu'un PIC16F877 vaut 4.74€ chez Mouser, et qu'un PIC32MX120 par exemple (32 bits, 32k de flash et 8k de ram) vaut 2.30€, le choix est très vite fait !!! Je radote, je sais....

Le 150 avec 128k de flash et 32k de ram vaut autour de 3€, donc, en amateur, ne pas hésiter à prendre le plus gros dans la famille et le boîtier qui convient, même pour écraser une mouche. Cette dernière sera amenée à grossir si les possibilités sont suffisantes.

Cela éviterait aussi de lire sans arrêt que les Microchip ne sont bons qu'a faire clignoter une led !!

[treels]

Tu ne radotes pas du tout.