2010-02

2010-01← → PIC日記 Arduino400 PICspx MINTIAspx

Tommy February 6 ...


  • そう、地球滅亡まで、あと35ヶ月となった。
  • そして、地アナ滅亡まで、あと18ヶ月もある。


戯言

  • 地アナは滅びても、RCA形の黄色いNTSC入力端子は永遠に不滅です。ファミコンがある限り。


今月の寝言目標

  • PIC18FでUSB to シリアル変換機を作る。(FT232RLを使ったら敗北だ。)
  • PIC18FでUSB to PS/2キーボード変換機を作る。(既製品を買ったら敗北だ。)
  • 赤外線でビビビ(これも既製品を買ったら敗北だ。)

敗北しそうな雰囲気ぷんぷん。








A4プロセッサにプロテクト機能?

http://home.att.ne.jp/sigma/satoh/diary.html

  • 充分ありうる話だと思う。
  • NDSにもチップ内のブート領域のプロテクトが施してあり、PassMeで破られるまでだいぶ時間稼ぎされた。
  • Appleはおそらく次のiPhoneとかiPodにもA4を使ってくるのではないかと思う。(製造はいずれもSamsung)
  • iPadだけに使うとしたら、PA Semiを買収するほどのことはやらなかったはずだ。(つまり、その時点での適当なARM SoC 、例えばTegraを使えば良かったはずだ。)
  • (Tegraと)性能的にはかなり拮抗しているのではないかと思う。


  • むしろ、iPadが出てきたことでKindleが値下げされたらいいなぁ、と思っている。
  • なぜかって?e-inkだからDocumentをぼーっと眺めてるだけの用途には向いてるし、中身はLinuxだからいろいろ手を入れやすい。

Kindle FAQ


しかしあれだ、Appleは

  • その気になればすぐにでも携帯型ゲーム機をリリース出来るだろう。(すでにiPhone3Gがそうだ、ともいえるが)
    • (bluetoothスタックがあるので、外付けキーボードやゲームコントローラーが使えるはずだ。)
  • 次世代NDSもしくはSONY次世代PSPと目されている性能のもの(PlatformとMarket)をすでに持っているのだから。
  • 逆に言えば、携帯ゲーム市場はAppleにとって(音楽や書籍に比べて)取るに足らないものと思っているのかもしれない。いきつくところは(携帯電話のように)無料ゲームになってしまうわけだから。







核融合発電の実現へ、一歩前進

http://www.nationalgeographic.co.jp/news/news_article.php?file_id=20100129001

  • やればできるじゃん。
  • つまり、プラズマを閉じ込めるタイプではなくて、レーザーによる爆縮タイプのやつね。
  • 急にやる気になったのは、石油メジャーが潰しにかかっていた重石が取れたから?それともレーザーの性能がよくなったから?







DELL: Mini10v叩き売り中

翌営業日出荷モデル Windows XP搭載 Inspiron Mini 10v 販売価格 24,980円 本体分配送料無料

2/1追記:注文殺到の為、完売しました。
  • 瞬殺だったか。


  • あやうくポチりそうになったが、思いとどまった。
  • 24,980-のやつは残念ながら(白)だけ。それから英語キーは選べない。
  • emチャージ付きだと26,980-、それからWin7のやつも26,980-。こっちは英語キーを選べる。


  • つまり、これはN450版Mini10がリニューアルされるというサインなんだろうか。
  • OSXを入れる、いわゆるハッキントッシュを作るには、現行Mini10vがベストだ。
  • ただし、BIOSをダウングレードしないとインストール時にハングするという報告もある。


  • 実はこないだ、一番安物のMacBookをubuntu化したばっかりなんだ。
  • じゃあ、なんでMini10vを買ってまでOSX化するのか、と言われても・・・山があるから登るだけなんだよ。







Adobeは怠け者、グーグルはクソ食らえと本音を語ったジョブズ

http://jp.techcrunch.com/archives/20100131jobs-calls-adobe-lazy-calls-google-on-the-their-bullshit/

  • jobs、この歳になってまで、ちょっと過激すぎないか?
グーグルのNexusはiPhoneに対する直接の攻撃であり、決してそうはさせないとも語った。
  • 攻撃なのか?普通のコンペティターだと思うけど。
そのうち誰もFlashなんて使わなくなるだろう。これからはHTML5が標準だとも述べた。-
  • それも、ないとおもう。Flashの無料ゲームって氾濫してるし。







VMWare-Player-3.0の出来があまりにも良い件

