デバイス作る人>>デバイス使う人>>デバイスおたく
前回、Jetson NanoのI2Cにセンサを接続してみたので、Jetson Nanoの40ピンヘッダ（ラズパイと互換性のあるGPIOピンヘッダ）にデフォルトで出ているインタフェースでテストしていないのはUARTだけとなりました。今回は、Jetson NanoのUARTの先に、USBシリアル変換モジュールを接続し、Jetson NanoとPCの間でシリアル通信を行ってみます。 “バリバリのSoCとSoM(3) Jetson NanoのUARTに接続” の続きを読む
昔の隔週刊だった頃の日経エレクトロニクス誌を知っている身としては、近年の月刊は分量が少ない気がいたします。それでも、ちょっと気を抜くと読んでいない日経エレ誌が積みあがってしまいます。というわけで積んであった山から2019年10月号をとりだしました。表紙を見て目が点。「温度差不要の熱発電も可能に」との記事。トンデモないものを見逃していた？
“Literature Watch Returns(10) 本当？「温度差不要の熱発電」日経エレ2019-10月号” の続きを読む
やはりちゃんとドキュメントを読めば、手も震えず（アル中か）、テキパキと自信をもって作業が進みます。前回、Jetson Nanoのデータシートを読んだお陰で、今回は、早速実践とI2Cバスの先にセンサを取り付けてみましたが、一発動作、ものの１０分もかかっていません（投稿するにはその何倍か時間かかりますが）
前投稿で、「接続する前にちゃんと調べようね」と反省（いつものことですが）をいたしました。そこで、今回は、NVIDIA社のJetson Nanoのデータシートとキャリア・ボードの参照回路図を読んでいこうと思います。大した分量じゃないにもかかわらず、後回しにしていた私が悪い。
“バリバリのSoCとSoM(1) NVIDIA Jetson Nano System-on-Module” の続きを読む
前回、Jetson Nano（正確に言えば Jetson Nano Developer Kit Carrier Board)にPIRセンサ（人感センサ）を接続しようとしたら、ラズパイのときより抵抗値の小さなプルアップにしないと動かない件を書かせていただきました。今回はその理由を調べたので記録しておきます。結局、モジュールとしてのJetson Nanoではなく、それを搭載しているCarrier Boardの回路が理由でしたんですが。 “トホホな疑問(19) Jetson Nano、GPIO入力つづき” の続きを読む
昨日、どこかのページに書いてあったラズパイのI2Cのデフォルトのクロック速度を鵜呑みにして、100kHzと書いてしまいました。しかし、アチこち見て回っているとそんなことはない、実際は
62.5kHz
とあります。どうも62.5kHzが正しそう。でも、折角なので、自分でもオシロを当てて測っておくかと。 “トホホな疑問(17) ラズパイ, I2Cの速度” の続きを読む
この間、ラズパイのI2Cの先にセンサを付けたりしていて思ったです。いわゆるマイコンのシリアルインタフェースにセンサなどを付けた場合、デバックしようとすると「結局、信号に聞くのが一番早道」だったりします。けれどもRaspberry Piのようなシステムの場合、i2ctoolsという便利なツールがあるので、それにお任せで済ませてしまう。でもね、ツールの出力も見れば疑問が湧いてくる。やはり一度、「信号に聞いて」おいた方が安心かも。
「第１３回」で Pythonのlxmlモジュールを使って、デフォルト名前空間が定義されたxmlファイルでXPath使うときはどしたら良いのかしら、と考え込みました。今日は今日とて、またlxmlモジュールで、xsdスキーマファイルが複数あるときに、どうやってバリデーションをばかけたらよかでしょうかとまたまた考え込んでしまいました。
「ラズパイに3角測量センサ接続」という話題で、何気にPythonの
smbus
というモジュールを使ってしまいました。理由は、PythonからI2Cを使うときに「よく使われているみたい」だったから。しかし、I2Cではなくsmbusです。遠い昔の朧げな記憶によれば、smbusは主にノートPC向けに始まった規格の筈。確かにI2Cベースだった気もしますが、そのあたり記憶もあやふや。それにsmbusモジュールのインタフェース関数が一体どのようなI2Cバス制御をしているのか実体が分からない。「簡易ロジアナ」で観察する元気もないし。。。
昨日は、ラズパイのI2Cにシャープ製測距センサGP2Y0E03をつなげて距離が測れている雰囲気が出て良かったね、で終わっていました。今日は「移植」したソフトウエアについて見ていきたいと思います。元は、MbedOSでcppで書いたのですが、今回はPythonであります。I2Cの制御には変わらないので、遠くからみたら「一緒」ですが、細かいところの書き方はちょっと「違う」のでした。
ようやくコンパイラにNEONのクワッドワードのレジスタを使うコードを吐き出してもらえるようになったので、わずかにハードルを上げてみたいと思います。当初から予定通りで、内積計算ですね。ベクトルの要素毎に単純な掛け算をしているのと比べると、それらの和をとっていかなければならないので、計算はちょっとだけ複雑。それに何と言っても結果はスカラー。コンパイラはどのように料理してくれるのでしょうか。
続けざまにぐだぐだです。前回、なんとかコンパイラがクワッドワード（１２８ビット）幅のレジスタを使ったNeon命令を吐き出すようになりましたが、何か思っていたより複雑なコードになっていました。もしやと思ってよく考えてみたら、それは私の書いたコードがイケないことに気付きました。それでもコンパイラ様は必死に注文にこたえるべく、コード生成をおこなってくれた結果、なにやら複雑なコードが生成されてしまったのでした。自分の書いたコードをコンパイラ様が素直に解釈できるようにちょいと直せば良かったのでした。それでようやく、クワッドワードかつシンプルなコードが出力されるようになりました。