Effectivement, c'est encore cher (la reconfigurabilité se paye en transistors supplémentaires) par rapport aux circuits intégrés "standard". Cela dit, pour des petites séries ca reste valable, car il n'y a pas besoin de faire des masques de gravure.
Avec les FPGA low-cost récents (sans faire de pub : Cyclone chez Altera, Spartan3 chez Xilinx pour les plus connus), on atteint des prix inférieurs à une dizaine de $ en volume pour un FPGA de qq centaines de milliers de portes logiques, capable d'acueillir un design de microcontrôleur et ses périphériques, plus un peu de place pour une application spécifique. Les fabricants cherchent à conquérir le marché "consumer", avec par exemples des décodeurs numériques dans lesquels on pourrait télécharger de nouvelles fonctions/codecs hardware ...
Ils misent à fond sur la réduction de coûts sur la quantité, avec des wafers de 30cm (plus de puces par galette) et même une gravure en 90nm pour les Spartan3 (je crois que c'est les premières puces commercialisées avec cette techno).
En pratique, vu les petites quantités mises en uvre pour le moment, il faut compter au moins 200 pour une carte de développement, 1000 pour qqch de sérieux (plus d'1M portes logiques). Plus les outils de développement, qui commencent à appraitre en version Linux, mais pas libre :-/ et loin d'être gratuits :-(
Deux exemples de cartes pas trop chères : http://www.atmark-techno.com/product/suzaku.en.html(...) http://www.charmedlabs.com/xport.htm(...)
Je suis d'accord.
Celà dit, si les performances annoncées ne sont pas au rendez-vous tu vas vite t'en rendre compte, à condition que tes jeux de tests soient bien faits, evidemment. Mais il ne faut pas attendre un problème grave pour ca !
Il y a quand même un minimum de validation et de tests qualité à faire avant de lâcher une application temps réel critique dans la nature. Les éditeurs le savent, et font attention à ce qu'ils annoncent (on n'est pas dans le domaine de l'OS bureautique avec écrans bleus ... d'aillleurs y'a pas toujours d'écran, juste un bon vieux terminal serie pour debugger)
Donc, entre bencher un OS proprio, et bencher un OS libre dans les mêmes conditions que l'application à développer, je ne vois pas la différence. Sauf que si les resultats ne te plaisent pas, tu peux aller regarder comment ca marche dans le cas de l'OS libre. Pour le proprio, tu attends la prochaine release ...
Un autre argument est le nombre d'architectures (processeurs) supportés. Un éditeur facturera très cher le portage de son OS sur un nouveau processeur, tandis qu'une bande d'enthousiastes peut porter linux et les extensions temps-réel sur n'importe quel CPU. Par exemple, le portage de µClinux sur le processeur reconfigurable MicroBlaze est en cours dans une université australienne. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/(...)
Je pense que la possibilité de trainer en justice un fournisseur n'a pas la même valeur que le fait de produire un système maitrisé dans sa totalité.
Le temps de réponse déterministe à une interruption ou à une commutation de tâche est garanti par conception de l'ordonnanceur de l'OS.
Avec un OS open-source, tu peux t'assurer toi-même de l'agorithme d'ordonnancement utilisé, eventuellement le patcher ...
Je en pense pas que le terme "garantie" s'applique ici en termes juridiques : je te vois mal coller un procès à un éditeur d'OS parce que ton air-bag ne s'est pas déclenché à temps ...
C'est plus une caractéristique du produit, tout dépend de ce que tu en fais. Par exemple, un bête printf() ajouté pour débugger une fonction va complètement bousiller ton beau séquencement de tâches périodique à 10ms, OS temps réel ou pas.
Effectivement, le temps réel est omnipresent dans l'industrie et plus particulièrement dans les systèmes embarqués. Ce qui signifie peu de mémoire, une consommation mesurée, et donc des perfos en deca de ce que vous avez sur vos bureaux ... ce qui oblige à bien optimiser son code. Je dirais même que seul le monde de la micro-informatique et des serveurs est épargné par le temps réel ...
Quand on entend parler de "bourse en temps réel sur Internet", ca me fait rire ... y'a rien de temps réel là dedans.
Dans le domaine des systèmes industriels régnent en maitres les OS propriétaires, les OS "maison", voire même pas d'OS du tout (chaque tâche est activée par une interruption). Mais Linux est en train de boulverser tout ce petit monde : pourquoi developper un OS "maison" quand on a les sources d'un OS tout fait, qui marche, il "suffit" de le rendre temps réel.
Je pense qu'après les serveurs, c'est par l'embarqué que Linux se diffuse le plus largement.
En ce qui concerne les sources d'infos, je conseille tout particulièrement : http://www.linuxdevices.com(...)
(du PDA au gros Cluster, tous les Linux embarqués, avec des études de marchés très intéressantes, et un joli comparatif linux 2.4 / 2.6)
http://www.enseirb.fr/~kadionik/(...)
(Site d'un universitaire français, qui regorge de liens et de cours sur Linux, les systèmes embarqués, et ... Linux embarqué ! )
Juste un précision sur RTAI : c'est effectivement un fork de RTlinux, mais qui est exempt du problème de brevet logiciel qui accable ce dernier ;-)
[^] # Re: La longue marche vers le hardware libre
Posté par Jimmy . En réponse à la dépêche La longue marche vers le hardware libre. Évalué à 10.
Avec les FPGA low-cost récents (sans faire de pub : Cyclone chez Altera, Spartan3 chez Xilinx pour les plus connus), on atteint des prix inférieurs à une dizaine de $ en volume pour un FPGA de qq centaines de milliers de portes logiques, capable d'acueillir un design de microcontrôleur et ses périphériques, plus un peu de place pour une application spécifique. Les fabricants cherchent à conquérir le marché "consumer", avec par exemples des décodeurs numériques dans lesquels on pourrait télécharger de nouvelles fonctions/codecs hardware ...
Ils misent à fond sur la réduction de coûts sur la quantité, avec des wafers de 30cm (plus de puces par galette) et même une gravure en 90nm pour les Spartan3 (je crois que c'est les premières puces commercialisées avec cette techno).
En pratique, vu les petites quantités mises en uvre pour le moment, il faut compter au moins 200 pour une carte de développement, 1000 pour qqch de sérieux (plus d'1M portes logiques). Plus les outils de développement, qui commencent à appraitre en version Linux, mais pas libre :-/ et loin d'être gratuits :-(
Deux exemples de cartes pas trop chères :
http://www.atmark-techno.com/product/suzaku.en.html(...)
http://www.charmedlabs.com/xport.htm(...)
Côté performances, les microcontrôleurs sythétisables en FPGA atteignent une centaine de MHz, et une petite centaine de MIPS, ce qui permet déjà de faire tourner sans pb un µClinux. Le portage de notre pingouin préféré est fait ou en cours pour la plupart des processeurs de ce type.
Par exemple :
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux(...)
http://www.gaisler.com/linux.html(...)
http://www.opencores.org/projects/or1k/uClinux(...)
Désolé de faire un post si long, j'espère juste avoir éclairé qq lanternes ...
JiM
[^] # Re: Sortie de RTAI 24.1.12
Posté par Jimmy . En réponse à la dépêche Sortie de RTAI 24.1.12. Évalué à 2.
Celà dit, si les performances annoncées ne sont pas au rendez-vous tu vas vite t'en rendre compte, à condition que tes jeux de tests soient bien faits, evidemment. Mais il ne faut pas attendre un problème grave pour ca !
Il y a quand même un minimum de validation et de tests qualité à faire avant de lâcher une application temps réel critique dans la nature. Les éditeurs le savent, et font attention à ce qu'ils annoncent (on n'est pas dans le domaine de l'OS bureautique avec écrans bleus ... d'aillleurs y'a pas toujours d'écran, juste un bon vieux terminal serie pour debugger)
Donc, entre bencher un OS proprio, et bencher un OS libre dans les mêmes conditions que l'application à développer, je ne vois pas la différence. Sauf que si les resultats ne te plaisent pas, tu peux aller regarder comment ca marche dans le cas de l'OS libre. Pour le proprio, tu attends la prochaine release ...
Un autre argument est le nombre d'architectures (processeurs) supportés. Un éditeur facturera très cher le portage de son OS sur un nouveau processeur, tandis qu'une bande d'enthousiastes peut porter linux et les extensions temps-réel sur n'importe quel CPU. Par exemple, le portage de µClinux sur le processeur reconfigurable MicroBlaze est en cours dans une université australienne. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/(...)
Je pense que la possibilité de trainer en justice un fournisseur n'a pas la même valeur que le fait de produire un système maitrisé dans sa totalité.
JiM
[^] # Re: Sortie de RTAI 24.1.12
Posté par Jimmy . En réponse à la dépêche Sortie de RTAI 24.1.12. Évalué à 3.
Avec un OS open-source, tu peux t'assurer toi-même de l'agorithme d'ordonnancement utilisé, eventuellement le patcher ...
Je en pense pas que le terme "garantie" s'applique ici en termes juridiques : je te vois mal coller un procès à un éditeur d'OS parce que ton air-bag ne s'est pas déclenché à temps ...
C'est plus une caractéristique du produit, tout dépend de ce que tu en fais. Par exemple, un bête printf() ajouté pour débugger une fonction va complètement bousiller ton beau séquencement de tâches périodique à 10ms, OS temps réel ou pas.
JiM
[^] # Re: temps réel dur ?
Posté par Jimmy . En réponse à la dépêche Sortie de RTAI 24.1.12. Évalué à 4.
Quand on entend parler de "bourse en temps réel sur Internet", ca me fait rire ... y'a rien de temps réel là dedans.
Dans le domaine des systèmes industriels régnent en maitres les OS propriétaires, les OS "maison", voire même pas d'OS du tout (chaque tâche est activée par une interruption). Mais Linux est en train de boulverser tout ce petit monde : pourquoi developper un OS "maison" quand on a les sources d'un OS tout fait, qui marche, il "suffit" de le rendre temps réel.
Je pense qu'après les serveurs, c'est par l'embarqué que Linux se diffuse le plus largement.
En ce qui concerne les sources d'infos, je conseille tout particulièrement :
http://www.linuxdevices.com(...)
(du PDA au gros Cluster, tous les Linux embarqués, avec des études de marchés très intéressantes, et un joli comparatif linux 2.4 / 2.6)
http://www.enseirb.fr/~kadionik/(...)
(Site d'un universitaire français, qui regorge de liens et de cours sur Linux, les systèmes embarqués, et ... Linux embarqué ! )
Juste un précision sur RTAI : c'est effectivement un fork de RTlinux, mais qui est exempt du problème de brevet logiciel qui accable ce dernier ;-)
JiM
[^] # Re: c'est pourtant la preuve que TCPA ne sert que pour palladium/DRM
Posté par Jimmy . En réponse à la dépêche IBM présente TCPA "tel qu'il aurait dû être". Évalué à 1.
C'est pas encore super puissant, mais c'est le début.
Pour info, le portage de µClinux sur le MicroBlaze de Xilinx :
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux(...)
Quant au Open Hardware, il y a déjà des schémas et des "IP libres" (non c'est pas un troll, même si IP signifie Intellectual Property), par exemple sur http://www.openhrdware.net(...) ou surtout sur http://www.opencores.org(...)
JiM