PATHpilotのブログ

GUIの表示を定期的に更新したくなるのはリアルタイムデータ処理では避けられない（と思う）。

GUI表示自体はTKinterで容易にできるようだけれど、それを定期的に更新する方法を調べて実装してみた。背景にあるのは、Pico+TWELITEによって定期的に取得する超音波距離センサー・データをGUI表示するためだ。

ここで使うのはTKinterが提供するafterメソッドだ。afterメソッドは、このメソッドコール後に実行するFunctionと、その実行までの待機時間をパラメータとして指定する。このFunctionとして、このafterメソッドを実行するFunction自体を指定すると再帰的なコールが実行される。つまり、指定した待機時間後のそのFunctionが繰り返し実行されるようになるわけだ。このFunctionにてGUIを描画すれば、定期ていなGUIアップデータ実現する。

class GUI(tk.Frame):

   def update(self):

      # GUIを描画するコード

      self.after(100,self.update)　＃ 100ms後に自分自身を実行する。結果的にループ化する


if __name__ == "__main__":
   gui = tk.Tk()
   app = GUI(master = gui)
   app.update()  # updateをコールして再帰的コールをキックする
   app.mainloop()　# 以後のイベント処理はmainloop内で実行される

ネット上に公開されている先人の知恵に学びながら作成した参考コードは以下からダウンロードできる。

ダウンロード - tktest04.py

また具体的な工作内容はこちらから参照できる。

aftetrメソッドを上手く使えばいろいろな事ができそうだ。

rshellでPicoをUSBで接続するにあたって/dev/ttyACM0を指定した。

そもそもACMってなんだろうってことで調べたので備忘録。

USB CDC ACM、Universal Serial Bus　Communication Device Class　Abstruct Control Modelの頭文字だということらしい。

このデバイスはLinux上では /dev/ttyACM* として認識されるとのこと。つまり、PicoはCDC ACMデバイスとして認識されたということだ。そこでlsusbを実行してみた。

pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 2e8a:0005
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

この中にPicoらしきものがない。とりあえず2e8a:0005をメモ。現在Raspberry PiのUSBにはデバイスが2つ（LogitechのUSBアダプターとPico）が接続されている。

そこでdmesgでカーネル出力メッセージをみてみた。

pi@raspberrypi:~ $ dmesg
....
[ 1.813769] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 1.996373] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21
[ 1.996394] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.996412] usb 1-1: Product: USB2.0 Hub
[ 1.998223] hub 1-1:1.0: USB hub found
[ 1.998538] hub 1-1:1.0: 4 ports detected
[ 2.323746] usb 1-1.1: new full-speed USB device number 3 using xhci_hcd
[ 2.463994] usb 1-1.1: New USB device found, idVendor=046d, idProduct=c534, bcdDevice=29.01
[ 2.464014] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.464032] usb 1-1.1: Product: USB Receiver
[ 2.464048] usb 1-1.1: Manufacturer: Logitech
[ 2.476766] input: Logitech USB Receiver as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C534.0001/input/input0

....

[ 2.723762] usb 1-1.3: new full-speed USB device number 4 using xhci_hcd
[ 2.861186] usb 1-1.3: New USB device found, idVendor=2e8a, idProduct=0005, bcdDevice= 1.00
[ 2.861207] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.861225] usb 1-1.3: Product: Board in FS mode
[ 2.861242] usb 1-1.3: Manufacturer: MicroPython
[ 2.861258] usb 1-1.3: SerialNumber: 000000000000

[ 6.833920] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

USB Bus 1-1.1にLogtech、1-1.3にPicoが検出された記録が残っている。そして1-1.3はUSB ACM Deviceと認識されてttyACM0でマウントされている。LogtechはMouseとKeyboardがその先に繋がっていて、ACM Deviceとしては認識されていない（実際コミュニケーションデバイスではないし）。

lsusbの出力でメモした2e8a:0005はUSB deviceとしてのpicoのVendor IDとProduct IDだったようだ。なのでBus 001 Device 005はpicoと判明した。

1-1.1とか1-1.3とかはUSBのソケット番号に対応するらしい。実際、LogtechのUSBアダプタを直下のソケットに移したらdmesgに以下が記録された。

[ 3602.399066] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd
[ 3602.539296] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c534, bcdDevice=29.01
[ 3602.539317] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3602.539335] usb 1-1.2: Product: USB Receiver
[ 3602.539353] usb 1-1.2: Manufacturer: Logitech