ubuntu-9.10 (64bit edition) 内にインストールしてみた。

  • vmwareのサイトからDLしたファイルはtextファイル属性だったが、中身は、というとunixのshell scriptで、その後ろにgzipされたようなバイナリーが連結したものだった。
  • ubuntu上でそのシェルスクリプトを起動すると、GNOMEのGUI画面上にインストーラーが出てきてびっくり。
  • たしか、昔の(ver2.5)VMWarePlayerだと、インストール対象Linuxのkernel moduleのソースかヘッダーが必要で、moduleコンパイルが実行されていたような気がするけれど、今はまるでWindowsのインストーラーのようなものだけで完結していた。
  • 次に、vmplayer というコマンドを実行すると、なんとこれもGUIメニューが出てきて、新しいVMを作成することが出来る。
  • そのときに、インストールしたいOSをDVDROMドライブから読むのか、isoイメージで与えるのかという指定までGUIで出来る。
    • 昔はなんちゃら.vmxファイルをテキストエディタで編集してisoイメージをマウントしていたぞ。
  • さらに凄いのが、Windows用のVMWare Toolsまで自動的にダウンロードしてインストールしてくれるという至れり尽くせり感。
    • 昔はVMWare Toolsのisoイメージをマウントして、ゲストOS起動後に、ゲストOS内で手動でsetup.exeだった。


  • 古い版(ver2.5)のVMWarePlayerにはユーザーが新しいVMを作る機能は無く、フリーソフト等(VMX-Builderとかqemuとか)でVM作成するか、既存のVMをインターネットから入手したあとで、リセット直後にDVDROMを認識、起動させて別のOSをインストールするという技しか使えなかったので、隔世の感がある。
  • というかサービスしすぎ。昔のVMWare製品版よりも出来がいいし、64bit/32bit両方サポートしていて無償なんて凄すぎ。他のメーカーだったら無償版にはいろいろ機能制限するのに・・・。







マイクロソフトの死

LOST:社内が一つにならなければ、マイクロソフトは一人で死ぬんだ

  • いや、むしろマイクロソフトは、例の独禁法違反で調べられていたときに、強制分割されるべきだったのだ。
Microsoftは膨大な収益を上げているが、そのほぼ全てが2ヵ所から来ている。
WindowsとOfficeだ。このため、この2つの部門が紛れもなく莫大な力を得ており、
彼の挙げた2つの例がそれを如実に表している。
永遠に続くものはなく、WindowsとOfficeも例外ではない。そして、そこに安住している間に
革新が妨げられるのは、ばかげた話である。
  • あるものに成功してしまったがためにそこに安住してしまい、気づいたときには手遅れ。
  • 何もマイクロソフトだけに起きた問題ではない。


  • WindowsとOfficeに限って言えば、これらのソフトは代替品が充分成熟してきている。
  • それはubuntuとOpenOffice.orgだ。しかも両方ともオープンソースだ。
  • 自分はいまだにWindowsXPに依存している。そして以前(2005年くらいまで)はWindows98に、その前はWindows95やMSDOSに依存していた。
  • しかし、今後はWindowsVistaやWindows7に依存しないかもしれない。つまりXPの次のOSとしてVistaや7を選択せず、むしろubuntuに乗り換えたいとさえ思っている。
  • その気になれば、例えば予算不足の自治体や教育機関では、WindowsとOfficeを使う代わりに ubuntuやOpenOffice.orgを使うことで経費節減が可能だ。

では、(エンドユーザーが直接MS製品を買ってくれなくなりつつあるのに)マイクロソフトがなぜWindowsで利益を上げ続けられたのだろうか?

  • それは、メーカー出荷されるパソコン1台に付きほぼ1セットのWindowsがプリインストールされ、PC価格に上乗せされているからだ。
  • ところが、将来的にはそうならないかもしれない。
  • なぜなら、新興諸国向けの廉価なPCには必ずしもWindowsがプリインストールされるとは限らないし、モバイルデバイスには省電力ARMプロセッサが使われていて、それらのOSは皆、Windowsではないからだ。
  • しかも、将来はPCの存在意義すら薄れていくと予想される。
  • WindowsCE(Mobile)は失敗し続けてシェア縮小が止まらない。
  • 対抗馬はiPhone,Android,ChromeOSなど、いずれも強豪が控えている。
  • どうやって脱Windows,脱Officeしていくのか?AzureやBingは次世代Microsoftの柱になっていくのだろうか・・・。







禁断のハック!? 「Amazon Kindle 2」を日本語化

ASCII.jp

  • http://ascii.jp/elem/000/000/494/494847/
  • こ、これは、まるで禁断のぶっこぬき記事みたいだな。いいのか、こんな記事出して。
  • そもそもAmazonは、ちゃんと日本語とか多言語対応のファームを配布すべきだ。日本で売るのなら。
  • 日本の書籍そのもののオンライン販売は難しいのだろうけれど、携帯小説とか雑誌とか、雑誌内のマンガだけ配信とかなら絶対需要はあると思う。
  • 専門書とかは無理だろうなぁ・・・。オンライン化されてもPCで読めないんじゃあね。
  • むしろ書籍の概念を越えたところの、リンク貼りまくり検索しまくりの(昔言われたマルチメディアってやつ)ドキュメントが、未来の書籍になっている可能性は大だ。
  • しかし、いくら低速とは言え、3G回線のWebブラウジングし放題で通信料がAmazon持ちっていうのは今だけなんだろうね。普通なら月々4000円は掛かるよ。(ってゆうかAmazon大損してるんじゃね?)
  • 3G回線要らないからWiFi対応して欲しい。







いまだかつてないARM

ARM社が3種類の新プロセッサIPの計画を明らかに、2011年にはIP供与を開始

「EagleはCortex-A9に代わって、ARM社としては最高の性能を発揮するプロセッサIPになる。
その性能は、Cortex-A9とは一段違うものになるだろう。Eagleは、ARM社としてはかつてない
ほど性能を追求したIPである」と語った。
  • どういうベクトルで性能向上させるのか、全然伝わってこない。
  • 今やx86世界でも、プロセッサのIPC性能を下げてまで、1コアを単純にしてコア数を稼ぐとか消費電力を落とす方向に向いているんで、
  • ARMで(1コアの中身を複雑にして)IPCを上げる方向を目指すのはおかしいと思うのだが・・・。
  • 単にクロックを上げる方向なら、新しいIPコアを設計する必要はなさそうに見える。
  • まあ、しかし、これでAtomとの競争激化は予想できるし、主要アーキテクチャーは2強(intel,ARM)に収束してしまうし、Renesas RXアーキの落日も確実だろう。







