2020年01月11日

Teraterm 16進数送信

前回紹介したUART I2CプロトコルブリッジをTeratermからマクロで制御する際に戸惑ったことがあったので紹介します。

Teratermには16進数で表示、送信する機能があります。ただ、この機能が少し厄介でうまく表示や送信できない制約があります。この制約を知らずになかなかUART I2Cプロトコルブリッジが意図して通りに動かなく試行錯誤してしまいました。


テスト0x00〜0xFFまでをUSBシリアルポートに送信し、ポートを結線してループバックで受信データを表示させます。送信する際のマクロは下記の通りです。

setdebug 2
mpause 500
send $00$01$02$03$04$05$06$07$08$09$0A$0B$0C$0D$0E$0F
send $10$11$12$13$14$15$16$17$18$19$1A$1B$1C$1D$1E$1F
send $20$21$22$23$24$25$26$27$28$29$2A$2B$2C$2D$2E$2F
send $30$31$32$33$34$35$36$37$38$39$3A$3B$3C$3D$3E$3F
send $40$41$42$43$44$45$46$47$48$49$4A$4B$4C$4D$4E$4F
send $50$51$52$53$54$55$56$57$58$59$5A$5B$5C$5D$5E$5F
send $60$61$62$63$64$65$66$67$68$69$6A$6B$6C$6D$6E$6F
send $70$71$72$73$74$75$76$77$78$79$7A$7B$7C$7D$7E$7F
send $80$81$82$83$84$85$86$87$88$89$8A$8B$8C$8D$8E$8F
send $90$91$92$93$94$95$96$97$98$99$9A$9B$9C$9D$9E$9F
send $A0$A1$A2$A3$A4$A5$A6$A7$A8$A9$AA$AB$AC$AD$AE$AF
send $B0$B1$B2$B3$B4$B5$B6$B7$B8$B9$BA$BB$BC$BD$BE$BF
send $C0$C1$C2$C3$C4$C5$C6$C7$C8$C9$CA$CB$CC$CD$CE$CF
send $D0$D1$D2$D3$D4$D5$D6$D7$D8$D9$DA$DB$DC$DD$DE$DF
send $E0$E1$E2$E3$E4$E5$E6$E7$E8$E9$EA$EB$EC$ED$EE$EF
send $F0$F1$F2$F3$F4$F5$F6$F7$F8$F9$FA$FB$FC$FD$FE$FF
mpause 100
setdebug 0
mpause 100


Teratermが日本語設定の場合は下記のように0x7F以降、意図しない送信データを含み、正しく表示もされません。

teraterm-1.jpg


Teratermが英語設定の場合は下記のように意図通りに動作しました。

teraterm-2.jpg

debug modeを有効かしている場合は言語を英語、デフォルトに設定することが必要です。

teraterm-3.jpg

0x7Fまでは正しく動作するため、制約に気づきづらく余計に試行錯誤してしまいました。
posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする

2019年11月09日

スリープ不具合調査 その2

対策しても、時々再発してしまうことがあったため、再度試行錯誤してみました。


普段はメインPCは電源を切らず、使わないときはスリープや休止で運用しています。使用しているPCのマザーボードはIntel i5-8400+ ASROCK製 H310M-ITX/acを使用しています。

High Definition Audio Controllerが原因と分かっていますが、以前、紹介した方法の「powercfg」コマンドでは完治しませんでした。


今回はドライバ側から原因を追ってみまいした。RealtechのオーディオドライバーをインストールするとRealtech Audio Cosoleを利用することができます。

「デバイス詳細設定」の項目から「フロントパネル」を「ヘッドフォン」に設定した上で、コネクタ設定「フロントパネルのジャックポップアップダイアログを無効にする」が「オフ」になっていたため、「オン」にして無効化しました。合わせて、「デバイスを差し込むとき、ジャック検出を有効にする」が「オン」になっていたため、「オフ」に設定しました。


realtech-audio.jpg

ジャック検出の無効化で様子を見てみるとスリープ状態に入らず、勝手に復帰する不具合はなくなりました。原因はジャック検出だったようです。一旦、様子をみてみたいと思います。

posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする

2019年09月07日

BMPフォーマット

組み込み機器向けのBMP(ビットマップ)の画像データを作成する際に便利なツールを紹介します。

