シュアファイアのフラッシュとか
欲しいなぁと思うんですけど
シュアファイヤのって高確率で123Aを使ってるんですよね
この電池 かなり前に発売された気がします
5年近く前
当時は「大容量、低価格、高耐久。そして安全」みたいな触れ込みだった気が
電動バイクのパワーソースになったり
電動工具とかにも使われてたと思います
要は 二次電池のはずなんですよ
実際に123A対応充電器とかも売ってますし
でも 12本入りで2000円台という値段を見ると
確実に一次電池ですよね
いや すっげー安い二次電池という可能性もあるんですけども
どっちにしろ 充電器が高いんですよねぇ
で、買うのを躊躇してます
純正電池がそんなに高くないんで
電池も大量に買えばいいんでしょうけど
2本で2時間しか使えないとなると あまり気軽に使えないんですよねぇ
でも 市販の「明るい」というLEDライトはたいして明るくないのが
経験的にわかってるので
とっとと明るい奴に移行したいです
僕が今使ってるのはOHMの140〜180lmの間くらいのモノだと思いますが
白なので せいぜい数十メートル程度しか照らせないです
ダイビングライトとか スゴい明るいらしいですけど
値段もスゴいですしね
シュアファイヤも値段は結構しますが
ブランド力がありますし
あとはS&Wも作ってるっぽいですね
こっちは安いですし単四電池で動くという利点もありますが
どうなんだろうなー とか思っちゃいます
で 何が言いたいかって
「明るいライトがほしい」
もちろん操作性のいいやつ
OHMのは普通の懐中電灯としてしか想定していないらしく
スイッチの操作性が悪いのと
ゴミでスイッチが簡単に使えなくなっちゃうので
なにかいいのないっすかね
2012年5月31日木曜日
2012年5月27日日曜日
らいとるーむふぉー 導入してみた
Lightroom4 略してLR4 導入してみました
PicasaでRAWの処理は無理だなー と思ったので
iPhotoはノーパなのでHDDの容量的な問題
ということで WinにLR4です
たぶん初めてアドビ製品買いました
で
LR4の利点とか欠点とか
PicasaでRAWの処理は無理だなー と思ったので
iPhotoはノーパなのでHDDの容量的な問題
ということで WinにLR4です
たぶん初めてアドビ製品買いました
で
LR4の利点とか欠点とか
2012年5月15日火曜日
ARMの変数型名
ARMは環境依存の変数型を無くすために普通のCとは違う名前で型が宣言されてます
ってことで その一覧です
↑の表のように 用途によって 色々と決まりごとがあるみたいです
(excelからコピペしただけなので見づらいですがご了承ください)
もちろん普通のCのようにintとかcharとかboolも可能ですが
この表に従ったほうが環境依存が減るので楽なんだそうです
覚えるのめんどくせーよ…
で ちょっと解説
かなり憶測を含んでるので間違ってたらごめんなさい
まず型の大きさですが
これはint+ビット数で決まります
コンパイラ依存のビットサイズじゃないので
移植が楽だけではなく 読むときにも楽なんだそうです
signed/unsignedですが まぁこれは説明しなくてもわかりますよね
符号あり/なしの区別です
符号ありはint 符号なしはuintです
constは定数か否かみたいな意味合いもありますが
組み込みの場合はRAMかROMかという違いもあります
でもまぁあまり意識することはないと思います
で 問題なのがvolatileっていう国の名前みたいなモノ
これはコンパイラの最適化を無効化するみたいな意味があります
例えば
uint8_t flag = 1;
while(flag) { ... }
というコードがあったて ブロックの中でflagを書き換えていない場合
コンパイラは
while(1) { ... }
と書き換えます
これは「どーせ値が変更されることはないんだから判定するだけムダ」という理由によるものですが
もしかしたらこのflagは割り込みで変更される可能性があるかもしれません
例えばシリアルの送信完了でRESETされる場合
本来は送信が終了されるまで待つだけのはずなのに
実際は無限ループに陥ってしまいます
これを回避するためにvolatileをつけることにより
「この変数は外部から変更されるので強い最適化はしないように」
ということになります
volatileについてはこのページがわかりやすいです
__IOだけでなく__Oも有るのは
コード中から間違って書き換えないように ということだと思います
が __Oを使う用途というのはあまり思いつかない(無いわけではない)
とりあえず こんなところですが
今まではARMでも普通にintとかcharとか使ってたけど
これから少しずつint32_tみたいな書き方に移行していこうかなぁ と 思ったり
ってことで その一覧です
通常の宣言 | CMSISでの宣言 | |||
-
|
signed | long | - | int32_t |
- | signed | short | - | int16_t |
- | signed | char | - | int18_t |
- | signed | long | const | const int32_t |
- | signed | short | const | const int16_t |
- | signed | char | const | const int8_t |
volatile | signed | long | - | __O int32_t |
__IO int32_t | ||||
volatile | signed | short | - | __O int16_t |
__IO int16_t | ||||
volatile | signed | char | - | __O int8_t |
__IO int8_t | ||||
volatile | signed | long | const | __I int32_t |
volatile | signed | short | const | __I int 16_t |
volatile | signed | char | const | __I int8_t |
- | unsigned | long | - | uint32_t |
- | unsigned | short | - | uint16_t |
- | unsigned | char | - | uint8_t |
- | unsigned | long | const | const uint32_t |
- | unsigned | short | const | const uint16_t |
- | unsigned | char | const | const uint8_t |
volatile | unsigned | long | - | __O uint32_t |
__IO uint32_t | ||||
volatile | unsigned | short | - | __O uint16_t |
__IO uint16_t | ||||
volatile | unsigned | char | - | __O uint8_t |
__IO uint8_t | ||||
volatile | unsigned | long | const | __I uint32_t |
volatile | unsigned | short | const | __I uint16_t |
volatile | unsigned | char | const | __I uint8_t |
↑の表のように 用途によって 色々と決まりごとがあるみたいです
(excelからコピペしただけなので見づらいですがご了承ください)
もちろん普通のCのようにintとかcharとかboolも可能ですが
この表に従ったほうが環境依存が減るので楽なんだそうです
覚えるのめんどくせーよ…
で ちょっと解説
かなり憶測を含んでるので間違ってたらごめんなさい
まず型の大きさですが
これはint+ビット数で決まります
コンパイラ依存のビットサイズじゃないので
移植が楽だけではなく 読むときにも楽なんだそうです
signed/unsignedですが まぁこれは説明しなくてもわかりますよね
符号あり/なしの区別です
符号ありはint 符号なしはuintです
constは定数か否かみたいな意味合いもありますが
組み込みの場合はRAMかROMかという違いもあります
でもまぁあまり意識することはないと思います
で 問題なのがvolatileっていう国の名前みたいなモノ
これはコンパイラの最適化を無効化するみたいな意味があります
例えば
uint8_t flag = 1;
while(flag) { ... }
というコードがあったて ブロックの中でflagを書き換えていない場合
コンパイラは
while(1) { ... }
と書き換えます
これは「どーせ値が変更されることはないんだから判定するだけムダ」という理由によるものですが
もしかしたらこのflagは割り込みで変更される可能性があるかもしれません
例えばシリアルの送信完了でRESETされる場合
本来は送信が終了されるまで待つだけのはずなのに
実際は無限ループに陥ってしまいます
これを回避するためにvolatileをつけることにより
「この変数は外部から変更されるので強い最適化はしないように」
ということになります
volatileについてはこのページがわかりやすいです
__IOだけでなく__Oも有るのは
コード中から間違って書き換えないように ということだと思います
が __Oを使う用途というのはあまり思いつかない(無いわけではない)
とりあえず こんなところですが
今まではARMでも普通にintとかcharとか使ってたけど
これから少しずつint32_tみたいな書き方に移行していこうかなぁ と 思ったり
2012年5月7日月曜日
宇宙兄弟 見てきたよ
映画 宇宙兄弟
見てきました
見始めてから思ったんだけど
僕、邦画嫌いだし(´・ω・`)
最近映画館で見たモノは全部洋画だったから
映画館では洋画ばっかりと無条件に思ってた
が、宇宙兄弟は面白かったですね
いろいろ突っ込みたいところはありましたが
で、問題の
南波六太が冒頭で使ってるPCのOS
あれは 間違いなくWinXPです えぇ
2025年でも企業の中ではXPが使われてるんですねぇw
あと
NASAのロケットの打ち上げシーン
字幕で
「燃料ロケット分離」という感じのがありますが
アレ どう考えても
「固体燃料ロケット分離」
ですよね
SRBって言ってるし
でも まぁそんな些細なことは大した問題じゃないですね
結構面白かったですよ
この映画
ついでに言うと
六太が探しものをしているシーンで
α-3が一瞬映ってましたね
あと2030年でもM4が使われているらしいです
以上、宇宙兄弟見てきたよ ということで
見てきました
見始めてから思ったんだけど
僕、邦画嫌いだし(´・ω・`)
最近映画館で見たモノは全部洋画だったから
映画館では洋画ばっかりと無条件に思ってた
が、宇宙兄弟は面白かったですね
いろいろ突っ込みたいところはありましたが
で、問題の
南波六太が冒頭で使ってるPCのOS
あれは 間違いなくWinXPです えぇ
2025年でも企業の中ではXPが使われてるんですねぇw
あと
NASAのロケットの打ち上げシーン
字幕で
「燃料ロケット分離」という感じのがありますが
アレ どう考えても
「固体燃料ロケット分離」
ですよね
SRBって言ってるし
でも まぁそんな些細なことは大した問題じゃないですね
結構面白かったですよ
この映画
ついでに言うと
六太が探しものをしているシーンで
α-3が一瞬映ってましたね
あと2030年でもM4が使われているらしいです
以上、宇宙兄弟見てきたよ ということで
2012年5月6日日曜日
STBeeでDAC
STBeeには12bitのDACが2本あります
PA4のDAC1とPA5のDAC2です
で これが使えれば面白そうだなぁと おもって
関数もADCより少ないので 楽にできそうだな と思って
試してみました
PA4のDAC1とPA5のDAC2です
で これが使えれば面白そうだなぁと おもって
関数もADCより少ないので 楽にできそうだな と思って
試してみました
2012年5月4日金曜日
2012年5月2日水曜日
Makeで書込み
STBeeをストリナの環境で書き込む場合
1.コードエディタ
2.Cygwin
3.コマンドプロンプト
が必要になります
ですが
Chromeでいろいろ見つつTweenでつぶやきつつ となると 結構狭い
ってことで Makeコマンドで書込みまで出来るようにしてみた
まず Makefileに
program: $(TARGET).hex
dfuw $(TARGET).hex
の2行を書き加える
これにより
make program
で書き込みをすることができる
が これだけじゃ意味が無い
と言うことで
all: gccversion build sizeafter
の後ろに
program
を書き加えて
all: gccversion build sizeafter program
とする
こうするとmakeコマンドでビルドから書込みまで出来るようになる
欠点を挙げるとすると
Cygwinは漢字とかが苦手みたい
なので 正常に書き込めた場合は問題ないのだが
正常に書き込めなかった場合(STBeeがつながってない とか)に ちょっとアレなことになる
具体的にはこんな感じ↓
上が正常に書き込めた場合
下が正常に書き込めなかった場合
ちなみに 「正常に失敗」した場合は ↓みたいになる
でもまぁ
「正常なら"done."って表示される」
「正常じゃないなら変にバケた文字が表示される」
ってことで わかりやすいしいいんじゃないかとw
Makefileはまったくわからないので
こんな書き方でいいのか とか
色いろあるのだけど
一応動いてるので良いことにする
ストリナさん
Mac OS Xで動作するDFUW お願いします><
DFUW使わないならMac OS Xでもいいのかな?
でもどっちにしても今手持ちのMBPはHDD空き容量がかなり少ないから
しばらくは本格運用出来ないしなぁ
1.コードエディタ
2.Cygwin
3.コマンドプロンプト
が必要になります
ですが
Chromeでいろいろ見つつTweenでつぶやきつつ となると 結構狭い
ってことで Makeコマンドで書込みまで出来るようにしてみた
まず Makefileに
program: $(TARGET).hex
dfuw $(TARGET).hex
の2行を書き加える
これにより
make program
で書き込みをすることができる
が これだけじゃ意味が無い
と言うことで
all: gccversion build sizeafter
の後ろに
program
を書き加えて
all: gccversion build sizeafter program
とする
こうするとmakeコマンドでビルドから書込みまで出来るようになる
欠点を挙げるとすると
Cygwinは漢字とかが苦手みたい
なので 正常に書き込めた場合は問題ないのだが
正常に書き込めなかった場合(STBeeがつながってない とか)に ちょっとアレなことになる
具体的にはこんな感じ↓
上が正常に書き込めた場合
下が正常に書き込めなかった場合
ちなみに 「正常に失敗」した場合は ↓みたいになる
でもまぁ
「正常なら"done."って表示される」
「正常じゃないなら変にバケた文字が表示される」
ってことで わかりやすいしいいんじゃないかとw
Makefileはまったくわからないので
こんな書き方でいいのか とか
色いろあるのだけど
一応動いてるので良いことにする
ストリナさん
Mac OS Xで動作するDFUW お願いします><
DFUW使わないならMac OS Xでもいいのかな?
でもどっちにしても今手持ちのMBPはHDD空き容量がかなり少ないから
しばらくは本格運用出来ないしなぁ
登録:
投稿 (Atom)