Site des Oraux

Informatique temps réel et réseaux de terrains 2008 (10) :: post
Années :: 2005 :: 2006 :: 2007 :: Toutes

Post nº10 (id3842) envoyé par jeanne  le 29 Jun 2008, 14:08
Alors comme OS, j'ai présenté l'iPhone OS, et les outils de développement qui y sont attachés (XCode et Instruments). Toutes mes sources provenaient de developpers.apple.com/iphone
J'ai parlé de plein de sujets du cours, mais sans jamais aller dans les détails. Il a bien aimé.

Question supplémentaire: la même que Tim, système de monitoring pour des soins intensifs. Donc en gros adapter les labos. On a discuté des débits d'information, et de savoir si c'était limitant ou pas (savoir évaluer combien d'octets/seconde pour un ECG, ...)

Post nº9 (id3831) envoyé par Lau  le 28 Jun 2008, 12:12
présentation du protocole LonTalk (LonWorks)

et comme question supplémentaire: l'ordonancement

Post nº8 (id3645) envoyé par Tim  le 17 Jun 2008, 23:15
Alors comme reseau j'ai présenté le BITBUS, un petit résumé de ceci (http://www.bitbus.org/dnl/BITBUS%20Interconnect%20Specification.PDF) lui convient parfaitement.

La question qu'il m'a posé était la suivante "vous voulez réaliser un système de monitoring avec différents capteurs (tension artérielle, temperature corporelle, ECG, MEG,...), comment faites vous?" En gros il faut adapter ce qu'on a fait au dernier labo a cette situation.

Sinon il est bien sur très sympa et il cote largement.

Post nº7 (id3585) envoyé par Xavier  le 14 Jun 2008, 10:46
salut

moi j'ai présenté les 2 cours ensemble (archi et temps réel)
voir section architecture pour cette partie ;)

comme pour archi j'ai présenté le intel pentium I MMX je me suis dit que j'allais etendre sur le debug de celui ci... mais les infos manquaient donc j'ai fais de la théorie et donné les exemples du pentium

ici j'ai simplement repris son cours sur les debuggers et les emulateurs... j'ai fait un "resumé" en 15 minutes...

voila
il m'a juste posé comme question pendant mon exposé: comment on fait pour placer les breakpoints... => on remplace l'opcode

et ma grosse question:
il m'a demande de lui parler de l'ordonnancement temps réel et d'étendre ca aux réseaux (CAN etait mon projet d'année il savait que ct mon truc)

donc je lui ai fait un ptit resume sur l'ordonnancement que je lui ai présenté... ca ct bon ^^
et pour l'extension vers les réseaux : je suis parti sans préjugés et je suis resté général ...

j'ai envisage reseau monomaitre ou multimaitre... j'ai conclu multimaitre difficile (il m'a dit que ca ne se faisait pas si simplement en effet ^^)
j'ai parle d'un reseau du type can ou ethernet broadcast ou j'ai dit qu'il est difficile d'assurer qu'il n'y ait pas de conflits
alors j'ai parle d'un reseau du type token ring ou token bus avec un jeton et ca ct je pense ce qu'il attendait... en effet si on envisage un train qui parcoure le reseau, on connait le temps qu'il met pour faire un tour (et hop on est parti dans l'ordonnancement)

voila il etait fort satisfait il m'a mis 17

bon courage à tous

Xavier

Post nº6 (id3583) envoyé par Bocko The Chocobo  le 14 Jun 2008, 10:39
J'ai présenté le Intel XScale PXA 270 (le proço de mon PPC, en fait) pour les deux cours. Il a juste posé quelques questions pendant ma présentation pour la partie temps réel où je parlais de la debug unit (faut juste être un poil logique et se référer au chapitre en question dans le cours).

Sinon pour la question après présentation, j'ai juste dû lui parler de l'ordonnancement temps réel. J'ai suivi la structure du cours en lui expliquant les différents algorithmes avec les schémas et les problèmes qui y sont liés. Au final, j'ai eu le temps de parler que de la partie clock-driven mais il m'a fait faire un rapprochement avec le cours du premier quadri : j'avais dit qu'on faisait face à un gros plantage du système quand un problème survenait en section critique (masque d'interruption non levé donc le système réagit plus à rien) >> Quelle solution pour retomber sur ses pattes ?
>> Première idée : un timer ??? non car s'il déborde on sait pas lire l'interruption
>> Deuxième idée : un reset >> oui et comment ? Il y a un système prévu pour ça >> le watchdog (yes je m'en suis souvenu !!!) donc on fait un reset à chaud :p

Voilà donc rien de bien méchant et pour répéter les autres, il est super sympa ;)

Bonne chance aux suivants ^^

Post nº5 (id3573) envoyé par Laurent H  le 13 Jun 2008, 20:36
I) Présentation du RTOS VxWorks. Sources :
http://www.windriver.com/
http://research.microsoft.com/~mbj/Mars_Pathfinder/Authoritative_Account.html
http://mars.jpl.nasa.gov/MPF/mpf/sci_desc.html#ATMO
http://www.slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/guide/
http://www.cs.stevens.edu/~quynh/courses/cs520-fa07/cs520.html

II) même question que les autres : les problèmes liés au debug temps réel, les solutions apportées, en particulier l'analyseur logique et la synchronisation de ses signaux avec le code source. En gros, résumer les chap.7, 8 et 9.

