Greboca  

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

LinuxFr.org : les journaux  -  Modélisation - question de point de vue ?

 -  Novembre 2023 - 

Bonjour.

J'avais initialement l'intention de poser une question simple dans un forum, mais au final, au fur et à mesure que je rédigeais ma question, je me suis dit que celle-ci méritait peut-être un journal. Si ce n'est pas le cas, veuillez m'en excuser.

J'essaie de modéliser un système à base de carte style arduino, Raspberry Pi ou Micro:bit, et je me pose une question un peu basique mais qui n'est pas si évidente que ça : comment représenter la hiérarchisation de la carte, du firmware si elle en possède et du logiciel développé, qui sera exécuté par la carte.

Habituellement on décompose ces éléments en couches : on a le hardware, puis par dessus, le firmware (s'il y en a), puis par dessus le système d'exploitation (s'il y en a un) puis par dessus l'applicatif. Le firmware et le système d'exploitation ne sont pas obligatoire : on peut directement développer une application bare-metal, ou se baser sur des SDK qui ne sont ni des OS, ni des firmwares, mais des libs de code qui permettent d'acccéder au matériel.

Cela dit je suis en train d'essayer de décomposer ceci d'un point de vue de blocs style 'poupées russes" ou boites qui contiennent d'autres boites, et je me demande comment modéliser le matériel par rapport aux couches "codées (firmware/OS/application).

Doit-on considérer que le matériel inclut le logiciel ? comment ensuite organiser le firmware, le système d'exploitation et le code applicatif ? En y réfléchissant je ne suis pas sûr que cette approche soit la bonne, sans être mauvaise non plus ( ça doit dépendre je pense de ce que l'on veut mettre en évidence dans le modèle) Du coup, je demande à ceux qui ont l'habitude de faire ce genre d'analyse de me donner leur point de vue. Comment faites-vous ?
Si ça peut aider j'ai quelques exemples en tête. On va prendre pour base un système de mesure de température (basé sur un capteur de température - I2C ou analogique importe peu ), un afficheur LCD (idem - i2C, SPI, ou à base de contrôleur 7 segments LED), et possibilité d''envoyer les données de température sur un bus série type UART. Comment modéliser ce système dans les cas suivants :

  • carte basée sur un microcontrôleur AVR ATTiny, sans système d'exploitation, développé en C avec avr-gcc
  • carte arduino (je considère la couche arduino comme un firmware - mais peut-être à tort ) - avec utilisation de tous les outils arduino
  • utilisation d'un raspberry pi zero, programmation C bare-metal ( un firmware, le système de boot du raspberry, pas d'OS, mais éventuellement des libs permettant de configurer les ressources du RPi)
  • raspberry pi zero avec un OS (au moins noyau + libC voire libs) - programme écrit en C.
  • raspberry pi nano et le logiciel écrit en python (micropython)
  • application qui se base sur un système Forth qui s'exécute sur une carte Micro:bit (je pense que ça doit ressembler au cas précédent).
  • utilisation d'une carte basée sur X86 + bios (le firmware), en C (ou en assembleur), sans utiliser d'OS, mais en utilisant les interruptions du BIOS pour accéder au matériel. L'affichage dans ce cas se fera sur la sortie vidéo, et non sur un écran LCD
  • utilisation d'une carte basée sur X86 + bios (le firmware) + Système d'exploitation. en C - ou tout autre langage de plus haut niveau - L'affichage dans ce cas se fera sur la sortie vidéo, et non sur un écran LCD

Commentaires : voir le flux Atom ouvrir dans le navigateur

par totof2000

LinuxFr.org : les journaux

LinuxFr.org : Journaux

antistress adventure in Flatpak land

 -  30 avril - 

Hello nal, ça faisait un bail !Certain (il se reconnaîtra) m'a demandé de le tenir au courant lorsque j'aurai basculé sur un usage de Firefox (...)


Téléphone sous Linux ?

 -  25 avril - 

Aujourd'hui, avoir un téléphone avec un Android libéré, c'est possible, on pense en particulier à Murena.Avoir un téléphone sous GNU/Linux, c'est (...)


Quand votre voiture vous espionne… et vous le fait payer

 -  23 avril - 

Ceci se passe aux États-Unis, pour l’instant, aucune preuve qu’une telle fuite existe en Europe. Mais… si votre assurance augmente brutalement, (...)


firefox, nouvelle fenêtre dans une session isolée

 -  15 avril - 

Les fenêtres de navigation privées de firefox partagent leurs cookies de session or je souhaitais avoir des fenêtres de navigation isolées, (qui ne (...)


Pretendo tente de déprogrammer l'obsolescence des consoles Nintendo

 -  9 avril - 

Ah Nal,Gros N vient de faire un gros doigt aux utilisateurs de ses consoles 3DS et Wii U en annonçant la fermeture des services en ligne pour (...)