STM32CubeF3のUSB CDCミドルウェアがバグってる

STMicroelectronicsが用意したSTM32のUSB CDCミドルウェアが、少々バグってるらしい。
　PCからVCP(仮想COMポート)に送信した文字を、STM32F3DISCOVERYからエコーバックするだけのプログラムを書いたが、最初の1文字しかエコーバックされない。デバッガで調べると、2文字目以降でコールバック関数が呼ばれていないようだ。ぐぐってみたら、ズバリの現象を特定したスレがフォーラムに見つかった。
　USB middleware issue with CDC/VCP: only x packets receivable (HAL 1.1.0 and Host-Device_Lib 2.1.0)

　受信処理の中で、受信完了のコールバックを呼んでいないらしい。HeapSizeが小さすぎるという罠もあったらしいけど、これは試す前に書き換えた。

　VCPが通るようになったので、PCからコマンドを送る経路が確保する目処が立った。でも、リセットの度にUSB抜き差しして再接続は面倒。いずれFT232RLのUSB-UART変換に逃避してしまうかもしれない。

Keil 5.11aはST-LINK2の最新ファーム(V2.J21)に未対応

　STM32用のファームの雛形は、今年リリースされたSTM32CubeMXで用意することにした。クロックの選択やピンアサイン、タイマーの設定がGUIでできて、禁則もチェックしてくれる。
　開発環境は、コードサイズが32kBを越えないと踏んで、STM32CubeMXが対応しているKeil MDK-ARM Liteにした。が、ここに落とし穴があった。

　Keil  MDK-ARMと別にインストールしたST-LINK UtilityをSTM32F3DISCOVERYに初めて接続したとき、「ファームが古いからアップデートせい」と表示されたので言うとおりにしたのだが、これが罠。現在最新のKeil 5.11aは、ST-LINK2の最新ファームに対応していない事を後で知った。お陰で、ビルドしたファームウェアをダウンロードさせようと何度試しても、「USB communication error」で失敗する。これで一晩無駄にした。
　ぐぐって見つけた解決策は、 ファームウェアのダウングレードだった。
　"Keil 5.11 st-link usb communication error"
　　http://www.keil.com/forum/58066/
　Keil 5.11aのインストール先にアップデータがあるので、これを使うとダウングレードが出来る。答えを見つけて3分で解決。

　今この時期だけに存在する旬なバグを踏んでしまった。天に見放されているのかもしれない。先が思いやられる。

初めてのSTM32F3DISCOVERY

マイコンでモーターを制御するために、STM32F3DISCOVERYその他一式を秋月電子で買ってみた。ファームウェアは、まだ1行も書いていない。


最終目標は、薄いカードをエアーポンプで吸引して動かす、卓上版リフティングマグネットもどき。ステッピングモーターで台座、サーボモーターでアームをを動かし、DCモーターで動く水槽用エアーポンプの吸引側を使ってカードを吸い付ける。

 ステッピングモーターのドライバとして選んだのは、DRV8830。I2Cで制御するので、配線数が少なくて済む。サーボモータはSTM32のPWMで直接制御。ポンプのDCモーターは、GPIOでモータードライバDRV8832に指令を出してON/OFFする。ドライバをDRV8830に統一しなかったのは、STM32の学習を兼ねるので、複数の方式を使いたかったから。

　STM32も、I2Cも、ステッピングモーターも、サーボモーターも、PWMも初めて使うものばかり。初物ばかりで、長い道のりになりそうだ。

Raspberry Piにshutdownスイッチ追加

　去年の暮れに、常時稼動させている家鯖をShuttle XS35からRaspberry Piに交替しました。Raspberry Piには電源スイッチがありません。通電すると即起動し、電源を切る前にはログインしてshutdownコマンドを実行します。電源OFFがちょっと面倒です。
　もっと手軽に電源を落とせるように、少々工作して、 GPIOとGNDの間に押しボタンスイッチを接続しました。プルアップしておいたGPIOのエッジ割り込みを監視し、GNDに落ちて5秒継続したらshutdownが走ります。参考になったのは、こちら↓。
　「Raspberry Pi にシャットダウンボタンをつける」
 　　http://d.hatena.ne.jp/penkoba/20130925/1380129824 

今は、このようなスクリプトでシャットダウンの指令を監視しています。

#!/usr/bin/env python2.7

import RPi.GPIO as GPIO
import time
import syslog
import os

# use GPIO 27 as shutdown button
WatchGpioNo = 27
LEDGpioNo = 4
SleepStepSec = 0.1

def KeepWatchForSeconds(seconds):
    GoFlag = True
    LEDState = False
    if seconds < 1:
        seconds = 1
    while seconds > 0:
        LEDState = not LEDState
        GPIO.output(LEDGpioNo, LEDState)
        time.sleep(SleepStepSec)
        seconds -= SleepStepSec
        if (GPIO.input(WatchGpioNo) == True):
            GoFlag = False
            break
    return GoFlag

def CallShutdown():
    syslog.syslog(syslog.LOG_NOTICE, "Going shutdown by GPIO.")
    os.system("/sbin/shutdown -h now 'Poweroff by GPIO'")

def SlowBlink(seconds):
    for i in range(int(seconds)):
        GPIO.output(LEDGpioNo, GPIO.LOW)
        time.sleep(0.5)
        GPIO.output(LEDGpioNo, GPIO.HIGH)
        time.sleep(0.5)
    GPIO.output(LEDGpioNo, GPIO.LOW)

