Aller au contenu
F4HTQ

Entraide, questions/réponses en programmation

Recommended Posts

F4HTQ

Bonjour,

Je crée ce sujet pour qu'on échange autour des thématiques de programmation. Cela semble avoir toute sa place dans un forum radioamateur vu la place toujours plus grande que prend le logiciel dans les équipements conçus.
Voila une liste de thèmes, non exhaustive, sur lesquels on pourrais échanger:
- les langages de programmation ( C, C++, Java, C#, Fortran, Javascript, langage de programmation des shaders,  ou assembleur..)
- Les API d'interface ( QT, .NET, HTML5,...)
- La programmation microcontrôleur ( Atmel, Pic, ...).
- Les environnement de développement  ( compilateurs, éditeurs..)
- les systèmes de gestion de dépôt de source ( source control ), SVN, Perforce..etc
- Les familles d'algorithmes utilisés dans les télécom ( Traitement numérique du signal, compression de données..)
Sont exclus de ce sujet tout ce qui touche l'utilisation des logiciels "finis", la configuration de la communication entre les Tx et les PC, les problèmes d'installation windows, etc...
On est vraiment dans un sujet de concepteurs et non d'utilisateurs.
Et si on pouvais aussi éviter les querelles de clocher ( Linux Vs Windows,  ou autre...)

Je rend le micro :)

David.
 

Modifié par F4HTQ

Partager ce message


Lien à poster
F4HTQ

Donc voila ou on en est sur la question de l'appuis de touche dans une application console en C++

 

Bonjour Antoine,

Il ne le prend pas en compte "comment" ?, erreur de compilation, de link, ou carrément ça ne fait "rien" ?

Voila ce qu'il faut normalement faire.

ne pas oublier d'inclure le header : 

#include <cstdio>

Ne pas oublier le namespace std devant la fonction, elle s'appelle donc par std::getchar();

ou alors pour ne pas taper le std partout, se placer dans le namespace avec un using namespace std; placé juste aprés les #include

c'est l'équivalent de std:getc(stdin) ce qui signifie :va me chercher un caractère sur l'entrée standard ( donc le clavier ).

Copier coller du test sous VS2010 fait à l'instant

#include <iostream>
#include <cstdio>

using namespace std;

void main()
{
    cout << "appuyez sur enter pour finir" << endl;
    int nKey = getchar();
}

 

C'est clair que ça aurait plus sa place dans un fil "programmation". D'ailleurs si on considère que la programmation tout comme l'électronique fait partie des outils de conception des radioamateurs, un tel sujet de discussion aurait sa place sur ce forum.

Bonne journée.
 David.

PS: je suis "forcé" d'utiliser Visual Studio car il est indispensable pour développer des application sur les consoles de jeu Microsoft, ce qui est le cas depuis la première XBox. Comme nous essayons de travailler avec un seul environnement de développement à la fois, nous utilisons aussi Visual studio pour les applications PlayStation et PC.

Modifié par F4HTQ

Partager ce message


Lien à poster
F6ITU

merci David. Bonne idée