いろいろと奥が深い。

PicoもTWELITEも電池2本で動かすことができる。

Picoは内部にスイッチング電源（Switched Mode Power Supply:SMPS) を持っている。VSYS(39ピン)に入力された電圧をSMPSで3.3Vにして内部供給している。したがってVSYSに入力する電圧に関わらず、GPIOは3.3Vだ。

一方、TWELITE DIPはVCCが2.0から3.6Vとなっている。SMPSを内部に持っていないから（多分）、VCC電圧でGPIOを駆動することになる。これはPicoとTWELITEを接続する場合に考慮しないといけない点だと思う。

乾電池2本で3Vとして、この電圧をTWELITEのVCCに与えると、PicoとTWELITEのインターフェース間で電位差が生じるわけだ。でもこのことをPicoはちゃんと考えていて内部のSMPSで生成した3.3Vを外部にも供給できるように3V3(36ピン)を備えている。これをTWELITEのVCCに接続すればインターフェース間の電位差が生じない。

まとめると、電池のプラスラインはPicoのVSYSに接続。TWELITEのVCCはPicoの3V3に接続する。

この状態で動かしている様子が以下の写真になる。

ここではPicoで以下のコードをmain.pyとして実行している。

import machine
import utime

led = machine.Pin(25, machine.Pin.OUT)

uart = machine.UART(1,115200)

while True:
      led.toggle()
      utime.sleep(1)

      uart.write("Hello World")

1秒おきにオンボードLEDの点灯消滅を繰り返し、その切替の度にTWELITEにUARTで”Hello World”と書き込む。TWELITEはそれをブロードキャストする。こんな具合だ。

これで写真のセットの電池ボックスのスイッチを入れると即座にその動作を始める。

これはおもしろい！！

PicoでMicroPythonを使っている時、このプログラムをPicoのパワーオンで自動実行したくなるのは人情。

調べた結果、以下が分かった。

main.pyというファイル

Pico Python SDKガイドには以下が書かれている。

If you "save a file to the device" and give it the special name main.py, then MicroPython starts running that script as
soon as power is supplied to Raspberry Pi Pico in the future.

つまり、今Thonny上で作ったコードをmain.pyでPico上に保存すると次回のパワーオンの時にそのプログラムが自動実行されるわけだ。早速試した。ファイル保存の時にpy拡張子が自動で付くかとともってファイル名をmainで保存したら拡張子が付かなかった。なのでファイルはmain.pyで保存しなおして、USBケーブルを抜き差ししたら確かに自動で保存したPythonプログラムが起動した。これはいい。

でも、さっき間違えて保存したファイル削除や、さらに自動起動を停止したい場合のファイル名変更はどうしたらいいんだ？？？

BOOTSELボタンを押してFlash Drive ModeでPicoを立ち上げてもそんなファイルは見えない。。。。

この手の処理はSDKガイドにも書かれていない。困った、、、でグーグルしてみたらこのブログが見つかった。救われた。 rshellで/pyboardディレクトリを見に行けばいいのだ。
こういった事は考えて分かることではないのでmain.pyを紹介するのであれば、その取扱いについても公式ガイドでちゃんと記載しほしいのもだ。

rshellでファイル管理

ガイドを見ると以下でrshellをインストールせよとある。
$ sudo apt install python3-pip
$ sudo pip3 install rshell

python3-pipは既にインストール済みだったので、rshellのみインストール実行となった。で、rshellの実行。救ってくれたブログでは -pで具体的に指定するポートが書かれていなかったが、こちらはSDKガイドの記載をそのまま使ってみた。

pi@raspberrypi:~ $ rshell --buffer-size=512 -p /dev/ttyACM0
Using buffer-size of 512
Connecting to /dev/ttyACM0 (buffer-size 512)...
Trying to connect to REPL connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /Hello_World.py/ /main.py/ /main/
Setting time ... Feb 20, 2021 12:40:22
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 1970
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/pi> ls /pyboard
Hello_World.py main.py main　    <<- 拡張子なしでmainを保存したので消したい。
/home/pi> rm /pyboard/main
/home/pi> ls /pyboard
Hello_World.py main.py
/home/pi>

