piklab => qui a essayé ?

[Toufinet]

Bonsoir,

Je n'utilise windows plus que pour Altium Designer et MPLAB ..
Je viens de trouver piklab, a priori le MPLAB de linux
Es-ce que quelqu'un aurait déjà essayé ?

L'ICD2 marche-t'il aussi bien qu'avec MPLAB ?

Merci.
-----

[invite87be5ae9]

Bonsoir Toufinet

Bienvenue au club ! Je n'utilise Windows plus que pour MPlab, et encore, en virtualisé sous VirtualBox !
J'utilise un peu Piklab et pour l'avoir testé, j'avoue qu'il est excellent !
L'intégration des différents compilateurs est très bien réalisée !
SDCC installé et prêt sous Piklab en quelques minutes, c'est un vrai bonheur !

De plus, l'environnement se veut plus innovant que MPlab, car il ne s'agit pas d'un clône ou d'une simple imitation.
Je citerais, par exemple, les différentes informations sur les pics disponibles directement sous Piklab, en quelques clics, comme le brochage, les registres, les graphiques de tension... Là où sous MPlab la bataille avec les datasheets est inévitable !

Piklab permet normalement d'utiliser des compilateurs commerciaux natifs à Windows en utilisant Wine, mais je n'ai pas encore testé ces compilateurs !