Pourrait-on ajouter "électronique et développement" ? Conceptuellement, il est, dans le cadre des projets radioamateur, très difficile de dissocier soft et hard, adaptation, bidouille et code. Je code un "write" sur une sortie série de microcontroleur, une branche de mon repo intègre au minimum le schéma du décodeur spi (même si c'est un unique registre) et au maximum le pcb routé et les gerber. Et si possible avec un outil ouvert. Cela ne s'applique pas à tous les projets, bien sur

La réciproque est également vraie. échanger sur des outils de conception hard, partager sur des dépots, associer les développements complémentaires. 

je ne fais strictement aucune différence entre l'usinage d'un boitier à la fraiseuse numérique (merci freecad), un filtre de bande qui rentrera dedans (Kicad über Alles) et le source qui le pilotera (arduilollerie ou drogues dures)

Si on doit voter pour un dépot et un outil de versioning, je vote pour une croisade en faveur de git (sourceforge, subversion etc sont franchement en perte de vitesse)

Et s'il y a un premier dépot ou Wiki à pondre dans la sphère amateur, ce serait une typologie des dépots tenus par des radioamateurs... 

73'

Marc

(qui chantonne "si tous les gars du mooooonnnndeu voulais bien forker tout plein

et partageaient un beau matin leurs github et leurs ..." (vas trouver une rime en "in" en informatique... crotte de crotte)

Partager ce message


Lien à poster
F8EBL

Bonjour.

Très bonne idée de créer ce fil !

Merci David d' avoir fait ce petit rappel aux bases, ça m' a permis de trouver mon erreur :

j' avais #include <cstdlib> au lieu de cstdio.

J' espère que ce fil sera très long et plein de bonnes infos.

Pour la rime en "in" : stdin ??

Aîe!

Tapez pas, je sors tout seul !

f8ebl

Partager ce message


Lien à poster
F4HTQ

Bonjour,

Ce week end j'ai réussi a installer les sources + outils pour compiler WSJT-X sur windows et à compiler ma propre version.
Un OM a mis en place un package "JTSDK" qui contient tout ce qui est nécessaire. 

Voila quelques infos pour ceux qui voudraient en faire de même.

  1. il faut commencer par télécharger et installer les 3 fichiers qui sont dans ce répertoire : https://sourceforge.net/projects/jtsdk/files/win32/2.0.0/base/contrib/
  2. il faut télécharger et exécuter les 4 installables qui sont ici : https://sourceforge.net/projects/jtsdk/files/win32/2.0.0/ . l'ordre est important, il faut commencer par JTSDK-2.0.0-win32.exe et finir par JTSDK-2.0.0-u4-win32.exe
  3. Ensuite, toute la procédure est très bien expliquée ici : README.md 

Si vous suivez bien les instructions ( il ne faut vraiment pas improviser...) tout devrais bien se passer, vous aurez sur votre machine à la fois les dernières versions des outils de compilation, mais aussi la dernière version des sources, le tout avec les scripts permettant de lancer la compilation. Il faut savoir que ce SDK va automatiquement vous configurer l'accès SVN aux sources, ensuite pour vous mettre à jour il suffira de faire un "SVN Update" sur le répertoire C:\JTSDK\src\wsjtx

David.

Partager ce message


Lien à poster
F6ITU

gggggnnnnn arrrrrrgggghhhhh 

sourcefooooorge..... ça résonne un peu comme "je suis ton pèèèèère" (ou grand père)

Merci David... je vais tenter ça... lorsque j'aurais deux minutes de libre bien sur

MArc 

Partager ce message


Lien à poster
F4HTQ

Bonsoir,

J'ai torturé un peu dans tous les sens l'IDE officiel de l'arduino le week end dernier.

Il faut savoir (pour ceux qui connaissent mal le truc) que les "sketch" arduino sont des sortes de programmes en C "simplifié", avec des librairies inclues par défaut, pas de makefile a faire, un seul fichier source... etc.

Mais derrière ça, c'est un véritable compilateur C++ qui est appelé pour générer le programme en langage machine.

En gros l'idée était de voir si on pouvais l'utiliser pour du C++ "avancé" comme on l'appelle.

Donc, j'ai testé pas mal de choses généralement assez tordues comme:

  • Instanciation d'une classe template dans le .ino.
  • Spécialisation d'une classe template dans le .ino
  • surcharges d’opérateurs, y compris ceux d'allocation.
  • Template metaprogramming 
  • Héritage virtuel.

Initialisation des constructeurs par défaut des objets globaux.

Et absolument tout est passé sans encombre.

J'ai juste eu des problèmes avec des constructeurs de classe statiques qui n'étaient pas appelés, mais ça c'est courant dans tout ce qui est embarqué ( dont les consoles de jeu ).

Ceci fait que je vais certainement porter dans l'IDE arduino ( sous forme de librairie C++ ) pas mal de code que j'ai initialement développé dans Atmel studio, en programmant  les microcontroleurs directement via l' ISP.

Par contre, point de vue confort de développement, on est des années lumières en avance avec Atmel Studio (on doit facilement pouvoir bosser 2 à 3 fois plus vite que avec l'IDE Arduino), donc pour le code un peu complexe ça vaut le coup de le mettre au point dans Atmel Studio et de le porter ensuite dans l'IDE Arduino . 

David.

 

Partager ce message


Lien à poster
F6ITU

c'est effectivement ce que font les "c0d3rZ" du lab, qui passent allègrement d'AVRDude à d'autres environnement comme je change de chemise

l'IDE arduino est un peu comme la langue d’Ésope : la meilleure et la pire des choses. Les libs en include par défaut qui ne sont pas optimisées, le camouflage de la partie "programmation pure et dure" notamment dans la section déclarative font hurler les programmeurs pro, mais il faut bien admettre que c'est un bonheur pour les handicapés du C (tels que moi par exemple) 

je cafte... j'en connais qui ne font même pas l'effort de porter leur dev dans l'IDE "a posteriori". (c'est notamment le cas des firmware de DG8SAQ, de Loftur tf3lj pour le firmware unifié softrock/widget... et j'en passe)

 

Marc

Partager ce message


Lien à poster
F4HTQ
Il y a 3 heures, F6ITU a dit :

c'est effectivement ce que font les "c0d3rZ" du lab, qui passent allègrement d'AVRDude à d'autres environnement comme je change de chemise

l'IDE arduino est un peu comme la langue d’Ésope : la meilleure et la pire des choses. Les libs en include par défaut qui ne sont pas optimisées, le camouflage de la partie "programmation pure et dure" notamment dans la section déclarative font hurler les programmeurs pro, mais il faut bien admettre que c'est un bonheur pour les handicapés du C (tels que moi par exemple) 

je cafte... j'en connais qui ne font même pas l'effort de porter leur dev dans l'IDE "a posteriori". (c'est notamment le cas des firmware de DG8SAQ, de Loftur tf3lj pour le firmware unifié softrock/widget... et j'en passe)

 

Marc

Bonjour Marc,

Il n'y a pas vraiment intérêt pour un développeur "pro" de faire des projets sous l'IDE Arduino, a part de pouvoir rapidement intégrer des libs pour gérer quelques périphériques (série, écrans, etc...).

Je me suis déjà retrouvé bloqué avec un Arduino par manque de ports ( un seul port est accessible au complet avec un arduino Uno) alors qu'avec un Atmega 328P monté sur une platine dédiée j'avais tout ce qu'il fallait.

Mais bon, quand on ne bosse pas en Arduino on se coupe de beaucoup de bricoleurs "amateurs", et pouvoir partager avec le plus grand nombre amène ce genre de concessions. Et ici ça commence avec ma fille qui débute en code Arduino et qui a besoin de certaines librairies "fait maison".

Autre chose qui n'a rien a voir.

Quand, il y a une quinzaine d'année, je codais des jeux sur Game Boy Advance on était quelques uns à utiliser du C++, les autres étaient restés en "C" car, disaient t'il, c'est plus rapide ( en fait c'est l'inverse, mais les développeurs sont remplis de préjugés et de croyances).

Le processeur en question n'était pas foutu de faire des calculs en virgule flottante ( pas de FPU ), ce qui compliquait un peu certains développements. A l'époque j'avais écrit une classe C++ de calcul a virgule fixe avec une surcharge de tous les opérateurs arithmétiques.  On travaillait alors avec ces "pseudo flottants" de façon transparente et avec des performances élevées. C'est une technique qu'on utilisais beaucoup dans les années 80, en assembleur 68000, dans les milieux démomackers sur Atari ST et Amiga.

Ensuite, non content de la lenteur des divisions ( les processeurs ARM étaient catastrophique la dessus) , j'avais crée une classe qui représentait les nombre sous forme fractionnaire. Ainsi une division devenait une multiplication, un inverse devenait une simple permutation. C'est uniquement quand on voulais repasser en flottant ou pseudo flottant qu'on payait le prix de la division.

Ceux qui étaient restés en C utilisaient une librairie de calcul, bien plus lente, mais étaient convaincus que leur truc était plus rapide car "optimisé" et "pas en C++".

Il doit me rester ces classes quelque part, je vais voir si elles peuvent être adaptées pour l'arduino ( à priori ça ne devrais pas poser problème) qui lui aussi est dépourvu d'unité de calcul à virgule flotante.

David.

Modifié par F4HTQ

Partager ce message


Lien à poster
F6ITU

Je le savais :-) (du moins, je m'en doutais)

j'ai surtout côtoyé la demoscene Commodore -64 est-il nécessaire de préciser- un peu moins celle de l'Amiga, pas trop celle des consoles, et j'ai encore quelques attaches avec quelques reversers du MAME coté arcades pro, tous d'anciens demomakers. Mais tout ça remonte à l'origine des temps (informatiques).

vous faites tous partie d'un monde de grands malades... :-) (incurables de surcroît) 

Pourquoi ne pas venir en parler précisément à l'occasion d'un Grehack ? ce genre de savoir et de maîtrise de l'optimisation de code intéresse toujours, tout le monde. 

un exemple 

https://bruno.kerouanton.net/blog/2011/06/20/ma-presentation-a-la-ndh2k11/

... il a récidivé à Jurhackersfest

et ça s'est terminé en un tonnerre d'applaudissements. Tout ça nous éloigne des arduilols, mais c'est ça aussi, le partage du savoir

Pour ce qui concerne les arduineries, j'en suis un défenseur inconditionnel en raison de son rôle initiatique. Il accompagne souvent les premiers pas des nouveaux venus à l'électronique, ou des débutants en programmation. Sans ce truc là, beaucoup de radioamateurs -et hackers- ne se seraient jamais intéressés au code pour les uns, au fer à souder pour les autres. 

... enfin, ceci est l'avis d'un nullissime en programmation

Marc

 

Partager ce message


Lien à poster
F4HTQ

Bonjour Marc,

Je vois que le monsieur à parlé des "blue box", ce qu'on a pu "s'amuser" avec ces trucs la.

le hacking "analogique" avec un bip + un générateur de fréquences vocales pour rediriger l'appel.

Bon, hiers soir j'ai retrouvé une classe de FFT optimisée a bloc il y a une vingtaine d'année. j'ai une version avec que des calculs en entiers et une minimisation au possible de la mémoire utilisée. 

a l'origine je l'avais développée en assembleur 68030 sur Atari Falcon au début des années 90, et ensuite portée en C sur PC avec le watcom C++.

Donc, elle va passer sous forme de lib arduino. Je vais passer en paramètres templates l'ordre de la transformée  ainsi que la type de la donnée de base ( 8 ou 16 bits entiers ou nombre flottants), ce qui permettra d'avoir toujours une version optimale ( calcul et occupation mémoire) pour un besoin donné. Chose totalement impensable en langage C ;)

 

David.

Partager ce message


Lien à poster
F6ITU

le monsieur en question, je le traîne à Grenoble l'an prochain, et je vous enferme tous les deux dans une pièce :-) (j'ai oublié son call.. HB9quelquechose) (hb9fzl, c'est reviendu)

faut venir jouer avec nous, à l'Electrolab... 

Marc

Partager ce message


Lien à poster
F4HTQ
Le 20/12/2017 à 15:19, F6ITU a dit :

l'IDE arduino est un peu comme la langue d’Ésope : la meilleure et la pire des choses. Les libs en include par défaut qui ne sont pas optimisées, le camouflage de la partie "programmation pure et dure" notamment dans la section déclarative font hurler les programmeurs pro, mais il faut bien admettre que c'est un bonheur pour les handicapés du C (tels que moi par exemple) 

Bonjour Marc,

Hier soir j'ai un peu regardé les fonctions "helpers" des libs arduino ( comme tout ce qu'il se passait derrière quand on appelait cette fonction digitalWrite() ) . ça m'a fait un peu hérisser les cheveux de la tête.

On perd effectivement pas mal de perfs ( plusieurs indirections et tests supplémentaires) en utilisant ces fonctions qui "simplifient la vie".

La double peine c'est quand on se tape aussi l'handicap d'utiliser une platine arduino et non un microcontroleur atmel cablé par nos soins.

Cas typique rencontré en début de semaine.

j'ai fais un peu de code "graphique" sur ce genre d'écran : 
https://www.ebay.fr/itm/2-4-TFT-LCD-Display-Shield-Touch-Panel-ILI9341-240X320-for-Arduino-UNO-MEGA/322627830346?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

normalement, avec un adressage //, 8 bits de datas d'un coup, ça doit tracer.

La première embûche c'est que quand on le monte sur un arduino nano c'est cuit pour mapper d0-d7 sur un seul port, il faut au moins en utiliser deux, avec des masquages à la clef.

Mais ensuite j'ai utilisé une lib existante pour gérer les transferts SPI, un truc rempli de ces fameux digitalWrite()... et bien rien que le fait d'informer l'écran qu'on veut écrire quelques pixels nous coûte aussi cher que plusieurs poignées de pixels.

Bref, dans ce cas précis, tout faire à la main ( la platine et le code) devrait rapporter un ratio 3 ou 4 de vitesse. Et la vitesse, avec ce genre de choses ce n'est pas un luxe, c'est de la réactivité de l'IHM.. bref, de l'ergonomie.

David.

 

Modifié par F4HTQ

Partager ce message


Lien à poster
F6FVY

Bsr

Lorsque l'on a des pb de réactivité et/ou une IHM lourde à gérer et/ou pas le temps (ou la flemme) d'écrire du code bas niveau performant, il peut parfois être utile d'utiliser des afficheurs "intelligents" auxquels ce travail est délégué, pour concentrer l'Aduino (ou autre) aux taches bassement matérielles, dans tous les sens du terme.

Voir la série Nextion chez Itead (entre autres) par exemple.

Par contre, évidemment, c'est un peu plus onéreux qu'un afficheur de Nokia 5331 ;-)

