RL78マイコン基板(RL78/G13)｜KurumiWriter V1.00(ソース公開版)のフラッシュ書き込み時間の改善
これまでの2つのエントリ(811, 819)でKurumiWriterとrl78flashでRL78マイコンの内蔵フラッシュメモリへの
書き込み時間を比較しましたが、両者に違いがあり過ぎるのがちょっと残念でしたので、KurumiWriterを改造
して書き込み時間をどの程度短縮出来るか試してみました。幸い、両者はMITライセンスでソースコードが公開
されていますので、両者を見比べつつ勘を頼りにKurumiWriterで以下の改造を行ってみました。
* 半2重で設計された通信プロトコルで受信スレッドを使う発想に違和感があったのでスレッド処理をやめた
* rl78flashがやっている非同期I/O読み出しを使わずに出来る受信タイムアウトの設定パラメータを拝借した
その結果、以下のように改善されました。(とは言え、ややタイムアウト時間が長かったので微調整が必要になり
そうですし、FT232RLの内蔵EEPROMを書き換える為のRun after COM openにチェックがあるとタイムアウト
するか意図的に調べている箇所を実行して不自然に暫く固まったりしますので、もうちょっとな感はあります。)
FT232RLのWindowsドライバのデフォルト設定
* KurumiWriter V1.00改造前 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 22sec
500,000bps → 20sec
1,000,000bps → 未サポート
* KurumiWriter V1.00改造後 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 8sec
500,000bps → 5sec
1,000,000bps → 未サポート
* rl78flash (rl78flash-0.5.2-mon80-20160914 -m 2 -b 通信ボーレート -a COM14 cotton_sketch.mot)
115,200bps → 16sec
500,000bps → 11sec
1,000,000bps → 11sec
以前のエントリでRL78/G10への書き込み時間が短くなることに気付いてから私が常用している設定
* KurumiWriter V1.00改造前 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 40sec
500,000bps → 36sec (+/-2sec程度のバラツキあり)
1,000,000bps → 未サポート
* KurumiWriter V1.00改造後 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 7sec
500,000bps → 3sec
1,000,000bps → 未サポート
* rl78flash (rl78flash-0.5.2-mon80-20160914 -m 2 -b 通信ボーレート -a COM14 cotton_sketch.mot)
115,200bps → 10sec
500,000bps → 4sec
1,000,000bps → 4sec
なお、改造したソースファイルとKurumiWriter_Win.exeを以下の7zファイルに固めておきました。
ファイル: KurumiWriter_Win_V100_Modify.7z
内容:
KurumiWriter_Win_V100_MON80_20160923.exe
KurumiWriter.vcxproj
SequenceProcessor.cpp
SequenceProcessor.h
SerialPortProcessor.cpp
SerialPortProcessor.h
ちなみに、ソースファイルの改造箇所の一例は以下の通りです。
ファイル: SequenceProcessor.cpp
改造内容(抜粋): 赤字の箇所を改造
追記 : メモ
Windows Communication API - MSDN
COMMTIMEOUTS structure
https://msdn.microsoft.com/library/aa363190.aspx
SetCommTimouts
https://msdn.microsoft.com/library/cc429719.aspx
追記 : メモ
KURUMI Writer for Win V1.00 Source - Rulz
http://japan.renesasrulz.com/gr_user_forum_japanese/m/mediagallery/119.aspx
追記 : メモ
Tool to program RL78 MCUs via serial bootloader - GitHub
master
https://github.com/msalau/rl78flash/
releases
https://github.com/msalau/rl78flash/releases/
v0.5.2
https://github.com/msalau/rl78flash/tree/v0.5.2/
書き込み時間を比較しましたが、両者に違いがあり過ぎるのがちょっと残念でしたので、KurumiWriterを改造
して書き込み時間をどの程度短縮出来るか試してみました。幸い、両者はMITライセンスでソースコードが公開
されていますので、両者を見比べつつ勘を頼りにKurumiWriterで以下の改造を行ってみました。
* 半2重で設計された通信プロトコルで受信スレッドを使う発想に違和感があったのでスレッド処理をやめた
* rl78flashがやっている非同期I/O読み出しを使わずに出来る受信タイムアウトの設定パラメータを拝借した
その結果、以下のように改善されました。(とは言え、ややタイムアウト時間が長かったので微調整が必要になり
そうですし、FT232RLの内蔵EEPROMを書き換える為のRun after COM openにチェックがあるとタイムアウト
するか意図的に調べている箇所を実行して不自然に暫く固まったりしますので、もうちょっとな感はあります。)
FT232RLのWindowsドライバのデフォルト設定
* KurumiWriter V1.00改造前 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 22sec
500,000bps → 20sec
1,000,000bps → 未サポート
* KurumiWriter V1.00改造後 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 8sec
500,000bps → 5sec
1,000,000bps → 未サポート
* rl78flash (rl78flash-0.5.2-mon80-20160914 -m 2 -b 通信ボーレート -a COM14 cotton_sketch.mot)
115,200bps → 16sec
500,000bps → 11sec
1,000,000bps → 11sec
以前のエントリでRL78/G10への書き込み時間が短くなることに気付いてから私が常用している設定
* KurumiWriter V1.00改造前 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 40sec
500,000bps → 36sec (+/-2sec程度のバラツキあり)
1,000,000bps → 未サポート
* KurumiWriter V1.00改造後 (Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 7sec
500,000bps → 3sec
1,000,000bps → 未サポート
* rl78flash (rl78flash-0.5.2-mon80-20160914 -m 2 -b 通信ボーレート -a COM14 cotton_sketch.mot)
115,200bps → 10sec
500,000bps → 4sec
1,000,000bps → 4sec
なお、改造したソースファイルとKurumiWriter_Win.exeを以下の7zファイルに固めておきました。
ファイル: KurumiWriter_Win_V100_Modify.7z
内容:
KurumiWriter_Win_V100_MON80_20160923.exe
KurumiWriter.vcxproj
SequenceProcessor.cpp
SequenceProcessor.h
SerialPortProcessor.cpp
SerialPortProcessor.h
ちなみに、ソースファイルの改造箇所の一例は以下の通りです。
ファイル: SequenceProcessor.cpp
改造内容(抜粋): 赤字の箇所を改造
追記 : メモ
Windows Communication API - MSDN
COMMTIMEOUTS structure
https://msdn.microsoft.com/library/aa363190.aspx
SetCommTimouts
https://msdn.microsoft.com/library/cc429719.aspx
追記 : メモ
KURUMI Writer for Win V1.00 Source - Rulz
http://japan.renesasrulz.com/gr_user_forum_japanese/m/mediagallery/119.aspx
追記 : メモ
Tool to program RL78 MCUs via serial bootloader - GitHub
master
https://github.com/msalau/rl78flash/
releases
https://github.com/msalau/rl78flash/releases/
v0.5.2
https://github.com/msalau/rl78flash/tree/v0.5.2/
2016/09/23 blog-entry-820 category: RL78 /* 16bit,8bit CISC */
RL78マイコン基板(RL78/G13)｜KurumiWriter V2.10とrl78flashの書き込み時間の比較 (CP2102編)
以前のエントリでFTDI社のUSBシリアル変換チップFT232RLを使った場合でのRL78マイコンの内蔵フラッシュ
メモリへの書き込み時間を、秋月電子さん販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールを使い、
KurumiWriter V1.00(ソース公開版)とrl78flashで比較してみたのですが、今度はSilicon Labs社のUSBシリアル
変換チップCP2102を使った場合での時間をKurumiWriter V2.10とrl78flashで比較してみました。書き込んだ
プログラム(binファイル or motファイル)は以前のエントリでR5F100LGAFBで動作するようにルネサスWeb
コンパイラのCOTTON基板のデフォルトのスケッチのリンカスクリプトを変更してビルドしたもの(45KB)です。
なお、CP2102ではWindowsドライバにFT232RLのような設定項目はありません。
* KurumiWriter (V2.10、Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 18sec
500,000bps → 16sec
1,000,000bps → 未サポート
* rl78flash (rl78flash -m 2 -b 通信ボーレート -a COM11 cotton_sketch.mot)
115,200bps → 10sec
500,000bps → 4sec
1,000,000bps → エラー(チップの仕様(未対応)?)
追記 : メモ
rl78flashの-aオプションは-ewvrオプション(消去して、書き込んで、ベリファイして、プログラムを実行)と
等価なのですが、ベリファイの動作は書き込んだデータと同じデータを再度送信して書き込まれていたデータ
(つまり読み出したデータ)と一致するか調べて正常に書き込まれているかチェックする方式になっています。
正常に書き込まれたかどうかをチェックする方法には、他に、書き込んだデータのCRC値と書き込まれていた
データ(つまり読み出したデータ)のCRC値を比較する方法もあり、KurumiWriterではCRC値を比較する方式に
なっています。前者は後者よりデータを再度送信する分だけ処理時間が長くなる傾向がありますが、いつもの
ようにちょっと好奇心から、rl78flashでベリファイを省いた場合の書き込み時間も計ってみました。(なお、
今のところ(G10専用のrl78g10flashにはあるものの)rl78flashにはCRC値を比較するオプションが無く、単に
ベリファイを省いただけなのでKurumiWriterとの公平な比較になりませんが、好奇心から計ってみました。)
* rl78flash (rl78flash -m 2 -b 通信ボーレート -ewr COM11 cotton_sketch.mot)
115,200bps → 6sec
500,000bps → 3sec
1,000,000bps → エラー(チップの仕様(未対応)?)
メモリへの書き込み時間を、秋月電子さん販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールを使い、
KurumiWriter V1.00(ソース公開版)とrl78flashで比較してみたのですが、今度はSilicon Labs社のUSBシリアル
変換チップCP2102を使った場合での時間をKurumiWriter V2.10とrl78flashで比較してみました。書き込んだ
プログラム(binファイル or motファイル)は以前のエントリでR5F100LGAFBで動作するようにルネサスWeb
コンパイラのCOTTON基板のデフォルトのスケッチのリンカスクリプトを変更してビルドしたもの(45KB)です。
なお、CP2102ではWindowsドライバにFT232RLのような設定項目はありません。
* KurumiWriter (V2.10、Run after COM openのチェック無し、cotton_sketch.bin)
115,200bps → 18sec
500,000bps → 16sec
1,000,000bps → 未サポート
* rl78flash (rl78flash -m 2 -b 通信ボーレート -a COM11 cotton_sketch.mot)
115,200bps → 10sec
500,000bps → 4sec
1,000,000bps → エラー(チップの仕様(未対応)?)
追記 : メモ
rl78flashの-aオプションは-ewvrオプション(消去して、書き込んで、ベリファイして、プログラムを実行)と
等価なのですが、ベリファイの動作は書き込んだデータと同じデータを再度送信して書き込まれていたデータ
(つまり読み出したデータ)と一致するか調べて正常に書き込まれているかチェックする方式になっています。
正常に書き込まれたかどうかをチェックする方法には、他に、書き込んだデータのCRC値と書き込まれていた
データ(つまり読み出したデータ)のCRC値を比較する方法もあり、KurumiWriterではCRC値を比較する方式に
なっています。前者は後者よりデータを再度送信する分だけ処理時間が長くなる傾向がありますが、いつもの
ようにちょっと好奇心から、rl78flashでベリファイを省いた場合の書き込み時間も計ってみました。(なお、
今のところ(G10専用のrl78g10flashにはあるものの)rl78flashにはCRC値を比較するオプションが無く、単に
ベリファイを省いただけなのでKurumiWriterとの公平な比較になりませんが、好奇心から計ってみました。)
* rl78flash (rl78flash -m 2 -b 通信ボーレート -ewr COM11 cotton_sketch.mot)
115,200bps → 6sec
500,000bps → 3sec
1,000,000bps → エラー(チップの仕様(未対応)?)
2016/09/21 blog-entry-819 category: RL78 /* 16bit,8bit CISC */
RL78マイコン基板(RL78/G13)｜CP2102+rl78flashで秋月のRL78搭載変換モジュールに書き込み
FTDI社のUSBシリアル変換チップFT232RLの代わりにSilicon Labs社のUSBシリアル変換チップCP2102を
使って、以前のエントリと同様にブレッドボード上に組んだ抵抗1本のフラッシュ書き込み回路で秋月電子さん
販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールにrl78flashでフラッシュ書き込みしてみました。
すると、FT232RLと異なり、CP2101ではrl78flashで250,000bpsでも500,000bpsでも書き込み出来ました。
(以前のエントリに書いた通りrl78flashにはソフトウェア上の何かしらがあるような気がしていますが、それが
(幸いにも?)表面化せずに済んでしまうような何かがCP2102とそのWindowsドライバにあるような気がします。)
なお、CP2102でも1,000,000bpsでフラッシュ書き込みしようとするとエラーが発生します。(チップの仕様?)
115,200bpsでも250,000bpsでも500,000bpsでフラッシュ書き込み出来る
1,000,000bpsではエラーが発生する
使って、以前のエントリと同様にブレッドボード上に組んだ抵抗1本のフラッシュ書き込み回路で秋月電子さん
販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールにrl78flashでフラッシュ書き込みしてみました。
すると、FT232RLと異なり、CP2101ではrl78flashで250,000bpsでも500,000bpsでも書き込み出来ました。
(以前のエントリに書いた通りrl78flashにはソフトウェア上の何かしらがあるような気がしていますが、それが
(幸いにも?)表面化せずに済んでしまうような何かがCP2102とそのWindowsドライバにあるような気がします。)
なお、CP2102でも1,000,000bpsでフラッシュ書き込みしようとするとエラーが発生します。(チップの仕様?)
115,200bpsでも250,000bpsでも500,000bpsでフラッシュ書き込み出来る
1,000,000bpsではエラーが発生する
2016/09/21 blog-entry-818 category: RL78 /* 16bit,8bit CISC */
RL78マイコン基板(RL78/G13)｜CP2102+KurumiWriterで秋月のRL78搭載変換モジュールに書き込み
FTDI社のUSBシリアル変換チップFT232RLの代わりにSILICON LABS社のUSBシリアル変換チップCP2102を
使って、以前のエントリと同様にブレッドボード上に組んだ抵抗1本のフラッシュ書き込み回路で秋月電子さん
販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールにKurumiWriterでフラッシュ書き込みしてみました。
すると、FT232RLと異なり、CP2101ではKurumiWriterとの組み合わせでも不安定さは全くありませんでした。
(以前のエントリに書いた通りKurumiWriterにはソフトウェア上の問題があるような気がしていますが、それが
(幸いにも?)表面化せずに済んでしまうような何かがCP2102とそのWindowsドライバにあるような気がします。)
なお、FT232RLの内蔵EEPROMを書き換える為のRun after COM openにチェックがあるとエラーが発生します。
115,200bpsも500,000bpsも安定してフラッシュ書き込み出来る
115,200bpsも500,000bpsもRun after COM openにチェックがあるとエラーが発生する
使って、以前のエントリと同様にブレッドボード上に組んだ抵抗1本のフラッシュ書き込み回路で秋月電子さん
販売のRL78/G13 64pin R5F100LGAFB搭載変換モジュールにKurumiWriterでフラッシュ書き込みしてみました。
すると、FT232RLと異なり、CP2101ではKurumiWriterとの組み合わせでも不安定さは全くありませんでした。
(以前のエントリに書いた通りKurumiWriterにはソフトウェア上の問題があるような気がしていますが、それが
(幸いにも?)表面化せずに済んでしまうような何かがCP2102とそのWindowsドライバにあるような気がします。)
なお、FT232RLの内蔵EEPROMを書き換える為のRun after COM openにチェックがあるとエラーが発生します。
115,200bpsも500,000bpsも安定してフラッシュ書き込み出来る
115,200bpsも500,000bpsもRun after COM openにチェックがあるとエラーが発生する
2016/09/21 blog-entry-817 category: RL78 /* 16bit,8bit CISC */
RL78マイコン基板(RL78/G13)｜rl78flashで書き込んでPython+pySerialでシリアル通信する設定
以前のエントリでPythonのpySerialというシリアルポート操作パッケージを試したことがあるのですが、これに
miniterm.pyという通信端末スクリプトが含まれていたことを思い出したので実行してみました。幸いなことに、
DTR信号(やRTS信号)を反転させる機能があり、それを使うことでうまく通信することが出来ました。
miniterm.pyのヘルプ
起動するとCOMポートを聞かれるので入力する(まだ通信は始まらない)
キーボードから ^T ^D を順に入力すると通信を開始(DTR信号の場合) (RTS信号であれば ^T ^R を順に入力)
小技として ^T ^D ^T ^D でRL78/G13をリセット可(DTR信号の場合) (RTS信号であれば ^T ^R ^T ^R で)
追記 : 補足
後で気付いたのですが、スクリプトminiterm.pyへの引数によって指定することも出来るようになっていました。
miniterm.pyの引数のヘルプ
引数に COM14 --dtr=0 で起動時から通信を開始(DTR信号の場合) (RTS信号であれば COM14 --rts=0 で)
追記 : メモ
Windowsではコマンドプロンプトの漢字コードがSJIS固定になっているので、miniterm.pyのままではルネサス
WebコンパイラでSerial.print()の引数に日本語を書くと文字化けしてしまいますが、Linux(やMac OS Xでも?)
ではコンソールウィンドウの漢字コードがUTF-8であれば、ルネサスWebコンパイラでSerial.print()の引数に
日本語を書いても問題無く日本語表示されそうな気がします。WindowsでもLinux環境をエミュレーションする
ツールに含まれているコンソールウィンドウであれば漢字コードを変更する機能とかはありそうな気がします。
例えば、以前のエントリで試してみたMSYS2というLinux環境をエミュレーションするツールにはありました。
(ただ、MSYS2がキー入力や画面出力をフックする処理がminiterm.pyと相性が良くなくて挙動が微妙でしたが、
よくよく考えてみると、Windows用PythonではなくてMSYS2用Pythonでやってみるべきだったような気も。)
コマンドプロンプトではルネサスWebコンパイラでSerial.print()の引数に日本語を書くと文字化けする
MSYS2のコンソールウィンドウであれば問題無く日本語表示させることが出来る
追記 : メモ
たぶん、miniterm.pyを改造すれば、UTF-8→SJISへ変換して表示させたり、表示にタイムスタンプを付けたり、
通信ログのバックアップを自動で何世代分か残しておいたり、といったことは出来そうな気はしていますが、、、
追記 : 雑感
Linux(やMac OS Xでも?)にリモートログインしたシェルでminiterm.pyを実行すれば、リモートでRL78/G13と
通信(シリアルモニタ)出来そうです、、、 さらに、miniterm.pyを改造して、特定のフォルダのHEXファイルが
更新されたら、通信(シリアルモニタ)を中断し、フラッシュ書き込みツールを起動し、フラッシュ書き込み完了
後に通信(シリアルモニタ)を再開する、ということを自動的に行うように出来たら、ちょっと面白そうです、、、
なお、CS+に以前のエントリのPuTTYのpscpコマンドでファイル転送する処理を外部ツールとして登録すれば、
メニューやツールバーボタンの操作でビルドしたHEXファイルをリモートへ転送することは出来そうです、、、
追記 : メモ
そういえば、という感じで思い出したのですが、以前ウェブで調べ物をしていた時にKURUMI基板をXBeeで遠隔
書き込みされている人のブログを読ませて頂いたことがありました。その人のブログをもう一度探してみました。
解禁？ルネサスのRL78マイコンを使ったArduino Pro mini互換ボードGR-KURUMIをXBeeでプログラミング
Under Power 研究所 - hamayan
http://hamayan.blog.so-net.ne.jp/2013-04-05
内蔵フラッシュメモリ書き換えプロトコルではフラッシュメモリブロック単位で書き換えることが出来ますので、
プログラムのパラメータデータをうまく配置すればパラメータデータだけを書き換えることも出来そうです、、、
追記 : メモ
CQ出版社のInterface誌10月号(8月25日発売済み)の特集はPythonだったようです。(マイコン用MicroPythonと
いうものの記事もあるようです。すみません。まだ今月号は買っていませんので、目次からの情報ですが、、、)
世界の英知！Pythonライブラリ事典101
データ解析時代の新定番Python
http://www.kumikomi.net/interface/contents/201610.php
miniterm.pyという通信端末スクリプトが含まれていたことを思い出したので実行してみました。幸いなことに、
DTR信号(やRTS信号)を反転させる機能があり、それを使うことでうまく通信することが出来ました。
miniterm.pyのヘルプ
起動するとCOMポートを聞かれるので入力する(まだ通信は始まらない)
キーボードから ^T ^D を順に入力すると通信を開始(DTR信号の場合) (RTS信号であれば ^T ^R を順に入力)
小技として ^T ^D ^T ^D でRL78/G13をリセット可(DTR信号の場合) (RTS信号であれば ^T ^R ^T ^R で)
追記 : 補足
後で気付いたのですが、スクリプトminiterm.pyへの引数によって指定することも出来るようになっていました。
miniterm.pyの引数のヘルプ
引数に COM14 --dtr=0 で起動時から通信を開始(DTR信号の場合) (RTS信号であれば COM14 --rts=0 で)
追記 : メモ
Windowsではコマンドプロンプトの漢字コードがSJIS固定になっているので、miniterm.pyのままではルネサス
WebコンパイラでSerial.print()の引数に日本語を書くと文字化けしてしまいますが、Linux(やMac OS Xでも?)
ではコンソールウィンドウの漢字コードがUTF-8であれば、ルネサスWebコンパイラでSerial.print()の引数に
日本語を書いても問題無く日本語表示されそうな気がします。WindowsでもLinux環境をエミュレーションする
ツールに含まれているコンソールウィンドウであれば漢字コードを変更する機能とかはありそうな気がします。
例えば、以前のエントリで試してみたMSYS2というLinux環境をエミュレーションするツールにはありました。
(ただ、MSYS2がキー入力や画面出力をフックする処理がminiterm.pyと相性が良くなくて挙動が微妙でしたが、
よくよく考えてみると、Windows用PythonではなくてMSYS2用Pythonでやってみるべきだったような気も。)
コマンドプロンプトではルネサスWebコンパイラでSerial.print()の引数に日本語を書くと文字化けする
MSYS2のコンソールウィンドウであれば問題無く日本語表示させることが出来る
追記 : メモ
たぶん、miniterm.pyを改造すれば、UTF-8→SJISへ変換して表示させたり、表示にタイムスタンプを付けたり、
通信ログのバックアップを自動で何世代分か残しておいたり、といったことは出来そうな気はしていますが、、、
追記 : 雑感
Linux(やMac OS Xでも?)にリモートログインしたシェルでminiterm.pyを実行すれば、リモートでRL78/G13と
通信(シリアルモニタ)出来そうです、、、 さらに、miniterm.pyを改造して、特定のフォルダのHEXファイルが
更新されたら、通信(シリアルモニタ)を中断し、フラッシュ書き込みツールを起動し、フラッシュ書き込み完了
後に通信(シリアルモニタ)を再開する、ということを自動的に行うように出来たら、ちょっと面白そうです、、、
なお、CS+に以前のエントリのPuTTYのpscpコマンドでファイル転送する処理を外部ツールとして登録すれば、
メニューやツールバーボタンの操作でビルドしたHEXファイルをリモートへ転送することは出来そうです、、、
追記 : メモ
そういえば、という感じで思い出したのですが、以前ウェブで調べ物をしていた時にKURUMI基板をXBeeで遠隔
書き込みされている人のブログを読ませて頂いたことがありました。その人のブログをもう一度探してみました。
解禁？ルネサスのRL78マイコンを使ったArduino Pro mini互換ボードGR-KURUMIをXBeeでプログラミング
Under Power 研究所 - hamayan
http://hamayan.blog.so-net.ne.jp/2013-04-05
内蔵フラッシュメモリ書き換えプロトコルではフラッシュメモリブロック単位で書き換えることが出来ますので、
プログラムのパラメータデータをうまく配置すればパラメータデータだけを書き換えることも出来そうです、、、
追記 : メモ
CQ出版社のInterface誌10月号(8月25日発売済み)の特集はPythonだったようです。(マイコン用MicroPythonと
いうものの記事もあるようです。すみません。まだ今月号は買っていませんので、目次からの情報ですが、、、)
世界の英知！Pythonライブラリ事典101
データ解析時代の新定番Python
http://www.kumikomi.net/interface/contents/201610.php
2016/09/18 blog-entry-816 category: RL78 /* 16bit,8bit CISC */
