SSブログ

nucleoじゃないけどmbedでサーモグラフィを作った話。

この記事はmbed Advent Calendar 2016
http://www.adventar.org/calendars/1661
の23日目の記事です。

といいつつまだ書きあがっていないので、随時更新します。
とりあえずリンク張りです。すいません。

トランジスタ技術2016年12月号で「プリント基板の温度分布,インフルエンザ,畑荒らし,
すみずみまで丸見え -273 ~+300℃! Piカメラ・サーモグラフィ」という記事を書きました。

http://toragi.cqpub.co.jp/Portals/0/backnumber/2016/12/p096.pdf


この記事ではRaspberry Piを使用しましたが、元々はmbedを使ったものを製作していました。

というわけで陽の目を見なかったmbed版サーモグラフィの記事です。

(後ほど更新予定。12/24夜を想定しています。)

--------


すいません結局年を越してしまいました。

元旦の夜にほろ酔い加減で書いています。
(誤字脱字あったらすいません)

さて、サーモグラフィーの話です。

トラ技の記事にも書きましたが、キーデバイスはLeptonというFLIR社の発売しているカメラになります。詳細は記事を参考していただくとして、ここではmbedの観点での記事を書きます。

LeptonはPure Engineerling社がリファレンスデザインを公開しています。

http://www.pureengineering.com/projects/lepton
https://github.com/groupgets/LeptonModule

この中でmbed系ではnucleo F401でのコードが公開されています。

https://github.com/groupgets/LeptonModule/tree/master/software/stm32nucleo_401re

このコードはSPI通信でカメラデータを受信して、フレームバッファに格納後、シリアル経由でPCに転送を行い、PC上で画像表示する、というものでした。

とりあえず、手持ちのNucleoがあったので繋いで動かすと、あっさり動きました。
ちなみにPC側もThermalViewというソフトが公開されているのですがMinGW環境が前提になっており
一度環境構築してみたのですが、ビルドできずに。結局バイナリをそのまま使っています。
(VisualStuioでビルドした後述の921kbpsサポートアプリもあるのですが、これは諸般の事情で公開できません)

で、終了! といいたいところなのですが、画像を見ると明らかに遅い。フレームレートも遅いし、レイテンシもあります。1fps位で数秒遅れて出る感じです。で、これではいかんということで、高速化を検討しました。

実際のNucleoのソースを見てみると、シリアルは115.2kで動かしており、帯域が足りないところはフレームを捨てていました。

Leptonの画素数は80 x 60で1画素辺り2bitなので1画面あたり9.6Kbyteです。フレームレートが9fpsなので帯域として780kbpsくらい必要になります。そこでmbedのシリアルを使うのを止めて、FT232Xを追加して、921kbpsで使うようにしました。mbedでもギリギリ動く速度です。実際のデータが84%くらいの転送率なので、まあマージン16%くらいなのでいっかー、と思ったらいろいろ障害がありました。

●SPI問題
最初はSPI問題です。このLeptonって奴は出力はSPIなのですが、カメラは9fpsまでしかうごかないのに、SPI側が3倍の27fpsで動くのです。つまり同じデータが3回出てきます。余計です。そのまま送ると無駄なので、SPIで読んだ時点でデータを間引いて1/3にしました。
しかも、転送タイミングがホスト側で分からない仕組みになっています。どういうことかというと、同期信号の類が一切出力されていません。そのくせ仕様書には「正確に27fpsで読んでね、遅くても速くてもエラーになるよ」とちょっとイラっとする表記があり、結局のところ、ちょっと早めに突っ込んで読んで、データが空読み気味にするのがいいという結果になりました。ちなみにSPIはbyte単位の転送ですが、1ラインあたりのデータが160byteなので、リファレンスコードではループで回してましたが、実はベタに書いたほうが速いということが分かって、シリアルをFT232Hを使ったパラレル転送に変えた高速版(本稿では言及しません)ではSPI転送命令を160行ベタ書きに変更しましたw。

●シリアル問題
シリアルは前述の通り、921kbpsで動かしていますが、最初全然速度が出ていませんでした。不思議に思っていたのですが、考えてみればSPI転送中はシリアル転送できないジャン、という単純な理由に気がつきました。シリアルはDMA転送できるみたいなのですが、いろいろ試してみたけど上手く動きませんでした、しょうがないので、SPIのタイミングの隙間にシリアル転送するようにして上手く辻褄をあわせるようにしました。結果的にフレームレートは6.3fpsまで上げることが出来ましたが、これ以上はシリアルDMA転送が出来ないと無理な感じです。

というわけでまあそこそこ動くようになりましたが、PC側のThermalViewは115.2kまでしかサポートされておらず、実際には公開できない専用アプリとの組み合わせで動かすことになっています。そこでオリジナルのThermalViewを使う115k.2k版作りました。単純にSPIとシリアルの転送タイミングを変更したものになります。フレームレートは遅く1fps以下かと思います(測っていない)。

というわけで上手く動作するようになったのですが、皆様ご存知の通り、Nucleoは大きいですw、諸事情で小型のケースに組み込む必要があり、また9.6KBのフレームバッファを確保できるということで、LPC1768で動くように変更しています。(単純に、ピンアサインとポートを変えただけですが)

と、ここまでが一昨年(2015年)あたりにやっていた話で、去年(2016年)はFT232Hを使ったパラレル転送に変更して、とある人に使ってもらったり、Raspberry Piで動かして、記事を書いたりとかをしていました。

実は記事には書いていませんが、Raspberry Pi版では原因不明のプチフリ現象が発生するので、CPUパワーにモノを言わせる、富豪プログラミングがメリットだよん、なんで記事に書いていますが、実用上はmbed版の方が使いやすいのかもしれません。電源ONですぐ起動ですし。

現状では使い勝手が悪いので、Raspberry Piで付けた小型LCDをmbed版に付けようと思っていて、付けたら記事を書こうと思っていたら、時が経ってしまったので、まずは現状の話を書かしていただいて、mbed Advent Calenderとしては〆たいと思います。

LCD追加版はこの正月休みに作ろうと思いますので、後日別稿にて公開します。

図面とか写真とか無くてつまんない記事ですいません。(元旦なので許して~)

以上、お粗末でした。

nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。

トラックバック 0

Maker Faire Tokyo 20..久しぶりのblog更新 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。