2010-04
2010-03← → AVR/PIC両用ライター usbシリアル変換 usbキーボード 簡易ロジアナ、赤外線リモコン信号観測
4月:ついにLHC再開3.5TeV 何が見える?
- 暗黒物質?Higgs粒子?次元の扉?はたまた地球の破滅?
ATLAS実験オフィシャルBlog
KEK
先月のまとめ
- PIC24Fライター--完成
- FPGA基板(LatticeXP2)でLチカ。--完了
- NXP基板でOpenOCD --玉砕
- hidmon-2550/hidmon-14kのソース整理。--済み
- hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。--ミカン、じゃなくて未完。
今月のたわごと目標
hidmon-2550/hidmon-14kのHID転送モードをインタラプト転送に戻す。--- 済み- (もれなく雑誌が付いてくる)SH2A基板を(万が一)買ったら使い道を考える。
- FT2232LでOpenOCD(JTAGkey互換品)を試す(作ってみる)。
- --->多分やらないかも。レベルコンバータ入手が面倒なのと、CQ付録基板でJTAGが必要になるシチュエーションはあまりなさそう。
- 必要になったときに考える。
- STM32のDFUビルド環境を整える。
まあ、素人にはどうせこの程度しか出来んのですわ。
hidmon-2550/14kのHID転送モードをインタラプト転送に戻す。
- うまくいった。
- コントロール転送系よりコードサイズは大きくなる。
- poll系は未実装。
bootloaderとしてのテストはこれから。
ファーム書き込みテストはパスした。
bootloaderとして使ってみた。一応使えるようになった。
- poll系は未実装を返すようにして、ホストPC側で代替処理に切り替えた。
毒味版のダウンロード(仮)
picmon.exeは統合化済み。
- 使用例1 --- ブートローダーから800番地のアプリ(例えばpic18spxファーム)を起動する。
C:>picmon.exe PIC> boot 800 PIC> q
- 使用例2 --- pic18spxファームから、ブートローダーに制御を移す。
C:>picmon.exe PIC> boot 0c PIC> q
- これで、ブートジャンパーを切り替えてUSBケーブルを挿しなおす手間は不要になった。
PIC関係ツールが(とても)分かりにくい件
まず、反省
- テキトーに作って、作り散らかしていた。(実験している、とも言う)
アーカイブ名 | 機能 | 実行ファイル | コメント |
hidmon-2550 | ブートローダとPICモニタ | picboot.exe / picmon.exe | diolanローダーを改造しただけのもの。18F2550/4550対応品 |
hidmon-14k50 | ブートローダとPICモニタ | picboot.exe / picmon.exe | diolanローダーを改造しただけのもの。18F14K50専用品 |
pic18spx | PICモニタとAVR/PICライタを実現するパッケージ | picmonit.exe / picspx-gcc.exe / picwriter.exe / writer24.exe | hidmon-2550/14k50ファームウェアをC言語でリライトして機能強化した(AVR/PICライター部分を追加した)もの。ファームのサイズが大きいので、ブートローダーとしては使えない。 |
picspx-classic | ATtiny2313(HIDaspx)ハードウェアを使用してPIC18Fに書き込むWindows上のツール | picspx.exe | 読み書きは非常に遅い。最初にPICにブートローダーを書き込むための限定ツール。 |
- さらにもう一個追加される。
アーカイブ名 | 機能 | 実行ファイル | コメント |
pic18boot | ブートローダとPICモニタ | picboot.exe / picmon.exe | ソースはアセンブラのままで、hidmon-2550/14k50とデバイスごとに別ソースになっていたものを統合し高速化したもの |
- なにがダメかというと、実行ファイルの名称がダブっているところ。
- 18F2550/18F14K50で別々になっていなければならない実行コマンドを同一名称のexeにしていた。
- picmon.exe / picmonit.exeのように良く似ている実装なのに実行ファイル名称が微妙に違っていること
- picmon.exeはアセンブラ実装側ファームをサポートし、picmonit.exeはC言語実装側ファームをサポートしている。
結局のところ、何をやりたいかというと・・・
- 3.3〜5V動作で、廉価で、DIP品が売られていて、USB内蔵のPIC18Fxxxxにプログラムを書き込みたかっただけ、とも言える。
- じゃあ、PICKit2を買えと言われると、まったく反論できないわけで・・・
図説
- PIC関係ツールを図式化して説明していただきました。
senshuさんのサイトに飛びます。
携帯:SIMロックフリー論争
- http://pc.watch.impress.co.jp/docs/column/mobile/20100405_359208.html
- http://www.itmedia.co.jp/promobile/articles/1003/31/news070.html
- そもそも無茶な話。
- なぜこのタイミングで出てきたかというと、iPad発売タイミングだから。
- おそらくガイアツ(外圧)。
LTEというのは3Gの次の規格なのか?(3.9Gらしい)
http://www.rbbtoday.com/article/2008/10/01/54649.html
- そうすると何が起きるか?
携帯電話(ハードウェア)はコモディティ化する。
- iPhone/iPad,Android,Kindleなどに収束してしまう。
- ガラパゴス消滅の危機!
Apple、第4世代iPhoneではCDMA版の提供も計画か - WSJ報道
- つまり、SIMロックフリーになってもAUと他2社間ではそもそも通信方式が違うので端末を融通できないってこと?
まあ、それは置いといて、
- iPhone/iPadがどのキャリアでも使えるようになってしまうと携帯キャリアは単なる無線WANプロバイダーに成り下がってしまう。(昔のような、端末製造電機メーカーを牽引する強い指導力は無くなる)
- そうすると、台湾中国韓国などメーカーもAndroid格安端末を製造するようになり端末のコモディティ化が起こってしまう。
- 日本国内メーカーもAndroid端末を調達するようになってしまうだろう。(使いやすいのかどうかは別として)
孫さんが言うように、
- DoCoMoとSoftbankは端末融通が可能なので、インセンティブを利用した端末安売りが出来なくなり、競争原理がSoftbank不利に働いてしまう。
あとの問題は、
- 音声通話が廃れてしまうかも。(もう廃れているのかな)
- Twitter,メッセンジャー、その他文字ベースのコミュニケーションとか(iPadなどでの/Web)アプリなどが携帯端末の主要用途になってしまう。
- 音楽や書籍などのダウンロードマーケットは携帯キャリアではなくAppleとAmazonらによる寡占がひどくなってしまうかもしれない。
Appleの驕り
Apple、「iPhone OS 4 SDK」規約変更 - Flash CS5/MonoTouch排除へ
新規約によれば、iPhoneアプリはiPhone OSやWebKitで実行可能なObjective-C/C/C++あるいは JavaScriptで必ず記述されなければならないという。また、これら言語で記述されたコードのみ がコンパイルによって規定のAPI群へのアクセスを許可されるという。 中間言語の使用や中間レイヤーを用いるツールの利用も禁止されるということだ。
- 自分で自分の首を絞めやがれ。
Objective-C/C/C++あるいは JavaScript
- C以外は全部ダメ言語じゃないか。
ARMの難易度はPIC以上?
- やっとビルドが通るようになった。
- 焼いてみると、案の定デバイス認識出来ない。
- やっとスタートラインか。
read more : ARMCortexM3
- おそらくLチカから始めるしかないのだろう。
- デバッグするのにOpenOCDがあったほうが良いのだろうけどドングル持ってない。
- そもそもARMを始めようとしたきっかけはARMを使ったOpenOCDドングルが欲しかった(作りたかった)からだ。
あれ?ここも鶏卵問題の発祥地?
そうやって、再帰問題ばかり作ってる。
つまり、
- ICEやICEに近いデバッグ環境とか、純正コンパイラ+すぐ動くUSBサンプルソースとかをすでに持っているのであれば、
- わざわざ大昔のマイコンモニターもどきを作ったり、JTAGKeyもどきを作ったり、GDBスタブを移植したりする必要は全くないわけ。
- そのような恵まれた環境でLチカをやったとしても何の達成感も得られない。
禅問答
- 無いから作る(作ろうとしている)
- すでにあるなら、何もしない。(何もする必要がない)
CQ:STARM基板
久々にクソなシステムを見てしまった。(DFUのこと)
- ビルドはMake一発で出来るようになった。
- main()関数をLチカのものに差し替え(#ifdefで)ビルド。
- 実行?しようとしたら、何これ珍システム(DFUのこと)
- HEXをDFUに変換するためにわざわざGUIを起動。
- HEXファイル選択ウィンドウうざい。
- dfuファイル選択ウィンドウうざい。
- 上書き出来ない。一回dfuを消さないと生成出来ないクソシステム。
- そして、DFuSeという変なダウンロードGUIを起動。
- dfuファイルを選ぶ。
- 書き込む。
- J6ジャンパーをOPENにする。
- USBを一回抜いて挿す。
- Lチカ成功。
GUIが生産性を上げるなんて誰が言ったんだっけ?
STARM基板について、今のところ分かっていること。
- キホンノキホン、Lチカソフトでさえ、有償コンパイラとgccで全くビルドが通らないくらい書き方が違うこと。
- もちろん、ヘッダーファイルもファイル名が違う。
- Lチカは動くが、USBデバイスをビルドしても不明なデバイスになる。(USBとして全く機能していない)
- ビルドのターンアラウンドに要する手間がかかりすぎて駄目。
hexがそのまま書き込めるなら、DFuSeのようなものを起動したままで書き込みボタンを押すだけなのに・・・
この開発環境はDFUが全てを台無しにしている。
- Lチカをprintf代わりに使って試したところ、
Set_System()USB_Init()呼出し前までは生きていて、呼出し後に全滅していることが判明した。たとえばEVAボードとCQ基板でXtalの周波数が違いすぎていてGHzオーダーで動いてしまうとかそんなオチ。PLL関係は8MHz水晶の9逓倍で同じ設定だった。
今のところ何が悪いのか分からない。
- USB_Interrupts_Config()にて、
NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000);
- が必要らしい。
- 主な問題はそれだけだった。
- vcomとhidは一応PCからデバイス認識するようになった。
- 機種判別的には、
#ifdef USE_STM3210C_EVAL
- になっているところは使わないのが正解のようだった。
hidが動かない件
- HIDデバイス認識まではこぎつけたが、PICmonから触ろうとすると、ProductID取得で失敗するようだ。
- VendorID,ProductID,Serialをオリジナル版に戻すと取得できる何故
- 実はSerialバッファが書き換え(上書き)バッファになっていて、サイズを大きめに確保しないとハングする仕組みが導入されていた。
- 定数バッファを上書きするなよと言いたい。酷いつくりだ。
- せめてコメント書いとけよ。>玩具屋
相変わらずhidが動かない件
- Custom_HIDのサンプルはEP1バッファのサイズが異常に小さい(2byte)
- こいつを64byteにして、echobackを返すようなコードを書いている(つもり)なのだが・・・
- エコーバックは返ってこない。
- というか、EP1エンドポイントへの書き込みコールバックさえ呼ばれていないような感じ。
- なんで?
理由はusb_prop.cにあった。
- ENDPOINTの初期化はusb_prop.cで行っていた。
- ここで、EP1BUFのアドレスやサイズの設定が行われていた。
- 何故か、EP1BUFのアドレスだけはusb_conf.hに定義していて、サイズに関してはcソース内で決め打ちだったのだ。
- てっきりディスクリプタに書いた値を採用するのかと思っていた。(あるいはEPのサイズはヘッダーで定義して、双方がそれを参照するとか。)
一応、ここまで出来た。
- Custom HIDクラスに64byteのEP_INとEP_OUTを用意。
- ECHOBACKとPEEK,POKE(両方ダミー)が動作。
read more : ARMCortexM3
PICKit3が安い
4500円
- http://akizukidenshi.com/catalog/g/gM-03608/
- 今まではDebugExpress込みで7000円でしか買えなかった。
- PICKit2なら3500円
- http://akizukidenshi.com/catalog/g/gM-02508/
もうライターを自作する時代は終わったな。
その前に、PICKit2互換ライターは(価格的に)終了。
エイヤフィヤトラヨークトル氷河の火山
アイスランド火山灰:飛行機への影響と「飢饉」の可能性
アイスランド南部 エイヤフィヤトラヨークトル(Eyjafjallajokull)氷河
- この氷河の名前、覚えられないんだよな。
- どこで区切るのかな?
- 飛行機が飛べないなんて、これから起こるであろう気象への影響に比べれば小さい小さい。
ARMの難易度はPIC以上!
例えば、USBフレームワークを入手したいとすると、
- http://ics.nxp.com/support/documents/microcontrollers/?search=USB&Search.x=9&Search.y=11
- どれを落とせばいいのか分からない。
- 品種依存ソースしか存在しない。
- 品種依存ソースを落としてみると、中身(Copyright)はKeilだったりする。
- つまり、NXPはフレームワークを提供するつもりがないようだ。
- USBスタックが何種類か存在するが、どれも製品のようだった。
- MicroChipですら、共通のUSBフレームワークをちゃんと無償提供している。
ある意味、ARMはPIC以下。
- NXPの製品ラインナップですら、まともなフレームワークが提供されていなくて、
- サードパーティのUSBスタックを買えという有様だ。
- フリーソフトでLPCUSBというものがあるんだけど、LPC23xxビルドが見当たらない。
- メモリーマップ(*.ld)だけLPC23xx対応してみたんだけど、全然動かない。
ARMクロスコンパイラ構築
- Windowsでやるとビルドがえらい遅いので、Linuxに乗り換え。
- 実はローカルHDD上でやればそんなに遅さは気にならない。
- sambaマウントしたドライブでやると死ぬほど遅い。
ビルドのコツ
- 最初にCだけ作って、あとでC++を作るよろし。
まず、アーカイブを適当なところに展開
$ mkdir build $ cd build/ $ tar xvfz binutils-2.19.tar.bz2 $ tar xvfz newlib-1.17.0.tar.gz $ tar xvfz gcc-4.3.0.tar.bz2
ビルド用ディレクトリを作成
$ mkdir _binutils $ mkdir _gccbuild $ mkdir _newlib
まず、binutilsから。
$ cd _binutils $ ../binutils-2.19/configure --target=arm-eabi --prefix=/usr/local/arm $ make $ sudo make install $ cd ..
次、gccのC言語のみ。config内容はWindowsのWinARMコマンドラインのhelpから取得
$ cd _gccbuild $ ../gcc-4.3.0/configure --prefix=/usr/local/arm \ --target=arm-eabi --disable-nls --disable-shared --disable-threads \ --with-gcc --with-gnu-ld --with-gnu-as --enable-languages=c,c++ \ --enable-interwork --enable-multilib --disable-libssp --disable-libstdcxx-pch \ --with-dwarf2 --program-prefix=arm-eabi- --with-newlib \ --disable-newlib-supplied-syscalls --disable-libunwind-exceptions \ --disable-newlib-atexit-dynamic-alloc $ make LANGUAGES=c all-gcc $ sudo make LANGUAGES=c install-gcc $ cd ..
次はNewlib
$ cd _newlib $ ../newlib-1.17.0/configure \ --prefix=/usr/local/arm --target=arm-eabi $ make $ sudo make install $ cd ..
最後に、残りのC++も含める。
$ cd _gccbuild $ make $ sudo make install $ cd ..
だいたいこんな感じ。
LPC2388:USBが動かない理由
- どうやら、割り込み関係でLPC214xと互換性がないようだ。
- どちらもarm7tdmiなので同じだと思っていたが・・・。
- IRQハンドラーの処理が、LPC214xだと、
example/crt.s
ldr PC, [PC,#-0xFF0] /* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by Trevor Martin */ ldr PC, FIQ_Addr
- になっているが、
- LPC23xxだと、
LDR PC, [PC, #20] @ IRQ entry, jump to IRQ handler LDR PC, [PC, #20] @ FIQ entry, trap .word Reset_Handler @ Reset handler .word Trap @ Undefined Instruction handler .word SWI_Handler @ Software Interrupt handler .word Trap @ Prefetch Abort handler .word Trap @ Data Abort handler .word IRQ_Handler @ IRQ handler .word Trap @ FIQ handler
- になっていて、
IRQ_Handler: SUB LR, LR, #4 @ Adjust LR_irq and push it STMFD SP!, {LR}
MRS LR, SPSR @ Save SPSR need to be saved for nested interrupt STMFD SP!, {R0-R3,IP,LR} @ Push scratch/used registers and SPSR LDR R0, =LPC_BASE_VIC @ Get the ISR address pointed by VIC_VectAddr LDR R0, [R0, #VIC_VectAddr] MSR CPSR_c, #M_SVC @ Enter SVC mode and enable Irq and Fiq
STMFD SP!, {LR} @ Call the ISR MOV LR, PC BX R0 LDMIA SP!, {LR}
MSR CPSR_c, #M_IRQ | B_Irq @ Enter IRQ mode and disable Irq LDMIA SP!, {R0-R3,IP,LR} @ Restore scratch/used registers and SPSR MSR SPSR_cxsf, LR @ Restore SPSR_irq
LDR LR, =LPC_BASE_VIC @ Issue EOI command to the VIC STR LR, [LR, #VIC_VectAddr]
LDMIA SP!, {PC}^ @ Reruen from the IRQ handler
- と、なっている。
- つまり、lpc214xのあっさりジャンプと上記コードは違いすぎる。
ldr PC, [PC,#-0xFF0] /* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by
- さらに、
.equ LPC_BASE_VIC, 0xFFFFF000 .equ VIC_VectAddr, 0xF00
- なのも意味不明。
そもそも
ldr PC, [PC,#-0xFF0] /* see page 71 of "Insiders Guide to the Philips ARM7-Based Microcontrollers" by
- って、どこに飛ぶつもり?
-0000_0ff0だから、ffff_f010か?
- この命令が置かれている場所は0000_0018だから、ffff_f010を足すと ffff_f028(f024??)になる(???)
- おそらくそこに原因ベクター(飛び先)が現れるようなハードになっているのだろうが、
- その番地もLPC23xxだとFFFF_F000+0000_0F00=FFFF_FF00だから、どのみち辻褄は合っていない。
- しかし、マニュアルを見ると、どちらの石もVICがFFFF_Fxxxあたりに出ていて、それほど違いがないようにも取れる。
- なんかこういう根っこの部分はメーカー側がしっかりしたフレームワークを提供しないと困るなぁ。
で、結局・・・
- LPC214xとLPC23xxで、VICのつくりは似ているように見えるが、アドレスが違うので、ソースを流用できない。
- LPCUSBは、残念ながらCソース内にVICなどのアドレスをじか書きしているのでポータビリティがない。
- そもそもARMの多品種を製造しているNXPは周辺定義ヘッダーなどを正しく管理して提供すべきなのに(意図してかどうか不明だが)そうしていない。モスバーガー屋だけじゃなくってRenesasだって、ちゃんと、やってるんだぞう!
続・・・
- VIC周りは直したつもり。
- TIMER割り込みはちゃんと来ている。
- USB割り込み許可したあたりでのハングも直したつもり
だけどUSBデバイスとしてちっとも認識しやしない。
- なんかI/OピンをUSBコントロールに使っていて、またチップ間の非互換があるっぽいな。
いやいや、そんな生易しいもんじゃなかった。
- LPCUSBのusbhw_lpc.c に書かれてるUSB関係のポートアドレスはLPC23xxと全く互換性がないし、全部絶対アドレスで書いてあるじゃん。
- さらに、LPC23xx.hにそれ相当のポートアドレスが載っているなら許すけれど、そっちはそっちでUSBOTGポートと混ざっていて分かりにくい。
これ全部NXPが悪い。でたらめにも程がある
続き。
- とりあえずUSB周りのポートアドレスをFIXしてみた。
- やっと、「不明なデバイス」というメッセージが出るようになった。(今まではそれさえ出なかった)
- メインループのハングはしていない。
- 「不明なデバイス」になる原因は不明。
LPCXpresso微妙に値下がり
- http://akizukidenshi.com/catalog/c/clpc/
- 2800円。
- ここであえてCortex-M0を選択する理由ってあるのだろうか・・・。
Apple死ねばいいのに。
きまぐれ日記より
- http://chasen.org/~taku/blog/archives/2010/04/mecabiphoneosx.html
- そもそもMacOS-Xって、最初からFreeBSDじゃないのか?
- iPhoneやiPadだって、カーネルはFreeBSDベースなんだろ?
- だったらソース公開しろよって感じ。
- いっそFreeBSDカーネルをGPLにしちゃったら?
思いつきで
- 8bit Port x 4というほぼ理想的なPIN Out.
- アドレスバス16bit , データバス(双方向)8bit , /RD , /WR , /CE (64k全部埋めるならCE要らない?)あと5bit余り。 外部ラッチ無しだとちょっと厳しいかな。
- SRAMはHM-628128LPとかなら腐るほど(といっても40個くらいしかないけど)余っている(もちろん5V DIP品。要る人いるなら差し上げますけど)
- コードエリア64Kあるので、マルチアーキテクチャエミュレータ(8080/6800/6809/SCMP/...)になれる。たぶん。
- うまく作れば、内蔵SRAM 4Kのうち1KくらいをSRAMからキャッシュするように出来るかも。
- 起動時に内蔵FlashからSRAMにブートコードを書きこむようにすれば自力ブート出来る。
- CP/Mエミュレータというよりむしろ、MZ−80Kエミュレータが欲しい。
- ビデオ回路は外付けのPIC24Fか別のAVRかな。5ビットではつらいけれど。
- あ、そうか、/CE のかわりに /IOREQのようなピンを1つだけ設ければ、外部バス信号を他のモジュールとの通信に24bit全開で使用できるんだっけ。
- 当然20MHz動作。場合によってはOverClockingもありで。
- 問題は・・・BIOS ROM(SP−1002)と、SP−5030とかをもう紛失済みであることだ。(カセットテープなら残っているかもしれないのでサウンドブラスターで吸い出すことも考えられるが・・・)
単なる思い付きだけんね。実行するとは限らないし。誰かかわりにやって欲しいくらいだ。
- はたしてAVRの20MHzに、レトロCPUを何MHz換算でエミュレート出来るのか?
- ただそれだけが関心があるのであって・・・。
- FPGAだと出来て当たり前なんで全くやる気がしない。AVRでやるところに意味があると思う。
今日の、Apple死ねばいいのに。
アップル、ARM買収を検討か--英報道
- アップル、ARMを一人占め。
- ARmチップのライセンス料金吊り上げ開始。
- 性能上限を設けて、他社には高性能チップを生産させない。(Adobeへの仕打ちと同様に)
- これで、他社(Android,Microsoft製うんちゃら携帯)を全部殲滅だ!
- そうなると、Renesasチャンスだ!
- RXマイコンのIPライセンス商売開始だ。
・・・って、ならないよな。
石油は採掘する時代から生産する時代へと変る。
藻類から作られる石油はジェット燃料となり、日本から石油が世界に輸出されるようになる。
- http://blog.goo.ne.jp/2005tora/e/f9d52904c89abac55615365d1275f82b
- 凄い。
- 日本も捨てたもんじゃないね。
苺:STM32F103VET6基板が3150円
DWM誌付録のSTM32F103のFlash増量(4倍)版。RAMも64kB
- http://strawberry-linux.com/catalog/items?code=32103
- ピンヘッダーとかUSB Bコネとかのパーツも付いているのでDWM誌を買うより断然お買い得感がある。
- なんといってもSRAMが多い(64K)
- しかもDFUが焼かれているので、JTAGケーブルを持っていなくても即使用できる気軽さ。
天安門事件を役立てる方法
● 簡単で完璧な阻止率100%のスパム対策の実装について
- 最近 .cnサイトからのアクセスが多いので(w
- やってみた。
- ここはdump2html.inc.phpで生成しているので、./skin/pukiwiki.skin.phpとかそれの代替のphpソース 1個に埋めて、あとは再生成するだけだ。
- はたして効果あるのかな?
- 理論上、.cn以外の全サイトにこれを埋めることで、.cnの中からは世界が消滅したように見えるはずだ。
- Webサイトアクセスは遮断できるようだが、.cnからのこうげきをふせぐのはむりそうだ。
Google、パスワード管理システムのコードを盗まれていた - スラッシュドット・ジャパン
今日も、Apple死ねばいいのに。
オンラインでApple純正製品が購入できるのはApple StoreとAmazonのみになる模様。 AmazonはアメリカのApple Catalog & Internet Resellersで登録されているが、 日本ではこの登録プログラムが無い為、日本の小売り店にはオンライン販売が許可されないとのこと。
- http://temple-knights.com/archives/2010/04/apple-yodobashi-stop.html
- いっそ、日本でのApple製品の販売を全部禁止しろ! ---いや、禁止しない代わりに独禁法違反で制裁金だな。トヨタの仕返しだ!
- ついでに所持も。(児ポルノかよ?)
ってゆーかあの会社の方針、なんとかならんのか?
WinARM(arm-eabi-gcc)でfloatが使えない件
- Linuxでビルドしなおしたarmgccでは、ちゃんと使えている。
- WinARMのほうは浮動小数点を使った瞬間にリンクエラーでこける。
- なんかlibgcc.aに
__aeabi_dmul
とかもろもろのsoftfloat関数が無い。
- なんでだろ?
- よく分からないけれど、ARMクロスコンパイラ構築Linuxで作ったlibgcc.aをコピーすればリンクは大丈夫のようだ。
- まだ動作テストまでやってないけれど、ちゃんと動くことがわかったらlibgcc.aをuploadしておこう。
- 普通にLinuxを使っている人なら簡単に(10分くらいで)arm-gccをビルドできるので、出来たlibgcc.aをWinARMの該当ディレクトリにコピーすれば浮動小数点も使えるようになる(はず)
参考文献。
LPC2388:USBが動かない理由
- いろいろいじくり回しすぎたので、何が原因だったのかさっぱり覚えていない。
- print文を埋めてデバッグする要領で、Lチカを埋めて試行錯誤を繰り返すしかなかった。
- JTAGがあれば簡単に原因が分かるかと言われるとそれも違うような気がする。無限ループになる箇所くらいなら分かるのだろうけれど、無限ループにはならずにUSB認識しないというだけなので、デバッガで追えない。
- そりゃ、どっかでASSERTするのであれば、シリアルコンソールを見れば何が起きたかは分かるけれど。普通にスルーしてメインループは回っているので、デバッガを使っても何が悪いのかなんて分からない。
- PICのときはUSBプロトコルアナライザが大いに役に立った。それはディスクリプタストリングを返すルーチンが元から腐っていた(ページアドレス決め打ちで書かれていた)のを見つけられたからだ。
- 今回のARMではUSBDevice側が全く微動だにしていなかったのでアナライザも役に立たない。
- 結局ソース書き換えてから試すまでのサイクルをどれだけ短縮できるかか勝負だった。
で、何が悪かったんだろう。いろいろあった。
- crt.S(?)swi(?)その辺は弄り回しすぎて一回りした。
- LPC23xx.hとかUSB周りのポートアドレスが腐っていたのが一番やられた。
- USBCLKCFG ポートの設定が抜け落ちていた。
- HW初期化周りにもいろいろ不文律があるようだ。自分にはさっぱり分からない。
- で、とにかくLPC214xとLPC2388ではアドレスも初期化手順も違いが多くて、まともではないような気がした。
- この様子だと、LPCXpresso(Cortex-M3)はもっとひどいかも。
あとでまとめよう。ARMはもう飽きた。
read more : interface 2009-05付録基板で遊ぶPartII
C級出版:SH−2Aさっそく落とし穴が
水晶は何MHz?
デフォルトはキャッシュOFF?
- ほかにもありそうだ。
- 開発環境がHEWなので、いろいろとね・・・色々。
- 内蔵SRAMが1Mバイトとか言ってるけれど、
殆どはフレームバッファ(データ用)としてしか使えないとか・・・(?コード用は64Kとか書いてあったので心配だ)
- んなこたあなさそうだ
- 高速SRAMは64kしかない。
- i-cache,d-cacheは各8kB,高速SRAMはcacheしない。
付録基板は所詮ジャンク基板なのか?
C級出版:SH−2Aって、国産ロケットみたいだな。
2枚冊も買った。
- SPDIFいじりにも使えそうだし。
- ほんとにSRAMが1MBも載っているんだな。
だれもが思いつくネタその1
- uCLinux動かんかいな。
- 内蔵1MBではさすがに厳しいといわざるをえない、たぶん。カーネルは600kBくらいらしいけどあぷりは動かないか。外部RAMを増設できるなら良いと思う。
- CP/Msh-2a
- きっと速かろう。
- ビデオ出力でコンソールが出せるといいのに。
- なんかこうフレームバッファがキャプチャを兼ねてるところといい、QVGAなところといい、RGB565なところといい、オーバレイするところといい、まるでデジカメのパーツみたい。
だれもが思いつくネタその2
- CP/Mは古すぎて誰もソフト持ってないと思うので、(それにディスク入れ替えのたび^Cは21世紀には理解されないと思う)MS-DOSくらいはエミュれないかハニー!というわけでDOSエミュ。
- もうひとつ、往年の名機PC9801エミュ。だって主記憶1Mバイトもあるじゃん。るねさすもNECに買収されたことだし頃合も良かろう。
- PC9801って640kBしかRAMがなかったんだよしかもD-RAM。こっちはSRAMで1Mバイト。夢みたいだ。
- クロック比:元祖PC9801は8086−
8MHz(だっけ??)いや5MHzなんだな。だから144対5。 - CISCとRISCの違いがあるしSH−2Aは2命令同時issueなのでたぶんこの10倍、1440対5くらいの開きがあるので、 JITコンパイラなんて載せなくてチンタラエミュレーションしても10倍速くらいになるかもしれない。
- これもビデオアウトをどうするかが鍵なんだがな。難しそうだな。TEXT-VRAMがないから全部グラフィックバッファに持ってかれるとメモリー無くなるもんな。どうやるかだな。
- ウルトラCとしては2冊同時購入して片方がTEXTVRAM担当ってやつ。接続はUSB host--deviceかな?
ギャグにしかなってないや。
C級出版:SH−2A:
Lチカ完了!<=今ここ
- このままで終わりそうな予感。
- 144MHzRISC CPU、1MBの内蔵SRAMがLEDを秒単位で点滅させる程度の仕事しかさせていない。
- なんという情けなさ。
チップを見て微妙に気になったこと。
- 型番だけしか刻印されていない。
- 昔のH8-3048FやH8S−2144には日立マークが刻印されていたのだけど。
- RENESASになってから刻印やめたのかな?
CQ-FRK-SH2Aはワンチップセガサターン(性能相当)なのか?
\ | セガサターン | CQ-FRK-SH2A |
発売 | 1994年11月22日 | 2010年4月24日 |
メインCPU | SH-2(HD6417095)28.64MHz×2 | SH-2A(SH7262)144MHz |
メインメモリー | DRAM 2MB | 内蔵SRAM 1MB |
FPU | なし | あり |
発売当初の価格 | 44,800円 | 2,310円(雑誌込) |
雑誌付録マイコンとしては破格の性能。
- なんといっても外部バスにSDRAMを接続してメモリー増設が可能。(サターンは不可)
- FPU内蔵
- デュアルCPUではないが、1クロックに2命令実行可能。
ARM(thumb)とSHのアーキテクチャー上の違い(レジスタ本数など)
どちらも32ビット長の整数レジスタ16本を持つ。
ARM SH +--------+ +--------+ | R0 | | R0 | +--------+ +--------+ | R1 | | R1 | +--------+ +--------+ | R2 | | R2 | +--------+ +--------+ | R3 | | R3 | +--------+ +--------+ | R4 | | R4 | +--------+ +--------+ | R5 | | R5 | +--------+ +--------+ | R6 | | R6 | +--------+ +--------+ | R7 | | R7 | +--------+ +--------+ | R8 | | R8 | +--------+ +--------+ | R9 | | R9 | +--------+ +--------+ | R10 | | R10 | +--------+ +--------+ | R11 | | R11 | +--------+ +--------+ | R12 | | R12 | +--------+ +--------+ |R13(SP) | | R13 | +--------+ +--------+ |R14(LR) | | R14 | +--------+ +--------+ |R15(PC) | |R15(SP) | +--------+ +--------+
+--------+ | PR(LR)| +--------+ +--------+ | PC | +--------+
- ARMは16本の汎用レジスタ内にPC,LRを含めている
- SHではPR(LR),PCは独立していて汎用レジスタ扱いではない。
- Thumbではレジスタ指定フィールドが3bit(実質レジスタ8本)なので、これでよいのかも。
LPC2388:まだ動かない。
- HIDクラスデバイスを作って、64byte書いて64byte読むというのをやってみた。
- 1回目はOKなのだが、
- 2回目の書き込みデータが前と同じままという変な現象が起きていて
- 先へ進まない。
- シリアルデバッグでもするかのう・・・(面倒くさい)
ubuntu10.04がリリースされたらしい。
- https://wiki.ubuntulinux.jp/Develop/Lucid/TechnicalOverview
- https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ja
- http://www.lifehacker.jp/2010/02/100224ubuntumusicstore.html