LLVM:Clang、始まったな。

 開発チームによると、今回ClangでLLVMとClangの作成に成功したという。
55万行以上のC++コードで、作成されたバイナリはClangとLLVMの全ての
リグレッションテストを通過し、Clangが作成したClangはLLVMとClangを
再度構築できたという。

gccと違って、ライブラリベースのアーキテクチャーなので、

いろいろな可能性を秘めているところが凄い。(つまり、パーツを組み合わせていくらでも悪用できる。例えばバイナリートランスレータとか、静的解析とか動的最適化とか・・・)







w32termにベンチマーク機能を追加。

W32_term usbserial

  • ProlificのUSB-Serial変換ケーブル(軽快電話に付属していたもの)のTxD-RxDをショートさせてテスト。
  • 230400bpsはさすがに理論値に近い速度が出ている。
  • 460800bpsは理論値に近い速度が出ることもあるが、たいていはベリファイエラーを吐いて止まる。
  • 921600bpsは即死に近い化け方。
  • 標準のボーレート数列から外れたボーレートは9600bpsくらいに矯正されて非常に遅い。
  • 1行80byteのエコーバックデータのなかに1個〜2個程度MSBがおかしくなったデータが混じる。
  • シリアルケーブルの長さが70cmくらいあって、その先でTxD-RxDショートさせているので波形がなまりまくりなのだろう。おそらく。(お城持ってないので分からない)
  • 変換ドングル内のTxD/RxDには直列抵抗が入っていたので、それもなまる原因かもしれない。

結論的には、TxD/RxDデータは引き回してはだめだってこと。460800bps以上はたとえ仮想COMドライバーが速くても、シリアルケーブルのほうで問題が出ることがわかった。

  • 12MbpsのUSBケーブルは、わりかし良く出来ているほうなんだな、と。







ARM:Cortex-M格安ボードの件

http://www.eleki-jack.com/mycom2/noritan-stm8s-01-03-400.jpg

  • 実はSTM8Sという8ビットマイコンには、何の興味も無かった・・・
  • しかし、USB経由の書き込み用のマイコンがARM Cortex-Mだ!

http://www.eleki-jack.com/mycom2/noritan-stm8s-01-02-400.jpg

信じられないことに、このセットが750円(秋月)で買える。

EJの記事

DigiKeyの価格

stm32f103c8t6

  • ROM 64K / RAM 20K / 72MHz / STM32(Thumb)
  • STM8Sまで付いて、Cortex-M3 (stm32f103c8t6)のチップ単価より安い!

何故?

Q&A:どうしてこんなに安いのですか?

  • ワロタ
  • もしかしたらST MicroがSTM8Sを広めるワナかもしれない(って、罠というか、もろにSTM8S広告のためでしょ)

http://www.akizukidenshi.com/img/goods/1/M-03457.jpg

  • 良く見たら、I/O線の引き出しに難ありだなぁ・・・。
  • でも、きっとこれに俺ファームを焼いてジャンク活用する人が出てくるに違いない。うん、間違いない。







高性能で低消費電力、32ビット・マイコンへ移行すべきか

  • 露骨に言えば、PICやAVR(その他ではH8,NEC78K,8051系など)からARM(Cortex-M)に移行すべきか?という話。
  • C言語で書く場合はARM(Thumb)のほうがコードが縮むので、大規模なファームではファームサイズの縮小効果により、フラッシュ面積が削減出来、消費電力も減るということらしい。

反論

  • PIC18以下や8051系で大規模ファームをC言語で起こす場合は無論そうなる。が、AVRは元々コード効率、速度ともに優れているので、32bit化によるCPUチップ面積の増大と相殺すると考えられる。
  • PIC24以上では普通にgccが使用できコード効率も悪くはない。おそらくThumbと張り合える。問題はPICのエラッタの多さである。せっかくC言語で書けるのに、チップのバグに悩まされ開発効率が上がらない。
  • AVRでは8bit処理が得意で、コードエリア64kステップまで、データエリア64kBまでというアーキテクチャー上の制限があるので、それを越える規模のファームを載せる場合はARMという選択肢が自然だ。それに納まる規模なら相変わらずAVRでも構わないような気がする。(ただし、USBを内蔵するものはAVRは苦手だ)
  • H8は8bitCPUなのか32bitCPUなのか分からないような中途半端さが売りであるが、とってつけたような32bitコードのコード効率が悪すぎるので即刻捨ててARMに移行すべきだ。
  • 他の零細(?)8bitや16bitの石はとっくに廃れていると思うのだが・・・でもMC6802とかはしぶとく生き残っているし。
  • いまだに新しい8bit(STM8S)が開発されているところを見ると、Cortex-M3にカバーしきれない領域もあるのかも。

ARMに移行したいけれど・・・

  • 安いチップが売られていない。(だいたい1000円以上する)
  • QFPばっかりで、DIP品がない。
  • JTAGライターが普及していない。高い。
  • ARMといっても、ARM社が提供しているのはIPコアであって、チップではない。なので、ST MicroとかNXPとかAtmelとかのチップを買うことになる。(自社で起こす場合は別だろうけれど)
  • それらのチップはI/O周りが各社バラバラの設計である。