73

Laurent - F6FVY

Partager ce message


Lien à poster
F4HTQ

Sympa, je connaissais pas.

ça multiplie le prix de l'écran par 5 ( pour l'entrée de gamme, comparativement à un LCD non accéléré de résolution et taille comparables), mais ça reste acceptable si c'est pour monter un un truc qu'on utilise tous les jours.

Ils sont allés jusqu’à faire un générateur d'IHM, pourquoi pas ?

Quand je pense que dans mon premier boulot je codait des routines de remplissage de triangle mappé en software.. ça fait loin.

 

Partager ce message


Lien à poster
F6FVY

Re

J'ai oublié de mentionner que la plupart sont aussi tactiles (résistifs le plus souvent - là aussi c'est une question de prix), ce qui facilite aussi l'IHM, et peut faire économiser des I/O sur le μC.

73

Laurent - F6FVY 

Partager ce message


Lien à poster
Ancien membre
Il y a 2 heures, F4HTQ a dit :

ça multiplie le prix de l'écran par 5 ( pour l'entrée de gamme, comparativement à un LCD non accéléré de résolution et taille comparables), mais ça reste acceptable si c'est pour monter un un truc qu'on utilise tous les jours.

Ils sont allés jusqu’à faire un générateur d'IHM, pourquoi pas ?

 

 

