A noté que le paramètre de taskDelay est de type int, ce qui signifie que le nombre pourrait être négatif. Je me demandais comment la fonction va réagir quand on passe un nombre négatif.Si vous passez un nombre négatif à la fonction taskDelay dans vxworks, que se passe-t-il?
La plupart des fonctions permettraient de valider l'entrée, et de retourner simplement le début/retour 0/définir le paramètre en question à une valeur par défaut.
Je présume qu'il n'y a aucun besoin critique de faire cela en production, et vous avez probablement du code qui traîne que vous pourriez tester avec .... pourquoi ne pas essayer?
La documentation ne l'aborde pas, et les seuls codes d'erreur qu'ils définissent ne couvrent pas ce cas. La réponse la plus correcte est donc que les résultats ne sont pas définis.
Voir la VxWorks/Tornado II FAQ pour ce petit bijou, cependant:
taskDelay (-1) montre un autre bogue dans VxWorks minuterie/tick code. Il a l'effet (latéral) de la définition de vxTicks à zéro. Cela corrompt l'heure locale (et probablement d'autres choses). En fait taskDelay (x) aura le même effet si vxTicks + x> = 0x100000000. Si le taux d'horloge système est de 100Hz, ce se produit après environ 500 jours (car vxTicks s'enroule). À des taux d'horloge plus rapides cela arrivera plus tôt. Quelqu'un essayant depuis plusieurs années de disponibilité?
Oh il existe une limite supérieure non documentée sur la fréquence d'horloge. Au taux ci-dessus 4294 select() échouera à convertir son heure 'usec' dans le nombre correct de ticks. (De: David Laight, [email protected])
À supposer que ce bug est vieux, j'espère qu'il soit renvoyaient une erreur ou faire la même chose que taskDelay (0), qui met votre tâche à la fin de la file d'attente prête.
Tornado 2 est .... Vieux. Très vieux. – mjs