マイクロソフト Windows Phone 7 Series 発表、完全新規OS

まあ、頑張ってくれ。

  • ふーん、silverlightにもFlashにも対応しないのか。(ブラウザ内では)
  • つまり勝手サイトゲームの締め出し方まで模倣じゃん。







STM8Sの性能

シンセアンプラグドさん







STM8SのReference Manualを読んでみる。

  • 怖いもの見たさ。

/ATMEL_AVR/jpg/stm8s.png

  • え゛?、これ何?クラシカルな8bit CPU?
  • 命令語はバイト可変長で最短1バイト、最長5バイト。
  • Yレジスタを使う場合や間接アドレッシングには、Z80のような前置プレフィックスが付く。

どれに似ている?

  • 6800と65816を足して2で割ったような感じかな。
    • X,Yレジスタは16bitのアキュムレータとして使える。比較も可能。
    • X,Yを用いて16bit幅の乗算、除算が用意されている。当然除算は遅い。

どこがだめ?

  • SPはあるがFP(スタックフレーム)がない。
  • C言語に向かない。Z80や6800,65816でまともな効率のC言語処理系があっただろうか・・。
  • あったとしても、変数や引数がスタックフレーム上に置かれるようではPIC18Fと全然変わらない。
  • Flashは32bit幅だが、データメモリーは8bit幅。
  • gccがサポートできるような石ではない。

効率

  • 65816以下。PIC24以下。もちろんFlashの読み出しだけは65816に勝る。

AVRのほうが100倍良い。

  • どこがハーバードアーキテクチャーで、
  • どこが32bitバスなんだろう。

21世紀も10年を過ぎようとしている今日この頃、なんでこんなビンテージアーキテクチャーを持ち出すのか分からない。

  • アセンブラで書けとでも・・・。







今日のPIC遊び

usbキーボード PICmonitor

  • MICROCHIP謹製のhid bootloaderを18F14K50用にビルド。sw2の設定がUBW互換ボードと合わないので修正してみたり。
  • 瓶詰堂さんの古いHIDaspのソースを引っ張り出して、VID,PIDをPIC用に合わせてみたり。
  • そのavrsp.exeを使ってhid bootloaderにHID Reportを送り、返信を確認する。
  • ついでにベンチマークしてみる。
  • HIDデバイスのEP1は、双方ともにインタラプト転送で1フレーム(1mS)につき1パケット=64byteが最大値。
  • つまり、上り、下り片道だけなら64kB/Sec程度
  • HIDデバイスを使う限り、これより速くすることは不可能。(バルクのEPが使えるならこの6倍くらいはOKなはず。)
  • 速度面では、これで充分。というかこれより速くてもPIC側が遅いので。


うまくいったので、次やることを忘れないうちにメモ。

  • 上位レイヤーを使ってHIDmonを実装する。
  • 出来たら次は、タイマー割り込みに挑戦。
  • それも出来たら、PS/2キーボードハンドラーを入れる。<-----今ここ PICmonitor参照のこと。

実行中のPIC18F2550のSRAMをダンプ出来たり逆アセンブル出来るのはやはり便利


read more : PICmonitor



PIC18F:今日の、分かったこと

  • PIC18Fのリターンスタックは32Level用意されている。
    • てっきり6レベルかと思って、ヒヤヒヤした。
  • Timerは4チャネルもあるくせに、どれも駄目駄目だ。
    • 例えば、毎秒10000回の間隔で割り込みしたいとか、44.1kHzの頻度で割り込みしたいとか、
    • 思っても出来ない。外部からそういうクロックを与えるしかない。
    • なんと、インターバルタイマーの開始カウントや終了カウント値を設定できないのだ。
    • 一応16bit精度でタイマーコンペアとタイマーキャプチャーはあるのだが、どうやらそれだけでは駄目らしい。
    • もちろん、割り込んだときに再設定することで擬似的にインターバルタイマーにすることは可能だが、割り込み応答時間を正確に見積もらないといけないし、なんらかの要因で応答時間が狂ったらインターバル時計は狂ってしまう。
  • Timer0のプリスケーラーを1:1にして8bitモードにすると、CPUクロックの1/256ごとに割り込むように設定できる。
    • 実際にやってみたらそうなった。
    • その場合の割り込み周期は(12MHz/256)=46.875KHzになる。
    • 割り込み応答の時間総計が256クロックに達したらアウトだが・・・。
    • この時間を制御するのは、プリスケーラー設定しかない。
    • プリスケーラーの設定は、1:1〜1:256まで2のべきの分周比を設定できる。
    • やっぱり256クロックしか猶予が無いので、割り込みハンドラーは全部アセンブラで書くしかなさそうだ。
  • PS/2キーボードの受信はAVRのものがほぼそのまま動いたので、良しとする。
    • 実際にはデータを1バイト受け取ったあとの処理が256クロックをはみ出ているので対策は必要だが・・。


残りの課題

  • HID Reportの受信にWindowsAPIのReadFile()を使っていて、デバイス側応答がない場合にハングアップする問題の対策を考える。
  • PIC側UARTの送受信を割り込みハンドラーで行ってみる。
  • hidaspxのAVR書き込みファンクションの部分も移植する。
  • WinLIRCっぽいやつを作ってみる。(赤外線でビビビ)

しかし50%くらいPIC飽き飽きモードになったので、途中で投げ出すかも。




