Salut les gens,
à chaque fois je recois une trame par le port série, je dois la placer dans un tableau. Mais le problème est que je ne sais pas comment on réalise ou plus simplement comment on défini un tableau en assembleur.
Quelqu'un pourrai m'expliquer comment on fait celà
Merci d'avance à tous
Ciao a+
salut,
cela dépend du microprocesseur, mais les adressages de type indirect et indexé sont généralement très adaptés à ce type de données.
Pour décrire un tableau en langage assembleur, là aussi, cela dépend de ton assembleur. Il existe en tout cas systématiquement des pseudo instructions du type RMB (reserve memory bytes) ou DS (define storage) qui te permettent de définir l'adresse et la taille du tableau et éventuellement de l'initialiser.
A+
Ok merci Jack de ta réponse!
A+
Bonjour Alex22,
si tu utilises un PC, tu peux te passer de l'apprentissage ardu de l'assembleur au profit du Visual basic ou du C. Ces langages traitent eux même de ces "détails" et gèrent très bien les événements du port série vu les vitesses actuelles bien plus grandes que celle du 8088 ou de ses trainards de successeurs.
Faire un tableau en VB est bien plus convivial et facile à mettre en oeuvre. Je ne sais pas si sur le net trainent des programmes de ce type, mais j'ai dans mes fouffes des ébauches et aussi des produits finis de ce genre. Je peux te dire que la gestion en assembleur de l'attente des infos, du controle des états des indicateurs du port série n'est pas piquée des hannetons... je l'ai pratiqué du temps du 8088 à 4,77 MHz : fallait pas être fénéant !
C'est pas mon genre, mais avec VB j'aurais bien été jusqu'à embrasser Bilou...
Si je pouvais joindre des fichiers zip ton problème serait résolu...
sinon tu peux voir du côté de:
http://www.vbfrance.com/
et plus spécifiquement sur:
http://www.asmfr.com/
essaye aussi http://www.vbfrance.com/code.aspx?id=3597
c'est le source d'un programme qui gère le port série du PC, il y a l'executable mais vu sa taille tu devras aussi charger les dépendances de VB6 qu'on trouve sur le net.
Salut curieuxdenature,
merci pour ton aide, mais je suis obligé de coder en assembleur. car je programme sur le pc mais après mon programme sera placé sur une carte ou j'ai un processeur H8S2144. Je sais qu'avec ce processeur je peux aussi programmer en C, enfin mélanger les 2 codes. mais je suis pas très bon en prog et le C c'est encore pire...lol. Cependant je garde quand meme tes lien qui sont pas mal du tout. Pour le port série ca va encore car l'année passé j'ai du traiter une trame par le port série venant d'une CMUcam. Alors pour traiter l'information ca devrait encore aller. C'étais juste que je ne voyais pas comment on faisait pour initialiser un tableau en assembleur.
Merci
A+
Bonjour Alex22,
il y a aussi d'autres section sur VBFrance, tu l'as vu.
La solution de ton problème ne dépend que du jeu d'instructions du h8s2144 que je ne connais pas du tout, mais la démarche est toujours la même, il faut choisir l'adresse de destination que tu réserves en mémoire vive, incrémenter le pointeur de cette adresse avec le compteur d'octets reçus, ecrire les valeurs à cette adresse indexée.
L'assembleur est un exercice extraordinaire, de nos jours, plus de 20 ans après les débuts de l'informatique, je rigole dans mes moustaches quand j'entends un p'tit jeune se proclamer informaticien parce qu'il sait se servir du C... A l'époque, il fallait optimiser au max le peu de mémoire vive disponible, c'était vraiment de la gymnastique sans filet.
Ceux qui connaissent le ZX80/81, l'Oric, l'Amstrad, le C64, l'Atari, l'Amiga, l'Apple etc.. savent de quoi je parle, avec 64 K de mémoire (ou de 128 avec le QL Sinclair ou l'Amstrad 128) qu'on optimisait grâce à la connaissance des points d'entrées dans la Rom, avec 3 ou 4 octets on économisait des Ko de routines toutes faites. C'était le bon temps... souvenirs nostalgiques.
A l'époque on pouvait dire qu'on maîtrisait le hardware et l'OS (enfin un erzats d'OS, sauf pour l'amiga et les MAC). Maintenant, il reste les systèmes embarqués et là rien ne change: rapidité = tables (LUT) et adressages comme Jack l'a écrit.L'assembleur est un exercice extraordinaire, de nos jours, plus de 20 ans après les débuts de l'informatique, je rigole dans mes moustaches quand j'entends un p'tit jeune se proclamer informaticien parce qu'il sait se servir du C... A l'époque, il fallait optimiser au max le peu de mémoire vive disponible, c'était vraiment de la gymnastique sans filet.
Ceux qui connaissent le ZX80/81, l'Oric, l'Amstrad, le C64, l'Atari, l'Amiga, l'Apple etc.. savent de quoi je parle, avec 64 K de mémoire (ou de 128 avec le QL Sinclair ou l'Amstrad 128) qu'on optimisait grâce à la connaissance des points d'entrées dans la Rom, avec 3 ou 4 octets on économisait des Ko de routines toutes faites. C'était le bon temps... souvenirs nostalgiques.
A+
Ne soldez pas grand mère, elle brosse encore.
C'est vrai, avec le PC, on avait des adresses théoriquement réservées à chaque usage, chaque interruption avait ses fonctions, mais avec la venue du pentium, ça s'est sérieusement corsé et plus personne ne se sert des adresses de la rom pour programmer.
Le bios IBM et ses règles étaient bien respectées jusqu'au 386, ensuite, la grosse galère... chacun a fait sa petite soupe dans son coin et même si les fournisseurs de bios sont en nombre limité, pour avoir les listings et savoir s'en servir, bonjour, le jeu n'en vaut plus la chandelle, ça change tous les 2 mois... pour le PC, j'ai laissé tomber l'assembleur il y a belle lurette, les programmes tout fait comme le Visual Basic ou le C pour sa plus grande efficacité et son portage sont prisés par les programmeurs.
Investir de son temps dans l'apprentissage des micro-codes d'un processeur en particulier c'est prendre le risque de le voir disparaitre à brève échéance, faut voir si c'est rentable...
Pour Alex je n'ai pas trouvé de lien sur ce proc. qui soit valable, sauf celui ci:
http://www.eurodis.it/pagine/semicon...d/h8s2148h.pdf
65 codes qui ressemblent fort au 8086 et seulement 6 pour les transferts de data, mama mia, c'est un regal de simplicité...
A priori, il y a 3 ports série, 4 ports USB, mais si tu programmes la bête sur un PC, c'est forcément avec un émulateur qui assure le transfert vers le programme final, je ne veux pas te décourager mais tu vas avoir du pain sur la planche pour maitriser l'ensemble.
Je pense que tu agis dans le cadre d'un groupe qui connait bien ce joujou, fais-toi un copain sympa, ce sera plus simple.
Bon courage.
Salut curieuxdenature,
j'imagine bien que le C et autre programme du genre sont bien plus facile à maitriser, mais par rapport à ce que j'ai fais au cours j'ai toujours eu énormément de peine. C'est vrai qu'avec l'assembleur tu peux vite avoir des problèmes pour réaliser des choses subtile, mais j'aime bien codé de cette façon car tu vois vraiment chaque étape de ton programme. tu peux vraiment y aller pas à pas.
Enfin après tout dépend des gouts
Mais il y a aucun risque que je me proclame informaticien un jour...mdr....j'aimerai bien mais la programmation n'est pas ce que je préfére. Mais bon si je veux avoir mon diplome de technicien va falloir me donner.
Merci pour ton lien, c'est sympa, mais j'avais déjà le data sheet de ce micro. J'ai déjà programmé avec ce dernier l'année passé donc je commence à le connaitre plus au moin bien. C'est impressionant le nombre de chose que tu peux faire avec ces ptites betes.
Allé a+ et merci encore
Bonjour,
si la connaissance de l'assembleur pour créer des programmes sur un PC est inutile depuis bien longtemps, je pense qu'il est indispensable d'avoir encore de bonnes notions d'assembleur lorsqu'on programme en C sur microcontrôleur.
On sait que l'inconvénient de ce genre de langage est l'optimisation du code généré dans les cas critiques de vitesse et de taille mémoire.
Cependant, les compilateurs sont paramétrables et surtout, il existe souvent plusieurs manières d'écrire un bout de programme. Sans cette connaissance du code généré, difficile d'optimiser.
En résumé, le passage par l'assembleur est une étape obligée. Enfin, c'est mon avis.
A+