rshellが立ち上がってlsを実行してもpyboradというディレクトリは見えなかったが ls /pyboard はThonny IDEで保存したファイルを表示した。で、rmを実行。

Thonnyを立ち上げてPico上のファイルを見たらmainが無くなっていた。これでmain.pyも消すことができる。

これで自由度がぐっと広がった。しかし、情報を集めるのに時間がかかる。。。。

そもそもrshellって。。。

そもそもrshellってなんだろう。Githubに記載があった。MicroPython用のRemote Shellなんだね。ESPってなんの頭文字か分からないけれど、Picoのようなマイコンボードを意味するらしい。そこでは/pyboardがデフォルトのようだ。これは知ってないと、考えて分かることではないね。

Remote MicroPython shell.

This is a simple shell which runs on the host and uses MicroPython's raw-REPL to send python snippets to the pyboard in order to get filesystem information, and to copy files to and from MicroPython's filesystem.

It also has the ability to invoke the regular REPL, so rshell can be used as a terminal emulator as well.

Note: With rshell you can disable USB Mass Storage and still copy files into and out of your pyboard.

When using the commands, the /flash directory, and the /sdcard directory (if an sdcard is inserted) are considered to be on the pyboard, and all other directories are considered to be on the host. For an ESP based board you can only reference its directory by using the board name e.g. /pyboard etc..

おまけにrshellではREPLが実行できる。replの終了はctl+X

/home/pi> repl
Entering REPL. Use Control-X to exit.
>
MicroPython v1.14 on 2021-02-05; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>>
>>> print("this is test")
this is test
>>>
>>>
/home/pi>

これを使うかどうかは分からないけれども、いろいろと機能があることがわかった。

Raspberry Pi Picoに超音波距離センサーHC-SR04を接続したい。

しかし、Picoは3.3VだけれどHC-SR04は5Vだ。すっぴんのままHC-SR04の出力をPicoに接続するとPicoを壊してしまう可能性がある。そこでTXS0108Eの利用を考えてみた。これはレベルシフト電圧トラスレータチップだ。Low VoltageとHigh Voltageを双方向で変換してくれる。つまり、例えばHigh 3.3V信号をHigh 5Vに、またはこの逆に変換してくれるわけだ。で、早速使ってみた。

購入したのはHiGetgoの5個入りパック。半完成品状態となっている。

ピンヘッダを半田付けして完成。

このレベルシフターをHC-SR04とPicoの間にいれた。PicoのGPIO出力とHC-SR04のTrigger入力、HC-SR04のEcho出力とPicoのGPIO入力の間にいれたわけ。

まず、全然信号が出てこなくて、OEが内部プルアップされていると思ったんだけれど、結局そうでなくて、OEを5V（HC-SR04のVCC）に10KΩでプルアップして出力がでるようになった。

で、変換なんだけれども、デジタルオシロがないので電圧レベルまではわからないけれども、このレベルシフターに電源供給すると回路全体に回路全体に大きなノイズが乗るようで、信号に変なディップが発生した。HC-SR04もバタバタしてしまって、単なるノイズというレベルではなかった。

結局利用をあきらめた。

PicoのGPIO出力は3.3VのままHC-SR04のTriggerに接続した。シグナルマージンはめちゃ少なくなるけれども、とりあえずTriggerはできているよう。ただ、時々Echo出力が変になる（妙に長い値になる）ので、あんまり上手くないのかもしれない（変な出力の原因は究明してない）。問題のHC-SR04の5V出力をPicoの入力につなぐにあたっては抵抗分割を使った。HC-SR04の信号を2.2KΩで受けて、それを3.3KΩで接地する。2.2KΩと3.3KΩの接合点をPicoのGPIO入力につないだ。これでほぼ3Vの電圧になると同時にHC-SR04から過大な電流が流れ込む事を防ぐことができる。

今のところ動いている。

Thonny IDEでのUI Mode切替について備忘録。

Thonny IDEの初期状態（インストール後の状態では）UIはSimple Modeに設定されている。メニューバーは表示されていなくて、画面右上にSwitch to regular modeがクリック可能となっている。

ここをクリックしてThonny IDEを立ち上げなおすとメニューバーが表示さえるRegular Modeになる。

UIを再びSimple Modeに戻したければ、Tools -> Options -> UI Modeを変更すればよい。

InterpreterのリストにPicoが無かったので、Raspberry Piの更新とパッケージのアップグレードを実施。

