PICAXEの省エネモードを試す

    PICAXE
    07 /22 2017
    PICAXEを電池で長時間使いたくなった時のために低消費電力(Reduce Power)モードでどれくらい電源電流が減るのか実験です。

    一定時間省エネモードにするのはPICAXE M2ではNAPとSLEEP命令。
    普通に使っていて省エネにするということではなく、CPUを止めて省エネにするということ。
     普通に使っていて省エネにするのはCPUクロックを下げることですが動作中では出来ません。
    なお、誤差が-50%~+100%の誤差となっている。 本当かな? 
    室温を測って表示する温度計ならば問題ないだろうが、特定の周期で測りたいとかPAUSE命令代わりに使うには問題。 これも測ってみよう。

    メモ: 基本的にセンサー類は自己発熱による誤差を減らすために、サーミスタの様なパッシブな素子は低電流で使い、シリアル通信でデータを読み出す素子は必要以上に速い周期で 読み出さない方がよい。

    NAP period
    periodは時間を決定する変数/定数。
    0     18ms
    1     36ms
    2     72ms
    3     144ms
    4     288ms
    5     576ms
    6     1.1s
    7     2.3s
    8     4s
    9     8s
    10     16s
    11     32s
    12     64s (1 min)
    13     128s (2 mins)
    14     256s (4 mins)

    SLEEP period
    periodは 1~65535 で 2.3秒の倍数でスリープ時間を指定する変数/定数。
    SLEEP 使用中は「time」変数は増加しない。

    因みにPICAXE Editor 6をインストールしたらWindowsがError 1310を返してできなかった。
    途中で「Only for me 」を選んだのが原因で「all users」ならできました。

    手持ちの08M2(PIC12F1840)、14M2(PIC16F1825)、18M2(PIC16F1847)で測ってみる。
    電源電圧5V。

    main:
     ;high C.2
      ;NAP 8 ;4s
      ;SLEEP 2 ;4.6s
     ;low C.2
      ;PAUSE 4000 ;4s
    goto main

    消費電流の測定 27℃

    goto main PAUSE 4000 NAP 8 SLEEP 2
    08M2 0.694mA 0.652mA 0.122mA 0.124mA
    14M2 1.097mA 1.050mA 0.438mA 0.438mA
    18M2 1.132mA 1.068mA 0.403mA 0.408mA
    goto mainだけ は動作電流を想定。
    参考までPAUSEも測ってみた。 僅かに減る。
    NAPとSLEEPが省エネモード。 08M2はそれなりに減るが14と18がイマイチ。
     CPUが完全には止まっていない為だがそれにしても14と18は多い。
     元のPICが12F、16Fと違う影響?
    なお、指でICを温めると0.4mA→0.5mA位に電流が増えた。 (FETのリーク電流が増えるので普通)

    時間の正確さ 27℃ 08M2で約4秒以下を測った。
     NAP
     Period
    Time
    Delay
    実測値
    0
    18ms 17ms
    1 36ms 33-34ms
    2 72ms 67-68ms
    3 144ms 132-134ms
    4 288ms 265-270ms
    5 576ms 540ms
    6 1.1s 1.06s
    7 2.3s 2.15s
    8 4s 4.3s
    SLEEP
    Period
    Time
    Delay
    実測値
    1 2.3s 2.15s
    2 4.6s 4.3s
    まあ、こんなものかなという精度。 温度で差は見られなかった。
    なお、NAPとSLEEPは他の命令に制約がでるので詳しくは説明を読むこと。
    マルチタスクでは他のタスクも止まるはずです。

    以上

    PICAXEでLEDイルミネーションの実験(失敗?)

    PICAXE
    11 /13 2016
    クリスマス前なもので?PICAXEでLEDイルミネーションの実験(遊び?)をしてみました。
    内蔵のEEPROMから周期的にデータを読み出して、シフトレジスタに転送して8個のLEDを点滅させる回路です。

    回路図
    LED_illumination01.png
    PICAXEからシフトレジスタ(74HC164)にデータを転送してLEDを点けるものです。 多数・大電流のLEDを繋ぐ場合TRかFETでバッファする必要があるのでHiで点灯させています。

    PICAXEで行う場合の難点はシフトレジスタへのデータの転送が遅いこと。
    この回路は原理的にシフト中のデータでもLEDが点灯するので転送が速い方が目立たない。 PICAXEは低速で厳しそうなのでやっていなかった。

    シフトレジスタとLEDの間にD-FF(74**574等)を入れて、シフトレジスタへ転送してからD-FFにまとめてシフトすれば問題なくなるのが配線が20本増えて面倒。(持ってないし)

    プログラム
    実際のデータ転送(シフト)時間はCLK8個分の時間。
    パラ→シリの変換時に1か0かの判断で時間差が出るので%10101010で平均時間をみる。
    LED_illumination02.jpgLED_illumination03.jpg
    20ms弱と思ったよりは速かった。 
    が、転送中の発光は基本的に目障りだった。
    ただ、データのパターンによっては全く感じないものもある。(55h、AAhの繰り返し)
    目立つのはLEDが1個しか点灯しないパターン。
    LEDが2個点灯するパターンだとそんなには気にならない?
     例 アニメーションGIF 2MB 20フレーム/s

    LED4個なら転送時間が半分になるので多少良くなるか?
    LED_illumination04.png
    プログラム
    う~ん、多少良くなったような気もするが差はよく分かりませんでした。
    最低1/10の2msとかにしないとダメな感じです。

    転送前にシフトレジスタをリセットして追い出されるデータを消すのもやってみましたがデータパターンによってはずっと消えっぱなしになるLEDが出て返ってシフト中の点滅が目立つのでやめました。

    なお、実験なので一つのプログラム中でEEPROMへの書き込みも行っていますが、このままだと電源を入れる度に毎回書き込みを行ってしまいEEPROMの寿命が縮みます。
    もし、この回路を使うならば一度このプログラムを書き込んだら、EEPROM 0,(・・・)の行をコメントアウトして、先頭付近の#no_dataを有効にして再度書き込んで下さい。

    因みにEEPROM(FLAHも)の寿命はフローティング(浮き、浮遊)ゲートの絶縁膜がへたることで来るようです。
    DRAMのようにゲートに電荷を溜めて記憶するのですが、絶縁膜を貫通するのに高電界(≒高電圧)を掛けてトンネル効果で書き込むので絶縁膜が劣化するようです。
    データの保持期間も絶縁膜の性能で決まるはずです。
    因みに東芝からSanDiskの情報が韓国のSK Hynixに漏れたのはこの絶縁膜の技術なようです。
    高電圧は内蔵のDC/DC(チャージポンプ?)で発生するようです。
     大昔のPROMは12Vが必要だった。

    発光パターンによっては使えそうですが基本的にD-FFを入れた方が良いでしょう。(当たり前)

    以上

    FTDIのUSBシリアル変換ケーブルが動かない

    PICAXE
    10 /23 2016
    Windows 10でFTDIのUSBシリアル変換ケーブル(アダプタ)(以下、変換ケーブル)をうまく認識しないのである。 (秋月電子通商で買ったTTL-232R-5V
    動かなくなってから2か月経ちましたがやっと原因が分かりました。(涙)
    新しくBUFFALOとか大手メーカーのを買わなくて良かったです。(BUFFALOのもFTDIだし)

    その前に症状の確認
    変換ケーブルを挿すとマウスのポインター(カーソル)が少しずつ勝手に動いて(飛ぶ、暴走して)おかしい。
    マウスを外してタッチパッド(ポインティングデバイス)だけにしても同様。
    マウスに干渉しているような感じ。

    変換ケーブルやマウスを挿すUSBポートを変えると一瞬まともに動くことがあるので変換ケーブルが壊れているわけではない。

    デバイスマネージャーで見ると USB Serial Port は存在し正常動作となっている。 これから見ても変換ケーブルは壊れていないはず。

    USB Serial PortのプロパティでCOM番号を変えようとすると使っている人がいるが本当に変えるかみたいなメッセージがでる。

    →どうも誰か(別のデバイス)が先に使っているようである。
    昔マイクロソフトでFTDIのチップを使ったマウスがあったせいではないかと推測した。 →正解でした。

    デバイスマネージャーの抜粋で説明します。(Windows 10)
    変換ケーブルを挿す前
    FTDI_NG_01.png
    タッチパッドとワイヤレスマウスが見えます。

    挿した後
    FTDI_NG_02.png
    USB Serial Portは良いのだが Microsoft Serial BallPointも追加される。
    調べてみるとトラックボールが付いたシリアルマウスみたいなもの。
     Microsoft Ballpoint Mouse になる場合もあるらしい。
    そんなものは使っていません。
    つまり誤認識でこのドライバーがロードされ、これがFTDIのチップをアクセスしているということ。 (今まで気づかなかったのはUSBコントローラーを見ていたため)

    これを右クリックして無効にする。
    マウス等が全く使いものにならない場合はカーソル、enter、tab、escキーを駆使する。
    FTDI_NG_03.png
    この件を解決するレジストリがあるらしいのだが上記の方法が簡単である。
    Windows 10 anniversary updateがせっかく使いやすくしたWindowsの設定(レジストリ)を初期化しまくってくれたので、その時余計なことをしたのだと思っています。 なお、これでも使用中にアクセスできなくなることがあるが挿し直すと問題なく使える。

    参考 (にならないけどヒントになった記事)
    Windows 7 でシリアル デバイスがシリアル マウスとして検出される

    Windowsのバージョン(2000,XP,Vista,7,8,8.1)によらず何かの拍子(IRQの組み合わせ?)で症状がでるらしい。
    FTDIのドライバーソフト(D2XX用VCP)も無関係。
    FT232RLだけでなくFT2xxシリーズ(FT234xとか)ででるらしい。(VCPドライバーが同じ)
    ProlificのPL2303を使った変換ケーブルでも同様という記事もあるが持っていないので未確認。

    この不具合は以前からあるようですがネットでの記載が少なく検索で引っ掛かりにくいようです。 分からずに泣き寝入りしている方が多いかもしれません。

    大手メーカー(バッファロー、ELECOM、サンワサプライ等)製の変換ケーブルがどこのメーカーのチップを使っているかは下記が参考になります。
     秋山製作所 USB-シリアル変換ケーブルについて

    ドライバーキャッシュの破損で動かない場合もあるので、この記事に当てはまらない場合はこちらの記事の末尾を参考にして下さい。
    なお、Windows 10にドライバーキャッシュがあるか調べましたが確認できませんでした。

    以上

    Friendship 7

    浅く広くのハード屋です。
    コメントへの返信には過大な期待をしないで下さい。 非公開コメントは停止しております。 不適切なコメントはFC2で自動的にはじかれます。
    リンクフリーですが盗作は禁止です。
    本ブログの内容を参考にされる場合はあくまで自己責任でお願い致します。