Bonjour à tous,
Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un
qui est confronté au problème de pouvoir dialoguer avec le port série et de
pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau
de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il
voudrait être sûr que ça va bien marcher. Avant de penser au driver, je
voudrais vos retours d'expérience sur le passage en priorité max du thread
user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps
de l'émission / réception ?
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous, Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un qui est confronté au problème de pouvoir dialoguer avec le port série et de pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il voudrait être sûr que ça va bien marcher. Avant de penser au driver, je voudrais vos retours d'expérience sur le passage en priorité max du thread user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps de l'émission / réception ? Si j'ai bien compris c'est surtout la réception son problème, car pour marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de caractère mais tout simplement un temps de non émission de l'ordre de 2ms. Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de détecter ces 10ms pour identifier que c'est 2 trames et non une seule... Et sinon au niveau driver vous avez une idée sur ce que ça représente comme travail ? Merci pour votre aide.
Bonjour à tous, un petit post, non pas pour apporter un quelconque élément de réponse, mais plutôt pour questionner aussi sur le sujet. Aller, enfin ma question : comment les applications MIDI (cubase par exemple) contournent l'abscence de temps réel de Windows ? Il semble bien que la chaine complète - depuis l'interface graphique jusqu'au flux MIDI - ait un temps de réponse garanti !? Mercis Pierre
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous,
Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un
qui est confronté au problème de pouvoir dialoguer avec le port série et de
pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau
de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il
voudrait être sûr que ça va bien marcher. Avant de penser au driver, je
voudrais vos retours d'expérience sur le passage en priorité max du thread
user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps
de l'émission / réception ?
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Bonjour à tous,
un petit post, non pas pour apporter un quelconque élément de réponse,
mais plutôt pour questionner aussi sur le sujet.
Aller, enfin ma question :
comment les applications MIDI (cubase par exemple) contournent
l'abscence de temps réel de Windows ?
Il semble bien que la chaine complète - depuis l'interface graphique
jusqu'au flux MIDI - ait un temps de réponse garanti !?
Mercis
Pierre
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous, Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un qui est confronté au problème de pouvoir dialoguer avec le port série et de pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il voudrait être sûr que ça va bien marcher. Avant de penser au driver, je voudrais vos retours d'expérience sur le passage en priorité max du thread user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps de l'émission / réception ? Si j'ai bien compris c'est surtout la réception son problème, car pour marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de caractère mais tout simplement un temps de non émission de l'ordre de 2ms. Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de détecter ces 10ms pour identifier que c'est 2 trames et non une seule... Et sinon au niveau driver vous avez une idée sur ce que ça représente comme travail ? Merci pour votre aide.
Bonjour à tous, un petit post, non pas pour apporter un quelconque élément de réponse, mais plutôt pour questionner aussi sur le sujet. Aller, enfin ma question : comment les applications MIDI (cubase par exemple) contournent l'abscence de temps réel de Windows ? Il semble bien que la chaine complète - depuis l'interface graphique jusqu'au flux MIDI - ait un temps de réponse garanti !? Mercis Pierre
Pierre Maurette
Pierre Hericourt a écrit:
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous, Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un qui est confronté au problème de pouvoir dialoguer avec le port série et de pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il voudrait être sûr que ça va bien marcher. Avant de penser au driver, je voudrais vos retours d'expérience sur le passage en priorité max du thread user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps de l'émission / réception ? Si j'ai bien compris c'est surtout la réception son problème, car pour marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de caractère mais tout simplement un temps de non émission de l'ordre de 2ms. Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de détecter ces 10ms pour identifier que c'est 2 trames et non une seule... Et sinon au niveau driver vous avez une idée sur ce que ça représente comme travail ? Merci pour votre aide.
Bonjour à tous, un petit post, non pas pour apporter un quelconque élément de réponse, mais plutôt pour questionner aussi sur le sujet. Aller, enfin ma question : comment les applications MIDI (cubase par exemple) contournent l'abscence de temps réel de Windows ? Il semble bien que la chaine complète - depuis l'interface graphique jusqu'au flux MIDI - ait un temps de réponse garanti !?
La question se pose également pour les WAV. (Suppositions) Parce que MIDI est supporté à bas niveau par Windows. Il n'est donc même pas nécessaire d'écrire entièrement les pilotes (ce qui serait également possible). Heureusement, Windows a accès au niveau kernel au hard plus ou moins en tant réel. Mais surtout parce que le hard fait une partie importante du boulot, comme pour les WAV. Le standard MIDI est le MPU-401, qui était le nom de cartes MIDI Roland au départ. D'ailleurs, bien bien bien avant XP, même sous DOS, le PC n'est devenu crédible en MIDI face à Mac et ATARI que grâce à cette carte, qui était plus qu'une simple interface à 6850. Les musiciens ont longtemps reproché au PC de ne pas respecter le click. -- Pierre
Pierre Hericourt <pierre.hericourt@wanadoo.fr> a écrit:
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous,
Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un
qui est confronté au problème de pouvoir dialoguer avec le port série et de
pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau
de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il
voudrait être sûr que ça va bien marcher. Avant de penser au driver, je
voudrais vos retours d'expérience sur le passage en priorité max du thread
user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps
de l'émission / réception ?
Si j'ai bien compris c'est surtout la réception son problème, car pour
marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de
caractère mais tout simplement un temps de non émission de l'ordre de 2ms.
Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de
détecter ces 10ms pour identifier que c'est 2 trames et non une seule...
Et sinon au niveau driver vous avez une idée sur ce que ça représente comme
travail ?
Merci pour votre aide.
Bonjour à tous,
un petit post, non pas pour apporter un quelconque élément de réponse,
mais plutôt pour questionner aussi sur le sujet.
Aller, enfin ma question :
comment les applications MIDI (cubase par exemple) contournent
l'abscence de temps réel de Windows ?
Il semble bien que la chaine complète - depuis l'interface graphique
jusqu'au flux MIDI - ait un temps de réponse garanti !?
La question se pose également pour les WAV.
(Suppositions) Parce que MIDI est supporté à bas niveau par Windows.
Il n'est donc même pas nécessaire d'écrire entièrement les pilotes (ce
qui serait également possible). Heureusement, Windows a accès au
niveau kernel au hard plus ou moins en tant réel.
Mais surtout parce que le hard fait une partie importante du boulot,
comme pour les WAV. Le standard MIDI est le MPU-401, qui était le nom
de cartes MIDI Roland au départ.
D'ailleurs, bien bien bien avant XP, même sous DOS, le PC n'est devenu
crédible en MIDI face à Mac et ATARI que grâce à cette carte, qui
était plus qu'une simple interface à 6850. Les musiciens ont longtemps
reproché au PC de ne pas respecter le click.
--
Pierre
Dans son message précédent, Aurélien REGAT-BARREL a écrit :
Bonjour à tous, Alors je sais que Windows n'est pas temps réel, mais je connais quelqu'un qui est confronté au problème de pouvoir dialoguer avec le port série et de pouvoir chronométrer le temps écoulé depuis la dernière reception au niveau de la ms, voire un peu moins. Il a fait un petit soft qui marchouille, il voudrait être sûr que ça va bien marcher. Avant de penser au driver, je voudrais vos retours d'expérience sur le passage en priorité max du thread user. Est-ce assez fiable pour pouvoir être assuré d'avoir la main le temps de l'émission / réception ? Si j'ai bien compris c'est surtout la réception son problème, car pour marquer la fin d'une trame dans le protocole qu'il utilise il n'y a pas de caractère mais tout simplement un temps de non émission de l'ordre de 2ms. Ainsi il peut recevoir 2 trames espacées de 10ms, et il faut êter capable de détecter ces 10ms pour identifier que c'est 2 trames et non une seule... Et sinon au niveau driver vous avez une idée sur ce que ça représente comme travail ? Merci pour votre aide.
Bonjour à tous, un petit post, non pas pour apporter un quelconque élément de réponse, mais plutôt pour questionner aussi sur le sujet. Aller, enfin ma question : comment les applications MIDI (cubase par exemple) contournent l'abscence de temps réel de Windows ? Il semble bien que la chaine complète - depuis l'interface graphique jusqu'au flux MIDI - ait un temps de réponse garanti !?
La question se pose également pour les WAV. (Suppositions) Parce que MIDI est supporté à bas niveau par Windows. Il n'est donc même pas nécessaire d'écrire entièrement les pilotes (ce qui serait également possible). Heureusement, Windows a accès au niveau kernel au hard plus ou moins en tant réel. Mais surtout parce que le hard fait une partie importante du boulot, comme pour les WAV. Le standard MIDI est le MPU-401, qui était le nom de cartes MIDI Roland au départ. D'ailleurs, bien bien bien avant XP, même sous DOS, le PC n'est devenu crédible en MIDI face à Mac et ATARI que grâce à cette carte, qui était plus qu'une simple interface à 6850. Les musiciens ont longtemps reproché au PC de ne pas respecter le click. -- Pierre
Aurélien REGAT-BARREL
> Sans avoir étudié les détails de votre problème, je vous propose une solution qui me paraît d'autant plus réaliste que votre employeur/donneur d'ordre fait dans le hard. Vous faites un dongle intermédiaire sur le port série en câblé/PLA ou avec un PIC bas de gamme (faut quand même deux ports série), et vous discutez en asynchrone avec ce dongle, par exemple avec des structures temps/donnée. PIC pour PIC, vous pouvez certainement lui déléguer un peu plus, comme l'envoi et la réception complets d'une trame, avec gestion des han dshakes et des répétitions. Le coût de revient d'un tel truc hors développement est peut-être de l'ordre de 10 à 20 euros.
Ok merci pour ces suggestions. Je vais lui dire de tester quand même de passer en priorité hight. Sous NT4 on arrivait pratiquement à freezer l'ordi (c'était plus rapide de faire reset que d'attendre taskmgr + kill), alors bon pendant 1 seconde ça devrait suffire. Ma question sur les drivers était surtout pour ma culture générale ;-) Sinon ben solution hardware, mais vu que c'est un tres bon electronicien, je vais le laisser se débrouiller. Merci à tous.
-- Aurélien REGAT-BARREL
> Sans avoir étudié les détails de votre problème, je vous propose une
solution qui me paraît d'autant plus réaliste que votre
employeur/donneur d'ordre fait dans le hard. Vous faites un dongle
intermédiaire sur le port série en câblé/PLA ou avec un PIC bas de
gamme (faut quand même deux ports série), et vous discutez en
asynchrone avec ce dongle, par exemple avec des structures
temps/donnée. PIC pour PIC, vous pouvez certainement lui déléguer un
peu plus, comme l'envoi et la réception complets d'une trame, avec
gestion des han dshakes et des répétitions.
Le coût de revient d'un tel truc hors développement est peut-être de
l'ordre de 10 à 20 euros.
Ok merci pour ces suggestions.
Je vais lui dire de tester quand même de passer en priorité hight. Sous NT4
on arrivait pratiquement à freezer l'ordi (c'était plus rapide de faire
reset que d'attendre taskmgr + kill), alors bon pendant 1 seconde ça devrait
suffire. Ma question sur les drivers était surtout pour ma culture générale
;-)
Sinon ben solution hardware, mais vu que c'est un tres bon electronicien, je
vais le laisser se débrouiller.
Merci à tous.
> Sans avoir étudié les détails de votre problème, je vous propose une solution qui me paraît d'autant plus réaliste que votre employeur/donneur d'ordre fait dans le hard. Vous faites un dongle intermédiaire sur le port série en câblé/PLA ou avec un PIC bas de gamme (faut quand même deux ports série), et vous discutez en asynchrone avec ce dongle, par exemple avec des structures temps/donnée. PIC pour PIC, vous pouvez certainement lui déléguer un peu plus, comme l'envoi et la réception complets d'une trame, avec gestion des han dshakes et des répétitions. Le coût de revient d'un tel truc hors développement est peut-être de l'ordre de 10 à 20 euros.
Ok merci pour ces suggestions. Je vais lui dire de tester quand même de passer en priorité hight. Sous NT4 on arrivait pratiquement à freezer l'ordi (c'était plus rapide de faire reset que d'attendre taskmgr + kill), alors bon pendant 1 seconde ça devrait suffire. Ma question sur les drivers était surtout pour ma culture générale ;-) Sinon ben solution hardware, mais vu que c'est un tres bon electronicien, je vais le laisser se débrouiller. Merci à tous.