$ sudo apt update
$ sudo apt upgrade -y

全体で1.6GBくらい消費したようだけれど、とりあえずフレッシュスタートということで。
MicroPython (Raspberry Pi Pico) を選択。

昨日はRaspberry Pi上に開発環境を作った。

これはこれでCOOLなんだけれど、Raspberry PiはGPIOをつないで色々と動かすので、そこに開発環境があるのはリスクが大きすぎる。ちょっと配線を間違えるとRaspberry Pi自体が昇天してしまう危険がある。デバッグはRaspberry Piで行うとしても開発環境はデバッグ環境とは別に用意したい。

そこでWindows PC上にC/C++ Raspberry Pi Pico開発環境を作ることにした。ガイドはRaspberry PiのWebサイトにある資料。

手順は以下の通り。

ARM gcc complierのインストール：gcc-arm-none-eabi-...を選択しインストールする。インストール最後でAdd path to environment variableにチェックを入れること（デフォルトではここにチェックが入っていない）。他はチェックが入っているのでそのまま。

CMakeのインストール：とりあえず32bit版をインストールした。理由はARM gcc compilerが32bit版しかなかったから、それに揃えている。途中でそういうチェックがあったかはっきり覚えていないけれど、pathはall usersに適用するように設定すること。

Build Tool for Visual Studio 2019のインストール：ここはちょっとわかりにくかった。

まず以下のメニューからVisual Studio 2019のツールを選ぶ。

このツールの中からBuild Toolsをダウンロードする。

ダウンロードしたインストーラを実行してC++ Build Toolsを選択しインストールする（詳しくはガイド参照）。

Python 3.Xのインストール：Python3.8じゃダメなのかな？とりあえず（たまたま）既にPython 3.7.3がインストールされていたのでこのままなんだけれど。

Gitのインストール：ここでも32bit版を選んでインストールした。ガイドにはDefault Editorとしてvimを使うな、とある。とりあえずVisual Studio Codeに設定した。他にも以下のように、いろいろと設定ガイドが書かれているの要注意。
allow Git to be used from third-party tools
以下にチェックを入れること。
"Checkout as is, commit as-is",
"Use Windows' default console window"
"Enable experimental support for pseudo consoles" 

以下を実行してサンプルコード等をダウンロードする。\work\picoってフォルダーを作ってそこにダウンロード・展開した。
C:\work\pico> git clone -b master https://github.com/raspberrypi/pico-sdk.git
C:\work\pico> cd pico-sdk
C:\work\pico\pico-sdk> git submodule update --init
C:\work\pico\\pico-sdk> cd ..
C:\work\pico> git clone -b master https://github.com/raspberrypi/pico-examples.git

この後Windowsメニューから以下を選択して、Developer Command Promptウインドウを開く。
Visual Studio 2019 > Developer Command Prompt for VS 2019

C:\work\pico\> setx PICO_SDK_PATH "..\..\pico-sdk"

この設定を有効化するためにDeveloper Command Promptウインドウを開きなおす。で、以下を実行するとダダ―とBuildが始まる。
C:\work\pico> cd pico-examples
C:\work\pico\pico-examples> mkdir build
C:\work\pico\pico-examples> cd build
C:\work\pico\pico-examples\build> cmake -G "NMake Makefiles" ..
C:\work\pico\pico-examples\build> nmake

結構時間がかかるけれども、これでelfファイルが作られた。

Visual Studio Codeの構成

基本的にガイド通りだけれど、一点分かりにくいところはProject構成のところ。
pico-examplesフォルダーを選択したあとProject構成をするよう問い合わせポップアップが表示されるとあるけれども、これが表示されなかった。で、Raspberry PiでのVSC構成と同様に、画面下のブルーラインのCMake [Debug] 準備完了をクリックするとコンパイラー選択リストが表示されるので GCC for none eabi ..を選択した。次に表示される画面でDebugを選択するとProjectの構成が始まり、無事（多分）終了した。

Raspberry Pi Picoの開発環境設定の記録。

ここではRaspberry Pi 4に開発環境を作っている。参考資料はこちらのRaspberry PiのWebページ。

環境構築用Scriptをダウンロードする。

$ wget https://raw.githubusercontent.com/raspberrypi/pico-setup/master/pico_setup.sh

$ chmod +x pico_setup.sh

