rick

Ma question s'adresse uniquement aux amateurs (comme moi), qui pratiquent l'électronique dans le cadre de leurs loisirs.

Seriez-vous prêt à acquérir une licence du compilateur PICC de HI-TECH version complète s'il était vendu à un prix plus accessible et, si oui, quel serait le prix maximum qui vous paraîtrait raisonnable ?

Son prix standard est de presque $1000. Certes, c'est effectivement un produit de qualité professionnelle (très performant aussi bien en vitesse de compilation que sur l'optimisation du code produit - cela fait presque 4 mois que je le teste en version light et 1 mois en version complète : durée limitée à 2 mois) mais un tel prix n'est évidement pas justifiable pour une utilisation de loisir. Ayant testé brièvement 2 autres produits, je me dis pourtant que cela s'avère fort dommage ...

J'ai donc essayé de négocier un prix pour particulier mais la société m'a répondu que son produit se destine effectivement au monde de l'entreprise. Cela dit, elle semblerait toutefois disposée à faire "des efforts ponctuels" dans le cadre d'un retour de bénéfice à son avantage, à savoir par exemple sous forme de pub ...

"Thank you for your email.

You are right in saying our compilers are aimed at commercial and enterprise
customers rather than the hobbyist.

We have the free version of PICC LITE on our website for the hobbyist if you
require more features then you would look at the full commercial versions.

However at times we do look at giving a reduced price to individuals if we
can see a benefit to our company by way of publicity or awareness in the
market if you have such a case please let me know and I will see what we can
do.
"

Je me dis donc que s'il existait effectivement une réelle demande pour son produit, cela serait plus facile de lui démontrer que, mieux vaudrait pour elle perdre en peu sur la vente aux particuliers (en terme de prix unitaire) que de ne pas leur vendre du tout, sachant en outre que bon nombre de jeunes passionnés (par définition : peu fortunés) sont de potentiels futurs professionnels du domaine (voir décideurs sur le choix des outils ) ...

Cela dit, il est vrai que ce type de produits n'est pas forcément de diffusion "grand public" et je n'ai évidemment aucune idée du marché potentiel ... D'où ma question ...

Merci pour votre aide et vos avis ...

Salut,
je me présente donc :
Rick,
de formation initiale en électronique, je travaille depuis quelques années dans l'informatique ... (et oui, on ne peut pas tout réussir dans la vie ...)
ayant récemment décidé de me remettre 1 peu à l'électronique, j'ai acheté le bouquin "123 pic microcontroller" de Myke PREDKO (très bon à mon avis pour débuter ...) et me suis donc formé à la programmation des MCUs PIC.
... et là, pour mettre tout ça en application, je me lance dans la réalisation de mon premier projet à base de MCU (PIC16F684 notamment), à savoir un proto de plateforme robot d'exploration pouvant évoluer par la suite vers : tondeuse automatique, aspirateur auto, etc ...
J'ai imaginé un ensemble de MCU connectées entre elles et chacune chargée d'une tache spécifique. Pour l'instant, j'ai réalisé le soft du module de gestion des moteurs (servomoteurs, asservissement par roues codées et partie communication) ainsi que celui du module central de gestion des échanges entre les différents modules (là, j'attends encore quelques composants pour commencer les premiers montages de tests ...).
Ayant quelques doutes sur la partie gestion des communications, je souhaiterais donc, avant de poursuivre l'étude, l'avis d'amateurs éclairés sur les choix techniques que j'ai retenu.
Pour l'instant, il s'agit donc d'un module MCU central qui gère les communications pour tous les autres (5 ou 6 max). Il dispose pour cela d'une sortie dédiée à la génération d'un signal d'horloge de période 200us et qui synchronise les échanges avec les autres modules connectés. Les échanges sont constitués de messages sur 3 octets (1 pour cmd + 2 pour paramètre(s)). Cette horloge est donc commune à chacun des autres modules.
Puis, une PIN est réservée par module connecté et gére les entree/sortie des échanges (en mode synchrone). Le module central se connecte donc cycliquement à chacun des modules (esclaves) lui transmettant ainsi les messages en attente d'envoi (provenant des autres modules) et réceptionne ensuite les messages en provenance de ce module pour les stocker en attendant sa prochaine connexion avec chacun des modules destinataires ... Ensuite, il se déconnecte et passe au module suivant ...
Voilà, un peu compliqué non ?... ou pas ? C'est l'avis que j'attends. Ne suis-je pas en train de ré-inventer la poudre et n'existe-t'il pas déjà quelque chose qui implémenterait une structure approchante ou suis-je sur la bonne voie ?
Merci de vos conseils ...
A+

PS: je veux pas être trop long dans mon message mais, ce que j'attends en fait de la robotique dans un futur proche, c'est une nomalisation des composants et des fonctionalités de base que l'on retrouve toujours sous diverses formes dans les différents projets, ceci afin de pouvoir concentrer ensuite les efforts sur des problèmes plus complexes. A ce titre, le modèle de développement du système Linux pour ce qui est de l'informatique est à mon avis un modéle à suivre en la matière ... N'existe-il pas déjà des groupes de travail et de normalisation sur de tels sujets ?...