Bonne m... !

Laurent

Post nº4 (id3530) envoyé par Michael  le 11 Jun 2008, 19:57
J'ai présenté le bus I²C (bus reliant des circuits intégrés dans une télé par ex) mais je n'ai pas parlé de ses gros défauts, certains sont évidents, par ex, il est bcp moins fiable que CAN (du fait qu'on ne code pas les données, faible immunité aux bruits...)==> on ne l'utilise que pour de petites distances. Mais d'autres sont moins évident : parler du fait que si un composant qui ralentit l'émission du maître(en maintenant le bus d'horloge à l'état bas) se plante (le bus reste alors à l'état bas), le maitre ne reprendra jamais la main et le système est bloqué... il ne reste plus qu'a retiré la prise.

Sinon ma question portait sur les RTOS (chapitre 5) et faire le lien avec µcos2 et ce qu'on a fait aux labos.

Post nº3 (id3514) envoyé par Billy  le 11 Jun 2008, 11:47
Salut à tous,

Apparemment, une question que Mathys aime beaucoup poser (au moins 4 fois sur la journée) est la suivante

1) expliquer les problèmes liés au débug d'un dispositif temps réel
2) Quelles solutions peut-on envisager pour concilier debug et temps réel.

Quelques idées:

1) En gros il y a 2 grands aspects: le premier est lié au fait que les opérations de debug sont incompatibles avec le temps réel, le second est lié au fait que le programme de debug doit tourner sur le même support physique que le prog TR .

aspect 1)lors du débug, on souhaite afficher l'état de variables en RAM ou dans des registres (traçage de l'exécution), observer si des branchements sont réalisés etc. Toutes ces opérations conduisent à un ralentissement de l'exécution du code.
L'exécution pas à pas ou l'introduction de breakpoints est totalement contradictoire avec les timing imposés par le processus temps réel. voir chap 7 slides 9 à 16
Vous pouvez aussi parler des run time check cf chap 7 slides 33 à 36

aspect 2)voir chap 7 slides 49 à 52

2) Il faut parler des émulateurs (chap 8). Présenter un peu émulateur ICE et ONCE. Dans les 2 cas, le programme de debug ne tourne plus sur le même support physique que le programme TR, donc les problèmes présentés au 1) aspect 2) ne se posent plus.
L'émulateur ICE présente bcp plus de fonctionnalités. Parler un peu de ces fonctionnalités et surtout de la RAM d'émulation qui est très utile! (Surtout si elle est à double entrée!)

Question subsidiaire: comment faire si on n'a pas les moyens pour un émulateur?
2 solutions:
- instrumenter le code : par ex faire clignoter des LEDs pour signaler quand on effectue un branchement. En gros, il s'agit de légèrement modifier le prog TR pour qu'il fournisse au monde extérieur des manifestations lors des étapes de son exécution. Si on demande de faire des choses simples, le ralentissement sera faible.

- améliorer la "cohabitation" entre le prog de debug et le prog TR sur le même µC en installant un RTOS. Les 2 parties seront bien cloisonnées et ne se marcheront plus sur les pieds. Il faut juste alors avoir un µC disposant de + de ressources, mais c'est toujours 10000 fois moins cher qu'un émulateur! La difficulté est apparemment d'établir les priorités entre tâches de debug et tâches TR.

Post nº2 (id3504) envoyé par Nico J  le 11 Jun 2008, 05:44
J'ai présenté le Profibus (doc disponible sur techniques de l'ingénieur).

Question : Quels sont les avantages de travailler avec un Os temps réel, et mise en relation avec le labo (qu'est-ce qu'on y a fait et manière dont on l'a fait).

Pour info, l'OS utilisé au labo est un mix entre un OS préemptif et non-préemptif. C'est à dire que les tâches doivent rendre la main à l'OS en s'adressant à celui-ci. Mais à chaque tic (15/s), l'OS reprend de toute façon la main pour faire quelques actions du genre augmenter les compteurs des tâches qui restent passives en attente pendant un labs de temps, cependant l'OS redonne la main à la tâche courante si elle n'est pas terminée, même si une autre tâche a une priorité supérieur. C'est donc une sorte d'OS hybride.


Post nº1 (id3450) envoyé par Scatt  le 08 Jun 2008, 12:44
Donc, pour ma présentation (j'avais imprimé mes slides et je l'ai fait donc sans ordi), j'ai fait un truc sur l'ordonnancement, en donnant un exemple d'un système multi-tâches et en expliquant différents ordonnancements possibles. (J'ai repris intégralement certains schéma de son cours, mais ça n'avait pas l'air de le déranger). Par contre, mon système n'était pas parfaitement adapté à l'ordonnancement event-driven, et je pense qu'il aurait été préférable, pour moi, de ne pas en parler, plutôt que de trouver un cas où ça aurait éventuellement pu être intéressant (pour l'event-driven) mais qu'il n'a pas trouvé adapté à ce type d'ordonnancement.

Puis, deuxième question (au moins 20 bonnes minutes de préparation): qu'est-ce que t'as fait au labo? Bon, ben ca se passe de commentaire si ce n'est que le chapitre 7.1 et 14 sont vos amis pour cette question.



oraux.pnzone.net - infos - 41ms