$ ./pico_setup.sh

このスクリプトは結構な仕事をしてくれるので作業時間が長い。気長に待つべし。

完了後にリブートすることでUARTの構成を有効化する。
$ sudo reboot

これでコマンドラインでのビルドが出来る環境が揃ったことになる。

Visual Studio Codeのインストールと設定

以下からVSCのARM版（32ビット版）をダウンロードする。
https://code.visualstudio.com/Download
ダウンロードしたdebファイルアイコンをダブルクリックするとインストールが完了する。
コマンドラインでのインストールは以下を実行すればよい。
dpkg -i <downloaded file name.deb>

以下を実行するようガイドがあるけれども、実際にインストールしてみたらこれらは既にインストール済みだった。
code --install-extension marus25.cortex-debug
code --install-extension ms-vscode.cmake-tools
code --install-extension ms-vscode.cpptools

次に以下の設定をするようガイドがあるけれども、これも既に設定済みだった。echo $PICO_SDK_PATHで確認の事。
$ export PICO_SDK_PATH=/home/pi/pico/pico-sdk

以上でVSCのインストールは完了で、コマンドラインから以下を実行するとVSCが立ち上がる。
$ code
アプリケーションメニュー => プログラミング　からでも起動できる。

VSCが立ち上がったらFileメニューからOpen Folderを選んで pico-samplesフォルダーを選択する。

画面下のブルーのラインで「Kitが選択されていません」といった感じのステータスが出ているので、それをクリックするとSelect Kitのメニューが表示されるので arm-none-eabi 7.3.1 を選択する。

同じく画面の下のブルーのラインに[Build]と[all]が表示される。[all]をクリックするとpico-samplesフォルダー内の全てがビルドされる。ちょっと時間がかかるけれども実行。

同じく画面下のブルーのラインのCMake [Debug]をクリックするとDebugやReleaseが選択できる。Debugを選択するとSWD Debuggingができる。SWD:Single Wire Debug

Debug Toolのインストール

minicom

シリアルターミナルのインストール。特にminicomをインストールした記憶はないけれど最新版2.7.1-1がインストール済みだった。多分pico_setup.shがインストールしたんだと思う。

$ sudo apt install minicom

これは以下の使い方をする。
$ minicom -b 115200 -o -D /dev/ttyACM0
このシリアルデバイスはUSBシリアル。

OpenOCD

SWD（Single Wire Debug）を行うためのツール。こちらもインストール済みだった。

GDB

これを使えばARMコードの逆アセンブルとかできる。これとOpenOCDを使うことでARMバイナリーコードのDebugがUART経由で外部から実行可能になるわけだ。こちらもインストール済みだった。

まとめると、pico_setup.shさえ実行すれば環境はすべて整うということになる。

昨日悩んでいた事の一つがUARTのBaud Rate設定。

インタラクティブモードのSet UART Baudが38400になっているのでてっきりそうだと思っていたことが混乱の元だった。実際Raspberry Pi側のBaud Rateは115200に設定していて、これで通信が成立していたので？？？だった。今日、改めてモノワイヤレスのホームページを見ていると以下の記述があった。

BPS（Pin-20）でBaud Rateが設定できて、オープン状態（O）だと115200とある。G、つまりGNDに接続すると38400とある。今は無接続なので115200なわけだ。ちなみにインタラクティブモードで設定するのはGの時のBaud Rateのようだ。これで謎が一つ解けた。

もう一つ悩んだのがApp_Uartでシリアル通信モードになっているTWELITE DIPからのパケットはMONOSTICKは受信できるけれど、その逆方向でMONOSTICKから送ったパケットがTWELITEのUARTのTXに出力されないこと。理解が正しいのか分からないけれども、これは出来ないとの結論に落ち着いている。

そもそもシリアル通信モードで送信されるパケットには宛先もコマンドも含まれていない（ブロードキャスト）。例えばシリアル通信モードのTWELITEから送信されるパケットはこんな感じになっている。

:03002020202020203734333768

最初の03が送信元のDevice ID、その次が送信シーケンス番号で任意の値。ここではディフォルトの00が設定されている。それ以降はUARTに書き込んだ文字列で最後がチェックサムになっている。MONO STICKには出荷時のApp_Wingsが親機として機能している。これをシリアル通信モードのApp_Uartに置き換えれば通信するのかもしれない。でも、それをしたいわけではなくて、一般的な親機に対して複数のシリアル通信モードのTWELITEからシリアル通信モードパケットを送りたいだけなので、MONOSTICKのAppを書き換えることまではしなくていいのかなっておもった次第。