Bonsoir,

Le nom du produit me disait quelque chose. Je viens de vérifier et, effectivement, le produit a été présenté assez en profondeur dans le Hackable Magazin de juillet/août 2017 (N° 19 pages 4-17)

Le générateur d'IHM, dont l'emploi est obligatoire, est un produit propriétaire, fermé, ne tournant que sous Windows. De plus, comme l'indique sa version (0.53 pour le dernier)), il est encore loin d'être stable et finalisé:

https://nextion.itead.cc/resources/download/

AMHA, c'est rédhibitoire.

73's Sylvain

Partager ce message


Lien à poster
F4HTQ

Bonjour,

j'ai un peu survolé les docs.

En gros, ce qu'ils ont fait c'est l'équivalent d'un adobe flash ( fonctions graphiques et langage de script sommaire) avec le moteur d'exécution ( proc ARM) directement sur la carte de l'écran, et donc avec un accès rapide au GPU. 

ça me semble un peu "overkill" pour faire l'IHM d'un appareil de mesure ou d'un Tx, mais ça peut avoir du sens sur des bornes interactives.

David.

 

Partager ce message


Lien à poster
F6ITU

hum

https://f6itu.wordpress.com/2017/07/17/milliwattmtre-08-ghz-650dbm-pas-cher/

