taskDelay のパラメーターは int 型であることに注意してください。これは、数値が負になる可能性があることを意味します。負の数を渡すときに関数がどのように反応するのか疑問に思っています。
4 に答える
ほとんどの関数は入力を検証し、早期に返す/0 を返す/問題のパラメーターをデフォルト値に設定するだけです。
本番環境でこれを行う必要はないと思います。おそらく、テストできるコードがいくつかあるはずです....試してみませんか?
ドキュメントはそれに対処しておらず、定義されている唯一のエラーコードはこのケースをカバーしていません。したがって、最も正しい答えは、結果が定義されていないということです。
ただし、この gemについてはVxWorks / Tornado II FAQを参照してください。
taskDelay(-1) は、vxWorks タイマー/ティック コードの別のバグを示しています。vxTicks をゼロに設定するという (副作用) 効果があります。これにより、ローカルタイム (およびおそらく他のもの) が破損します。実際、vxTicks + x >= 0x100000000 の場合、taskDelay(x) は同じ効果があります。システム クロック レートが 100Hz の場合、これは約 500 日後に発生します (vxTicks がラップするため)。より速いクロック レートでは、より早く発生します。数年間のアップタイムを試している人はいますか?
ああ、クロックレートには文書化されていない上限があります。4294 を超えるレートでは、select() は「usec」時間を正しいティック数に変換できません。(差出人: David Laight、dsl@tadpole.co.uk)
このバグが古いものであると仮定すると、エラーを返すか、タスクを準備完了キューの最後に置く taskDelay(0) と同じことを行うことを願っています。