[C] Conversion int vers tableau de char sur pic18f

[invitef16fb0b5]

Bonsoir à tous,

Je suis nouveau sur le forum.

Je suis en train de travailler sur un petit projet sur un PIC18F46J50 (sur un mplab starter kit http://www.microchip.com/Development...artNO=DM180021

Mon problème est simple.
J'aimerais convertir un nombre entier (int), issue d'une conversion avec le CAN en un tableau de char que je pourrais afficher ensuite sur le petit écran.

Exemple:
123 -> [1][2][3]

J'ai regardé sur internet, et j'ai vu la fonction "malloc()" pour éviter que le pointeur ne "se vide" à la fin de l’exécution de ma fonction.
Mais malheureusement malloc() ne fonctionne pas sous mon compilateur (compilateur XC8 :http://www.microchip.com/wwwAppNotes...pnote=en012157)...

Auriez-vous une solution? En sachant je suis encore un débutant en C (je précise)

Merci d'avance!
-----

[Jack]

Si ton compilateur possède la fonction itoa, ton problème est résolu (en ayant réservé un tableau à la bonne dimension)

[inviteb9f49292]

J'ai regardé sur internet, et j'ai vu la fonction "malloc()" pour éviter que le pointeur ne "se vide" à la fin de l’exécution de ma fonction.
Mais malheureusement malloc() ne fonctionne pas sous mon compilateur

Non, malloc c'est pour "Memory ALLOCation", donc tu demandes "au système" de la mémoire, et si il en a il te donne un pointeur dessus... Ce n'est pas "que" le compilateur qui ne connaît pas le malloc, c'est surtout que sur un PIC je doute qu'il y ait du "tas" ("heap"), ça fait rentrer dans les couches très basses du C. Attention dans tes recherches, programmer sur un PIC (comme très souvent sur les micro-contrôleurs) c'est très restrictif par rapport au C que tu vas utiliser sur un PC, et tu trouveras beaucoup plus d'info pour le 2ème cas, fait gaffe à faire le tris.

Auriez-vous une solution? En sachant je suis encore un débutant en C (je précise)

Pour la mémoire, je te propose d'allouer statiquement ton tableau de caractère, à toi de décider de combien de caractère max tu veux afficher, et sachant que un entier sur 32bits c'est maximum 2milliards et des brouettes.
Ensuite, en tant que débutant, 2 options: tu cherches la fonction qui fait tout le boulot pour toi (et la réponse de Jack est plus qu'un indice), soit tu veux un peu faire d'algorithmique et tu te fais ta petite fonction à la main.
Pour cette 2nde solution, je te donne un indice, tu peux faire des "calculs" avec les caractères, ainsi le caractère "9" c'est bien le caractère "0" + 9...
Je te conseillerai de faire les 2 car le boulot de développeur n'est pas de réinventer la roue, donc apprendre à chercher dans l'existant des solutions qui nous conviennent, c'est quand même une bonne partie de notre boulot. Et la 2nde méthode, c'est un petit exercice assez simple, qu'on pourra t'aider à compléter ici même.

[invitef16fb0b5]

Merci de vos réponses.

Concernant la création d'un algorithme (si la fonction itoa ne fonctionne pas sur mon compilateur, je n'est pas encore testé !), j'ai pensé à quelques chose de tout bête (sur le papier en tout cas).

On récupère le nombre de chiffres du nombre, ensuite on divise successivement par 10, puis on récupère le modulo (par 10) de ce résultat qui contient le chiffre.
Reste ensuite à stoquer dans le tableau static.

[A voir en vidéo sur Futura]

[Jack]

si la fonction itoa ne fonctionne pas sur mon compilateur, je n'est pas encore testé !

En principe, c'est écrit dans la doc du compilateur

On récupère le nombre de chiffres du nombre

Et comment comptes-tu connaitre le nombre de chiffre du nombre? C'est possible en comparant successivement à 10, 100, 1000 etc. mais franchement, ça n'est pas la bonne solution.

[inviteb9f49292]

Et comment comptes-tu connaitre le nombre de chiffre du nombre? C'est possible en comparant successivement à 10, 100, 1000 etc. mais franchement, ça n'est pas la bonne solution.

Je te trouves dur Jack!
Si la solution simple fait le job, vas-y. Tu seras toujours à même d'améliorer plus tard...

[Jack]

Non, je ne suis pas dur. C'est un vrai problème: comment déterminer simplement le nombre de caractères nécessaires pour écrire "123" à partir de la valeur 123?

[invite2d7144a7]

Bonjour,

comment comptes-tu connaitre le nombre de chiffre du nombre? C'est possible en comparant successivement à 10, 100, 1000 etc. mais franchement, ça n'est pas la bonne solution.

Alors quelle est TA bonne solution ?

[Jack]

J'utiliserais une boucle de divisions entières et modulos par la valeur de la base attendue à l'affichage jusqu'à ce que le reste soit inférieur à la valeur de la base.

[bisou10]

C'est XC8 le compilateur ??? Moi je ferais un bête:

int entier = 12345;

char buffer[6];

sprintf(buffer,"%d",entier);

[Jack]

oui, j'y avais pensé, mais il me semble que sprintf consomme beaucoup de mémoire et sur ce genre de petits µC, il faut faire gaffe.

[invite2d7144a7]

Bonjour,

oui, j'y avais pensé, mais il me semble que sprintf consomme beaucoup de mémoire et sur ce genre de petits µC, il faut faire gaffe.

Ça fait effectivement partie des points qu'il faut surveiller.

[bisou10]

Je code sur des PICs similaires, et j'ai des applications en production avec 8 langues: la routine de traduction fait une utilisation systématique du sprintf. C'est vraiment indolore, compte tenu des 64K. Quand bien même, c'est le haut de gamme des gammes 8bits, donc la disponibilité de cette routine n'est pas uniquement pour faire joli: sur un 12F ou 16F on peut se poser la question (1 à 4K de RAM). Pour info, le 18F va chercher dans les 16MIPS à plein régime (de mémoire).

Ce n'est pas tout à fait délirant cependant, car ces MCUs ont des aspects dédiés. Celui là intègre l'USB, et sans connaitre, j'imagine qu'il faut gérer un buffer de réception / un buffer d'émission), ce qui mis bout à bout... Mais pour moi c'est tiré par les cheveux. Autant passer par une routine de formatage dédiée et performante qu'un bidouillage avec des modulos, des divisions en base 10 et des ajouts de 0x30 pour passer en ASCII

[bisou10]

(ce modèle possède moins de 4K RAM (64K programme) mais doit avoir ses buffers RX/TX réservés pour l'USB, petite coquille )

[invite2800a7c8]

Bonsoir à tous,

Je suis nouveau sur le forum.

Je suis en train de travailler sur un petit projet sur un PIC18F46J50 (sur un mplab starter kit http://www.microchip.com/Development...artNO=DM180021

Mon problème est simple.
J'aimerais convertir un nombre entier (int), issue d'une conversion avec le CAN en un tableau de char que je pourrais afficher ensuite sur le petit écran.

Exemple:
123 -> [1][2][3]

J'ai regardé sur internet, et j'ai vu la fonction "malloc()" pour éviter que le pointeur ne "se vide" à la fin de l’exécution de ma fonction.
Mais malheureusement malloc() ne fonctionne pas sous mon compilateur (compilateur XC8 :http://www.microchip.com/wwwAppNotes...pnote=en012157)...

Auriez-vous une solution? En sachant je suis encore un débutant en C (je précise)

Merci d'avance!

Salut,
A titre d'information regarde ici
http://www.flashforth.com/

Il y a tout ce qu'il faut et c'est très simple.

Cordialement

Ludwig

[JPL]

Salut,
A titre d'information regarde ici
http://www.flashforth.com/

Tu vas le publier dans toutes les discussions ce message ? Cela finit par être monomaniaque.

[invite2800a7c8]

Tu vas le publier dans toutes les discussions ce message ? Cela finit par être monomaniaque.

Salut,

je peux te mettre ça:
http://www.forth-ev.de/

Mais je ne sais pas si t'arriveras à lire

Ici il y a même un journal
http://www.forth-ev.de/filemgmt/viewcat.php?cid=2


Je ne comprends pas pour quelle raison il est pratiquement interdit ici de montrer ou dire qu'il
existe différentes méthodes de développement, pas seulement la pensée unique
" Edition compilation debug "

Cordialement

Ludwig

[inviteb9f49292]

Je ne comprends pas pour quelle raison il est pratiquement interdit ici de montrer ou dire qu'il
existe différentes méthodes de développement, pas seulement la pensée unique

répondre "forth" à une question en C sur du PIC est tout sauf productif pour la personne qui posait initiallement la question

[invite2800a7c8]

répondre "forth" à une question en C sur du PIC est tout sauf productif pour la personne qui posait initiallement la question

Salut,

Le fait est que:
Quand j'essaye de vous parler de développement interactif sous C,
c'est viré ailleurs par la modération,
ICI:
http://www.mpeforth.com/sockpuppet/index.htm

Et c'est directement en relation avec les processeurs PIC

Je ne sais pas si tu connais les techniques de développements interactives,
bien des gens de la "Silicon Valley" utilisent cette technique.
On installe un Interpréteur Forth sur la cible, ce qui va permettre la mise au point en mode interactif des procédures
écrites en C puis une fois que tout fonctionne, on retire l'interpréteur et on compile l'application sous C.
C'est bien plus rapide que le long cycle " Edition Compilation Debug "
sockpuppet est une variante de cette technique.

Cordialement

Ludwig

[JPL]

Je ne comprends pas pour quelle raison il est pratiquement interdit ici de montrer ou dire qu'il
existe différentes méthodes de développement, pas seulement la pensée unique

Mais pour la pensée unique c'est toi le champion : quelle que soit la question la réponse est forth !

Et pour le message que j'ai relevé, tu l'avais posté deux fois avant.

[invite2800a7c8]

Mais pour la pensée unique c'est toi le champion : quelle que soit la question la réponse est forth !

Et pour le message que j'ai relevé, tu l'avais posté deux fois avant.

Salut,
Pas Vraiment la pensée unique,
avant de faire du développement en mode interactif avec une machine virtuelle,
j'ai pissé des Km de code en langage machine, Basic, Pascal Un peu de fortran, également du C, etc... et ce jusqu'au
jour ou j'ai été confronté à des PB d'IA (Commande d'un robot pour l'industrie automobile). C'est la que j'ai découvert Lisp et autre ainsi que le développement en mode interactif à l'aide d'une machine virtuelle.
Depuis, je refuse de faire du développement avec les méthodes classiques.
Julian Noble qui enseignait la physique nucléaire à l'université de Virginie, disait que le développement
en mode interactif était probablement le secret informatique le mieux gardé.
Ceci étant dit, personne n'est obligé d'utiliser ces techniques.
Mais personne n'a le droit d'interdire à quelqu'un d'autre d'en parler.
Le développement en mode interactif peut entre autre aussi se faire sous C pour ceux qui aiment la syntaxe C.
Cordialement

Ludwig


PS
Informe toi donc avec quoi Mathématica à été développé
Ou AutoCAD et autre.

[pm42]

Le problème est que comme d'habitude, tout ce discours sur les langages ne parle que de choses ayant 20 ou 30 ans d'age, au moins...

Il y a aujourd'hui de nombreux environnements et langages qui permettent de développer de différentes façons, y compris en interactif et qui sont largement plus efficaces que le Forth (sans doute l'un des pires langages de ce point de vue) et que Lisp qui ne s'est jamais imposé.

Bref, continuer à nous raconter l'informatique sans jamais avoir entendu parler de Python, Ruby, Scala, Javascript et ses variantes plus évoluées (Typescript, etc), le monde .NET, Haskell et j'en oublie traduit juste l'impossibilité à apprendre et à rester à jour.

Cela explique sans doute la pollution systématique de tous les fils par "Forth, Forth, Forth"...

Je pense que le 1 dans Ludwig1 est la profondeur de sa pile : avec juste 1 entrée, il ne peut pas faire autre chose que de répéter la même chose.

[invite2800a7c8]

:

Le problème est que comme d'habitude, tout ce discours sur les langages ne parle que de choses ayant 20 ou 30 ans d'age, au moins...

Il y a aujourd'hui de nombreux environnements et langages qui permettent de développer de différentes façons, y compris en interactif et qui sont largement plus efficaces que le Forth (sans doute l'un des pires langages de ce point de vue) et que Lisp qui ne s'est jamais imposé.

Salut,

En premier lieu c'est pas un langage, c'est un système, c.a.d. une machine informatique virtuelle,
ce qui n'est vraiment pas la même chose.

Bref, continuer à nous raconter l'informatique sans jamais avoir entendu parler de Python, Ruby, Scala, Javascript et ses variantes plus évoluées (Typescript, etc), le monde .NET, Haskell et j'en oublie traduit juste l'impossibilité à apprendre et à rester à jour.

Je ne sais pas ce que signifie pour toi rester à jour. Mais j'ai, selon tes propos, j'ai le sentiments que ça veut dire suivre la mode.
Pour ce qui me concerne, le critère d'évaluation fondamental est le temps de développement.
Le reste est secondaire et sans fondement, car économiquement non défendable.

Pour ce qui est de javas puis les variantes qui suivent, je ne suis pas sur non plus que tu connaisses la genèse.
Le cas échéant, tu pourras toujours poser la question.

Cela explique sans doute la pollution systématique de tous les fils par "Forth, Forth, Forth"...
Je pense que le 1 dans Ludwig1 est la profondeur de sa pile : avec juste 1 entrée, il ne peut pas faire autre chose que de répéter la même chose.

Pour quelle raison te montres-tu si agressif?
Mais tu dis juste, l'entrée c'est le sommet de pile, et comme par hasard il n'y a qu'un sommet, c'est pas une pile à n sommets

Ceci étant je revient dans le sujet et répète ma remarque, on peut faire du développement interactif sous C pour les processeurs PIC,
Voir les liens précédents.

Cordialement

Ludwig

[invitef16fb0b5]

Merci tout le monde pour toutes vos réponses, je vais regarder ça

J'ai réussi avec la méthode "facile" (itoa) mais je vais essayer de creuser ça

Merci encore !

[inviteb9f49292]

Pour quelle raison te montres-tu si agressif?

Parce que tu squattes une discussion avec ton obsession et qui n'a rien à voir avec la question de base. Et ce que tu racontes est au mieux confus... au pire n'importe quoi, mais les gens qui viennent poser des questions ici n'ont pas forcément assez de recule pour faire le trie entre les réponses qui essaient d'apporter des éléments, et tes délires. Du coup à toi tout seul tu fait baisser la qualité des discussions où tu interviens en noyant les réponses intéressantes sous le flot de ta monomanie sur le forth...