2011-09
地球暦２０１１年。台風に非ず、白色彗星帝国が接近してきているらしい。†
http://omoroid.blog103.fc2.com/blog-entry-555.html
どうする？
- （１）逃げる
- （２）たたかう。
- そんな低スペック装備で大丈夫か？ヤマトの諸君、いや地球人類。
- 大丈夫だ。問題ない
だめだこのテンプレ。
必ず大丈夫になってしまう。
libmapleで仮想COMの続き†
現状の問題認識
- libmapleでも仮想COMの実装は手抜きになっている（というかバグがあるくさい）
- 具体的には、以下のusb関数に、受信データから(len)バイト分の要求を行った場合、
- 必ず、vcomBufferRx[]の先頭から(len)バイトをコピーして寄越すので、
- ぜんぜんFIFOっぽくないというかバグじゃねえか？という件である。
/* copies len bytes from the local recieve FIFO (not
usb packet buffer) into recvBuf and deq's the fifo.
will only copy the minimum of len or the available
bytes. returns the number of bytes copied */
uint32 usbReceiveBytes(uint8* recvBuf, uint32 len) {
if (len > newBytes) {
len = newBytes;
}
int i;
for (i=0;i<len;i++) {
recvBuf[i] = (uint8)(vcomBufferRx[i]);
}
newBytes -= len;
/* re-enable the rx endpoint which we had set to receive 0 bytes */
if (newBytes == 0) {
SetEPRxCount(VCOM_RX_ENDP,VCOM_RX_EPSIZE);
SetEPRxStatus(VCOM_RX_ENDP,EP_RX_VALID);
}
return len;
}
- さて、どうすりゃいいんだ？
バグその２†
- 現状のcdctoolは、大量のデータをホストＰＣに送れない。
- 必ず、32byteのコマンドパケットを送って、32byteの返答を貰うようにしている。
- これを、不定長というか32byte以上のデータをまとめて送ると、何故か転送が完了せずにハングするのだ。
- これ、仮想COMとはいえ、RS232Cだぞ。まとめて送ろうが五月雨に送ろうが、TxDはTxDのはずなのにハングするとか
何事だ。
- たぶんホスト側のバグなんだろうなぁ・・・
原因調査中。続く・・・。
- 以下次号
libmapleで仮想COMの続きの続き†
ごめんな、疑って。
- 前回bugと書いた件。
- 速攻で直されてた。
- gitから落としてみた。
/* copies len bytes from the local recieve FIFO (not
usb packet buffer) into recvBuf and deq's the fifo.
will only copy the minimum of len or the available
bytes. returns the number of bytes copied */
uint32 usbReceiveBytes(uint8* recvBuf, uint32 len) {
static int offset = 0;
if (len > newBytes) {
len = newBytes;
}
int i;
for (i=0;i<len;i++) {
recvBuf[i] = (uint8)(vcomBufferRx[i+offset]);
}
newBytes -= len;
offset += len;
/* re-enable the rx endpoint which we had set to receive 0 bytes */
if (newBytes == 0) {
SetEPRxCount(VCOM_RX_ENDP,VCOM_RX_EPSIZE);
SetEPRxStatus(VCOM_RX_ENDP,EP_RX_VALID);
offset = 0;
}
return len;
}
- 変更履歴を見たいけど、オレgitの使い方わかんない・・・。スマン。
- 残念ながらmaple-ide-0.0.11-windowsxp32.zipの時点では、まだ直っていないので、IDEを使う人でここらへん がクリティカルな人は、git経由でlibmapleを落として使うことをお勧めする次第。
https://github.com/leaflabs/libmaple
もしくは、Linuxコンソール等で
$ git clone git://github.com/leaflabs/libmaple.git $ git clone git://github.com/leaflabs/maple-bootloader.git
追伸
バグその２：解決†
- 不定長というか32byte以上のデータをまとめて送ると、何故か転送が完了せずにハングするのだ。
たぶんホスト側のバグなんだろうなぁ・・・
- 原因が判明。意外なところに盲点があった。
- 32byte以下の転送要求に対しては、データはバッファにコピーされた後、SerialUSB.write(buf,size); される。
- 32byteを超える転送要求に対しては、（転送長が分からないので）ポインタをそのままSerialUSB.write(buf,size); に渡している。
- ハングするのは32byte以上だから、ではなくて、０番地を逆アセンブルするときだ。
- SerialUSB.write(buf,size);のbufがたまたま０番地になると、bufにNULLを渡されたと勘違いしたＣ＋＋クラス が怒ってなにもしないで制御を返す-->ホストＰＣはデータが送られずに延々と待ち続ける。がっかりだよ
- 現在、逆アセンブルを高速化するためにある程度まとまったブロックでメモリー要求しているのだけれど、０番地 のブロックだけは32byteに小分けして転送するように改良した。
- この方法なら、０番地の内容はいったんローカルバッファにコピーされるので、引数bufにNULLを渡す恐れは無い。
予定稿†
- libmapleを使って仮想COMベースのブートローダーを作る。
ステージ１）・・・完了
- libmapleのフレームワークのまま、ブートローダー（仮）のダミーモジュールを組み込んだものは、一応仮想COMデバイスとして認識に成功した。
- ただし、まだブートローダーとしての機能はない。
- サイズは8Kを超えている。
- wirish/ と libraries/ は削除済み。Ｃ＋＋ソースは使用していないけれどcrt0.oやリンカスクリプトなどはＣ＋＋用をそのまま使用している。
ステージ２）・・・完了
- Ｃ＋＋用のリンカスクリプトとcrt0.oを排除してみた。
- コードは8kB未満。
- まだブートローダーとしての機能はない。
- USBをイネーブルするとハングする。USB用割り込みベクターの名称が異なるようだ・・・
修正中--- USB割り込みハンドラーの関数名だけを変更したら、一応デバイス認識まで通るようになった。
ダウンロード（仮）：
説明：
ブートローダーとしての機能はまだありません。---使えるようになりました。
ステージ３）
- ブートローダーにする。
以下次号へ
- libmapleを使って仮想COMベースのAVR/PIC/PIC24/OpenOCDライターを作る。
ちょっとだけフォントにこだわってみる。†
- 2007年くらいまで頑張って使い続けていたWindows98を捨てて、
- XPに移行した今も、
- モニターコンソールだけは頑なに800x600(SVGA)を守り続けてきた。*1
- Windowsなのに、自分のデスクトップときたら、ほぼ全画面状態のＤＯＳ窓かteratermしか起動していない。
- 昔はVz派だったけど、ファイル名やパス名が長くなりすぎたので、Linuxのjedを改造して(Vzのかわりに)使っている。
- フォントはPC9801のものをFixedsysに移してそのまま使っているので、まるでPC9801状態。
- （そういうわけで、ＧＵＩが嫌いというか使ってないというか。WindowsなのにCUIのままだ）
- しかし、800x600で何が困るって、ダイアログがはみ出してＯＫボタンを押せないことだ。（たびたびある）
- ほかにもいろいろ困り始めたので、しかたなく8x16dotの馴染み深いフォントを捨てることにした。
代替品はこのへん。
M+IPA†
http://mix-mplus-ipa.sourceforge.jp/
DOS窓用ConsoleFontへの追加方法†
http://ub.blog85.fc2.com/blog-entry-235.html
- なんかWindowsなのにubuntuのMonoSpaceフォントを使っている気分だ。
- だったらubuntuを使えばいいのか。そうなのか。
- ちょっと慣れるまで大変そうだ。
今週のインストールトラブル†
- Wake-on-Lanが使えない。
- H61のとあるマザー。AMIのAptio BIOSなんだけど、WAKE ON LANの設定が無い。
- Resume by RING(S3)とかはある。
- Resume by KB(S3)を試してみたけれど、シャットダウンした後にKBのPOWERボタンを押しても電源は入らない。
- というかキーボードに電気来てないから。
- 試行錯誤の末、Linuxをsuspend(S3)させて、magic packetで復帰するしかない、ということが分かった。
- Suspend To RAM(S3)はDDR3に電力供給してDRAMリフレッシュも要るので、ＡＣから測って5Wくらい消費する。
ちなみにいろいろ分かったこと。
- SandyBridgeはCore2や旧世代爆熱Core-iと比べて消費電力が30W〜40W低い。アイドリングで30W程度。フルスロットルでも100Wくらい。（Core2Quadだとそれに+30W〜40Wくらい）
- 2chの低消費電力スレには20W以下の猛者もいる。消費電力でもAtomは完全に要らない。用済みだ。
- それでいて性能が上なので、Core2にしがみつく理由が無くなった。
- 互換機電源には２種類あって、力率が100%近い部類と、せいぜい60%くらいの部類が存在。
- だったら、ＡＣに電流計入れるだけの計測では、まともに測れるやつと誤差だらけのやつがあることになる。
なんかＰＣの消費電力にこだわるのは昔は静音追求だったんだけど、今は原発のせいだけんね。
- こまめに電源を切らなきゃならなくなったのも。
- 昔はサーバーなんて電源入れっぱなしでよかったのに。
加速する「MacでARM採用」の噂、議論の存在をIntelが認める - 米報道†
- MacのCPUは昔は68000だったし、次はPowerPCだった。
- 昔のMacOSと、今の(*bsdベースの)OSXは全く別物。
- なので、x86の次はARMでも全然かまわない。
- そうやって変化するものだけが生き残れるとしたら、Windowsは・・・。
armon/armbootの高速化†
- cdcboot.zipの成果を少しだけフィードバックしてみたなり。
- armboot.exe でVerifyが特に遅いと感じる人はお試しあれ。（かなり速くなっているはず）
- armon.exe で逆アセンブルが相当速くなった。意味があるかどうかは分からないが。
- cdcbootをブートローダーとして使えるようにするのは、もう目前の状態だけど、上記改良を行ったので、HIDのままでも特に困らない。
NHKのネットラジオ†
- ラジオなので、受信料は払わなくてよい。（テレビのほうですでに払っているが）
- FMのクラシック番組「ベストオブクラシック」は権利関係でネット放送できないらしい。
- そのときはどうなる？もうすぐ7:30 --->ちゃんと聞こえていますよ。いいのかな
利点
- ラジオサーバーのようなものを用意しなくても普通にブラウザーで聞けること。
- ということは、ラジオの出力を録音するようなハードウェアを用意しなくても普通にパソコンで録音出来る（はず）なので手間が省ける。
- AMなのに音質が良い。（逆にFMだとすこし悪いのか）
- 本物ラジオでありがちな、パソコンなどから出るデジタルノイズを拾わないでクリアーに聞ける。
- 都市圏だったら、地下鉄やビルの谷間でも聞けるというメリットがあるかもしれない。（ただしパケ死とかするかも）
弱点？
- 弱点ではないけれど・・・やっぱり作業の邪魔になる。（話番組が多いので）
- HappyDay(インターネットラジオ)を聞きながら、のほうが効率が良いので。
- mp3で録音とかしないで、流し聞きするだけだったら、わざわざパソコンつけるのが面倒くさい。
秋月：ＬＰＣ１1Ｕ１４評価ボードＬＰＣＸｐｒｅｓｓｏＢｏａｒｄ †
- http://akizukidenshi.com/catalog/g/gM-05091/
- この手の基板でターゲット側にUSBコネクタが付いているのは初めてだ。（いつもは自分でつけないと使えない）
- 2000円なので、他のXpressoより少し安い。
- と、思ったら、他のXpressoも、すこしづつ安くなっている。(1114,1343は2000円、1769でさえ2500円)
円高のせい？
- 1227とか11c24とかも2000円。
- 11U14はクロックも低い(48MHz?)し、SRAMも少ない(6kB)。Flashも32K。
- あいかわらずST-Link側(LPC3154)はプロテクト掛かってるから再利用できないのが残念なんだな。
- LPC3154はスペックむちゃくちゃ高い。こんなのがおまけで付いてていいのか？
物欲ついでに
- ＸＩＬＩＮＸ ＦＰＧＡ評価ボードＳｐａｒｔａｎ−６ ＬＸ９
- ナナキュッパ。
- すこし惹かれた。
- DRAMが64MB乗っているので、Linuxっぽいものがぎりぎり走るかも。(MicroBlaze)
- 基板形状と拡張コネクタが、ちょっとだめか。
STBee/Miniのファームを飛ばしてしまった†
- 案の定
- やっちまったな
STBeeもだよ。
もっと読む STBeeMini
- 失敗の理由は、ファーム自身のエリアを誤消去から守るため、エリアチェックを入れていたのだが、
- そのstartとendが適切に設定されていなかったから。
- ついでに言うと、Eraseだけ保護してもProgramWordを保護しなければ、結局だめなことにかわりはない。
libmapleでブートローダー†
- STM8S_Discovery(のSTM32側) に対して、ほぼブートローダーが完成。
- CQ-STARM/STBee/STBeeMiniでも、ブートローダーとして使えるようになった。
read more : libmapleでブートローダー
- 結局、手持ちのSTM32は全部cdcbootに移行してしまった。
残念なお知らせ。
- STM32の（STmicroの）サンプルソースがなぜかcdcbootで動かない。
- armbootに戻して調べるの面倒だな。そうだ１枚だけSTM8S-Discovery基板をarmboot専用にしておこう。
残念なお知らせ２。
- STBeeのファーム復旧のために、手持ちのLPC-Xpresso(1343)にvcomサンプルを焼いて使ってみたのだけれど、 FlashLoader Demonstratorで書き込み中、（４％くらいのところで）必ず失敗する。
- しかたがないので携快電話に付いてきたProlificのUSB-Serialポート（を改造して電子工作用にした）ドングル経由でファームを書き換えたら問題なくうまくいった。
- LPCのvcomサンプルはマジ馬具ッテイルのかな？
なんかここんところ仮想COMファームのバグに当たりっぱなしだぎゃー。
今後の予定
書き込みの高速化。--- 済み- maple-bootloaderのコードを見たら、flashProgramWord()で４バイト書くごとにベリファイしてエラーコードを返しているので、このエラーをカウントして、ノーエラーだったら基本、読み出しチェックいらないのでは。
- エラーカウントが０じゃないときだけ、普通のベリファイを実行するようにすると速度２倍お得。
- ついでに、書き込みのブロックサイズを1024単位にしてみた。
- 注意: 前のバージョンから自己書き換えでupdateする場合は、0x803000番地hexを書くときだけ、
- 前のバージョンのcdcboot.exeを使用する必要があります。
例）
D:> cdcboot-oldver.exe -r DISCOVERY-3000.hex D:> cdcboot.exe -B DISCOVERY-0000.hex この後、USBケーブルを挿しなおす。
- オレオレBitBangモードのようなもの。
- FTDIのbitbangは専用のドライバーが必要だけれど、普通に仮想COMだけでbitbangを実装してしまえば、
- それを使うだけで、大抵のマイコンへの書き込みメソッドは事足りるようになる（はず）。
- Flashライターのほとんどの処理はPC側の仕事になってしまうけれど面倒なライターファームを開発する必要は無くなる。
- 今はAVR用/PIC18F用/PIC24F用と、それぞれの細かい書き込み処理をファーム内でこなしているので、容量がでかくなる問題と、それ以外のマイコンの場合ファームを拡張しないと対応できない問題を抱えている。
いろいろあったバグ：
- Flash書き込みを1024バイト単位に・・・ならない。
- ファームの受け側のsize変数が何故かuchar。これpicのソースか。
- Flashに書くと化けまくり
- flashProgramWord()関数のsizeはword(4byte)単位なのに上位層のsizeは全部byte数に統一していた。
- ある関数レベルからword単位に換算するのだけれど、その後の大小判定や分割処理をbyte数だと勘違いして実装。
その他
- なんかlibmapleの仮想COMは、一度にホストに転送できる文字数(byte数)が63くらいまでっぽい。
- USBのパケットは64byteまで許されているのだけれど、64にするとハングする。(これはCDCの仕様を守ってないから？)
- たぶん64バイト転送したら、次に0バイトのパケットを送るか、後続のデータを送らないとだめなんだろう。
- libmapleでは最大32byteまでしかホストに送らない（超えたら分割送信）
- ホストＰＣから受信するときはこの制限は一応ない。
- 実は内部で分割転送しているから。
- ただし、受信パケットの扱いは非効率。usbReceiveBytes()で64byteの受信バッファを全部引き取って空にするまでは、次のパケットの受信をイネーブルに出来ない。ホストＰＣからの送信はふんづまりになる。
libmapleでブートローダー、libmapleで仮想COMを更新†
中身は、似たり寄ったり。C++が使えるかどうかだけの違い。
やはりARMのWindows8ではレガシーアプリは動かず†
- http://www.geocities.jp/andosprocinfo/wadai11/20110917.htm
- ARMでx86アプリを動かそうと思っていた人には残念なお知らせかも。
- しかし、言い訳が、電池の持ちに転嫁されている。
これは変な話だ。
- MS-DOSアプリなら、大半の処理はビジーループだらけなので電力効率は悪いに決まっている。
- しかしwin32のGUIアプリなら、ほとんどの処理はイベント駆動なので、基本的にイベントが来なければ電力を消費しないと思うんだけど、どうなんだろう。
- マウスmoveのイベントはどかどか来るかもしれないけれど、そのたびにredrawするわけじゃない。
*1 液晶モニタは1280x1024なので、800x600を拡大で映すとややボケするのが欠点だ