真偽はわかってないけれど、次のステップに進むにあたってはここまで確認できればいいのかなって思っている。

Raspberry Pi 4とTWELITEを会話させようとして一日終わってしまった。

Raspberry Pi 4 と TWELITEの接続は至って単純で4本繋ぐだけ。

しかし、これを通信させるのには一苦労した。おまけに理由は分からないけれどTWELITEを一つ殉職させてしまった。

分からなかったのはRaspberry PiのGPIOのUARTに信号を出力する方法。あと、TWELITEのアプリのApp_Uartが送出する信号フォーマット。

まず、Raspberry PiのSerialポート機能を有効化する方法は幾つかの書き込みがあった。それは以下コマンドを実行すること。

$ sudo raspi-config

ここで表示される画面で 5. Interfacing Optionsを選ぶ。

次に P6 Serial を選ぶ。 

ここでは＜いいえ＞を選ぶ。＜はい＞を選ぶとLinuxのコンソールアウトプットが怒涛の如くこのシリアルポートに流れてくる。

結果的に以下の組み合わせ（login shellは禁止でSerialをイネーブルにする）に設定する。
 

ここからが分からなかった。どのポートにどのボーレートでデータを書き込むのか。
採用したのは以下のファイルの記述。これは上のraspi-configでlogin shellの利用で＜はい＞を選んだ場合にcmdline.txtに書かれる内容。ここではconsole=serial0, 115200 と書かれている。login shellで＜はい＞を選ぶと、GPIOのUARTに怒涛の如くコンソール出力が書かれて、それをTWELITEは送り続ける。この様子はMONOSTICKをTeraTermで観察しているとわかる。つまり、serial0を115200でオープンすればよいわけだ。

で、以下のコードをRaspberry Piで動かしてみた

import serial

s = serial.Serial("/dev/serial0", 115200)
bs = '112233445566778899\n\r'
s.write(bs.encode())

結果はビンゴで、MONOSTICK側のTeraTermに以下が出力された。

:0300313132323333343435353636373738383939000043

Byte0はTWELITE DIPのDevice ID
Byte1は不明（親機のMONOSTICKのDevice ID＝０だから宛先か？）
一番後ろはチェックサム
その前の2バイトの0000は不明

いずれにせよRaspberry PiのUART出力をTWELITEで送信することが出来た。

なお親機側は以下のコードで文字列化された16進数データをアスキー文字列に変換している。

import serial

s = serial.Serial("COM6", 115200, timeout=1)

try:
　　while True:
　　　　line = s.readline()
　　　　line = line.decode('utf-8')
　　　　if len(line):
　　　　　　print("%s" % line)
　　　　　　rdata = [line[i:i+2] for i in range(5,len(line)-6,2)]
　　　　　　for x in rdata:
　　　　　　　　n = int(x, 16)
　　　　　　　　print(chr(int(n)),end='')
　　　　　　print('\n')

except KeyboardInterrupt:
　　pass

s.close()

明日ははMONOSTICK側からTWELITE経由でRaspberry Piにコマンドを送ろう。

構築中の別のブログに対してGoogle Adsenseから「駄目よー」と返事が来た。

Googleで調べてみると、「オリジナリティの欠如」が審査落選の一番大きな理由らしい。

そもそも、今も自分がGoogleで検索して「ここを見てみようかな」って思うのは、そこには他のサイトにないユニーク（有用性の高い）情報が掲載されていると思うから。Google AdSenseは、そのようなサイトにターゲットを絞って許可を出しているらしい。まぁ、自分が誰かのサイトに頼るけれど、自分のサイトは誰にも頼られないってのは流石にマズイわけだな。

SEOについて「重点キーワード」ってのが文字通りのキーワードだって書いているサイトがあるけれども、この重点キーワードにオリジナリティ臭を付けないといけないわけだな。

素人の自分がこの審査を自動化するのであれば、まずは単純に重点キーワードらしきキーワードを抽出して、そのキーワードでGoogle検索かけて、同様の重点キーワードが設定されているサイト数がある程度以上あれば、それでボツってのを作るかも。

これは企画を再構築しないとダメだ。