WindowsのBMPの場合、24bitカラーが標準的です。24bitカラーでは組み込み機器の場合、データが少し重すぎます。そのため、組み込み機器16bitカラーBMPを使用することがあります。さらに低い8bitカラーでは色の表現力に欠けます。

MS Paintでは16bitBMPの保存ができないため、16bitカラーBMPを生成するために便利なツールを紹介します。


■Webサイト上で簡単に変換できるツール
組み込み向けのGUIライブラリを提供しているlittlevglの画像変換オンラインツールです。

16bitBMPの他に8bitBMPやC言語用の配列データ変換なども利用できます。
試しにデータ変換する場合にお勧めです。

littegl.jpg

■OSSの変換ツール
OSSの変換ツールではGIMPが便利です。16bit変換BMPに対応しています。変換したい画像を開いてから「名前をつけてエクスポート」で16bitBMPに変換できます。

なお、8bitBMPで保存したい場合は「画像」→「モード」→「インデックス」からカラーマップを8に変更してビットマップで保存すると変換できるようです。

gimp3.jpg


gimp2.jpg

「WindowsBMP」を選択して「エクスポート」をクリックします。


gimp.jpg

詳細選択画面が表示されるため、16bitBMPを選択します。今回はRGB565を選択しました。今度は変換した16bitBMPを「Digital Video Shield」を使って表示させてみたいと思います。
posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする

2019年07月27日

スリープ不具合調査

メインで使用しているPCが時々スリープから勝手に復帰してしまうことがあったため、調査してみました。

普段はメインPCは電源を切らず、使わないときはスリープや休止で運用しています。時々、スリープしたにも関わらず勝手に数秒後に復帰してスリープ状態に入らないことがある状況でした。使用しているPCのマザーボードはIntel i5-8400+ ASROCK製 H310M-ITX/acを使用しています。

スリープ状態に入らず、勝手に復帰する原因として多くは下記の原因が挙げられます。
・マウス、キーボードがスリープ解除可能デバイスになっている
・Windows Update、タスクスケジューラによる自動起動
・スリープ解除タイマーの許可が有効化されている

デバイスマネージャで各デバイスを確認するとスリープ解除可能デバイスのチェックは外れており、タスクスケジューラ等もイベント登録もない状況でした。また、電源オプションのスリープ解除タイマーは無効化されていました。

今回の原因はよくある原因ではなさそうなので少し調べてみました。


いつも通りスリープさせて、勝手にスリープから復帰する不具合を確認後、イベントビューアーのシステムを確認してみました。スリープ関連のイベントはPower-Troubleshooterとして登録されており、最新のイベントを確認すると原因が判明しました。

img2.jpg

High Definition Audio Controllerが原因と分かりました。

powercfg -requestsoverride DRIVER "デバイスドライバ名" SYSTEMのコマンドを使用して、指定のデバイスについてデバイス側でなく、電源管理の設定を優先にしました。

img1.jpg


上記のコマンド実行後にスリープ状態に安定して入るようになりました。Windowsのアップデートでデバイスドライバとの相性が出たようです。スリープに関係のないと思われがちなオーディオが原因でした。今度のアップデートでの改善に期待です。


posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする

2019年06月01日

Kibana日本語対応まもなく!

今回はElastic社が開発している可視化ツールKibanaの多言語対応化について紹介します。

Kibanaの言語は標準では英語のみ対応でした。
19年に入ってからElastic社から多言語対応の発表があり、日本語は7.1から対応と発表されました。
すでに19年5月下旬時点では7.1.1がリリースされていますが、日本語対応していません。

Githubのコミット状況をみると、19年5月下旬に日本語対応関連のコミットがあり、7.1.2か、7.2当たりで正式に日本語対応されそうです。


ちなみに日本語化する場合は
kibana.yml
の最終行にi18nの設定項目があり、コメントアウトを解除して設定します。

デフォルトは
i18n.locale: "en"
となっています。

中国語にする場合は
i18n.locale: "zh-CN"

日本語にする場合は
i18n.locale: "ja-JP"

設定変更後はkibana.ymlを反映させるためにkibanaの再起動が必要です。

19年6月上旬時点では中国語と英語のみの対応となっていますが、もうあと数週間以内には日本語対応されそうです。
日本語対応版のkibanaが待ち遠しいです。
posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする