Pour ma part, je ne vois pas l’intérêt de Windows sur un Raspberry PI alors que Linux fournit déjà un environnement bien plus complet et totalement libre.

goldbergg a écrit :



Voila, le véritable intérêt c’est de pouvoir dev avec les outils MS (Visual Studio, C#, …), dans ma boite (ou l’on dev principalement en C#), on s’intéresse de prêt a Windows 10 IoT pour porté certaine appli vers cette plateforme affin que sa tourne sur des boitier connecté.







La force de l’habitude est parfois mauvaise conseillère…



Sous Linux, il y a d’excellents outils de développement, une multitude de langages et de très bons environnements de développement.



Mais IMHO, l’erreur, c’est de penser qu’on pourrait faire de l’IoT juste avec langages de haut niveau. J’en connait qui vont rapidement déchanter dès que vous aurez le moindre circuit à piloter avec un timing temps réel.







lunehurlante34 a écrit :



C’est pas parce que Open office est gratuit pour toi, qu’elle l’est aussi pour l’administration/entreprise! C’est valable pour la plupart des freewares!







Le problème, c’est que tu confonds complètement freewares et logiciels libres.



Aucune licence de logiciel libre ne peut stipuler que la liberté de redistribution et d’utilisation se limiterait aux seuls particuliers.

goldbergg a écrit :



Ha j’adore ceux qui débarque comme sa avec leurs “vérité ultime” et qui vienne critiqué se que fond les autre alors qu’ils ne savent absolument rien de se qu’ils font ni des problématique auquel ils doivent répondre…







Comme tout le monde ici, je ne fais que donner mon humble opinion.



Est t’il vraiment besoin de préciser que si elle ne vous plait pas, vous êtes parfaitement libre de penser (et de dire) le contraire.



Il ne faut jamais prendre une discussion comme un affront personnel.





Comme je l’ai dit précédemment utiliser une solution Linux aurais été très problématique d’autant plus qu’on utilise des techno MS sans équivalent, donc on aurait été en plus obligé de réinventer la roue pour Linux (et de passer plusieurs mois, pour un truc qui existe déjà en c#)…





Evidemment, je ne présume pas d’un cas particulier ou il peut arriver qu’un outil ait des fonctionnalités qui facilitent certaines choses par rapport à d’autres.



Mais d’une manière générale, si dans l’embarqué on utilise surtout le C et l’assembleur, c’est parce que ce sont les langages les plus adaptés. Le C permet à la fois la programmation de haut niveau et un bon contrôle à bas niveau.





Et encore une fois, c’est bien d’avoir des idée toute faite sur les inconvénient des langages haut niveaux, mais visiblement t’as oublié quelque chapitre en cours de route sur la façon d’avoir des haute performance en C# (et autre language de haut niveaux) ;)





Avez vous seulement conscience que les langages ont des différences et que ces différences les rendent plus ou moins approprié à tel ou tel usage ?



Je vous engage donc à étudier les différence de fonctionnement entre C#, Java, javascript, C/C++ et du langage machine.



Ensuite, je vais vous donner (au hasard) cela :http://www.microchip.com/wwwproducts/en/PIC12F675



J’attends que vous m’expliquiez comment vous allez faire pour le programmer avec du C#.





Même en JS on peut avoire des haute performance avec asm.js





D’abord, asm.js, c’est du javascript sans être du javascript. La différence n’est pas facile à expliquer aux profanes(en gros, on utilise un sous ensemble du langage), mais ce n’est pas un simple détail : ce n’est pas de la programmation javascript.



Et ensuite, non, ça ne permet justement pas de hautes performances parce qu’on perds de manière significative par rapport à un programme compilé nativement.

MrPCB a écrit :



Moi je vois cette solution (Raspberry + Win IoT) comme une plateforme de prototypage.

 

Je ne comprend pas ce point de vue élitiste qui consiste à rabaisser sans cesse les languages de haut niveau.

Le but ici n’est pas la performance mais le fait de pouvoir prototyper rapidement/facilement.







Ce n’est pas une question d’élitisme. Les langages de programmation, c’est comme les outils d’un bricoleur : ils ont chacun leur utilité et leur fonction. Il faut en avoir conscience.



Et même pour du prototype, utiliser n’importe quoi en croyant se simplifier la vie n’est pas toujours une bonne idée. Par exemple, avec Javascript, vous allez juste vous arracher les cheveux à la moindre problématique de timing. En C, c’est beaucoup plus facile. Et en assembleur, on peut tout gérer d’une manière très fine.



Il ne faut pas faire l’erreur de ceux qui pensent se simplifier la vie en utilisant un tableur à la place d’une base de données.



Cela dit, c’est vrai qu’aujourd’hui, tout le monde veut se lancer dans l’IoT. J’ai vu des gars qui pensaient avoir trouvé l’idée du siècle… en pilotant une lampe. Alors au fond, ça n’a pas tellement d’importante.

goldbergg a écrit :



Ok, autant pour moi si je me suis fourvoyer.







Tu est pardonné. L’important est d’échanger des points de vue.



Et il n’y a pas d’obligation d’être d’accord.





Pour les problématique de temps réel, c’est avant tous une question de besoin, faire de l’IoT ne signifie pas forcement faire de l’embarqué avec se besoin de faire du temps réel (on est pas forcement à la milliseconde prés, ni même a la seconde).





C’est vrai. Tous les usages de l’embarqué et de l’IoT ne nécessitent pas du temps réel.



Mais dans les projets matériels, les problèmes de timing ne sont jamais tapis bien loin. Au moindre oubli ou évolution dans le projet, on peut très vite se retrouver embêté.



C’est pour cette raison que dans ce domaine un langage comme le C/C++ simplifie la vie. Parce que c’est un langages à très large spectre qui peut aussi bien descendre à très bas niveau (voir mixer de l’assembleur), mais également monter à haut niveau. C’est également un des rare langage à pouvoir s’interfacer avec presque tout et à disposer d’une quantité astronomique de bibliothèques disponibles pour faire presque n’importe quoi.





D’ailleurs l’OS a lui seul rend le temps réel compliqué.





Les Os font souvent mauvais ménage avec le temps réel. Et pour jouer de manière ultime avec les timings, il vaut mieux éviter les processeurs sophistiqués dont les timings sont peu prédictibles.



Il y a différentes manières de résoudre le problème avec les OS. On peut effectivement s’en passer sur certaines cartes. Mais on peut aussi combiner une carte avec un Os comme le RPI avec des petits microcontrôleurs qui vont gérer les aspects plus temps réel. C’est un schéma intéressant dans les cas ou l’on veut combiner les avantages des deux logiques.





Dans mon cas, les boitier seront placé chez différent  client pour faire de la collecte de donnée (via des capteurs comme des balance et/ ou un mini serveur utilisant les socket pour faire des requête sur le réseaux local), l’expédition des donnée vers un serveur central se fera seulement une a deux fois par jour, donc on est pas à la seconde prés.





Si le problème est principalement d’envoyer des données sur le réseau, ça se fait assez simplement en C/C++, il y a des bibliothèques pour cela.



Et même sans OS sur un arduino, on trouve moyen de communiquer sur le réseau.





Aprés moi aussi je trouve débile l’utilisation de JS pour faire de l’IoT (et un peux tous en général en faite), c’était plus pour l’exemple que l’on peut réutiliser certain langage pour faire autre chose que se que l’on fait habituellement avec.





Effectivement, on peut le faire bien que ce ne soit pas l’idéal.



Mais comme il y a des millions de programmeurs javascript, il était inéluctable que des gens voient un marché à prendre.





Mais quand on regarde IoT.js qui utilise le moteur jerryscript, on vois quand même que sa n’est pas une veille V8 qui est utilisé, mais qu’il y a un travail poussé d’optimisation pour que sa consomme trois fois rien.





Mais il faut cependant rester réaliste sur ce qu’on peut en tirer face à des outils mieux adaptés.



Prendre l’outil le plus puissant et adapté pour un problème donné, c’est la meilleure façon de se simplifier la vie.