vu la place que l'on a sur un arduino nano, utiliser un truc overkill mais qui économise du code peut passer pour une bénédiction (c'est toujours ça de gagné pour grappiller de la place pour les tableaux d'étalonnage et autres calembredaines). Et franchement, le produit a été pensé pour une clientèle qui n'a pas nécessairement le programmeur de MCU adéquat. Look, Ma, no SPI : je glisse une carte SD pondue sur ma machine, et en voiture !

L'environnement de dev graphique n'est pas si instable que ça.  "il fait sa job" comme disent les Canadiens. Surtout pour des "pas gourous du code" comme moi. Enfin, j'ajouterais, pour tous les béotiens des arduiloleries, que franchement, ça nous change du 16 caractères/2 lignes, pour à peu près le même niveau de complexité d'utilisation.

mais oui, closed source de chez closed source (et closed hardware).

Marc

ps : un dernier avantage : ce truc est plus silencieux que n'importe quel afficheur lcd 16x2. Il rayonne moins, il pourrit moins la ligne d'alimentation, même si quelques découplages énergiques sont recommandés.

Partager ce message


Lien à poster
Ancien membre

Si certains qui suivent cette discussion sont intéressés par les Nextion, Philippe Demerliac (CYROB) a publié deux vidéos sur le sujet. La première est une présentation rapide ; la seconde dédiée à la présentation de ce matériel.
 

--
 

Partager ce message


Lien à poster
F4HTQ