USB2.0:ハブの影響

  • USB2.0ハブなし。intel G31
    C:>picmon.exe
    TARGET DEV_ID=25 VERSION=1.1
    PIC> bench
    hid write start
    hid write end,  125.000 kB/    8.00 s,  15.625 kB/s
    PIC> q
    Bye.
  • USB2.0ハブあり。intel G31
    C:>picmon.exe
    TARGET DEV_ID=25 VERSION=1.1
    PIC> bench
    hid write start
    hid write end,  125.000 kB/    0.56 s,  222.024 kB/s
    PIC> q
    Bye.
  • 16倍も違う。


ところが、

  • USB2.0ハブなし。intel G31
    C:>picmonit.exe
    TARGET DEV_ID=25
    PIC> bench
    hid write start
    hid write end,  125.000 kB/    3.00 s,  41.666 kB/s
  • USB2.0ハブあり。intel G31
    C:>picmonit.exe
    TARGET DEV_ID=25
    PIC> bench 10
    hid write start
    hid write end,    1.250 kB/    0.28 s,   4.448 kB/s
  • なんと1/10になる。
  • なんで?

解釈

  • つまり、コントロール転送はUSB2.0HUBの機能によりパケットのおまとめが出来て、さらにマイクロフレームの恩恵を受ける。
  • インタラプト転送は、1mSインターバルの縛りがあるのでマイクロフレームの恩恵を全く受けないばかりか、余分なオーバヘッドを受けてしまう(?)
  • にしても1/10って・・・






PIC18:picspxを仮作成

  • PIC18F2550/4550を使って、HIDaspxの代替品を作ってみました。

read more : pic18spx






今日のPIC18F

>Timerは4チャネルもあるくせに、どれも駄目駄目だ。
--例えば、毎秒10000回の間隔で割り込みしたいとか、44.1kHzの頻度で割り込みしたいとか、
--思っても出来ない。外部からそういうクロックを与えるしかない。

抜け道を発見した。

  • Timer2は8ビットだが、PR2というPeriod Registerを持っていて、カウント値=PR2になると勝手に0に戻してくれる。
  • つまり 1:1 〜 1:256 までの任意整数の分周が出来る。
  • さらに、Timer2はCPUクロック12MHzの1/1,1/4,1/16のどれか1つを入力に取ることが出来る。
  • Timer2がさらに2分周されてMSSP(SPIとかI2C)の入力クロックになる。
  • Timer2の後段にさらにPost Scalerがあり、1:1〜1:16までの任意整数の分周を行なったあとにCPUに割り込みを掛けることが出来る。

つまり

12MHz ---> プリスケーラー ---> PR2による分周 ---> ポストスケーラー ---> CPU割り込み
                1/1            1/n (nは1〜256)    1/m (mは1〜16)
                1/4
                1/16 から選択

ということらしい。

  • Timer2は(何故か10bit精度を持った)PWM波形生成用のカウンターにもなっている。
  • なぜ10bitかというとカウンター8bitのさらに下位に、前段プリスケーラーの2bitを繋げて10bit表現を行っているらしい。
  • プリスケーラー1/1のときはFosc/4の分周器の2bitを持ってくるらしい。
  • だから、(プリスケーラー)1/2とか1/8が使えないのか。分かったぞ。
  • ATtiny2313ですら、16bit精度の任意インターバルタイマーが可能だと言うのに・・・。






自分メモ:EPSONマイコンを解析してる人がいた

Interface増刊 S1C17702基板 デバッグモニタ 調査記録

  • 自分のEPSONマイコン、現在絶賛死蔵中。





今日のPIC18: pic18spxを仮作成

  • PIC18F2550/4550/14K50を使って、HIDaspxの代替品を作ってみました。
  • 18F14K50用のファームでAVR/PICの両方のFlash読み出しに成功しました。

read more : pic18spx

  • PIC18F14K50を使って、TIMER2割り込みによるLEDチカチカ実験

read more : pic18timer2





今日のPIC18:ReadFile問題

  • Win32APIでReadFileするとデバイスからのUSBパケットが来るまでずっと待ち続けてしまう。
  • 要は、タイムアウトでアボートしたいのだが、
  • RS232Cやってたときに散々苦労した挙句非同期ReadFileは諦めてComm関係のAPIでお茶を濁した経験上、ReadFileはあまり信用していない。
  • しかし、こいつをやっつけないとストリーム受信っぽいやつがうまく作れないのだな。


適当に見切りをつけてlibusbに移行するという手もある。そのほうが性能は出せる。

  • ただしlibusbとWinVistaの相性は最悪らしい・・・





文明を崩壊させる方法

最近気づいたこと。

  • 本を読まなくなった。(買わなくなった)
  • 調べ物はたいていインターネット(google検索)で済ませてしまう。
  • 買い物(通販)やいろいろな申請とかもインターネット化されてしまった。
  • 電子書籍が流行ってしまったら端末がないかぎり一切の知識にアクセス出来なくなる。
  • ライフラインだって、たとえば電話回線も裏ではVoIP化されている。
  • スマートグリッドなんか広まったらほんとにインターネットがないと何も出来なく なってしまう。

しかしまてよ、インターネットは40年前には存在しなかったのだ。

  • この傾向はずっと続く。人類はインターネット(や、電子機器)に完全依存してしまったのだ。昔に戻ることは出来ない。

つまり、文明を崩壊させる方法とは、

  • 人類に便利な道具を与え、それに完全依存させる。
  • あるとき、突然それを取り上げる。

