いろいろ試す64 - 2024年反省会 -
あっという間に2024年もおしまいです…。
副業(本業は虹裏メイド)が多忙になってしまい出来ることが少なく
なってしまいましたができる限り拾ってまいりました…！
●arm-gcc更新
arm-gccが12月10日付で更新しておりました。
今回のリリースからWindows向け64bit版のツールチェインも追加と
なっております。x86_64ってやつですね。i686が32bit版です。
なお、前回詰まってしまったGDBの挙動がおかしかった件ですが、上記の
64bit版ツールチェイン付属のARM-GDBでは修正されていました。
"tbreak main"がしっかり効いてデバッグ開始時にmain関数の先頭で
ちゃんと停止してくれます。一方で32bit版は相変わらずダメでした。
これからは64bit版を使っていきましょう。
昨今のOSは64bitが主流なので特に強い理由がない限りは64bit版の
ツールチェインを選択していくことになりますね。
…これでやっとARMマイコンデバッグ手順の更新ができる…かな？
●FatFsが0.15aに更新
ChaN'師のFatFsも先月末に更新しておりました。
小規模な変更だったので移植もスムーズにすることができました。
私のFatFs移植例にも反映しておりますのでどしどしご利用ください！
*STM32H7
*STM32H5
*STM32F7
*STM32F4
●OpenOCDのSTM32U0正式対応
ついにやってきましたね…半年以上待ちましたがー！
書き込み時のログはこんな感じです↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00823-g4f2744d0f (2024-12-31-14:06)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-dap.cfg is deprecated, please switch to interface/stlink.cfg
Info : STLINK V2J45M31 (API v2) VID:PID 0483:3752
Info : Target voltage: 3.234510
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [stm32u0x.cpu] Examination succeed
Info : [stm32u0x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[stm32u0x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x08002b28 msp: 0x2000a000
Info : device idcode = 0x10006489 (STM32U073/U083xx - Rev A : 0x1000)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
Warn : Adding extra erase range, 0x08004d20 .. 0x08004fff
Info : wrote 19744 bytes from file main.elf in 0.969477s (19.888 KiB/s)
Info : verified 19744 bytes in 0.512074s (37.653 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02
以前と変わりはほぼありませんね。
もちろんデバッグも自由自在です。
これでSTM32U0も(正式に)バリバリ開発ができるようになります！
わたしのおきぱにもOpenOCDバイナリを置いていますのでこちらも
大いにご利用ください！
…あとは昨年から放置状態のSTM32H5のフラッシュ対応待ちですね…！
また、夏にコミットされたgdbコマンド体系の再編への対応について、
ねむいさん特製フラシュ書き込み用cfgファイルは対応しておらず
書き込みとかデバッグするたびにwarning出まくりで放置状態でした。
今回のブログ記事を書くにあたりようやっと対応させてみました。
もうwarningは出ませんので安心してご使用ください。
●avrdudeがいつの間にかV8.0に
かつての停滞が嘘のようにまさに日進月歩の進化を遂げるようになった
AVRマイコン書き込みプログラムavrdudeですがV8.0まで上がっております。
ちなみに上がったの8月だったんですが更新したの紹介して
ませんでした。かなりの修正と機能追加がされております。
AVR-EBシリーズ使うならV8.0以降が必須となります。
こちらも私がビルドした最新のバイナリを挙げていますので
ご利用ください〜！
●2024年反省会
…ぇっと…今年はやりたいこと全くできなかったのですが来年は…
��2025年度版のarmマイコンビルド・デバッグ手順の作成
��STM32H5を使ったmp3プレーヤーの作成
の達成を目標にがむばっていきたいとおもいます…！！
それでは皆様良いお年を〜
近畿自然歩道を行く -天橋立雪めぐり-
今年の走り収めは天橋立にすることにしました。
おきらくご気楽な観光&温泉メインで行くつもりでしたがはてさて…
●2024.12.28 近畿自然歩道(天橋立)
場所はJR京都駅
虹裏メイドの朝はちょっとだけ遅い
今回は電車で目的地に行かず高速バスとなります。
バスに揺られること約２時間、天橋立駅に
到着しました…なんかちらほら雪が降りだしてますが
何はともあれスタート…
知恩寺文殊堂で道中祈願を行います。
今回のルートは天橋立を突っ切って進みます。
天橋立は松林になっていてその中を進んでいきます。
与謝野鉄幹・晶子の歌碑があります。
磯清水と天橋立神社です。
ひたすら松林の中を駆け抜けていきます。
遠くに今から向かう笠松公園が見えてきました。
松林が終わったところで道標が次の場所に誘います。
超メジャーな観光地のおかげかいたるところに
案内板があり迷いません。
元伊勢籠神社です。
奥宮となる眞名井神社です。
眞名井神社の本殿はは写真撮影禁止な神域となります。
ケーブル山麓駅の下にやってきました。
そいえば今回は近畿自然歩道の道案内がやたらとありますね…
そして雪もたくさん降ってきました…
ケーブルカーのわきの道をひたすら上っていきます
途中にある大谷寺です。
長い階段が終わりようやく笠松公園に出てきましたが…
天橋立で有名なまた除きですが…
…
何も見えねぇ…！！！
とりあえず股覗いて写真を撮ってみました…
くそぁ！！
さて近畿自然歩道はここから北に少し進んで山麓に降りる
ルートのようですね…
進んでるうちにどんどん雪が出てきて…
…
気が付いたら行くつもりはなかった成相寺についてしまいました。
せっかくなので境内を見て回りました。
すっかり雪景色ですね…
成相寺本堂です。
雪の量がすごいですね…。
さて成相寺から離れて今度こそルートを進もうと思いましたが
また笠松公園の分岐まで来ちゃった！？
探すこと２０分、めっちゃわかりづらいところに次の分岐が
…フ〇アック！！！！！！！１１！
一応このルートで正しかったようです…
滑りやすい落ち葉の道を降りてきます。
途中で視界が開けたところで天橋立がちょろっと見えました
やった〜(虚無
結構危険な落ち葉のくだりを交わして無事下界に戻ってきました。
ケーブル下バス停です。次のルートの分節点となります。
残りのルートは舗装路なのでらくちん…のはず！
観光地仕様だからか近畿自然歩道の道標も黒塗りの格好良い
スタイルに仕上がっております。
西に進んで丹波国分寺跡と現在の国分寺です。
そしてその近くにある丹波郷土資料館です。
天橋立がどんどん離れていきます。
天橋立ワイナリーです…
お酒はまだ我慢…！
与謝野町に入って道は国道から府道に進路を変えます。
スーパー銭湯のクアハウス岩滝です。
板列稲荷神社です。
城山公園と古墳群です。
このあたりでまた風雪がきつくなってきました…
次につながるエントリポイントで道を分かれます。
近畿自然歩道はあとちょっと続きます。
今回のルートの終点、与謝野町役場につきました。
しかしゴールはまだ先となります。
ミニストップで買い物を済ませます。
天橋立周辺はまともなコンビニがないので重要です！！
トドメと言わんばかりにまた風雪がたたきつけてきました。
山肌もすっかり白くなっていますね…
何とか岩滝口駅に到着です…
やってきた電車に乗り込み天橋立駅に戻ります…
天橋立駅まで戻ってきました。
駅チカの知恵の湯で冷え切った体をあっためました♨
天橋立唯一のこんびにヤマザキショップで帰りのおつまみと
お土産を買っていきます。別のところでもお土産買いこみましたが。
知恩寺にもう一度お参りして帰りの道中祈願を行いました。
予定通り大阪方面の高速バスに乗って帰還しました…
京都じゃなくて大阪なのは京都行のチケット取れなかったからです…！！
そんなわけで今回も終始ドタバタしてしまいましたが、なんとか
年末のトレランを終えることができました。
来年は大きなプロジェクトを考えているので気を引きしめて頑張ります…！！
●2024.12.28 近畿自然歩道(天橋立) GNSSログ
今回は雪にやられたので晴れてる日にりべんぢしたいですね…！
中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
今年の初頭にねむいさんはついに石川県を超えて富山県にも到達しました。
今回は富山と石川県の境を通って富山県は城端に行き着くことを
画策して実行してみました！いざ勝負！
●2024.11.16 中部北陸自然歩道(倶利伽羅〜医王山(〜城端))
二次裏メイドの朝は早い。
夜行高速バスで金沢駅に降り立ちます…。
金沢駅からはIRいしかわ鉄道で倶利伽羅駅へと向かいます…
倶利伽羅駅から65kmの長きにわたるバトルの開始です…！！
いきなりの登坂がお出迎えでいきなり歩いてしまう…
そして今回は全ルートでツキノワグマの恐怖にもおびえないといけない…
津端方面からくる旧北陸道と合流します。
倶利伽羅峠頂点部にある不動寺で道中祈願を行いました。
倶利伽羅剣がある場所が石川県と富山県の県境となります。
倶利伽羅峠周辺は源平合戦の地となっており、それにちなんだ
地名が紹介されています。そこにいざなう古道へと歩を進めていきます…！
道は下り基調になり高度を下げていきます。
合戦の舞台の開設やルート案内もここかしこにあります。
…しかし、ねむいさんは道間違えたのか変なところに入り込んでしまう…
強引に突っ切って降りた先は霧に包まれていた…
マヌーサ…
電子コンパスを頼りにとりあえず北に進んでチェックポイントの
松尾神社に行きつけました…年初の地震の影響で倒れた鳥居は
撤去されていました。
今回の自然歩道は3ルート分ありますがとりあえず1ルートはクリアです。
次のエントリポイントへと霧の中を進みます。
加越能バス藪波バス停です。
ここから2ルート目スタートです…！
ちょっと道に迷って時間食ったので巻き返します。
サイクルターミナルなる場所で道標に従って進んだつもりでしたが…！？
また間違って時間ロスしちゃった！
あーもうめちゃくちゃだよ！
チェックポイントの戸久神社です…
ここから道を南下…南下…して山の中に左折…
あれれ？？
峠超えて県道の分岐に出ちゃった！？
ここでまた正規ルートを探して迷う…
だいぶ戻って写真の民家の手前の薮超えた先に山道らしきものを発見…
こんなのわかりませんよう！
更なる激藪がねむいさんを襲う…
ようやく安全地帯らしきところに出た…
あとは下るだけ！
延々と下っていくとさっき間違えた県道と落ち合いました。
迷ったらこっちの道行ったほうが確実ですね…
さらに降りると安居寺です。
安居寺から離れたら別の県道に押し込まれます。
ちょうど自販機があったので補給を兼ねて小休止…
これはありがたい。
今度は県道をひたすら南下していきます。
遥かむこうに今回のターゲットの医王山が見えてきました…！
ひたすら舗装路を走って南下していきます…
ひたすら…ひたすら…
国道304号とクロスしてさらに進みます。
チェックポイントの光徳寺に到達しました…
壺がたくさん配置された変わったお寺です。
ここで中部北陸自然歩道の巨大案内板が出てきましたので
またまた小休止しました…。今ねむいさんが走ってきた安居寺〜光徳寺の
区間は車移動区間だったそうです･･･###
さて、ここから今回の本番の医王山への道が始まります…！
時刻は11:30、今のところ予定時刻通りに進んでいますが間に合うのか！？
医王山トンネルを抜けてぬく森の里の分岐から
県境をひたすらなぞる"百万石道路"の始まりです…
ここでも熊の脅しがありますね…
百万石は車でも登れるように舗装路となっていますが
疲労が蓄積した足にこれはきつい…
別の登山道や近年発掘された殿様道路とも合流して
道はづづいていきます…！
ひたすら続く道、道、道…！
足が上がらずほとんど歩いちゃってます…
でも急がないと…！
だいぶ高度が上がってきたと感じたところで国見ヒュッテに到達しました。
今年の営業はもう終了しているようですね。
医王権現社で残りの道中祈願をしました。
無事に城端に戻れますように…！
鳶岩、白兀山への分岐がある辻堂を超えていきます。
山道は延々と続く…
疲れがたまっているところに上り下り入れられるとマジきつい…！
進んでいくとイオックスアローザスキー場が見えてきました…！！
夕霧峠まであと少しＤＡ！
巨大休憩所がある夕霧峠に到着です…！！
夕霧峠は菱広峠とも呼ばれています。
さて夕霧峠に到達した時点で13:50、時間も余裕ができたので
追加ちゃれんぢの奥医王山山頂にアタックを行いました！
がぁあああああ…50�匐瓩�走ってきてこの階段攻めは効く…
見返り杉と龍神池です。
?
ッッようやく奥医王山に到着です…！
あとはひたすら駆け下りて城端に帰るだけとなります…！
さすがに下りは早い。
夕霧峠がどんどん離れていきます…！
イオックスアローザスキー場の中の道を駆け下りていきます…！
途中で湧き水の金銘水がありました。
これはありがたい…！
紅葉とススキのコラボを見ながら駆け下りていきます。
中部北陸自然歩道の今回のルートの起点に到達しました…！
ですがねむいさんのゴールは城端なのです！！
アローザ村の中を駆け下り、スキー場の敷地とも別れを告げます…！
さらに東に進んで長沢バス停に到達です。
公式の案内ではこのバス停がルートの終点ですがバスの便は
一切期待できないのでJR城端駅までさらに進んでいきます！
最後の最後まで上り坂でねむいさんを苦しめる…がぁああああ！！
ぁあ…やっと道路標識も城端の文字が…！
城端大橋を通過して城端の市街にとりつきました。
城端は小京都と呼ばれていてちょっとした観光地になっております。
(最後のローソンで物資買ってから)ラストスパートで17:00丁度で城端駅に
無事ゴールとなりました…！予定時間より20分早く到着です☆
ですがこの先も気が抜けません…ここから京都に帰らないといけません。
まずは城端線に揺られて新高岡へ…
そんでもってタイトなスケジュールで新高岡駅で敦賀行の
北陸新幹線に乗り換えます…！
そんで新幹線に乗っても気が抜けず敦賀に到着したら乗り換えレースが
はぢまります…エスカレーターで詰まったときちょっと焦りました…！
何とか乗り換え時間以内に在来線特急のサンダーバードに乗ることが
できてようやく一安心です…！！
ほんとに最後まで気が抜けない戦いの一日でした…！
というわけで積雪期になる前に富山のこのルートを攻略してまいりました。
んでもってようやく敦賀延伸後の北陸新幹線乗ったりして新しい北陸への
アクセスに体験してまいりましたが徐々に慣れていこうと思います。
これからも北陸方面には手を広げていこうと思いますので今後ともヨロシク…！
●2024.11.16 中部北陸自然歩道(倶利伽羅〜医王山(〜城端)) GNSSログ
にしても今回はひたすら長かった…
ほとんど舗装路だったのもあるでしょうね〜
いろいろ試す63
ああもうこんな季節だ…忙しいのに頭が空回りで何もできていない…
とりあえずできることをできるだけ頑張っていく…!!
●ねむいさんのぶろぐhttps化
タイトルの通りでござます。私のぶろぐの母体"びぃブログ"の仕様が
常時https化したことにより私のぶろぐもhttpsに強制的に変わったの
ですが…
10年来使用してきたソースコードハイライト機能syntax highliterが
今回のhttps化で機能しなくなったのが判明し別のハイライト機能に
切り替えることにしました。それで見つかったのがhighlight.jsです。
かつてのsyntax highliterとほぼ同じ表示感覚で使用でき、表示方法も
ほぼ同じ感覚でした。9月末からhighlight.jsを導入しております。
こんな感じにソースコードの
//ハイライト表示ができますしかしながらhtmlタグがsyntax highliterのころとは微妙に違うので
過去にさかのぼってブログの記事をせっせと修正しました…
くそ…もっと早くやっておけばよかった…
いちおうすべての記事でhighlight.jsに対応しましたが疲れた…
●OneDriveが仕様変更で古い共有リンク全滅
あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”！！！！
9月末くらいの仕様変更でおきぱにおいてあるSTM32のプロジェクトとか
OpenOCDバイナリとかのリンク全部不通になってたぁああああ！！！
というわけでこちらにも対応して全部共有リンクを再生成してソース
コード置き場のリンクはちゃんとダウンロードできるよう修正いたし
ました…あとは過去のぶろぐ中に張った直リンクたちですが数が膨大に
あるのですがこちらもできる範囲で適宜修正していこうと思います…
また、記事を見直して10年以上前の古いものはリンク仕舞いする個所も
あるのでご注意願います…なるべく残せるようにがむばります…
●最新のarm-gccのgdbの挙動がおかしい？
う〜〜ん私のやり方が悪いのかどっちが悪いのか断定はできませんが
現時点で最新のArm GNU Toolchain Version 13.3.Rel1のgdbなんですが、
なんでか"tbreak main"が効かずデバッグ開始時にmain関数の先頭で
止まってくれません。
*問題の13.3.Rel1(GDB14.2)の場合
ソースコードはスタートアップの最初のところを示していますが
breakがかからずそのままプログラムが走ってしまいます。
↓ログはこんな感じ。Continuing...の後音沙汰がありません。
Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit
Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg
Launching gdb from : ../../../
Starting debugger : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"
Debug session started successfully!
GNU gdb (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 14.2.90.20240526-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.
¥nType "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:¥n <
http://www.gnu.org/software/gdb/documentation/>.¥n
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.elf...
Output radix now set to decimal 16, hex 10, octal 20.
`R:¥STM32H563xxx_NUCLEO_20241101¥main.elf' has changed; re-reading symbols.
Remote debugging using localhost:3333
Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59
59¥t ldr r0, =_estack
Successfully connected to debugger server
Applying breakpoints...
Applying breakpoints... done
Unable to match requested speed 480 kHz, using 200 kHz
Unable to match requested speed 480 kHz, using 200 kHz
[stm32h5x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting
Note: breakpoint 1 also set at pc 0x8000252.
Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.
Continuing... *ひとつ前の13.2.Rel1(GDB13.2)の場合
ちゃんとmain関数の先頭で停止します。
↓ログはこんな感じ
Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg
Launching gdb from : ../../../
Starting debugger : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"
Debug session started successfully!
GNU gdb (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.90.20231008-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.
¥nType "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:¥n <
http://www.gnu.org/software/gdb/documentation/>.¥n
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.elf...
Output radix now set to decimal 16, hex 10, octal 20.
Remote debugging using localhost:3333
Note: automatically using hardware breakpoints for read-only addresses.
Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59
59¥t ldr r0, =_estack
Successfully connected to debugger server
Applying breakpoints...
Applying breakpoints... done
Unable to match requested speed 480 kHz, using 200 kHz
Unable to match requested speed 480 kHz, using 200 kHz
[stm32h5x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting
Note: breakpoint 1 also set at pc 0x8000252.
Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.
Continuing...
Temporary breakpoint 1, main () at src/main.c:41
41¥t¥tSet_System();
古いほうは古いほうでちょっと問題があってなんでかバイナリサイズが
256MBもあるデバッグビルドになっており、elfファイルの読み込み時間も
時間がかかります(私の環境ではそこまで気にならなかった)。
切り分けのためにFreddieChopin氏のarm-gcc野良ビルド"Bleeding-Edge"
を使ってみます…(32bit版が動作しなかったので64bit版を使います)
GDBが14.2になったのが原因なら同じ14.2なら再現性があるはずですが…
ちゃんとmain関数の先頭で停止しますね…。
Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit
Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg
Launching gdb from : ../../../
Starting debugger : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"
Debug session started successfully!
GNU gdb (bleeding-edge-toolchain) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.
¥nType "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:¥n <
http://www.gnu.org/software/gdb/documentation/>.¥n
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.elf...
Output radix now set to decimal 16, hex 10, octal 20.
Remote debugging using localhost:3333
Note: automatically using hardware breakpoints for read-only addresses.
Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59
59¥t ldr r0, =_estack
Successfully connected to debugger server
Applying breakpoints...
Applying breakpoints... done
Unable to match requested speed 480 kHz, using 200 kHz
Unable to match requested speed 480 kHz, using 200 kHz
[stm32h5x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting
Note: breakpoint 1 also set at pc 0x8000252.
Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.
Continuing...
Temporary breakpoint 1, main () at src/main.c:41
41¥t¥tSet_System();
FreddieChopin氏一番新しい版はGDB15.2まであがっておりましたので
こちらでも念のため確認してみます。
こちらもちゃんとmain関数の先頭で停止します。
Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit
Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg
Launching gdb from : ../../../
Starting debugger : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"
Debug session started successfully!
GNU gdb (bleeding-edge-toolchain) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.
¥nType "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:¥n <
http://www.gnu.org/software/gdb/documentation/>.¥n
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.elf...
Output radix now set to decimal 16, hex 10, octal 20.
Remote debugging using localhost:3333
Note: automatically using hardware breakpoints for read-only addresses.
Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59
59¥t ldr r0, =_estack
Successfully connected to debugger server
Applying breakpoints...
Applying breakpoints... done
Unable to match requested speed 480 kHz, using 200 kHz
Unable to match requested speed 480 kHz, using 200 kHz
[stm32h5x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting
Note: breakpoint 1 also set at pc 0x8000252.
Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.
Continuing...
Temporary breakpoint 1, main () at src/main.c:41
41¥t¥tSet_System();
ううむ…バージョンの違いで起こった現象でもなさそうですしビルド環境の
差なのでしょうか…あとARM公式のはx86版なのが気にかかりますが…
ひとまずはFreddieChopin氏の物を使ってその場をしのぎつつARM公式の
次回リリース版のGDBの挙動を待つとしましょうか…
CodeLiteを使ったデバッグ方法を何とか安定させ正式に公開したいのですが
なかなか手ごわいです…
STM32H7を使ってみる7 -ティアリングを何とかしたい-
←前回
なんと4年ぶりのSTM32H7の記事です！
ちなみに最新のSTM32H7R/SシリーズについてはOpenOCDが正式対応して
いないため、当面の間はSTM32H747I-Discoveryを使用した記事となります…
お前アリアハンから全然脱出できてないじゃないか！１！！
さて、ねむいさんが公開しているFatFs移植サンプル通称"いつもの"に
ついてはChaN師のFatFsのほかに簡易ファイラーやtxt(S-JISのみ)ファイル、
さらに独自フォーマットの動画ファイルも対応しております。
それでSTM32H747I-DISCOはDSIインターフェースでLTDCを動作させて
映像を出力しているのですが、素早く画面切り替えた際や動画再生時などに
画面のティアリングが発生してしまっておりました。
例としてゼERO動画を再生しているところ
赤色で線引いて強調してみましたが横方向のティアリングの上に斜め方向
にもティアリングが発生してしまっている状態です。
横方向のティアリングはLTDCのVSYNCを待つようにしたら解消しました。
具体的なコードは下記のようなコードをDMA2Dでぶん投げる前に挿入すれば
解決です。
/**************************************************************************/
/*!
Wait VSYNC signal.
*/
/**************************************************************************/
void Display_WaitVSYNC(void)
{
/* reload shadow registers on vertical blanking period */
LTDC->SRCR = LTDC_SRCR_VBR;
/* wait for next frame */
while ((LTDC->CDSR & LTDC_CDSR_VSYNCS) == 0);
}コード詳細は./lib/display/mcu_depend/src/lcdc_if_basis.cと
./lib/display/abstract/src/ts_fileloads.cを参考にしてください。
しかし、斜め方向のティアリングはこれでだけは解消しませんでした…
画面切り替えたときとかの斜め方向のティアリングがどうしても
気になってしまう…
不思議なことに斜めティアリングはDSI接続のLCDモジュールを横方向
(LANDSCAPE)で使用した時だけ発生し、縦方向(PORTRAIT)なら一切発生
しないことに気づきました…いないさんかわいい…
STのフォーラムも調べてみましたが同じ現象に悩んでる方が結構いることが
わかりました
��STM32F769-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人
��ねむいさんとおなじSTM32H747I-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人その２
共通するのはDSIインターフェースのLCDモジュールを横方向で使った際に
斜めティアリングが出ちゃっているようです。
ちなみにねむいさんが所持しているSTM32F769N-Discoveryでも同じ現象が
発生しておりました。
�，里箸海蹐�ST社員の人が斜めティアリングが起こる仕組みと対策を示して
おりました。
ねむいさん所持のSTM32H747I-DISCOのTFT-LCDモジュールのコントローラは
OTM8009Aという480x800(MAX864)のWVGAの縦方向表示に特化したやつでした。
横方向にして使用すると原理通りスキャン方向の相違が起こって斜め方向に
ティアリングが発生してしまうということなのでしょうか…
で、原理は納得しましたが具体的な対策(フレームバッファを2分割せよ)
とやらを文字で示していますがソースは提示されておらずねむいさんは
肝心のソースコードを知りたかったので再び泥沼にはまってしまいました。
しかし…
最後の�い里箸海蹐�VerticalBackPorch(VBP)を増やしたら斜めティアリングを
画面の外に蹴りだせたとコメントを見つけ、ねむいさんも真似してやってみた
所確かに斜めティアリングが垂直方向に移動しました。
いろいろ試した結果、VBPの値を480追加すると丁度画面から消えるのが判明し
横方向表示の際の時だけVBPにVBP_OFSとして480を追加するようにしました。
/* Timing parameters for all Video modes
* Set Timing parameters of LTDC depending on its chosen orientation
*/
/* The following values are same for portrait and landscape orientations */
if(Orientation == LCD_ORIENTATION_PORTRAIT)
{
VSA = OTM8009A_480X800_VSYNC; /* 1 */
VBP = OTM8009A_480X800_VBP; /* 15 */
VFP = OTM8009A_480X800_VFP; /* 16 */
HSA = OTM8009A_480X800_HSYNC; /* 2 */
HBP = OTM8009A_480X800_HBP; /* 34 */
HFP = OTM8009A_480X800_HFP; /* 34 */
}
else
{
/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */
VSA = OTM8009A_800X480_VSYNC; /* 1 */
VBP = VBP_OFS + OTM8009A_800X480_VBP; /* 15(+480) */
VFP = OTM8009A_800X480_VFP; /* 16 */
HSA = OTM8009A_800X480_HSYNC; /* 2 */
HBP = OTM8009A_800X480_HBP; /* 34 */
HFP = OTM8009A_800X480_HFP; /* 34 */
} 
…コメント先ではNT35510のLCDモジュールではうまくいかなかったという
結果でしたがねむいさんがもってるOTM8009Aの奴は対策できたっぽいので
まぁワークアラウンドとしてはいいのかな…と思いまし、た！
DSI接続のLCDモジュールがあるDiscovery系ボードをお持ちで同じような
問題抱えてる方は追試していただけたら幸いです…！！
おきぱのSTM32H7,STM32F7のサンプルはワークアラウンド済です。
いろいろ試す62
●Picoscope7のソフトがバージョンアップ！今度こそ安定…か？
すぐフリーズしたり落ちたりでなかなか安定しないPicoscope7のソフトですが
Stable版が7.1.29にバージョンアップしておりました。
今度こそ本当にStableなんでしょうね…！？(どきどき
※会社で現役でバリバリ使用中のPicoscope3206Aで試してます
☝2画面で動かして放置すると固まったorz
…
ファ〇ッッック！！！！！
基本的な操作はだいぶ安定してきましたがちょっと複雑な操作はまだ
安定していないようですね…
というわけで安定して使用できるまでPicoscope6使っていきましょ…。
●arm-gccが久々の更新
Arm GNU-GCCが久々の更新です。
といってもGCC14ではなくまだGCC13のままです…。
13.2->13.3のマイナーチェンジですね。
また、今回はセキュリティ対策のアップデートしております。
同じプログラムをビルドしてバイナリサイズの比較です。
13.2Rel1(前のやつ)
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 479156 0 479156 74fb4 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
477416 1740 39668 518824 7eaa8 main.elf
main.elf :
section size addr
.text 0x747fc 0x8000000
.ctors 0x0 0x80747fc
.dtors 0x0 0x80747fc
.eh_frame 0x54 0x80747fc
.ARM.exidx 0x98 0x8074850
.data 0x6cc 0x20000000
.bss 0x18a8 0x200006d0
.heap 0x0 0x20001f78
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x44 0x0
.debug_frame 0x1e88 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x80b9e13.3Rel1(新しいほう)
arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478396 0 478396 74cbc main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476624 1772 39668 518064 7e7b0 main.elf
main.elf :
section size addr
.text 0x744e4 0x8000000
.ctors 0x0 0x80744e4
.dtors 0x0 0x80744e4
.eh_frame 0x54 0x80744e4
.ARM.exidx 0x98 0x8074538
.data 0x6ec 0x20000000
.bss 0x18a8 0x200006f0
.heap 0x0 0x20001f98
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x45 0x0
.debug_frame 0x1d98 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x807b7Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。
mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。
一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1
13.3Rel1
あ…ありり…
ちょっとかなり遅くなってる…(脂汗
…
GCC14に期待しましょう〜！！
13.3Rel1のGDBはCortex-M33コアでbreakpointが効かなくてデバッグが
できないことが判明しました…(多分バグです)
ひとつ前の13.2Rel1のやつ使いましょう…
20240828追:
13.3Rel1のGDB(GDB14)はちょっと規模が大きいプロクラムになると
breakpointが効かなくなってデバッグが全くできなくなることが
判明しました…orzおそらくGDBのバグっぽい挙動ですがまだ情報が
出そろっていないので今は13.2Rel1のarm-gccを使ったほうが無難です…
どうしてこんなことにorzorz
●組み込み向けのLTO考察
リンク時最適化(LinkTimeOptimization)。ねむいさんは10年位前に使った際に
バグが多くて封印してそれっきりでした。ここ最近はどうなっているのか色々
調べてみましたが、あのころと比べてかなり様変わりしてるのがわかりました。
まずは公式のLTOの解説をしっかりと読みとおすこと。
そのうえでLTOのビルドを成功させるためには幾つかの障壁がありました。
*FONTX2のファイルを直接取り込むincbinと相性が悪い
LTOなしだとビルドできるのにLTOつけるとアセンブラでエラー吐いてこける。
LTOの場合はmakefileがあるところからのフルパスを指定しないといけない。
makefileが存在するディレクトリからの相対パスを指定しなおすことで
苦しみ紛れに屁をこいたような対策ですが何とか対処できました。
*引数も重要
ビルド時に与える引数も"-flto"だけじゃダメになっていて、試行錯誤した結果
以下のオプションを全部追加することでLTOビルドを達成できました。
-flto
-ffat-lto-objects
-fuse-linker-plugin
-flto-partition=noneSTM32H5のビルドサイズ比較をしてみましょう
LTOなし
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478260 0 478260 74c34 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476488 1772 39668 517928 7e728 main.elfLTOあり
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 473372 0 473372 7391c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
471608 1764 39672 513044 7d414 main.elf5kByte弱削減できました。SRAM消費量も微量ながら減ってますね。
もちろんLTOありでもちゃんとプログラムは機能します。
大規模プロジェクトなので効果は感じづらいですがSTM32C0とかの
小規模なプログラムなら削減効果をかなり実感できると思います。
あとリンク段階で変なワーニング出るんですけど対象方法知ってる人いたら
教えてくだち。
●mbedサ終
ついに来てしまいましたね…
ねむいさんもほとんど使用しないままここまで来てしまいましたが
時代の仇花として人々の記憶に残るでしょう…(2026年完全終了)。
ねむいさん的にはオンラインコンパイラは圧倒的に相性悪くてやっぱり
PCで普通にコンパイルするのが身の丈に合っていると感じました。
●STLinkV3はST製以外のマイコンを排斥する！実質STM32専用ｯ！
まぢですか…、OpenOCDからも使えないとは…！
秋月で売ってるやつ買わないでよかった…！
実質STM32以外の他社製のCortex-Mのマイコンのフラッシュ書き込みは
おろかコアにconnectすらできないようです…。
一方で手持ちのSTLink/V2系は大丈夫なのかどうか実際に確認してみました。
使用したのはおそロシアの力でSWIMに無理やり対応させたSTM32F0Discovery
付属のSTLink/V2です…相手は今は亡きLPC810です！
まずはHLAとして接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : clock speed 1000 kHz
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.905861
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.093837s (2.743 KiB/s)
Info : verified 3072 bytes in 0.055933s (53.636 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01お次はDAPDirectで接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.882555
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0bc11477
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.219387s (2.460 KiB/s)
Info : verified 3072 bytes in 0.063133s (47.519 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
ファームのVerは20240821最新のV2J45S7を使用しておりますが、
STLink/V2のハードウエアなら他社製Cortex-Mマイコンでも大丈夫なようですね…
●そしてぱちもんSTLinkV2にもパチモン対策が
まぁこんなこったろうと思っていましたが、粗製乱造で広まっている中華製偽物
STLink/V2を検知したらシリアル番号を"C"にしてしまうファームウエアが発動
しているようです。
STM32CubeProgrammerではこのシリアルをもつぱちもんSTLink/V2が
使用できなくなります。
OpenOCDからはまだ大丈夫っぽいですがこちらも穴がふさがれそうですね。
ちなみにねむいさんがSTM8マイコンの読み書きするためにおそロシアの力を
使って改造したSTLink/V2はシリアル番号は"C"ではなかったのでセーフでした。
恐らく正規のSTM32マイコンを使用しているか否かで判別しているようですね。
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (116)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (82)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (27)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ねむい (12/18) - 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ひかわ (12/15) - STM32U0はぢめました
⇒ ねむい (08/07) - STM32U0はぢめました
⇒ ひかわ (07/28) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (05/17) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - いろいろ試す61(と今年の反省会)
⇒ ねむい (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/01)
- December 2024 (2)
- November 2024 (1)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (6)
- May 2009 (14)
- January 1970 (1)
Copyright(C) B-Blog project All rights reserved.