if __name__ == '__main__':

    GPIO.setmode(GPIO.BCM)

    # GPIO 27 set up as input. It is pulled up to stop false signals
    GPIO.setup(WatchGpioNo, GPIO.IN, pull_up_down=GPIO.PUD_UP)
    # GPIO 4 set up as output.
    GPIO.setup(LEDGpioNo, GPIO.OUT)

    try:
        SlowBlink(5)
        while True:
            GPIO.output(LEDGpioNo, GPIO.LOW)
            syslog.syslog(syslog.LOG_INFO, "Waiting for falling edge on port %d" % WatchGpioNo)
            GPIO.wait_for_edge(WatchGpioNo, GPIO.FALLING)
            syslog.syslog(syslog.LOG_INFO, "Falling edge detected.")
            if KeepWatchForSeconds(5):
                SlowBlink(5)
                CallShutdown()
                break
        GPIO.cleanup()           # clean up GPIO on normal exit
    except KeyboardInterrupt:
            GPIO.cleanup()       # clean up GPIO on CTRL+C exit

　単にスイッチを監視しているだけでは、スイッチを「ちょん」と押しただけでシャットダウンが走ります。自分の感覚としては、PC並みに数秒間押し続けてからシャットダウンしたほうが安心なので、ある程度の時間継続してスイッチが押されたことを見届けてからshutdownが走るようにしました。
　また、スイッチだけで表示が無いと、シャットダウンが受け付けられたか否かがしばらく待たないとわかりません。GPIO4にLEDを接続して、点滅動作で受付状況がわかるようにしました。

　試運転中の動画は、こちら。

AOSPのmirror用manifesttが足りない

KitKatのソースが公開されたので、毎日syncしているAOSPのmirrorからsyncしてみたが、何か足りないっぽい。

fatal: '/home/aosp/AOSP/platform/external/lzma' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
...

error: Exited sync due to fetch errors

この問題は、Android Buildingのgroupでも指摘されていた。

 　aosp mirror/manifest missing some git projects form android-4.4_r1 

ワークツリーに展開する際に参照する  https://android.googlesource.com/platform/manifest.git に含まれているprojectの幾つかが、ミラーリングに使用する  https://android.googlesource.com/mirror/manifest.git に含まれていないのが原因らしい。
KitKat公開直後は多くのprojectが不足していたようだが、指摘を受けて大半は改善されたようだ。しかし11月10日の時点でも、まだlzmaとsil-fontsがmirrorに含まれていない。

　Mirror/manifest project

この件について、Repo and Gerrit Discussionで質問があり、スレ違いの指摘と共に解決策が提示されていた。
 　aosp mirror/manifest missing some git projects form android-4.4_r1

ミラー用の .repo ディレクトリの中に、このようなlocal manifestを追加したら、デフォルトのmanifestに抜けているプロジェクトもミラーされるようになった。

$ cat .repo/local_manifests/missing.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="platform/external/lzma" />
  <project name="platform/external/sil-fonts" />
</manifest>

 めでたし、めでたし。

Microsoft Updateができなくなった

　毎月恒例のMicrosoft Update公開日になったので、自宅で使っている3台のPCでアップデートを仕掛けたところ、1台だけ、アップデートの確認中から先に進まなくなった。自宅proxyのログを確認したところ、エラーコードを含んだURLに繰り返しアクセスしていて、先の画面に進めなくなっている模様。エラーコードをぐぐってサポートページに行き着いた。

Error code 0X80248007 when you try to use Windows Update or Microsoft Update to install updates　　 http://support.microsoft.com/kb/958046

書かれている手順の通りに、フォルダを削除したら解決した。
C:\Windows\SoftwareDistribution\Download を削除しても変化は無く、
C:\Windows\SoftwareDistribution を削除したら、何事も無かったように問題は解決した。

このエラーコード「0X80248007」だが、PCの画面には全く出て来なかった。たまたまproxyのログを見て知ることが出来たが、普通の家にはマイproxyなんて置いてない。滅多に遭遇しないだろうが、難問だと思う。

Ubuntu 10.04 LTS から 12.04 LTS へ移行してトラぶった話

　Ubuntu 10.04 LTS DesktopがEnd of Lifeになったので、Androidのビルド用に使っているPCのOSを12.04 LTSへアップデートしました。で、いろいろトラぶりました。

アップデートマネージャでアップデートしたらブートマネージャが壊れてHDDから起動しなくなった

OS更新でありがちなトラブルですが、いきなりブートしないのには焦りました。インストール媒体でブートしてgrubを更新して解決しました。

Androidのビルドが出来なくなった

これは前から分かっていた事なので、http://source.android.com/source/initializing.html に従ってパッケージを入れる等してみましたが、これでは足りませんでした。gcc-4.4を追加でインストールして、gcc-4.6ではなくgcc-4.4が優先的に呼ばれるようにして解決しました。ターゲットによっては、問題無いのかも知れません。

Windowsサーバの共有をmount.cifsでマウントできなくなった

共有のアクセス権設定が妙に凝っていて、上位のフォルダに対して読み込みアクセス権が無く、一部の下位のフォルダだけが読めるようになっている場合に、mount.cifsでマウントできません。同じフォルダが Ubuntu 10.04 LTSではマウントできていました。
SambaのBugzillaには登録されていますが、未だ解決のめどが立っていません。
　　https://bugzilla.samba.org/show_bug.cgi?id=8950
　この問題にはとても困っていますが、もともとcygwinでやっていてUbuntuに引越しした作業に関する要件なので、手順の一部をcygwinに戻して回避しようと思っています。

　Unityがとっても使いにくいのですが、よく使うTerminal,Emacs等をデスクトップに置いて日常的には不自由は無くなりました。