Replyドローンをいじっていると色々とパーツが増えてきます。SBUS出力の受信機もそうなのですが、ふと思い立って固定翼の飛行機に普通のサーボを積もうと思うとPWM出力の受信機がないのです。そこでSBUSからPWMに変換する基板を作ってみました。シリアルポートが複数あってデバッグし易いArduinoMEGAを引っ張り出してきます。SBUSの受信は何度もやっているのでソースをコピペし、沢山定義したサーボ出力に値を渡せばファームは出来上がりです。その後ArduinoUNOに移しても問題なく動作しました。私が作る飛行機は大抵スチレンペーパー製の小型のものなので基板もなるべく小型がよいです。そこで最近はリフロー炉も稼働した事だし、中華格安メーカーに表面実装の基板を発注しました。マイコンには0.5mmピッチQFNパッケージ(リードがないやつ)のATmega328MUを使います。約500円の格安基板シルクデータを含めるのを忘れていました。0.5mmピッチのところソルダーレジストが載っていません。一瞬基板メーカーにヤラれたか?と思いましたが仕様を見るとレジスト幅は最小0.4mmという仕様でした。0.5mmピッチでリード幅もあり、どう考えてもレジスト幅は0.4mmには収まりませんよね。いえばフライトコントローラーを作った時、わざわざレジスト幅が細かいメーカーを選んだのでした(でもそのメーカーは面付けすると価格が上がるのです)。マイコン周りのソルダーレジストが崩れているとりあえず比較的上手くレジストが載っている基板を選んで(120枚もあるので中には上手くいっているのもあるのです)部品を実装しました。ArduinoUNOを使ってブートローダーを書き、FT232RLを使ってファームウェアを書きます。ブートローダー書き込み中。奥に見えているフリスクケースがFT232RLピンヘッダを付けて完成!12chまで出せます。6chまでは3pinのピンヘッダで、残り6chは信号だけ出しています。例によって1か所ミスっておりジャンパーで補修しています。(どこかわかります?)息子が製作していた機体に積んで飛ばしてもらいました。問題なく飛んでいます。高校生の息子が作った機体。キット化して小遣いを稼ぐ野望を抱いている様です。reply前回ArduinoUNOを使った書き込み機で、PIC18F14K50のコンフィグビット0x30002番地に0x01を書いたのに読出したら0x21になってしまう件を書きました。違いはbit5が0か1かで、このbitはデバイス上で何にも割り当てられず、データーシートによると割り当てが無いbitは0として読み出される筈なのに1が出てきているという謎でした。因みにHID版ブートローダーをビルドするとこの番地は0x01ですがMCHPUSB版ブートローダーでは0x21になっています。この違いがなぜあるのか、特にMCHPUSB版をビルドすると割り当てのないbitがなぜ立つのかは気になりますが、これについてはその内調べたいと思います。その前に今回はArduinoに載せたスケッチがバグっているのか、またはPICKit3が何か細工をしているのかを確かめたくて波形を見てみました。いってもわが家のオシロスコープは古くてこの出力をピンポイントで見るのは困難です。そこであるところからAnalogDiscovery2を借りてきました。AnalogDiscovery2そしてまずArduinoUNOで0x30002番地を読み出す瞬間の波形がこれ。上段の波形がクロックでこの下りエッジで下段のデータを読み取ります。データはLSB側から出てくるので左右反転すると00100001=0x21と読めます。デバイスから0x21が出ているんですね。Arduinoで読み取る瞬間(0x21と出ている)次にPICKit3で読み出す瞬間も見てみます。こちらはクロックがだいぶ早いですがやはり同じ様に0x21が出ています。PICKit3で読み取る瞬間(こちらも0x21と出ている)・・・という事でArduinoに書いたスケッチでもPICKit3でも波形的には’0x21’が出ています。PICKit3の画面には’0x01’と表示されているのは恐らく使用していないbitを無条件に0として表示しているのだと思います。Arduino用スケッチはどういう対策するのが正しいのでしょう?使っていないbitなので書き込んだのと違う値が読めるのは当然と考えれば「ベリファイからこのbitは除外」が正解なのかな。読み出して表示する時には「読んだ通りに表示」しないと紛らわしい気がします。表示する値とベリファイする値が異なるのは気持ち悪いけど「ベリファイ時は未使用bitを除外し、表示の際は読んだ通りに表示」かな。いうか、そもそも未使用bitなのであまり深く考える必要もないか・・・。ReplyPIC18F14K50にArduino+9V電池方式でHIDブートローダを書込んでみたらベリファイでエラーが出ました。コンフィグビット0x30002番地に0x01を書いたのに読出したら0x21になっています。40PICKit3で読むと0x01ですがArduinoだと0x21になるのです。違いはbit5が0か1かですが、このbitはデバイス上で何にも割り当てられていません。PIC18F14K50のデーターシートによると割り当てが無い番地は0として読める事になっているのでPICkit3の結果が正しくArduinoの結果が間違いです。Arduinoのスケッチを見ていますが特に問題なさそうに見えます。この番地のこのbit以外は問題が発生していないのも納得がいきません。因みにデバイスを交換しても変化なしでした。書込み自体はできており問題なく動作はするのですが・・・謎です。UNOを使ってブートローダーを書き込みました。その際以前書いた「ArduinoでPICマイコンに書込む~OpenStickLite(PIC18F14K50)編~」とは若干変更する必要がありました。ブートローダーだけでなくHOI-Linkのファーム全体を書いてみました。Arduinoに入れる書込み用スケッチにミスっていた箇所があったので修正版を掲載しています。DIPパッケージ単体では¥220ですが発振子やUSBコネクタも買う事を考えると基板もそんなに割高ではありません。以前DIP版のPIC18F14K50にArduinoからブートローダーを書き込んだのと同様にこの基板にも書込んでみました。前回DIPパッケージ版と今回のAE-PIC18F14K50とで異なるところ前回の回路図はこれ。この時マイコンのVDDにはArduinoから3.3Vを供給し、VUSB端子もVDDに直結していました。ArduinoUNOでPIC18F14K50に書き込んでみた回路図。AE_PIC18F14K50基板はVUSB端子が外部に出ていません。VUSBはチップ内にレギュレータを持っていて3.3Vが出力されるのでVDDに少し高い電圧(まあ5Vですよね)を入れてやればVUSBには外から印加する必要はありません。PICkit3でもそうなっていますしね。いう事で次の様な回路で上手くいきました。上と違うのは電源を5Vに変えたのとVUSBには接続していない事。VUSB端子はGNDとの間にコンデンサを接続する必要がありますがAE-PIC18F14K50は基板内に0.22μFを内蔵しています。AE-PIC18F14K50基板に書き込む配線ブートローダーだけでなくファームウェア本体も書いてみる。といつもはブートローダーだけを書き込み、そのブートローダーから本体のファームウェアを書き込んでいました。今回ちょっと試しにブートローダー+HOI-Linkのファーム全体を書き込んでみます。その前に書き込みデータを作ります。PICkit3を接続してファーム書込み済のマイコンからプログラムを読み出し、HEXファイルに書きだしました。このファイルにはフラッシュに書かれたプログラムとコンフィグデータ以外にEEPROMの内容も含んでいます。Arduino上の書込みスケッチをEEPROMには対応させていないのでテキストエディタでEEPROMに関する行を消しておきます。出来たのがこのファイル→HOI-LinkAndBootloader.zip解凍すると次のHEXファイルが出てきます。HOI-LinkAndBootloader.hexこれをメモ帳で開いてTeratermにコピペする事でAE-PIC18F14K50に書き込みます。このあたりの手順は前回の記事に書いています。ファーム全体を書き込むと1分程度で何事もなく終わりました。因みにブートローダーだけだと約10秒です。Arduinoのメモリーに保存できないのでシリアル通信でPCから順次送りながら書き込んでいる為です。この時PCとArduinoの間でフロー制御できればよいのですが、Arduinoの素の状態ではこれが出来ないので送り込み速度の方を落としているのです。続いてベリファイをしてみると・・・なんだかエラーが出ます。調べてみるとArduino上の書込みスケッチのベリファイルーチンでチェックサムの計算をミスっていたので、これを修正するとベリファイもエラー無く終了しました。書込みルーチンでもチェックサムを計算していますがこちらは正常です。書き込みとベリファイは殆ど同じ処理なので上手くサブルーチンで共有すればいいのに面倒になってコピペで作成した為、デバッグの時にベリファイ側の修正を忘れていた様です。秋月電子のAE-PIC18F14K50基板に専用PICライタを使わずファームを書き込めるようになりました(Arduinoは必要ですけど)。直接ファームを書いても良し、ブートローダーを書いてUSB経由でファームを送り込むのも良しでお手軽にUSB工作が楽しめます。replyやっぱり二代目3Dプリンターにラズパイを取付けました。初代RaspberryPiのModelBです。ラズパイにモニターやキーボードは取付けていませんが、Xwindowの画面をメインPCに飛ばしPronterfaceを実行できます。TeratermでログインしてPronsoleを使う事も。フロントパネルにはラズパイ専用の電源スイッチとシャットダウンボタンを設置したのでLCDコントローラだけで動作させる場合にはラズパイ電源はOFFにできます。手持ちのスイッチを取付け。対策をしなければラズパイ専用電源をOFFにしてもArduinoからの電圧でラズパイのLEDが点いてしまいます。正常動作する程の力はない様ですがArduino側のレギュレータに負荷が掛かりそうです。気持ち悪いのでUSBコネクタの+5V端子にカプトンテープを貼って絶縁するという、いい加減な対策をしました。USBコネクタの+5V端子を絶縁。これで3Dプリンタ2号機は一旦完成とします(多分まだ何かやりますが)。admin.どどーんはじめました。Replies今回のマルチコプターでS.BUSを初めて使ったので信号をArduinoで読み出してみました。S.BUSとは何かという詳しい説明はコチラ→https://ja.wikipedia.org/wiki/S.BUS要はラジコン受信機から昔ながらのサーボ信号を出すのではなくシリアル通信にする事で全チャンネルを1本の信号線で制御するという物です。飛行機の場合はサーボの位置が分散しているので結局それぞれに配線する必要があり、あまりメリットを感じませんでした。マルチコプターでは受信機の信号は全てフライトコントローラ基板に接続するのでこれが一本で済むのは大きなメリットになります。S.BUS信号はシリアル通信ですが、UARTでよく使う仕様とは微妙に違うところがあり面倒になっています。次のところ・・・ボーレートが100Kbps。115.2Kbpsではなく100Kbpsです。妙なボーレートですがArduinoではSerialBegin()のとき100000と指定する事で対応できます。Arduinoに入れる信号はインバータで反転してやる必要があります(もしかするとArduino側に反転機能があるのかもしれませんが見つけられませんでした)。あと受信後のデータが11bit区切りなので並べ替えがややこしいです。S.BUSプロトコルに詳細はこちらを参考にしました。→https://os.mbed.com/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/→http://anarchy.hatenablog.com/entry/2014/12/07/181853そして最低限の部分をスケッチに書きます。MEGA2560で動かしてみます。MEGA2560でS.BUSをモニター。ブレッドボード上のICは信号極性反転のための74HC00。こんな感じでデータが出てきました。送信機が6CHなので7CH以降が正しいかどうかは確かめられていません。19番目のデータはFailsafeが働いたときに1になるはずですが、これも確かめていません。各データが11bitt幅なので0~2047が表せるはずで、どうやらニュートラルが1024の様です。ところでCleanflightにも受信データを表示する機能があります。今回のモニターとCleanflightの値が一致しません。そこで何ポイントか対応を取ってみました。Cleanflightの表示値は昔ながらのPWMサーボ信号のパルス幅に換算した値をμS単位で表示しているのだと思います。ニュートラルはS.BUSの生データは1024ですがPWMだと1520μSといった感じ。いうことでS.BUSの生の値にざっと0.625掛けて879.5を足すとほぼCleanFlightの値になる様です。feedWordPress.orgこちらも見てちょ~だい。