これだけで原始時代に逆戻りだ。「突然それを取り上げる」ということが、はたしてあり得るのかどうかだが、

  • 強力な電磁パルスで全ての電子機器が無力化される。(成層圏核爆発)
  • 電子機器が高度化しすぎて、あるときそれを(自力で)作れなくなる。(ロスト・テクノロジー)
  • 電子機器の製造が1国に集中しすぎて、その国の滅亡とともに供給が絶たれる。
  • 電子機器の中枢に関わる技術を1つの会社が独占してしまうが、いずれ崩壊してしまう。
  • 「電子機器」ではなく「インターネットクラウド」に置き換える場合もありうる。

杞憂に過ぎないと思うが、人類という種が、インターネットの影響により、ある意味大きく退化する(退化が始まる)ということは確かだ。人間はもはやインターネットに組み込まれたボーグへの道を歩んでいる。

ありうるシナリオとしては、

  • 電子機器の製造が集中しているある1国で秘密裏にトロイの木馬が全ての機器に仕掛けられていて、それが一斉に発動し機器が無力化する。
  • 電子機器にあらかじめイネーブラー(アクティベーション)が組み込まれていて、不用意に|故意にディセーブルにされる。

現実にiPhoneや携帯電話にはそのような機構が含まれているし、Windowsだって海賊版対策のためにWindowsUpdate側からリモートでOSが使えないようにすることだって出来る。

  • だから、すでに仕組み自体は存在するのだ。


核爆発ではないが、太陽系からわずか640光年先で超新星が近々誕生するかもしれない話題。





PS/2→USB変換器を6製品試す

  • 結局どれもだめだったらしい。





今日のPICmon

  • ASYNC ReadFile / WriteFile を実装した。
  • poll系コマンドの仮実装をしてみた。
  • Win7だとハブあり、ハブなしのどちらでも登り64kB/Sの速度が出る。
  • WinXPだと不調。48kB/Sしか出ないし、ハブありだとほぼ全滅。というかUSB 2.0ハブ自体を認識しなくなった。XPとHubの相性?わけわからん。


  • 結局、Athlon(Barton)の時代からマザーを5回くらい渡り歩いた(つまり、再インストールせずにだましだまし使っていた)WindowsXPだけに問題があるようだ。
  • たしかに、最初にi965上ではUSBが全然使えなかったし。(USBルートハブを全部消したら使えるようにはなった)
  • 普通にXPな別マシン上ではUSB 2.0Hubがあろうとなかろうと、ちゃんとFull Speedのインタラプト転送は1mSに1回通るようだった。

今後の予定:壮大な計画

  • あえてLPCXpressoを買わず、STM8S-Discoveryだけで手に入れて、オレオレファームを焼くという野望だけのために存在。

http://www.eleki-jack.com/arm/noritan-lpcxp-01-02-400.jpg

ちなみにLPCXpressoのLPC Linkの石はHighSpeed-USB(480Mbps) 付のARM-926EJ-Sでクロック最大270MHz(LPC3154は180MHz)

  • http://ics.nxp.com/products/lpc3000/lpc313x.lpc314x.lpc315x/~LPC3154/
  • SRAM 192kB / オンチップFlashは、入っていない、bootROMにより,外部Flash(SPI/NAND)かUSB(DFU)かSD-Cardを読み取ってBoot出来る。
  • つまり超ハイエンド(DS-Liteよりずっと上)のARM-926と、Cortex-M0もしくはM3のターゲットボードがペアで、 3000円を秋月に寄付するだけでもれなくプレゼント!
  • なんかもう、AVRとかPICをちまちまやるのがアホらしくなってきたな。(投売り価格の)PICkit2ライター単体買うより安いじゃん。


  • 簡易オシロ、ロジアナ ---たぶん簡単に出来るはずなんだけどなぁ・・・。
  • 割り込みUSART --- 今日、0008hと0018hの割り込み分けする方法が分かったから、あと一息。
  • 赤外線リモコン ---これもロジアナの応用。
  • USB to PS/2 ---HID-Keyboardの仕様書をちゃんと読めば作り方が分かるかもしれない。





LPCXpressoをポチる前にいろいろ調査

http://cliffhacks.blogspot.com/

  • なんかこのマイコン、DFU(USB)ブートなんじゃないかと予想する。
  • でもって、最悪なことにブートローダーがAESなんとかで暗号化されていて、ユーザーコードは実行できない予感。
  • 開発環境はCortex-M用のgccらしい。
  • http://www.jp.nxp.com/news/content/file_1668.html
  • CのランタイムライブラリRedlibはnon GNU、でもnewlibも使えるとある。(そりゃまあgccだから普通は使えて当然だ)
  • http://lpcxpresso.code-red-tech.com/LPCXpresso/
  • ターゲットボード側のLPC1343にはFullSpeed(12Mbps)のUSBは接続可能。LPC1114(Cortex-M0)にはUSBはない。





今日のPICmon

  • 18F2550と18F14K50の手配線基板(秋月C基板)を作った。
  • これでPIC18F(USB)基板は都合5枚も持っている。(うち1枚は秋月の1000円モジュールをマザー基板に差したもの)

/ATMEL_AVR/jpg/PIC/pic3.jpg

左:PIC18F2550 中:18F14K50+PIC24FJ64 右:18F14K50+ATmega88

