2017年06月17日

ProjectionBallオープンハードウェア化

先月、MakerFaireBayAreaに参加して以降、
海外からの問い合わせが増えました。


一方で海外向けに販売できる体制を短期間で構築できないため、
最新版のProjectionBall IoTをオープンハードウェア化することにしました。

ProjectionBall IoT v5.4の特徴
・スマートフォンやPCからWifi経由で遠隔操作可能
・アナログ時計、デジタル時計を内蔵
・任意の文字列を表示可能(最大32文字、フォント内蔵)
・直径が10cm(旧モデル12cm)と一回り小さく
・Wifiはアクセスポイントモード、サーバモードの両対応


◆ProjectionBall IoTファームウェア&ソースコード

◆ProjectionBall IoT部品リスト&STLデータ&カーバーデータ

◆ProjectionBall IoT Wifiモジュールソースコード


ドキュメント類や説明がまだ充実していない状況のため、
英語版のドキュメント含め、順次、追加していきたいと思います。


また、国内向けにはProjectionBall IoTの完成版を
近日、協力会社から販売開始予定です。



ぜひ、Facebookページへ「いいね」をお願いします。

posted by Crescent at 00:00| Comment(0) | TrackBack(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2017年05月12日

コードプロテクト機能

今回はSTMマイコンのリードプロテクト機能(RDP)について紹介します。


製品などにSTMマイコンを組み込んで出荷する場合に
JTAGやSWD端子を介してマイコン内部のデータを取り出して、
解析やコピーされてしまうことを防止するためにリードプロテクト機能を利用します。


F4やL4ではPCROPという更に強化されたプロテクト機能があります。
第三者のコードをCPUに実行させて内部のコードを取り出す操作を防止します。
ただ、F3ではPCROPに対応していません。


他に意図しない書き込みを防止するための書き込みプロテクト機能(WRP)もあります。


今回は一般的なリードプロテクト機能についてのみ紹介します。


リードプロテクト機能には3つのレベルがあります。

◆読み出し保護レベル0
 コードプロテクトなし、書き込み、読み込み可能、初期状態。

◆読み出し保護レベル1
 JTAG、SWD等で読み込み不可、書き換え可。
 また、読み出し保護レベル0へ変更も可

◆読み出し保護レベル2
 JTAG、SWDの認識を不可にさせるため、
 読み込み書き込み完全に不可。
 また、読み出し保護レベル2から他のレベルは変更不可。

今後、ファームをアップデート等に対応させるためには、
最大でも読み出し保護レベル1が適当なようです。
読み出し保護レベルを2にしてしまうと
マイコンを丸ごと載せ替えない限り何も変更できません。


上記の読み出し保護レベルの変更方法は
ST-Link Utilityから行う方法とコード内から行う方法の2種類あります。



◆ST-Link Utilityから行う方法

ST-Link Utilityの「Target」から「OptionByte」を選択します。

readprotect-btn.jpg

上部の「Read Out Protection」の項目のレベルを変更します。
FlashSectorProtectionを必要に応じて解除、もしくは選択して
「Apply」をクリックすると
現在の書き込まれたファームに対して保護が適用されます。

readprotect.jpg



◆コード内から行う方法
 コード上に埋め込む場合はSTコミュニティー内のこちらで紹介されていました。



毎回行うのは面倒という場合はコードに埋め込んだ方が良さそうです。

ただ、更新ファームを配布する場合はファイルとして配布されてしまうため、
あまりプロテクトを掛ける意味は薄くなってしまいます。


製品のコピーを避ける場合は
コードプロテクト&OTAアップデートなどを利用する他に
Apple製品のように基板の色を黒色等にして、
配線パターンを見にくくするなど多面的に対策する必要がありそうです。


タグ:部品 HAL STM32
posted by Crescent at 00:00| Comment(0) | TrackBack(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2017年04月01日

STM32CubeF3 v1.7.0

今回はCubeMXのライブラリをアップデートした際に
遭遇した不具合?について共有したいと思います。


先日リリースされたSTM32CubeMX4.2.0
とSTM32CubeF3 1.7.0を適用しました。


その後、STM32CubeF3 1.6.0で生成した
CubeMXのプロジェクトファイル(*.ioc)を開いて、
再度、別のコードを生成すると
・HALドライバはSTM32CubeF3 1.6.0
・自動生成コードはSTM32CubeF3 1.7.0という
現象が発生しました。

そのため、STM32CubeF3 v1.7.0から増えたパラメータ

htimX.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;

がHALドライバにないため、
コンパイルが通らないという現象が発生しました。



cubemxf3.png

設定はSTM32CubeF3 1.6.0から読み込む設定です。


STM32CubeF3 1.6.0で生成したCubeMXの
プロジェクトファイル(*.ioc)を流用せずに
0から新規プロジェクトで生成すると上手くバージョンが一致したコードが生成されました。

古いバージョンで生成したプロジェクトファイル(*.ioc)は
テンプレートの読み込み先を最新にするか、
0から新規プロジェクトで生成するのが良さそうです。

特に新しい機能が追加された場合、
旧ドライバにない機能をコメントアウトで対応できますが、
新機能が不定となる可能性もあり、
別の不具合を起こす可能性もあるので、統一した方がよいと思いました。


バージョンアップするとこいう不具合が起きたりするので、
アップデートを見送るか、適用するか悩ましいものです。


ちなみに新しく増えたパラメータAutoReloadPreloadは
TIMx_ARR registerのバッファ有無切替が可能なようですが、
どのような効果があるのか、
資料を見つけられず良く分かりませんでした。
また、追って調査してみたいと思います。


**追記**
おすすめできる方法ではありませが、
あとから再度、旧ライブラリで生成する場合は
*.iocファイルをテキストエディタで開いて、
V1.X.X.Xの部分を書き換えるのが手っ取り早い方法と分かりました。

posted by Crescent at 00:00| Comment(0) | TrackBack(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2017年02月06日

静電容量センサ

今回はSTM32での静電容量センサについて紹介します。


環境はこれまで同様、
・STM32F303K8
 +SW4STM32(System Workbench for STM32)
 +STM32CubeMX(HAL ライブラリ、F3 ver. 1.60)
です。


静電容量センサとは、接点等を使用せずに静電容量を監視することで、
人などの指が触れたかどうかを判断するセンサです。

エレベータのボタンや機器のボタンなどに使用されています。
電極を露出しなくとも、筺体に触れるだけでタッチ操作、
複数電極の組み合わせで旧iPodのようなスクロール操作等が可能になります。


STM32では標準で静電容量センサ機能(TSC:Touch Sensing Controller)が
搭載されているため、使用方法の概要を紹介します。


CubeMX上で「TSC」の項目から設定します。

TSCはセンサグループが分かれており、
グループ毎に設定や読み取り等を行います。


tsc-setting.png


グループ毎に必ずサンプリングキャパシタを接続する必要があります。
サンプリングキャパシタのIOには基準となるコンデンサを接続します。
サンプリングキャパシタの容量を変更することで、
タッチセンサの感度が変わります。
そのため、グループの中で1つはサンプリングキャパシタに接続するため、
グループ内のすべてのIOをタッチセンサで使用できない仕様です。


今回はG1_IO_1にサンプリングキャパシタとして0.1uFの積セラを接続し、
GNDへ落としました。

STM32L152 DiscoverySTM32F072 Discoveryのタッチセンサでは
47nFをサンプリングキャパシタとして使用していました。


tsc-cubemx.png

パラメータ詳細設定ではMax Count Valueが小さいと
上手く値が取得できないため、要注意です。
上記では16383に設定しました。


コードとしては
初期化で
MX_TSC_Init();

while(1)内では

   htsc.Init.ChannelIOs = TSC_GROUP1_IO2;//ADD for multi ch read
   HAL_TSC_Init(&htsc);                              //ADD for multi ch read
     HAL_TSC_IODischarge(&htsc, ENABLE);
     HAL_Delay(1);


      if (HAL_TSC_Start(&htsc) != HAL_OK)Error_Handler();
      while (HAL_TSC_GetState(&htsc) == HAL_TSC_STATE_BUSY)
          {           
          }

      __HAL_TSC_CLEAR_FLAG(&htsc, (TSC_FLAG_EOA | TSC_FLAG_MCE));

      if (HAL_TSC_GroupGetStatus(&htsc, TSC_GROUP1_IDX) == TSC_GROUP_COMPLETED){
          Value1 = HAL_TSC_GroupGetValue(&htsc, TSC_GROUP1_IDX);
      }


      htsc.Init.ChannelIOs = TSC_GROUP1_IO4; //ADD for multi ch read
      HAL_TSC_Init(&htsc);                               //ADD for multi ch read
      HAL_TSC_IODischarge(&htsc, ENABLE);
      HAL_Delay(1);

      if (HAL_TSC_Start(&htsc) != HAL_OK)Error_Handler();
      while (HAL_TSC_GetState(&htsc) == HAL_TSC_STATE_BUSY)
       {        
        }

       __HAL_TSC_CLEAR_FLAG(&htsc, (TSC_FLAG_EOA | TSC_FLAG_MCE));

      if (HAL_TSC_GroupGetStatus(&htsc, TSC_GROUP1_IDX) == TSC_GROUP_COMPLETED){
         Value2 = HAL_TSC_GroupGetValue(&htsc, TSC_GROUP1_IDX);
       }

      printf("Value: %d, %d \n\r",Value1,Value2);


本来、複数のタッチセンサを読み出す場合はDMA等を使用するのが正しい方法ですが、
今回は実験のため、IO設定とHAL_TSC_Initを行うことで
強制的に複数chを読み出しました。




tsc-setting2.png



電極部に指を近づけると値が小さくなりました。


電極部のサイズ、配線の引きまわし、
基準となるサンプリングキャパシタ(Cs)などの要素を調整しないと
誤検知なく、反応のよいタッチセンサは難しいと思います。



また、次回、タッチセンサ設計ガイドラインの
データシート[PDF]を参考にしながら、
ここらへんを実験してみたいと思います。
posted by Crescent at 00:00| Comment(0) | TrackBack(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2017年01月21日

磁気エンコーダTLE5012B

今回はInfineon製の磁気エンコーダTLE5012Bに試食について
紹介させて頂きます。


環境は、
・STM32F303K8
 +SW4STM32(System Workbench for STM32)
 +STM32CubeMX(F3_1.6.0)
です。


ProjectionBall等のロボット制御では
これまでAMS製磁気エンコーダAS5048AやAS5047Dなどが
性能に優れるため、好んで使用してきました。


ただ、値段が安く更に高性能化できないかと
色々なメーカの磁気エンコーダを探していました。


ちょっとシリアル通信に癖があるものの、
現行のAMS製AS5048AやAS5047Dなどに比べて
少し性能が高く、安いエンコーダを見つけたため、
試食してみました。



性能比較
◆AMS製AS5048A、AS5047D
-分解能:14bit (16384bit/rev)
-サンプリング周期:100us
-通信:SPI
-最大エラー角:0.7~1.4°
-価格:約900円/1個

◆Infineon製TLE5012B
-分解能:15bit (32768bit/rev)
-サンプリング周期:42.7us
-通信:SSC
-最大エラー角:1.0°
-価格:約600円/1個



単純な比較では性能はほとんど同じですが、
注目すべきはTLE5012Bのサンプリング周期が
42.7usということです。


アナログエンコーダやインクリメンタルエンコーダであれば、
制御周期の上限はないようなものですが、
シリアルエンコーダの場合はエンコーダのサンプリング周期で
制御周期が決まるといっても過言ではありません。

エンコーダのサンプリング周期以上に制御周期を速くしても、
同じ位置を返してしまうため、意味がありません。
TLE5012Bのサンプリング周期が42.7usと非常に高速なため、
他の性能が同様であれば、
サンプリング周期だけでも大幅に性能向上が期待できます。



ただ、TLE5012Bの問題点は少し癖のあるインタフェースということです。
SPIでなく、SSCというインタフェースを採用しています。

SCKやCSはSPIと同様ですが、
MISOとMOSIがそれぞれ1線でなく、1線で送信と受信を行います。
まるでSPIとI2Cを掛け合わせたような仕様です。


ただ、I2CのようなACK等はありません。
そのため、SPIのドライバを使用して通信します。
IOを入力と出力とその都度、切り替えては処理が遅くなるため、
下記のようにハードウェアで1線化しました。

TLE5012B_.png

そのままSPIのMISOとMOSIを接続すると、
PushPullのため、マイコン側の出力が短絡してしまいます。
そのため、抵抗を挟んで対処しました。


また、MISO側の抵抗を1k、MOSI側を10kに設定することで
マイコン側の出力とエンコーダ側の出力で
エンコーダ側を優先できるようにしてあります。
※マイコンの出せる電流値とエンコーダの電流値のバランスで決まるため、
マイコンに応じてオシロでHighとLowの電圧値を確認すること。
STM32F303では上記でHigh2.8V前後のいい感じになりました。


今回の試食ではTLE5012Bを2つ接続して、
CSで2つを切り替えて取得してみました。
CS以外のSCK、MOSI,MISOは共通配線です。

また磁石はAS5048A、AS5047D同様、こちらの磁石が使用可能です。

SPIの設定は下記の通り。
ポイントは16bitデータ転送、SPI_PHASE_2EDGEです。




static void MX_SPI1_Init(void)
{

  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES;
  hspi1.Init.DataSize = SPI_DATASIZE_16BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
  hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_8;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi1.Init.CRCPolynomial = 7;
  hspi1.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
  hspi1.Init.NSSPMode = SPI_NSS_PULSE_ENABLE;
  if (HAL_SPI_Init(&hspi1) != HAL_OK)
  {
    Error_Handler();
  }

}



while(1){

   /* Encoder A*/
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4,0);//CS A LOW
     
   sData[0]=0x8021;//SSC Command to read the angle value
      HAL_SPI_TransmitReceive(&hspi1,sData,rData,1,100);
     
   sData[0]=0x0000;//Empty Data     
     HAL_SPI_TransmitReceive(&hspi1,sData,rData,1,100);
      res=rData[0]&0x7FFF;//15bit

      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4,1);//CS A HIGH
      asm("NOP");
   
   /* Encoder B*/
      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_3,0);//CS B LOW
     
   sData[0]=0x8021;//SSC Command to read the angle value
      HAL_SPI_TransmitReceive(&hspi1,sData,rData,1,100);
     
   sData[0]=0x0000;//Empty Data
      HAL_SPI_TransmitReceive(&hspi1,sData,rData,1,100);
      res1=rData[0]&0x7FFF;//15bit

      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_3,1);//CS B HIGH
   


   printf("POS: %d %d\n",res,res1);
      HAL_Delay(300);
}



下記のように2つのTLE5012Bでそれぞれのエンコーダ値を取得することができました。


TLE5012B-uart.png


ちょっと癖のあるSSC通信ですが、
SPI通信ベースに実装できました。


TLE5012BはAS5048Aなどのように有名ではないようで、
Web上で調べてもほとんど情報がありませんでした。
メーカのHPではSPI互換といっているが、
どのような実装を想定しているのか少し疑問です。




今回は高速周期でのテストはしていませんが、
ロボットに組込んでどれくらい性能に差があるか
今後、実験してみたいと思います。


posted by Crescent at 00:00| Comment(0) | TrackBack(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする