Top
HIDaspx
DownLoad
HIDasp高速化
制作
AVR関係
AVR_Monit
AVR_term
W32_term
HIDmon88
HIDtester
usbRS232
Arduino2313
デジタルテスター
ATmega88生活
KeyBoardマニア
KeyBoardマニアII
Arduino400
PICライター
ARMライター
赤外線リモコン
ARM
STM32ブートローダー
STM8S-Discovery改造
STM8S-OpenOCDライター
LPCXpresso
LPC用ブートローダー
NXP用LPCUSB
NXP用ブートローダー
MARY基板
LPC1114FN28
OpenOCD JTAGアダプター
OpenOCDビルド方法
arm-gccビルド方法
mapleIDEの改造
libmapleで仮想COM
PIC32
PIC32MX
Pinguinoで遊ぼう
ブートローダーを作る
シリアルブートローダー
USB仮想シリアル
USBカスタムデバイス
USB簡易モニター
USBオシロスコープ
USBホスト
PIC32でBluetooth
USBAudio
USBStudy
VGA出力に挑戦
BASICを動かす
WinUSB
勝手に改蔵*PIC32
PIC18F
HIDブートローダー
AVR/PIC両用ライター
ARMライター
usb汎用クラス
usbシリアル変換
usbキーボード変換
sdccを使いこなす
mcc18を使いこなす
HIDmon-2550
HIDmon-14K50
PICmonitor
試行錯誤の記録
UBWを試す
旧HIDboot
PIC18F2550試用記
PIC18F4550試用記
その他マイコン
NEC78K
RX62N
SH2A
H8
FM3
XPからubuntuに乗り換え
Android
Xen-hypervisor
Windows8カスタマイズ
開発日記
2015-04
ノウハウ
AVRUSB_Tips
HIDasp情報
汎用USB-IO
・
リンク
フリースペース
ゲストブック
旧コンテンツ
WinVista
インターフェース考
最新の20件
2022-07-25
2008-10
HIDasp高速化
H8/3048F
AutoTicketLinkName
2021-12-11
FormattingRules
2021-12-08
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/V-Z
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/H-K
2020-02-23
YukiWiki
PHP
PukiWiki
WikiWikiWeb
2018-12-19
SandBox
InterWiki
2015-05-07
2015-04
2015-05-02
MenuBar
編集
差分
2011-11 の編集
-- 雛形とするページ --
(no template pages)
[[2011-10]] [[LPC1114]] *11月なのに夏並み・・・ [#b88375e3] この気候何?罰ゲームの一種? ~ ~ --------- *今ごろになって[[MARY基板:http://toragi.cqpub.co.jp/tabid/412/Default.aspx]]アタック! [#z5352568] ~ 参考サイト: MARY-MB (LPC1114) 用プログラムの雛形(Makefile など) -http://goldfish.blogzine.jp/memo/2011/05/marymb_lpc1114_.html ~ -相変わらずCODE_REDとかEclipseとか、全く使う気しない。 -ので、[[圓山さんの親切なサンプル:http://toragi.cqpub.co.jp/tabid/432/Default.aspx]] -をDLしてきて展開する。 workspace/以下のディレクトリの、 CMSISv1p30_LPC11xx .... いわゆる共通らいぶらりぃ。CMSYSってヤツ。Cortex-M 用 verは1.30 PROG01_COLOR_LED .... Lチカのサンプルソース。 これをちょっと配置換えして、 D:/MyProject/HW/CMSISv1p30_LPC11xx D:/MyProject/PROG01_COLOR_LED/ みたいにする。 ~ そして、Makefileを置く。 ダウンロード:[[Makefileなどなど:http://psp.dip.jp/web/upload.cgi/NXP/prog1make.zip]] -開発環境の定番は[[CodeSourceryG++Lite:http://www.lineo.co.jp/modules/codesourcery/configurations.html]]のARM EABI -だったんだけど、何故か[[ダウンロードサイト:https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?@template=lite]]はMentorGraphicsに変わっている。(買収された) ~ ~ -書き込みツールはELM ChaNさんの [[lpcsp (LPC1000/2000用書き込みプログラム):http://elm-chan.org/works/sp78k/report.html]]で決まり。高速すぎ。便利すぎ。 --コツ: '-c3' オプションを lpcsp.ini に書いておくこと。これにより、DTR=RESRTやRTS=BOOTの制御をうまくやってくれる。書き込み後に即起動してくれる。言うことなし。 ~ ~ *だけど・・・ビルドしても動かない。何故だー? [#z6f79d42] 落とし穴その1: -MARY基板は内蔵RC発振なので、CMSISv1p30_LPC11xx/ 内のheaderを一部書き換える必要がある。 --これはCODE REDから落としてきたCMSISを使う場合であって、cq出版のサイトのMARYサンプルに 含まれているCMSISv1p30_LPC11xx/はすでに改造されているのであった。 落とし穴その2: -すごく詰まらない理由だった。 × -mcpu=cortex-m3 ○ -mcpu=cortex-m0 -LPC1343のMakefileを使いまわしていたのでm3のままにしていた。 -一見、コンパイルもリンクも、出来たコードにも何の問題もないように見えて、 -''全然動かないのであった'' ORZ! -Cortex-M0はM3の命令がいくつか抜けているらしい。''ほんとか?''(たぶん割り算とか・・・、いや割り算しないんだけど)ヒマな時に何故動かないか差分攻撃してみようっと。 *やってみた。 [#n3979cea] -Cortex-m0 0000035c <NVIC_ClearPendingIRQ>: 35c: 231f movs r3, #31 35e: 4018 ands r0, r3 360: 2301 movs r3, #1 362: 4083 lsls r3, r0 364: 1c18 adds r0, r3, #0 366: 4a02 ldr r2, [pc, #8] ; (370 <NVIC_ClearPendingIRQ+0x14>) 368: 23c0 movs r3, #192 ; 0xc0 36a: 005b lsls r3, r3, #1 36c: 50d0 str r0, [r2, r3] 36e: 4770 bx lr 370: e000e100 .word 0xe000e100 -Cortex-m3 00000358 <NVIC_ClearPendingIRQ>: 358: 2301 movs r3, #1 35a: f000 001f and.w r0, r0, #31 35e: fa13 f000 lsls.w r0, r3, r0 362: 4b02 ldr r3, [pc, #8] ; (36c <NVIC_ClearPendingIRQ+0x14>) 364: f8c3 0180 str.w r0, [r3, #384] ; 0x180 368: 4770 bx lr 36a: bf00 nop 36c: e000e100 .word 0xe000e100 -cortex-m0系の命令コードはbranch系のみ2ワード(16bit x 2)で、それ以外はすべて1ワード(16bit) となっている。 -cortex-m3系には、2ワード(16bit x 2)に拡張された命令がいろいろ存在している。 396: e8bd 4070 ldmia.w sp!, {r4, r5, r6, lr} -こんなやつもそうだ。 -また、cortex-m0ではレジスタは前半8つ(r0-r7)までしか使えない(レジスタフィールドが3bitしかない)が、 cortex-m3では、r8,r9なども使用できるようだ。 つまり、簡単にまとめると、 -Cortex-M0は、ARM7TDMI(LPC2388等古いARM)などに実装されているThumbステートそのもの。ARMステート無しのコア。 -Cortex-M3は、いわゆるThumb-2と呼ばれている拡張セット。 ということらしい。どうりで、まったく動かないはずだ。 -m3のほうが、(誤差程度だが)短くなるようだ(1〜2%くらい?) ~ ~ ~ -なんとなく、この基板HIDaspx互換とpic18spx互換基板になったような気がする。''気がするだけだけど。'' -シリアルは実ボーレートを設定しないとちゃんと動作しない。(仮想COMで適当に9600とかやってたらマイコン側も9600にしないと動かない。これ当然なんだけど最後まで仮想COMなマイコンではボーレート関係ないからなぁ) -とりあえず230400bpsはOK。460800bpsは字化けして使えない。少し増やして500000bpsだと逆にOKになった。 -LPCXpressoの4.1を拾ってきたけれど、LPC2000の中身は29xxしかなかった。''2388は放置かい。''まあ、1769とI/O互換に近いという話はあるが。 ~ ~ ~ ~ ~ ---------- *時期はずれのアイスクリームサンド。 [#k4a2d252] Android 4.0 "Ice Cream Sandwich" ソースコード公開 -http://japanese.engadget.com/2011/11/14/android-4-0-ice-cream-sandwich/ ■[android][ICS] ICSのミラー終わったのでビルドしてみた -http://d.hatena.ne.jp/kinneko/20111116/p39 -ビルドするのに16GBのRAMが要るらしいけれど・・・。 -どのマシンも4GBしか積んでないからなぁ・・・(2G SIMM x 2) -昔はWindows上のVMWareでubuntu走らせて十分ビルドできていたのに。 -ていうか、Linuxカーネルの部分だけなら、普通にカーネルビルド程度で済むはずなんだけど、何が重いのかな? -やっぱりJava開発環境のところ? とりあえずRAM買ってくるか。(4GB x 2くらい。貧乏なので) ~ でも、だめだった。歯が立たない。なんかいろいろビルドエラーする。(ARM,x86ともにだめな感じ) -奴ら(Google)はどのubuntuを使っているのだろう? -次は、クリーンインストールしたubuntuでも用意するか。 ~ えっ?やっぱビルド出来ないのが正しい(?) -http://androider.sblo.jp/article/50525384.html -ubuntu10.04だって?もうそんなOS使ってないよ。(VMイメージなら残してるけど、使ってない) -http://androider.sblo.jp/article/50537280.html -http://groups.google.com/group/android-building/browse_thread/thread/a859d5e6ab1de2bf?pli=1 -結局32bitのlibstdc++が要るってことが分かった。こうする #!/bin/sh sudo apt-get install git-core gnupg flex bison gperf build-essential \ zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \ x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \ libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \ libxml2-utils -ビルドは出来たんだけど、output/の system/とか system.imgしかなくって、ISOファイルが出来ていない。Orz ~ -アイスクリームのバイナリー(ISO)は落ちてないけど、Honeycomb(3.2)のISOなら、ここにあるみたい。 --いつものところ: --http://www.android-x86.org/download ~ -そしてICS 4.0のISOもあるらしい。 --http://ktkr3d.byethost7.com/?p=1264&utm_source=rss&utm_medium=rss&utm_campaign=android-x86-4-0-ics-%25e3%2582%2592%25e8%25a9%25a6%25e3%2581%2597%25e3%2581%25a6%25e3%2581%25bf%25e3%2581%259f ~ ~ ---------- *OpenOCD:USB-Blasterサポートが少し良くなっているような気がする。 [#x6e1f382] -気のせいか? -ヒマなときに追試してみるか。 - "Remote 'g' packet reply is too long"問題ってもはやFAQレベルだと思ったが… 知らん人多いのですか… -ええ、知りませんでしたとも。 -ねむいさんのHPはとても参考になる。 -OpenOCDはいまだにROMライターソフトだと思っている人> ./ ~ ---------- *OpenOCD:高速化のヒントが大体分かった(つもり) [#y6ad7fc0] -openocdは各ドライバーに対して、jtag_command という構造体を渡して、JTAGコマンドを逐次実行してもらう。 int bitbang_execute_queue(void) { struct jtag_command *cmd = jtag_command_queue; /* currently processed command */ -で、*cmd は実は1個のコマンドだけが渡ってくるのではなくて、単方向リストで繋げられた一連のJTAG コマンドの束を送りつけられる。 -各ドライバーのexecute_queue()は、 while(cmd) { switch(cmd->type) { case ... : ... ; } cmd=cmd->next; } -のようにリストを全部実行して結果を返す。 -そこで、JTAG_SCAN:のようなコマンドはUSBの先のデバイスにコマンドを送りつけて結果をもらってこないと いけない。 -それを逐次的にやると、JTAG_SCAN1個に対してどうしてもUSBの1フレーム以上の時間を費やしてしまう。 -なので、高速化したいのであれば、このwhileループの処理を遅延評価(Lazy Evaluation)する(USBから返答が帰ってくるまでほおっておいて、どんどん処理を進める)か、あるいは -2パス処理にして、1パス目でコマンドを全部投げつつ、2パス目で戻ってきたUSBパケットを全部結果に書き戻すとかすれば良いことに気づく。 -と、まるで分かったように書くのは簡単なんだけど、実際にコードを書くのは大変だ。 - ---> 一応思いつく限りの遅延評価や遅延バッファを実装してみたんだけど、ちっとも速くならなかった。 - ---- なんか、Win32 APIの ReadFileとWriteFileがRS232Cに対しておもいっきり腐ってるような気がする。 - ---- ReadFileはたいていブロック処理されてしまうので、その前にClearCommStateするんだけど、なんかそこでUSBパケットが飛んでいるような気が・・・(気のせい?) - ---- ReadFileを非同期で処理すると、WriteFileが出来ない(ファイルハンドルが共通なのでいろいろ待たされる不思議)という本末転倒さはなんとかしてほしいけど、いまさらWin32APIが変わるとは思えない。 -ドライバーのソースは読みづらいし、処理を追いかけにくいと来ている。おまけにlibftdiだのD2XXだの、未知のデバイスドライバーの仕様も良く分かっていない。 ~ ~ ~ [[|次の月>2011-12]]> ~
タイムスタンプを変更しない
[[2011-10]] [[LPC1114]] *11月なのに夏並み・・・ [#b88375e3] この気候何?罰ゲームの一種? ~ ~ --------- *今ごろになって[[MARY基板:http://toragi.cqpub.co.jp/tabid/412/Default.aspx]]アタック! [#z5352568] ~ 参考サイト: MARY-MB (LPC1114) 用プログラムの雛形(Makefile など) -http://goldfish.blogzine.jp/memo/2011/05/marymb_lpc1114_.html ~ -相変わらずCODE_REDとかEclipseとか、全く使う気しない。 -ので、[[圓山さんの親切なサンプル:http://toragi.cqpub.co.jp/tabid/432/Default.aspx]] -をDLしてきて展開する。 workspace/以下のディレクトリの、 CMSISv1p30_LPC11xx .... いわゆる共通らいぶらりぃ。CMSYSってヤツ。Cortex-M 用 verは1.30 PROG01_COLOR_LED .... Lチカのサンプルソース。 これをちょっと配置換えして、 D:/MyProject/HW/CMSISv1p30_LPC11xx D:/MyProject/PROG01_COLOR_LED/ みたいにする。 ~ そして、Makefileを置く。 ダウンロード:[[Makefileなどなど:http://psp.dip.jp/web/upload.cgi/NXP/prog1make.zip]] -開発環境の定番は[[CodeSourceryG++Lite:http://www.lineo.co.jp/modules/codesourcery/configurations.html]]のARM EABI -だったんだけど、何故か[[ダウンロードサイト:https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?@template=lite]]はMentorGraphicsに変わっている。(買収された) ~ ~ -書き込みツールはELM ChaNさんの [[lpcsp (LPC1000/2000用書き込みプログラム):http://elm-chan.org/works/sp78k/report.html]]で決まり。高速すぎ。便利すぎ。 --コツ: '-c3' オプションを lpcsp.ini に書いておくこと。これにより、DTR=RESRTやRTS=BOOTの制御をうまくやってくれる。書き込み後に即起動してくれる。言うことなし。 ~ ~ *だけど・・・ビルドしても動かない。何故だー? [#z6f79d42] 落とし穴その1: -MARY基板は内蔵RC発振なので、CMSISv1p30_LPC11xx/ 内のheaderを一部書き換える必要がある。 --これはCODE REDから落としてきたCMSISを使う場合であって、cq出版のサイトのMARYサンプルに 含まれているCMSISv1p30_LPC11xx/はすでに改造されているのであった。 落とし穴その2: -すごく詰まらない理由だった。 × -mcpu=cortex-m3 ○ -mcpu=cortex-m0 -LPC1343のMakefileを使いまわしていたのでm3のままにしていた。 -一見、コンパイルもリンクも、出来たコードにも何の問題もないように見えて、 -''全然動かないのであった'' ORZ! -Cortex-M0はM3の命令がいくつか抜けているらしい。''ほんとか?''(たぶん割り算とか・・・、いや割り算しないんだけど)ヒマな時に何故動かないか差分攻撃してみようっと。 *やってみた。 [#n3979cea] -Cortex-m0 0000035c <NVIC_ClearPendingIRQ>: 35c: 231f movs r3, #31 35e: 4018 ands r0, r3 360: 2301 movs r3, #1 362: 4083 lsls r3, r0 364: 1c18 adds r0, r3, #0 366: 4a02 ldr r2, [pc, #8] ; (370 <NVIC_ClearPendingIRQ+0x14>) 368: 23c0 movs r3, #192 ; 0xc0 36a: 005b lsls r3, r3, #1 36c: 50d0 str r0, [r2, r3] 36e: 4770 bx lr 370: e000e100 .word 0xe000e100 -Cortex-m3 00000358 <NVIC_ClearPendingIRQ>: 358: 2301 movs r3, #1 35a: f000 001f and.w r0, r0, #31 35e: fa13 f000 lsls.w r0, r3, r0 362: 4b02 ldr r3, [pc, #8] ; (36c <NVIC_ClearPendingIRQ+0x14>) 364: f8c3 0180 str.w r0, [r3, #384] ; 0x180 368: 4770 bx lr 36a: bf00 nop 36c: e000e100 .word 0xe000e100 -cortex-m0系の命令コードはbranch系のみ2ワード(16bit x 2)で、それ以外はすべて1ワード(16bit) となっている。 -cortex-m3系には、2ワード(16bit x 2)に拡張された命令がいろいろ存在している。 396: e8bd 4070 ldmia.w sp!, {r4, r5, r6, lr} -こんなやつもそうだ。 -また、cortex-m0ではレジスタは前半8つ(r0-r7)までしか使えない(レジスタフィールドが3bitしかない)が、 cortex-m3では、r8,r9なども使用できるようだ。 つまり、簡単にまとめると、 -Cortex-M0は、ARM7TDMI(LPC2388等古いARM)などに実装されているThumbステートそのもの。ARMステート無しのコア。 -Cortex-M3は、いわゆるThumb-2と呼ばれている拡張セット。 ということらしい。どうりで、まったく動かないはずだ。 -m3のほうが、(誤差程度だが)短くなるようだ(1〜2%くらい?) ~ ~ ~ -なんとなく、この基板HIDaspx互換とpic18spx互換基板になったような気がする。''気がするだけだけど。'' -シリアルは実ボーレートを設定しないとちゃんと動作しない。(仮想COMで適当に9600とかやってたらマイコン側も9600にしないと動かない。これ当然なんだけど最後まで仮想COMなマイコンではボーレート関係ないからなぁ) -とりあえず230400bpsはOK。460800bpsは字化けして使えない。少し増やして500000bpsだと逆にOKになった。 -LPCXpressoの4.1を拾ってきたけれど、LPC2000の中身は29xxしかなかった。''2388は放置かい。''まあ、1769とI/O互換に近いという話はあるが。 ~ ~ ~ ~ ~ ---------- *時期はずれのアイスクリームサンド。 [#k4a2d252] Android 4.0 "Ice Cream Sandwich" ソースコード公開 -http://japanese.engadget.com/2011/11/14/android-4-0-ice-cream-sandwich/ ■[android][ICS] ICSのミラー終わったのでビルドしてみた -http://d.hatena.ne.jp/kinneko/20111116/p39 -ビルドするのに16GBのRAMが要るらしいけれど・・・。 -どのマシンも4GBしか積んでないからなぁ・・・(2G SIMM x 2) -昔はWindows上のVMWareでubuntu走らせて十分ビルドできていたのに。 -ていうか、Linuxカーネルの部分だけなら、普通にカーネルビルド程度で済むはずなんだけど、何が重いのかな? -やっぱりJava開発環境のところ? とりあえずRAM買ってくるか。(4GB x 2くらい。貧乏なので) ~ でも、だめだった。歯が立たない。なんかいろいろビルドエラーする。(ARM,x86ともにだめな感じ) -奴ら(Google)はどのubuntuを使っているのだろう? -次は、クリーンインストールしたubuntuでも用意するか。 ~ えっ?やっぱビルド出来ないのが正しい(?) -http://androider.sblo.jp/article/50525384.html -ubuntu10.04だって?もうそんなOS使ってないよ。(VMイメージなら残してるけど、使ってない) -http://androider.sblo.jp/article/50537280.html -http://groups.google.com/group/android-building/browse_thread/thread/a859d5e6ab1de2bf?pli=1 -結局32bitのlibstdc++が要るってことが分かった。こうする #!/bin/sh sudo apt-get install git-core gnupg flex bison gperf build-essential \ zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \ x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \ libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \ libxml2-utils -ビルドは出来たんだけど、output/の system/とか system.imgしかなくって、ISOファイルが出来ていない。Orz ~ -アイスクリームのバイナリー(ISO)は落ちてないけど、Honeycomb(3.2)のISOなら、ここにあるみたい。 --いつものところ: --http://www.android-x86.org/download ~ -そしてICS 4.0のISOもあるらしい。 --http://ktkr3d.byethost7.com/?p=1264&utm_source=rss&utm_medium=rss&utm_campaign=android-x86-4-0-ics-%25e3%2582%2592%25e8%25a9%25a6%25e3%2581%2597%25e3%2581%25a6%25e3%2581%25bf%25e3%2581%259f ~ ~ ---------- *OpenOCD:USB-Blasterサポートが少し良くなっているような気がする。 [#x6e1f382] -気のせいか? -ヒマなときに追試してみるか。 - "Remote 'g' packet reply is too long"問題ってもはやFAQレベルだと思ったが… 知らん人多いのですか… -ええ、知りませんでしたとも。 -ねむいさんのHPはとても参考になる。 -OpenOCDはいまだにROMライターソフトだと思っている人> ./ ~ ---------- *OpenOCD:高速化のヒントが大体分かった(つもり) [#y6ad7fc0] -openocdは各ドライバーに対して、jtag_command という構造体を渡して、JTAGコマンドを逐次実行してもらう。 int bitbang_execute_queue(void) { struct jtag_command *cmd = jtag_command_queue; /* currently processed command */ -で、*cmd は実は1個のコマンドだけが渡ってくるのではなくて、単方向リストで繋げられた一連のJTAG コマンドの束を送りつけられる。 -各ドライバーのexecute_queue()は、 while(cmd) { switch(cmd->type) { case ... : ... ; } cmd=cmd->next; } -のようにリストを全部実行して結果を返す。 -そこで、JTAG_SCAN:のようなコマンドはUSBの先のデバイスにコマンドを送りつけて結果をもらってこないと いけない。 -それを逐次的にやると、JTAG_SCAN1個に対してどうしてもUSBの1フレーム以上の時間を費やしてしまう。 -なので、高速化したいのであれば、このwhileループの処理を遅延評価(Lazy Evaluation)する(USBから返答が帰ってくるまでほおっておいて、どんどん処理を進める)か、あるいは -2パス処理にして、1パス目でコマンドを全部投げつつ、2パス目で戻ってきたUSBパケットを全部結果に書き戻すとかすれば良いことに気づく。 -と、まるで分かったように書くのは簡単なんだけど、実際にコードを書くのは大変だ。 - ---> 一応思いつく限りの遅延評価や遅延バッファを実装してみたんだけど、ちっとも速くならなかった。 - ---- なんか、Win32 APIの ReadFileとWriteFileがRS232Cに対しておもいっきり腐ってるような気がする。 - ---- ReadFileはたいていブロック処理されてしまうので、その前にClearCommStateするんだけど、なんかそこでUSBパケットが飛んでいるような気が・・・(気のせい?) - ---- ReadFileを非同期で処理すると、WriteFileが出来ない(ファイルハンドルが共通なのでいろいろ待たされる不思議)という本末転倒さはなんとかしてほしいけど、いまさらWin32APIが変わるとは思えない。 -ドライバーのソースは読みづらいし、処理を追いかけにくいと来ている。おまけにlibftdiだのD2XXだの、未知のデバイスドライバーの仕様も良く分かっていない。 ~ ~ ~ [[|次の月>2011-12]]> ~
テキスト整形のルールを表示する
ログインまたはアカウント作成