/ATMEL_AVR/jpg/pic18f1.jpg

秋月のモジュールAE-18F2550

/ATMEL_AVR/jpg/PIC/pic18f4551.jpg

18F4550基板

  • で、調べた結果、18F4550と18F2550でSPIを使うと、AVR書き込みや書き込み後のベリファイでこける。
  • こけ方は2kBファームに対して2個程度だがほぼ90%の確率で起きる。
  • SPIクロックをいくら遅くしても同じ。速くしても同じ。
  • 18F14K50ではこけない。
  • エラッタのどっかに書いてあると思うんだけど、ソフトウェア実装のSPIでは全くこけないので、もう調べる気にもなれない。
  • しかしこれ、こけるんだったらSPI使用のJTAGライターもこけるはずなんだけど・・・。

SPIのたたき方が根本的に間違っているのかなぁ・・・

//------------------------------------------------------------------------
//uchar SPI_MasterTransmit(char cData)
//	SPI転送を1バイト分実行する.
uchar usi_trans(uchar data)
{
	SSPBUF = data;
	while(!SSPSTATbits.BF) {};  // BF = SSP Buffer Full . 1=Full 0=Empty 
	return SSPBUF;
}
  • SPIのクロックフェーズは4通りあるらしいので・・・。(実のところよくわかっていない)

read more : pic18spx





今日のPICmon

  • ハンズマンで電動ドリル(1980-)とUEW線を買った。
  • USB-Bコネクタ差込用の穴を広げるのにこれまでは細いドライバーとかキリでゴリゴリやっていたのが、電動ドリルだと超楽だ。工作が楽しい。
  • UEWはショートにさえ気をつければ、ふつうのビニール皮膜線とかジュンフロン線より楽だ。
  • 18f14K50を3.3Vで動かす実験がどうしてもうまくいかなかったのだが、今日原因が分かった。
  • なんと、3端子レギュレータのGNDが未配線だったのだ。
  • それでも、電圧が3V出ていたので気づかなかった。(なんで3.3Vじゃないのかなーとか気づいてたんだけど)
  • たぶん(3端子が)発振してるんだろうと思って、コンデンサーばかり増やしていたのだった。

PIC18F14K50+PIC24FJ64GA002基板のICSP端子関係を接続

http://akizukidenshi.com/img/goods/L/I-02000.jpg

  • してみた。

/ATMEL_AVR/jpg/PIC/pic24fj64.png

  • PGC/PGDのペアが3組ある。気持ち悪い。
  • PGMがない。しかしHVPというわけではなさそうだ。
  • ICSPモードに入るためにはMCLRをL->H->Lにした後32bitのIDをシリアルで送る必要があるらしい。その後MCLRをHにする。
  • ICSPモードから抜けるのはMCLRをLにするだけでいいらしい。
  • PIC18Fの書き込みプロトコルをそのまま持ち込めない。
  • 結局ICSPモードというのは、8080の割り込み命令受付状態のような気持ち悪いモード、つまり
  • Flashメモリ上の命令コードを実行するのではなくて、ICSPからDMA的に流し込まれた命令コードだけを実行するような雰囲気だ。
  • なので、16bit長のPIC18命令と24bit長のPIC24命令では、与えるビット数からして、そもそも異なっている。
  • FTDIのようなBitBangだけを実装して、あとはホストPCが複雑な制御をするというのもありかもしれない。
  • そうすると、これまでの前提が全部崩れてしまう。
  • Bulk転送なら良いが、HIDデバイスだったりとかLowSpeedだったりすると、BitBangでは速度低下がひどくなる。





今日のusbserial

  • 頑張ってTx割り込みとRx割り込みを実装してみた。
  • しかし、実効速度は112kbps程度で頭打ちとなり、ボーレートレジスタをたとえ900kbpsに 設定しても、119kbps程度しか出ないという結果になった。
  • つまり、1文字のTxとRxを両方ハンドリングするのに要する時間が、実は1000クロックくらい掛かっていて、それ以下にすることが出来ないというなさけないジレンマになっている。
  • TxとRxはだいたい独立しているので、TxかRxのどちらかで考えると、割り込み処理1回当たりに250クロック程度消費され、フォアグラウンド処理にも1文字当たり250クロック程度消費されているという計算になる。(実際はUSBバッファの扱いは全部フォアグラウンドなので、この比率はもうすこしフォアグラウンド側が大きいはずだ。)
  • (一部をアセンブラにしたり、インラインを徹底したりして)工夫して高速化しても、この倍がいいところだと思う。

結論としては、PIC18FによるUSB-シリアルの実効速度は全く期待外れだったことになる。

  • むしろ、現在公開中のusbserial.zipのほうが、全く割り込みを使っていないにもかかわらず、
  • 900kbps設定のときに300kbpsくらい出るので性能が良い。
  • つまり、割り込みなしのフォアグランド処理だけのほうが性能が良いという面白い結果になってしまった。
  • (割り込み処理に遅いコードを書いたつもりでは決してないのだけれど・・・)

結論が出たので、コードを整理してUP.

read more : usbserial






今日のPICmon

  • ps2keyb.c を統合したものを作った。
  • ユーザー関数をサポートして、ユーザー関数内でのprintサポートを始めようとした。
  • ハング多発、原因究明中。

なかなか手ごわいそのわけは、

  • (1)追加のプロトコルを決める。
  • (2)ファームに実装する。
  • (3)焼く。
  • (4)ホストPC側ツールにも実装する。
  • (5)試す。

