サーボはマイクロコントローラーではなく、サーボテスターに​​応答します。信号は同じに見えます

TowerPro MG90Dサーボ（Manufactuer Link）（ServoDatabase Link）を持っています。
範囲は180度です（非連続）。

それは私のサーボテスターに​​素晴らしく反応します：

テスターで次の7％デューティサイクル（約90度）を確認します。

サーボは正常に応答します。

ただし、servo.write()Arduino Mega 2560クローンを使用すると、サーボが角度出力に反応しません。同じピンの同じコードで問題なく動作する他のいくつかのサーボがあります。

Arduinoで次の7％デューティサイクルを観察しますservo.write(90)。

応答なし。サーボは「リンプ」です。それはいかなるポジションも保持していません。

私がこの質問を書いている間、私はしようと考えましたservo.writeMicroseconds()。

ここにありservo.writeMicroseconds(1450)ます：

サーボが反応！

これがservo.writeMicroseconds(1472)（working）で、これはprevoius non-working と同じ時間間隔servo.write(90)です！

servo.writeMicroseconds(1550) （ワーキング）：

違いはなんですか？
サーボテスターは49.5Hzで動作しましたが、49.9Hzでservo.write()失敗しました。どういうわけかその0.4Hzが違いを生んだのかと思ったのですが、それでも49.9Hzで動作することがservo.writeMicroseconds()わかります。

上記のスコープキャプチャでは、両方が同じ時間間隔servo.write(90)をservo.writeMicroseconds(1472)持っていることがわかります。
 1,474,560ns HIGH
18,544,640ns LOW

信号は非常に似ています... 動作しない原因servo.write()は何ですか？

私のコードは可能な限り基本的です：

#include <Servo.h>
Servo serv1;

void setup() {
  serv1.attach(3); // Pin 3
}

void loop() {
  serv1.write(90); // No response
  delay(3000);

  serv1.writeMicroseconds(1472); // Works
  delay(3000);

  serv1.write(0); // No response
  delay(3000);

  serv1.writeMicroseconds(1800); // Works
  delay(3000);
}

^{この回路のシミュレーション – CircuitLabを使用して作成された回路図}

まず、簡単な説明をしておきます。サーボの動作について少し誤解しているようです。サーボはPWMによって制御されず、49.whatHzでパルスを送信していることを知りません。彼らは、パルスが任意の期間のいくつかの割合であることを知りません。サーボは、パルス間の時間を気にすることができませんでした。あなたが実際には関係のないことに集中しているように見えるからです。

サーボは、特定の時間に電圧が高いか低いかを実際に認識したり、気にすることすらありません。気になるのは、立ち上がりエッジと立ち下がりエッジの間の時間だけです。

サーボは、電圧の立ち上がりエッジを検出し、立ち下がりエッジが発生するまでの時間を測定することによって制御されます。有効な時間は通常1.0〜2.0ミリ秒ですが、サーボごとに異なる場合があります。

1Hz、10Hz、50Hz、100Hzで制御できます。ほとんどはさらに高い脈拍数に反応しますが、これも変動します。私が言おうとしているのは、周波数、デューティサイクル、パルス間の持続時間など、すべて問題に関連しているわけではないということです。つまり、サーボは期待どおりに応答していません。

関連する唯一のものはあなたが何も注意を払っていないあなたの脈拍の端です。これを理解したい場合は、まず重要なことから見て、パルスエッジのキャプチャをクローズアップしてください。これらのスクリーンショットでは何も役に立たなかったので、おそらく問題や違いがないように見えます。あなたが測定したものでは決して見えない問題や違いがたくさんあります。

私が見ることができるのは、動作していないパルス列のキャプチャが、他のどのパルスよりも、パルスと地面の両方で著しく汚れていることです。他のものと同じ関数を呼び出す必要があるため、これは奇妙です。なぜそんなにうるさいのですか？

さらに重要なのは、非稼働キャプチャで「フォールタイム」を確認することです。809µs？オシロスコープは、立ち下がり時間が0.8ms続くと考えています。それは...悪い。明らかにそれは正しくありませんが、実際にはそれが測定されます。

それは汚いエッジの典型的な兆候です。それについて考えてください。このパルスがオシロスコープであるハイエンドのテスト機器をだまして、途方もなく長いエッジまたは立ち下がり時間を検出するか、または非常に汚れているため、常に立ち下がりエッジを正しく検出できない場合（または誰が知っているか）、そのかわいそうな小さな$ 8サーボがまともな立ち下がりエッジをピックアップする可能性はどのような可能性がありますか？

許容パルス範囲内でサーボが有効なパルスを取得しない場合（立ち下がりエッジに時間がかかりすぎる、ダーティである、または見落とされている場合など）、およびサーボがエッジを考慮しているため、パルスエッジをどのように考えるかで処理すると、オフであるかのように応答します。

つまり、移動しないだけでなく、シャフトの移動に抵抗しません。あなたが見ている通りに、それは単にリンプになります。

さて、これは疑問を投げかけます... なぜサーボを呼び出すとエッジ品質に影響を与えるのでしょうか？

あなたはクローンと言った。このように？

特にこれらのクローンは、信じられないほど貧弱なデカップリングのために不規則に振る舞う傾向があります。すべての電源ピンにデカップリングコンデンサを配置し、mega2560にできるだけ近づける必要があります。実際のarduinoには確かにあります。しかし、これらのクローンでは遠くにあるか、おそらく存在しないため、判別するのが困難です。ボードを見ると明らかなように、確実に動作しないことが重要です。

それでは違いは何ですか？

Servo.writeを呼び出すと、writeMicrosecondsを呼び出す場合よりもスタックが高くプッシュされます。mega2560の3バイトのスタックポインター（17ビット）を考えると、writemicrosecondsを呼び出すときに必要のない一連の重要なビットをフリップする必要があります。これはありそうにない違いのように思えますが、十分に分離されていないマイクロコントローラーの公平なシェアを経験しました。特に、タイマーを使用したり、スタックをプッシュまたはポップしたりすると、特にatmegasが奇妙な動作をするようです。PWMでLEDを駆動しようとしたときにスタックだけが壊れていましたが、スタックをプッシュせずにすべてをインラインに配置した場合、スタックは機能しました。最終的には、デカップリングが不十分でした。

貧弱なデカップリングが、そのatmega2560で知られている理由で、他の誰もそのパルスのエッジ品質に有害な影響を与えないことを十分に期待しますが、スタックを直前にプッシュしているときのみです。このサーボは、これらのエッジがサリされる方法を処理することができないため、その場合は有効なパルスがありません。他のサーボは明らかにそれを管理します。

デカップリングのものは常に奇妙で、このように非常に特殊です。これが、分離が非常に重要である理由です。悪夢のような地獄のような問題を抱え続けると、静電容量の不足が原因で、物理的に可能な限りチップに近い、すてきな脂肪セラミックキャップができなくなる可能性があります。

これは、.write（）ルーチンによって行われた出力ピン設定に関連している可能性があります。1Kプルダウン抵抗を使用してみてください。それは機能しません。それを削除して、プルアップ抵抗を使用してください。これにより、ルーチンによって設定される可能性のある内部の週のプルアップ/プルダウン抵抗の影響のバランスが取られます。スコープで信号を測定する場合、プローブの内部抵抗はプルダウンとして機能します。
信号が10パルス続けてプリセットされていない場合、ほとんどのサーボは内部モーターへの電力も解放します。これは、電力を節約するために使用されます。