My Blog

IObitのSystemCare系のアプリは良いのだが余計な事もしてくれるので不必要な機能は削除する

LiveUpdate

> sc delete LiveUpdateSvc

以下のフォルダを削除

C:\Program Files (x86)\IObit\LiveUpdate

Uninstaller

Uninstallerのuninstallerを実行した後、以下のフォルダを削除

C:\Program Files (x86)\IObit\IObit Uninstaller

AVRのフューズビットについて調査してみようと思いAtmelのデータシートを参照した

• ATmega168Pと328Pのみ
• フューズビットとされているがデータシートではフューズバイトと記載されている
• 負論理なのでビットの意味に対する肯定・否定は、０：肯定、１：否定となる
• クロック選択関係はややこしかったので未稿

328P

上位バイト（HIGH FUSE）

名称	ビット	意味	備考
RSTDISBL	7	PC6がI/Oピンかリセットピンかを選択 0:I/Oピン 1:リセットピン
DWEN	6	デバッグWIRE機能許可
SPIEN	5	プログラム許可 0:許可 1:非許可	フラッシュメモリとEEPROMへの書込みを制御
WDTON	4	ウォッチドックタイマを常時有効 0:有効 1:無効（プログラムモード）	0:有効ではリセット後から開始される 1:無効の場合WDTCSRで有効にできる
EESAVE	3	ChipErase（初期化）時EEPROMの内容を保護 0:初期化しない 1:初期化する	0なら内蔵されているEEPROMを初期化しない
BOOTSZ1	2	ブートローダの容量選択 00:2048bytes($3800～$3fff) 01:1024bytes($3c00～$3fff) 10:512bytes($3e00～$3fff) 11:256bytes($3f00～$3fff)	()内はブートローダアドレス範囲（開始～終了） 開始アドレスがブートローダ実行時のリセットアドレス プログラム領域は$0000～ブートローダ開始アドレス-1となる
BOOTSZ0	1
BOOTRST	0	リセット時に実行される領域の選択 0:ブートローダ領域 1:プログラム領域

下位バイト（LOW FUSE）

名称	ビット	意味	備考
CKDIV8	7	システムクロック８分周 0:８分周する 1:8分周しない
CKOUT	6	システムクロック出力 0:出力する 1:出力しない	PB0に出力
SUT1	5	起動時間選択（最低14×CK） 00:+0 01:+4.1ms 10:+65ms 11:予約	00でリセット時RSTDISBLが0の場合は+4.1ms
SUT0	4
CKSEL3	3	クロック種別選択
CKSEL2	2
CKSEL1	1
CKSEL0	0

拡張バイト（Extended FUSE）

名称	ビット	意味	備考
-	7	未使用
-	6
-	5
-	4
-	3
BODLEVEL2	2	低電圧検出リセットの検出電圧選択
BODLEVEL1	1
BODLEVEL0	0

168P

上位バイト（HIGH FUSE）

名称	ビット	意味	備考
RSTDISBL	7	PC6がI/Oピンかリセットピンかを選択 0:I/Oピン 1:リセットピン
DWEN	6	デバッグWIRE機能許可
SPIEN	5	プログラム許可 0:許可 1:非許可	フラッシュメモリとEEPROMへの書込みを制御
WDTON	4	ウォッチドックタイマを常時有効 0:有効 1:無効（プログラムモード）	0:有効ではリセット後から開始される 1:無効の場合WDTCSRで有効にできる
EESAVE	3	ChipErase（初期化）時EEPROMの内容を保護 0:初期化しない 1:初期化する	0なら内蔵されているEEPROMを初期化しない
BODLEVEL2	2	低電圧検出リセットの検出電圧選択
BODLEVEL1	1
BODLEVEL0	0

下位バイト（LOW FUSE）

名称	ビット	意味	備考
CKDIV8	7	システムクロック８分周 0:８分周する 1:8分周しない
CKOUT	6	システムクロック出力 0:出力する 1:出力しない	PB0に出力
SUT1	5	起動時間選択（最低14×CK） 00:+0 01:+4.1ms 10:+65ms 11:予約	00でリセット時RSTDISBLが0の場合は+4.1ms
SUT0	4
CKSEL3	3	クロック種別選択
CKSEL2	2
CKSEL1	1
CKSEL0	0

拡張バイト（Extended FUSE）

名称	ビット	意味	備考
-	7	未使用
-	6
-	5
-	4
-	3
BOOTSZ1	2	ブートローダの容量選択 00:1024bytes($1c00～$1fff) 01:512bytes($1e00～$1fff) 10:256bytes($1f00～$1fff) 11:128bytes($1f80～$1fff)	()内はブートローダアドレス範囲（開始～終了） 開始アドレスがブートローダ実行時のリセットアドレス プログラム領域は$0000～ブートローダ開始アドレス-1となる
BOOTSZ0	1
BOOTRST	0	リセット時に実行される領域の選択 0:ブートローダ領域 1:プログラム領域

 

 

先日Arduino上で確認したものを実際に使用する回路にするためブレッドボードで実装した

ブレッドボードでの実装は消費電力を確認する目的もある

回路は3.3V供給とArduinoの簡易互換で済むので楽勝

（回路図は未稿）

通信状態時の電流は6.77mA、LEDが点灯している割には省電力である

パワーダウンスリープ時は0.19mA（こちらの情報では0.13mAとありほぼ同じなので問題ないだろう）

PC（Tera Term）と実際に通信してみた（USB経由だがUSBへのレベル変換はPCから電力供給しているので以下の測定値には含まれない）

実際の通信では7.11mAで、一瞬なのではっきりとした数値は不明だが偶に10mA位になる

おそらくSDカードに書き込みする際に3mA位消費するのだろう

最大でも約10mAと考えて良さそうだ

電源部の三端子レギュレータはNJU7223F33（500mA）を使ったが余裕過ぎるので、XC6202P332TB（150mA）に変更

同じ低損失CMOSなので消費電力はほとんど同じであった

まだ余裕だし50mAタイプの物（秋月ならS-812C33AY-B-G）でも良さそうなので今度購入しておこう

とりあえず問題なさそうで後はユニバーサル基板に実装してケースに入れるのだがSDカードスロットやボタンがあるため配置で悩んでいる

急ぐこともないのでじっくりと考えてからにする

（追記）

ユニバーサル基板への実装（ケースに付けた写真は撮影してなかった）

プログラムはできTera Termとのテストは完了したので実際にUSART（UARTかな）接続による実機確認を行うことにする

先ずはオシロキットの転送機能の確認を行っていないのでUSBで接続で確認してみた（動作しなかったら確認にもならないので・・・）

電源ＯＮ時にそれなりの文字が表示されると、どこかのサイトで見たことがあるが文字化けで最初の文字は確認できなかった（USB変換の性能の問題か？）

Tera Term側からXmodem受信したところ正常終了したのでオシロキットの転送機能は正常動作している

転送前後で何らかの文字が送られてないか期待したが何もなかった（転送後も上のTera Term画面から変化なし）

次は作成した（Arduino上）プログラムで確認し正常終了

これまでテストで使ったSDカードの中身、タイムスタンプが同じになるのは残念なところ

今回転送した波形イメージ

今日はここまでで終了