Bonsoir,

Pour initier les enfants à la programmation, le langage en vogue est scratch. ( https://scratch.mit.edu/ ) 

c'est utilisé dans les écoles primaires, dans les collèges.

C'est un langage graphique dont le formalisme force à "écrire" du code correct. Je pense que c'est une bonne école pour les enfants.

Il est disponible sur windows, linux, mac ( et même mac power PC sur une version ancienne).

Un équipe a mis au point, il y a quelques années, scratch arduino 

C'est quoi ?

Et bien c'est scratch au complet ( exactement comme le scratch original) mais avec en plus des modules correspondants aux entrées sorties d'un arduino:

  • Sorties logiques
  • Entrées logiques
  • Entrées analogiques
  • Sorties en PWM

Si certains d'entre vous on utilisé un arduino comme carte d'E/S pour labview, l'approche est identique, c'est à dire:

L'arduino n'exécute pas le code scratch ( il reste exécuté sur le PC ), mais il sert uniquement de carte d'entrées sortie "bon marché".

l'avantage est que l'on ne souffre pas des limitations d'un arduino au niveau de l'exécution ( vitesse, mémoire..), mais avec la conséquence que le PC doit toujours être connecté a l'Arduino pour exécuter le code.

Comment on s'y met ?

on récupère ici : http://s4a.cat/index_fr.html à la fois le programme a installer sur le PC et le code qui devra être téléchargé dans l'arduino pour le transformer en carte d'entrée-sortie.

Donc on commence par charger dans l'arduino ce sketch la : http://vps34736.ovh.net/S4A/S4AFirmware16.ino  ( en utilisant l'IDE arduino comme on le ferait pour n'importe quel sketch).

( Cette manipulation n'est a faire qu'une seule fois ).

Et ensuite on lance le programme "SA4" ( que l'on a préalablement installé) . Il  va automatiquement détecter l'arduino et l'initialiser.

Ensuite, on peut programmer.

En se levant tôt on devrait même pouvoir programmer un DDS en scratch arduino.. 

C'est vraiment une bonne passerelle pour les enfants qui ont "accroché" sur scratch et qu'on a envie de faire passer, très progressivement" dans l'univers des microcontrôleurs.

Ma fille ( 10 ans) en fait plusieurs heures chaque week end. Hier elle a bricolé un petit système qui allume automatiquement des led selon le niveau d'illumination de la pièce ( via des photorésistances et les ADC).

David.

 

  

 

 

Partager ce message


Lien à poster
F6ITU

... on devrait dénoncer de telles pratiques à la Protection de l'Enfance. Car je le devine bien ! David, insidieusement, va influencer son héritière à utiliser des outils 

https://www.crowdsupply.com/lime-micro/limesdr-mini/updates/raspberry-pi-3-and-scratch-demo

en phase avec ses (nos) propres perversions !

Oui, Scratch est un superbe workbench qui simplifie l'approche algorithmique, avec considérablement plus d'efficacité de Logo (imho). Et Scratch Radio, bien qu'encore très embryonnaire, est sacrément prometteur comme outil d'initiation au pilotage soft 

https://github.com/myriadrf/ScratchRadio

Marc

 

Partager ce message


Lien à poster
F0CRU

Bonsoir à tous,

C'est une chance, je trouve, pour les jeunes d’aujourd’hui de pouvoir être initier au codage assez tôt dans la scolarité.

Quand je vois la galère à 45 ans pour apprendre, que dis-je, commencer à apprendre...

Enfin, merci Python quand même...

73's

Stephan

Partager ce message


Lien à poster
F4HTQ

Bonsoir,

Et pour la programmation microcontrôleur on a aussi fait de gros pas vers l’accessibilité.

On a de bons compilateurs, des composants à l’architecture assez simple, et surtout un accès au partage de la connaissance via internet.

Mon projet de fin d'étude ( radar à effet Doppler ) fonctionnait autour d'un 68HC11 avec plusieurs centaines de lignes de code en assembleur.

Ce n'est pas si vieux, c'était en 1998.

Si les choses n'étaient pas devenues plus accessibles, on aurait jamais eu cette vague d'apprentis roboticiens.

David.

Partager ce message


Lien à poster
F0CRU
Il y a 10 heures, F4HTQ a dit :

Si les choses n'étaient pas devenues plus accessibles, on aurait jamais eu cette vague d'apprentis roboticiens.

C'est pas Faut....

Partager ce message


Lien à poster

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×