Sujet Et Windows XP embedded?
- 28 réponses
- 9 participants
- 1 020 vues
- 1 follower
Yannou le Jacky
Parce que la je suis en train de l'essayer et c'est la galere pour les pilotes !!! !! Donc si qqun a déja testé et peux m'aider ca serait cool !
Jacky repenti. SeuRn
Anonyme
Ce n'est pas un windows classique, il n'a pas toutes les fonctionnalités et son architecture est très fermée vu que normalement c'est destiné au marché de l'informatique embarquée et pas au marché du pc.
Yannou le Jacky
Jacky repenti. SeuRn
Pov Gabou
Citation :
Ben ecoute j'ai vu tourner XP sur un terminal avce meme pas 128 de RAM,
Avec que 128 Mo de ram pour un terminal ?
Citation :
Ce n'est pas un windows classique, il n'a pas toutes les fonctionnalités et son architecture est très fermée vu que normalement c'est destiné au marché de l'informatique embarquée et pas au marché du pc.
C'est exactement le contraire, il est beaucoup plus ouvert (c'est pas bien difficile, tu vas me dire). Tu peux pas faire un système embarqué qui ne soit pas un minimum ouvert.
Mais tu peux oublier pour la zik quand même: embarqué ici = RT (real time, temps réel), et entre autre... Les drivers doivent être totalement repensés. Par exemple, un système temps réel "dur" doit assurer qu'un truc prendra pas plus qu'un certain temps donné. Sur windows, aucune garantie que ton truc va pas prendre 10 ans au lieu d'une seconde. Le temps de latence entre une interruption et sa gestion est pas prévisible, je crois, sous windows, alors qu'il l'est sur XP embedded.
Bref, c'est comme pour linux: t'es baisé, si tu prends l'option RT, ça veut dire de nouveaux drivers. C'est là que QNX peut être intéressant...
Yannou le Jacky
Citation : Mais tu peux oublier pour la zik quand même: embarqué ici = RT (real time, temps réel), et entre autre... Les drivers doivent être totalement repensés. Par exemple, un système temps réel "dur" doit assurer qu'un truc prendra pas plus qu'un certain temps donné. Sur windows, aucune garantie que ton truc va pas prendre 10 ans au lieu d'une seconde. Le temps de latence entre une interruption et sa gestion est pas prévisible, je crois, sous windows, alors qu'il l'est sur XP embedded.
Euh j'ai pas bien saisi la mais bon ...
Citation : Bref, c'est comme pour linux: t'es baisé, si tu prends l'option RT, ça veut dire de nouveaux drivers.
La c'est plus clair
Bon je ferai un essai quand meme. Je me ferait une image et on vera bien si ca tourne. Sinon tant pis, ca sera la solution XP pro + XP lite.
Jacky repenti. SeuRn
Anonyme
Citation : meme pas 128 de RAM
c'est ce que j'appelle une perle.
Yannou le Jacky
Pov Gabou
Citation :
Euh j'ai pas bien saisi la mais bon ...
T'as fait de l'info, si je ne m'abuse ?
En temps normal, chaque processus tournant sous l'OS est divisé en slices ( ça s'appelle des giffies sous linux, je crois, je suis plus sûr), et le scheduler, qui est la partie de l'OS chargé de dire quel processus fait quoi quand, décide à chaque fin de slice quel processus il va lancer.
Maintenant, comment marche un soft qui par exemple utilise la carte son (relativment courant en MAO ;) ) ? La carte son a des buffers internes, en hard, de qqs samples. Par exemple, les RME ont deux buffers de 64 samples (plus sûr du nombre de buffers, mais la taille des buffers est exacte, je crois). Le son rentre dans la carte son, et quand le buffer est rempli, la carte son envoit une interruption (sur un certain IRQ, ie une certaine route de requêtes d'interuption, c'est à ce niveau que les IRQ interviennent, les fameux IRQ modis du PC) au CPU, et alors l'OS dit "STOP, je sauvegarde le processus courant, qui s'arrête tout de suite, je traite la fonction que me demande d'exécuter l'IRQ, puis après, dès que c'est fini, je reviens en temps normal". Ben entre l'envoi de l'interruption et le traitement de l'interruption, le temps de traitement n'est pas assuré sous windows. Tu "espères" que ça va bien se passer, ça se passe souvent bien, d'autant mieux que ton PC est puissant, entre autre, mais ça marche pas toujours (et donc crack, entre autre).
Sous un truc RT dit temps réel "dur", ben ce temps doit être constant, prédictible. L'OS a la notion d'échéance: t'as pas le choix, dans X temps, tu DOIS avoir fini ça, sinon, c'est mal, très mal. Imagine que le temps entre l'appui sur le frein et la gestion de l'ABS ne soit pas constante, et que des fois ça foire, et tu comprendras le problème, je pense. Ie pour un train d'atterissage sur un avion de ligne, etc...
Cette notion de temps réel dut est tellement fondamental que ça demande des caractéristiques très particulières sur les OS, et donc sur les drivers, qui doivent souvent être repensés.
Citation :
Software causes of latency
A switch from Windows XP to RTSS happens on an interrupt, either from the RTX high-speed clock or from another device generating RTX interrupts. Therefore, achieving RTX ISR determinism requires reducing Windows XP interrupt latency. Let us examine the sources of Windows XP platform ISR latencies without RTX present.
The most significant latency is IRQ masking by the Windows XP kernel and drivers, routinely done for periods up to several milliseconds through Windows XP KeRaise/LowerIrql calls. The Windows XP kernel, HAL, and certain special drivers also perform processor-level masking of all interrupts through x86 STI/CLI instructions, for periods of up to several microseconds.
Windows XP and RTX interrupt processing naturally, masks interrupts, thereby adding to ISR latency. Although Windows XP relies very heavily on interrupts in many situations (for example, raising software exceptions or unwinding a thread's stack), the Windows XP interrupt sequence is reasonably compact in its contribution to the worst-case ISR latency.
Hardware causes of ISR latency
The most obvious hardware-related problem is cache dirtying and flushing by applications and the operating system. This category also includes refilling of the TLBs. Video drivers are particularly aggressive users of caches, causing contention-related flushes when an RTX interrupts starts running. Histograms of ISR behavior in the presence of cache-dirtying applications would typically have a double-hump profile, with most samples near the best-case band, and another large number of samples in the flushing-related band (see Figure 3).
Power management, especially on portable devices, creates occasional long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. A typical system can disable those features through basic input/output system (BIOS) setup.
Some systems, again typically notebooks, use the Pentium processor's System Management Mode (SMM) to perform specialized keystroke or other processing in BIOS firmware. While in SMM, the processor does not field interrupts that adds to ISR latencies.
Fortunately, new generations of system platforms, starting with Advanced Configuration and Power Interface (ACPI) platforms and Windows 2000, use the operating system and not BIOS to provide power management. As a result, these sources of latency are now minimal.
Bus mastering events can cause long-latency CPU stalls. Such cases include high-performance DMA small computer system interface (SCSI) devices, causing CPU stalls for periods of many microseconds, or video cards that insert wait cycles on the bus in response to a CPU access. Sometimes the behavior of such peripherals can be controlled from the driver, trading off throughput for lower latency.
Although no operating system can protect an application against such hardware factors, RTX offers tools to diagnose platform-related latencies, and to identify the misbehaving peripherals. Being mindful of such factors and using RTX tools to qualify one's development platform are essential for a system's overall performance.
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/xpehelp/html/startpage.asp?frame=true
Stx4Sound
Pov Gabou
http://sic.epfl.ch/SA/publications/FI02/fi-9-2/9-2-page9ag.html
SUr linux et temps réel.
Et un OS temps réel célèbre:
http://www.qnx.com (version d'évaluation totalement utilisable gratuite).
Stx4Sound
En particulier sur declenchement d'irQ. ca te garantie un temps de reveil pire cas.
mais c'est vraiment sur des syteme critique.
pas besoin en zicmu
Bordel c'est le weekend on parle pas boulot
- < Liste des sujets
- Charte