ハングした。(1)とか(2)に戻る。

これを繰り返しているので効率が悪いらしい。

  • バッチ1個で全部ビルドしてテストするような環境が欲しいが、現在いろいろ不安定なのでそういかないのと、
  • リセットSWとブートSWを手抜きして(省略して)あるので、毎回USBケーブルを抜き差ししているのがいけないらしい。






今日のPICmon

ps2keyb.c を統合したものの続き

  • まず、PICは甘くない。
  • AVRでちゃんと動いていたソースも、PICに持ってくると全然間に合わない。
  • PS/2キーボードから送られてくるシリアルデータはCLKとDATAがあり9600bps程度(のI2Cのようなもの)なのだが、
  • それを正しく(low,highエッジともに抜けないように正確に認識するように)サンプリンクするには、最低でもその5倍くらいのクロック(53kHz程度)で割り込んでサンプリングする必要があるらしい。
  • 仮に50kHz割り込みだとすると、割り込みハンドラーが消費できるクロック数は最大で12MHz/50kHz=240クロック。
  • でも本当に240クロック使ってしまうとフォアグランドが全く動かなくなってしまうので、せいぜいその半分の120クロックくらいが望ましい。
  • しかし、逆アセンブルしてみると、割り込みハンドラー内には相当量の無駄な命令が落ちているのだ。(その大半はかなりの量のレジスタコンテキストの退避と復帰で、それにFSRが使用されている。)
  • なので、PIC用にはAVRのソースは流用できない。
  • CLKのFalling Edge割り込みのみを使用するように仕様を変更中。
  • INT0IEを使おうとしているのだが、これまたハングの連続攻撃を受け中。

PICは遅いし、良く分からない。

  • もちろんアセンブラで書けば、2倍程度には高速化出来るだろうけれど、割り込みハンドラーを全てasm表記しなければならないし、自分が使うレジスタコンテキストは全部自前で退避する必要がある。(それに、asmからCの関数を絶対に呼んではならない縛りがつくので、FIFOのようなものをC側と共有するのも面倒になる)

結論が出たので、コードを整理してUP.

read more : PICmonitor






今日のHIDkey

  • ps2keyb.c をHID-Keyboardデバイスに移植した。
  • かなり不完全だが、PS/2 Keyboard to USB 変換アダプタとして機能する。

read more : pic18hidkey

そして、今日のpicmon

  • ロジアナもどきのサンプリングレートを10kHzにしてみた。
  • 但し、10kHz対応するのは18F2550/4550のみ。
  • なぜかというと、サンプリングを割り込み内で実行していて、
  • fifoキューを贅沢にも256バイトも取っているからである。
  • そして、サンプリングレートの切り替え機能は無いが、フリーランしているTIMER2割り込みの周期をPICmon側からリアルタイムに変更できる。
    PIC> p pr2 08
    こうやって、
    PIC> graph portb
    とか出来る。
  • 便利なんだか不便なんだか・・・。

read more : pic18spx

番外編

  • pic18spxのgraph機能を使って、赤外線リモコンセンサーのパルスを表示してみた。

10kHzサンプリング

/ATMEL_AVR/jpg/PIC/infrared.png

番外編2

  • アナログサンプリングも実装してみた。

接続

AN0 (PIN2) <=== アナログ信号

使い方

C:> picmon/picmonit.exe
PIC> graph analog

read more : pic18spx

番外編3

  • 赤外線リモコンの波形観測が出来た。

■ 応用3

  -------------------------------------------------------------------------
  赤外線リモコンの受光波形などを観測することが出来ます。
  -------------------------------------------------------------------------
  リモコン受信器(38kHz)の出力端子をPortA.bit0に繋いで、
PIC> graph porta

フリーランモードで観測します。

PIC> graph porta trig 0

porta bit0の変化によるトリガーで観測します。

/ATMEL_AVR/jpg/PIC/infrared2.png

read more : pic18spx






自分メモ:STM8S-Discoveryを汎用JTAGライター化する記事

ねむいさんのぶろぐ

License::

vsprog and vsgui is distributed under GPLv3 license.
OpenOCD support, CDC and MSC, USB_TO_XXX is distributed under GPLv3 license.

Supported Target:

All targets supported by OpenOCD
STM32_JTAG/SWD/ISP
STM8_SWIM
AVR_ISP/JTAG
89S51_ISP
C8051F_JTAG/C2
LPC900_ICP
MSP430_JTAG(without TEST pin)
PSoC1_ISSP
CPLD/FPGA_JTAG(by svf)

8bitマイコンのターゲットボードはもちろん使いません。

  • とりあえず鶏卵用に別のJTAGライターが要るのか?・・・FT2232Dでいいのかな。一応シリアルEEPROMは載せてある。(壊れたNICから抜き取って)






コールド・スリープ

R25:人間の冷凍保存、始めました(1/2)

妄想:

  • 人間のコールドスリープが無理なら、
  • まず、シマリスに惑星探査の方法を教えこませる。
  • シマリスを冷凍保存する。
  • 星間ロケットで惑星に送り込む。

これでOKだ。

  • え?無理がある?

ちなみに、人間がコールドスリープして、未来の医療技術で・・・、というやつは、

  • ほんとにその可能性が高いならみんながコールドスリープに入り、
  • だれも技術進歩に貢献しなくなって、
  • 未来になっても医療技術が進歩してなかったなんていうオチに。