Le logiciel propose aussi des outils sympathiques comme un générateur de configuration (cependant, dans mon cas il n'a pas bien fonctionné) ou un générateur de boucles de temporisation.

Enfin, il peut s'interfacer avec un nombre important de programmateurs !

A tester et à supporter selon mon avis !


PS : Petite question : quelle distribution utilises-tu ?

[katmai]

Salut,

Sinon MPLAB émulé avec wine ça fonctionne pour la compilation mais par contre ça ne marche pas avec l'icd2.

A+

[Toufinet]

Je vais voir ces jours-ci si l'ICD2 fonctionne vraiment bien sous piklab , car le but est d'avoir un truc fonctionnel de A à Z ( de la compilation à la programmation du PIC ), sinon ça ne sert à rien.

[A voir en vidéo sur Futura]

[invite87be5ae9]

Je vais voir ces jours-ci si l'ICD2 fonctionne vraiment bien sous piklab , car le but est d'avoir un truc fonctionnel de A à Z ( de la compilation à la programmation du PIC ), sinon ça ne sert à rien.

Je serais intéressé de savoir comment l'ICD2 fonctionne sous cet environnement, en tant que programmateur au moins. Je suis en train de me faire, à temps perdu, un ICD2-clone sur port série et ça me permettrait de pas lancer ma machine virtuelle pour programmer !

Quand tu dis "de A à Z" en parlant d'ICD2, veux-tu aussi évoquer le déboguage ?
Parce que si c'est le cas, il me semble que Piklab utilise gpsim pour le déboguage et la liste des Pics supportés n'est pas très longue :
http://www.dattalo.com/gnupic/gpsim.html#processors

Et aussi, avec quel(s) langage(s) et compilateur(s) souhaites-tu programmer ?
J'ai testé la suite gputils et SDCC et ça marche plutôt bien !

A+

[Toufinet]

Je programme principalement en asm, mais il va bien falloir que je passe en C un jour ou l'autre, car plus ça va et plus mes programmes se compliquent ... bref

Mis à part ça, je ne sais pas si piklab possède cette fonctionnalité, mais un truc que j'aimerais VRAIMENT avoir, c'est des informations sur la consommation du PIC en lui-même ( sans prendre en compte les I/O donc ). Je comprend pas pourquoi ce n'est toujours pas en place dans mplab ça ...

En tout cas, si ça n'y est pas non plus dans piklab, je vais très certainement faire un petit prog qui indique la consommation en temps réel, et la conso moyenne, car pour mes applications, ça m'est indispensable.

[Toufinet]

Bon, premiers tests, premiers problèmes

Je compile un petit programme avec gpasm, et une fenêtre s'affiche :
"Il y a eu des erreurs lors de la détection des circuits pris en charge par la chaîne d'outils sélectionnée ( GPUtils ). Veuillez vérifier la configuration de la chaîne d'outils. Continer malgré tout ?"

Alors je répond "oui", le message apparaît plusieurs fois, mais le fichier hexadécimal est quand même généré.

Même problème avec tous les compilateurs C

Quelqu'un sait comment résoudre ce problème ?

[invite87be5ae9]

Je programme principalement en asm, mais il va bien falloir que je passe en C un jour ou l'autre, car plus ça va et plus mes programmes se compliquent ... bref

J'ai également connu ça... On se donne des règles de programmation qui tiennent la route au début et pour un petit programme, mais quand ça se complique, j'ai remarqué qu'en asm plus qu'en C, ça devient vite une jungle !
Et pour travailler à plusieurs aussi je trouve plus pratique... Mais bon, c'est mon expérience perso...

Mis à part ça, je ne sais pas si piklab possède cette fonctionnalité, mais un truc que j'aimerais VRAIMENT avoir, c'est des informations sur la consommation du PIC en lui-même ( sans prendre en compte les I/O donc ). Je comprend pas pourquoi ce n'est toujours pas en place dans mplab ça ...

En tout cas, si ça n'y est pas non plus dans piklab, je vais très certainement faire un petit prog qui indique la consommation en temps réel, et la conso moyenne, car pour mes applications, ça m'est indispensable.

Tu parles de consommation en énergie ? Ou en consommation en ressources ?
Si c'est le dernier cas, je peux t'économiser un précieux temps si je te dis que MPLab, comme la suite Gputils, ainsi que tous les compilateurs C que j'ai utilisé ont cette fonctionnalité !!!
Soit tu programmes en code absolu, dans quel cas le linker ne décide pas où placer les variables et n'a donc aucune visibilité sur l'utilisation des ressources (mémoire RAM et programme).
Soit tu programmes en code relogeable et dans ce cas, le linker répartit les variables dans les espaces indiqués dans le fichier .lkr et connait donc précisément le pourcentage d'utilisation des différentes zones de mémoire.
(c'est vite indiqué mais je fais peut-être un hors-sujet, donc j'abrège...)

Bon, premiers tests, premiers problèmes

Je compile un petit programme avec gpasm, et une fenêtre s'affiche :
"Il y a eu des erreurs lors de la détection des circuits pris en charge par la chaîne d'outils sélectionnée ( GPUtils ). Veuillez vérifier la configuration de la chaîne d'outils. Continer malgré tout ?"

Alors je répond "oui", le message apparaît plusieurs fois, mais le fichier hexadécimal est quand même généré.

Même problème avec tous les compilateurs C

Quelqu'un sait comment résoudre ce problème ?

As-tu bien sélectionné le bon PIC dans ton projet ? (j'imagine que oui, mais sait-on jamais...)
Quelle version de SDCC ou de GPUTILs utilises-tu ? compilé/package ?
Quelle est ta distribution ? (question précédemment posée)

A+

[Toufinet]

Non , je parlais de la consommation en courant

Oui, j'ai (malheureusement) bien sélectionné le bon pic dans le projet.
- Version de SDCC :

vincent@debbie:~$ sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.0 #4309 (Oct 15 2006) (UNIX)

- Version de GPUtils :

vincent@debbie:~$ gpasm -v
gpasm-0.13.4 beta

- Distro :

vincent@debbie:~$ cat /etc/debian_version
4.0
vincent@debbie:~$ uname -r
2.6.18-5-486

Tu m'as fait pensé que j'ai installé les versions package de SDCC et GPUtils ... donc pas forcément les dernières. Je vais voir si j'en trouve des plus récentes, et les installer.

[Toufinet]

Problèmes réglés, ça venait en effet des versions de sdcc et gpasm.
La compilation fonctionne maintenant.

Par contre, j'ai pas trouvé d'outils incorporé à piklab pour visualiser la consommation. Je vais farfouiller google pour voir si quelqu'un a déjà fait ça, et si c'est pas déjà fait, je me lance dedans.

Lobomatic, tu aurais un bon site expliquant la programmation en C pour SDCC ? Je connait parfaitement le C, mais je sais que le C pour pic présente des différences ( et ce sont ces différences qui m'ont fait abandonner à chaque fois ... ). Merci

[invite87be5ae9]

Non , je parlais de la consommation en courant

Au temps pour moi, j'étais donc en hors-sujet total

Problèmes réglés, ça venait en effet des versions de sdcc et gpasm.
La compilation fonctionne maintenant.

J'oubliais de préciser que je n'utilise plus de package concernant SDCC car, quelque soit la distribution, il est impossible de suivre les versions quasi-quotidiennes !
De plus, dans le cas de ma Fedora, comme ta Debian apparemment, ils se sont arrêtés à la branche 2.6.x alors que la 2.7.x apporte des améliorations significatives concernant les PICs.

Lobomatic, tu aurais un bon site expliquant la programmation en C pour SDCC ? Je connait parfaitement le C, mais je sais que le C pour pic présente des différences ( et ce sont ces différences qui m'ont fait abandonner à chaque fois ... ). Merci

Ce dont souffre principalement SDCC par rapport à ses concurrents commerciaux est un manque cruel de librairies (I2C, LCD, USB, ...).
Par contre les librairies principales sont présentes et sont relativement bien optimisées (stdio.h, math.h, delay.h, ...).

Le premier conseil qui m'a été donné pour SDCC est de s'inscrire sur la liste de diffusion. Cela permet de suivre les nouveautés et d'avoir de précieux conseils.
https://sourceforge.net/mailarchive/...name=sdcc-user
Pour voir ce que ça donne
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Pour s'inscrire

Ensuite vient naturellement le manuel, en ligne (plus pratique à parcourir) ou en PDF.
http://sdcc.sourceforge.net/doc/sdccman.html/

Le forum sur sourceforge peut aider aussi :
https://sourceforge.net/forum/?group_id=599


Pour finir, quelques tutoriels francophones :
http://jmandon.free.fr/sdcc/sdcc.htm
Vieille version de SDCC, sous Windows qui plus est. Mais un bon aperçu avec des liens intéressants en bas
Le même auteur propose un cours de prise en main en PDF :
http://jmandon.free.fr/download/devsdcc.pdf

http://sjeffroy.free.fr/new/index.ph...d=29&Itemid=63
En un peu plus détaillé, mais cela reste assez court.

Personnellement, je n'utilise pas encore SDCC en production, mais je suis de très près ce compilateur qui progresse très vite.

Bonne continuation.

[Toufinet]

Merci pour tous ces liens

J'ai eu le temps d'essayer sdcc sur un programme simple ( affichage de l'heure sur des 7 segments ). J'ai perdu à peu près .... 10 heures ? , à chercher comment accéder à un bit Y d'un port X sans passer par les masques, et il semblerait que ça ne soit pas encore developpé !!

Je suis donc "très vite" repassé sous windows avec CC5X, où j'ai pu "torcher" mon programme en 1h ..

C'est vraiment dommage, car l'environnment piklab possède des fonctionnalités que mplab ne propose pas, et qui sont fortes agréables !

Dommage ... comme toi Lobomatic, je vais attendre patiemment


PS : en compilant à partir des sources, tu peux avoir sdcc 2.7 ...

[invite87be5ae9]

Merci pour tous ces liens

J'ai eu le temps d'essayer sdcc sur un programme simple ( affichage de l'heure sur des 7 segments ). J'ai perdu à peu près .... 10 heures ? , à chercher comment accéder à un bit Y d'un port X sans passer par les masques, et il semblerait que ça ne soit pas encore developpé !!

Arf ! pourtant SDCC gère les champs de bits (bit fields) comme C18 pour accéder à un bit donné d'un port ou d'un registre d'ailleurs.
Si on prend le fichier pic16f88.h (à inclure dans le projet)

// ----- PORTA bits --------------------
typedef union {
struct {
unsigned char RA0:1;
unsigned char RA1:1;
unsigned char RA2:1;
unsigned char RA3:1;
unsigned char RA4:1;
unsigned char RA5:1;
unsigned char :1;
unsigned char :1;
};
} __PORTA_bits_t;

Cela marche de même pour tous les autres registres, et pour activer la ligne RA5 du port A, il faut saisir :

PORTAbits.RA5 = 1 ;

Il ne faut surtout pas hésiter à ouvrir les librairies et fichiers d'en-têtes qui accompagnent ce compilateur ! Ils contiennent souvent des informations qui ne sont pas présentes ou mises à jour ailleurs.

Dommage ... comme toi Lobomatic, je vais attendre patiemment

PS : en compilant à partir des sources, tu peux avoir sdcc 2.7 ...

Merci pour l'information, mais comme j'expliquais plus haut, je n'utilises plus de package et je compile directement à partir des fichiers sources directement ! (Surtout que le package sdcc pour Fedora est inutilisable!)

J'hésite d'ailleurs à récupérer directement les sources depuis le dépôt SVN et à compiler dès que je verrais une modif concernant les PICs. Et soumettre mes propres modifications ou librairies !
Cela me permettrait de participer activement au projet

En tout cas, si un problème de ce genre se pose à nouveau, n'hésites surtout pas à poster sur ce forum ou sur celui de SDCC afin d'avoir de l'aide !

SDCC est un produit open source, et comme le veut cette philosophie particulière, un utilisateur n'est pas un consommateur mais un participant ! Même en utilisant le logiciel et en étant confronté à un problème, il est possible de participer en donnant ses impressions, en signalant une erreur !
Pas besoin d'être développeur, chacun à son importance

Mais tu as raison : il faut de la patience... Mais pas forcément d'attente !

A+

[invitebc46d461]

Bonjour

Qui a essaye l icd2 sous piklab?
Il me reclame un micrologiciel ,c'est quoi donc ?



Moi je maitrise avec le Kit Vellman K4808 si ca interesse..
mais maintenant je voudrais passer a l'icd2 et sous linux ..
en liaison serie et peut etre en USB cerise sur le gato

Merci de votre aide precieuse.

Brad

[invite855cd7fb]

Je déterre ce topic car je cherche quelqu'un (ou quelques deux ou plus) ayant réussi a le faire marcher sur mac.
il veux pas compiler chez moi

pour l'histoire du problème de micrologiciel, je pense avoir la réponse : il faut mettre a jour le firmware de ton flasheur car pk2cmd n'aime pas les firmwares trop vieux.
Je pense qu'elle servira jamais a Brad vu l'ancienneté de son message, mais qui sait, peu être a d'autres ?