sakura.ioとは何なのか

はじめに

巷でIoTブームが起きている中、さくらインターネット株式会社がsakura.ioたるサービスの正式リリースを開始しました。

今回はIoTとsakura.ioについて解説したいと思います。

IoTとは

近年IoTという単語がバズっていますが、IoTとはそもそもどういうものなのでしょうか。

IoTはInternet of Thingsの略であり、日本では「モノのインターネット」と言われています。
これは、あらゆるモノがインターネットに繋がりデータを交換することで、互いに状態の可視化・制御をし合うことを意味します。

IoTのよくある例としては以下のようなものがあります。

  • ドアの開閉や会議室の使用状況
  • GPSトラッカー
  • 気温・気圧の共有
  • 故障事前検知

これらのことは全て2010年までにはすでに実現可能だったことですし、この程度のことでIoTと言われても全くイノベーティブとは思えませんよね。
それもそのはずで、IoTという考え自体は1999年から既に存在したものなのです。ではなぜバズってるのでしょうか?
その大きな理由は低価格化です。

2010年はじめではLTEモデムは最大手のQualcomm社が独占している市場であり、150ドルするのが当たり前の時代でした。
そのような中、Altair等の企業がIoT向けの低価格LTEモデムを開発し、価格が下がったことにより、現在のIoTブームに至ります。

IoTの障壁

価格的問題

さて、低価格化したモデムですが、モデムを搭載したArduinoシールドは以下のものがあります。

はい、どちらも3万円します。
モデム自体が低価格化されたとは言え、我々がホビーユースで使えるように市販されているモデム(のArduinoシールド)は非常に高価です。

また携帯回線を使用するため、モデムとは別に回線契約をする必要があります。IoT向けの回線としては、SORACOMが提供しているSORACOM Airが維持費が月額300円程度と安く、実用的です。

技術的問題

さて、高いお金を払ってモデムを手に入れたとして、どのようにプログラミングすれば良いのでしょうか。

上の図は、一般的なモデムを用いてIoT製品を開発する際のイメージです。

マイコンとモデムの通信にはUARTを用い、PPPプロトコルによる通信を行います。また、モデムの設定を行うにはATコマンドの知識が必要です。
PPP・TCP/IP・UDP・DNS等のプロトコルの実装は、LwIPと呼ばれるフリーのTCP/IPプロトコルスタックを用いることで比較的簡単に行うことができます。
また、LwIPを動かすに当たってRTOSを使用する必要があります。

  • LwIPを用いてTCP/IPによる通信ができるようになると、HTTPによる通信もできるようになります。しかし、HTTPのままでは平文で通信を行うことになるためセキュリティに問題が生じます。SSLによる暗号化通信を行うためにはPolarSSLと呼ばれるオープンソースのSSLライブラリを用いるのが一般的です。

以上をまとめると、モデムを購入してIoTを実現するには以下の技術・知識が必要となります。

  • 割り込みやDMAを用いたUARTの送受信バッファの作成
  • 使用するマイコンへのRTOSのポーティング
  • ATコマンド
  • LwIP
  • PolarSSL(セキュアな通信をする場合)

LwIPを一度でも触ったことがある方ならわかると思いますが、超メンドクサイです。
少なくとも、Lチカと同じレベルで実現できるようなものではありません。
(面倒とかそういう話とは別で、組み込み屋を名乗るなら上記のことはできるようにはなりたいですね笑)

これらの知識がなくてもIoTをできるように、以下のような通信部分を隠蔽したモジュールが出てきています。

3GIMは、TCP/IPによる通信やHTTP/GET・HTTP/POST(SSL対応)に特化したモジュールであり、UARTを使って簡単に接続することができます。
問題点として考えられるのは、3Gモデムなので消費電力が4Gと比べ大きいことと、価格が25,000円前後と高価なことでしょうか。
LwIP等の知識なしにTCP/IPの接続をできるという点で、技術料としては安いと考えられます。

さくらの通信モジュールに関しては後述します。

セキュリティ的問題

前節でPolarSSLを用いればSSLによるセキュアな通信が出来ると言いましたが、LwIPやPolarSSLに脆弱性が存在する可能性があります。(実際、PolarSSLに任意のコードを実行できる脆弱性が発見されたことがあります)

このような場合に製品回収をしなくていいように、IoTの製品を販売する場合にはファームウェアアップデートの機能を持たせる必要があります。

さくらの通信モジュール

さくらの通信モジュールはTCP/IPやその先の通信プロトコルまで全てを隠蔽し、チャンネル番号・変数の型・値・タイムスタンプの値を1セットとして送受信する機能を有したモジュールです。
マイコンとモジュールの接続はI2CまたはSPIで行われます。
先に紹介したモデム・モジュールと異なる点は、さくらの通信モジュールの接続先はインターネットではなく、専用のSIMを用いて接続される、専用回線である点です。
これにより、外部からのアクセスを遮断した閉域網でマイコン・サーバ間の通信は行われるため、ハッキングされる心配が非常に少なくなります。
また、sakura.ioサーバとコネクションを張り続けているため、データの受信もほぼリアルタイムに行うことができます。

sakura.ioでは、自身のWebサーバとデータをやり取りする方法としてIncoming WebhookとOutgoing Webhookが用意されています。
それ以外にもIBM BluemixやAWS IoT、myThings等のサービスと提携しており、サーバサイドのプログラミング知識がなくてもある程度のものは開発というメリットがあります。

価格面でも、モジュールの価格は8,000円程度と破格の安さとなっています。

モジュールの問題点を上げるとすれば、TCP/IPやHTTP等で汎用的な通信は行えないことが挙げられます。そのため、さくらの通信モジュールの仕様で自分が作りたいアプリケーションを実現できるかどうかは、あらかじめ検討する必要があります。とはいえ、個人でちょっとしたIoTなアプリケーションを作ろうという場合はこのモジュール1つで殆ど解決します。

各モジュールとの比較

モデム・3GIM・さくらの通信モジュールを比較すると以下のようになります。

モジュール 初期費用 回線(月) 入手性 汎用性 プログラミング FWアップデート
3G, 4Gモデム 20,000〜30,000 300円 〜 × ×
3GIM v2 25,000
程度
300円 〜 ×
さくら 8,000
程度
60円 〜  ◯

さくらの通信モジュール

データ形式と通信

sakura.ioでやり取りするデータ形式は以下のようになっています。

名称 サイズ 内容
module ID 各モジュールの固有ID
channel ID 7 bit 何のデータであるかを識別するためのID
type 1 byte データの型
value 1〜8 byte データの値。サイズはtypeに依存する
timestamp 8 byte データに紐ついた時刻

また、データの型は以下のものがサポートされています。

int32_t 4 バイト符号付き整数
uint32_t 4 バイト符号なし整数
int64_t 8 バイト符号付き整数
uint64_t 8 バイト符号なし整数
float 4 バイト(単精度)浮動小数点数
double 8バイト(倍精度)浮動小数点数
uint8_t [8] 8バイトのBYTE型

データの送受信

送信

enqueue命令により、データは最大32個までモジュールの送信キューに保存できます。
また、送信命令により、このデータを最大16チャンネルまで一度に送信できます。

17個キューにデータが保存されている状態で送信指令を行なった場合、「初めにキューイングされた16個のデータを初めに送信し、その後、最後に入力した1個のデータが送信される」という動作になります。

受信

クラウドからモジュールへのデータの受信は自動的に行われ、受信用のキューに蓄積されます。
キューは最大32個まで受信データを蓄えることができ、その数を超えるデータが送られてきた場合、そのデータは取りこぼされます。

 

実際どれくらい簡単なのか

Arduinoで温度情報をサーバに送信する例を見て見ましょう。
簡単のため、温度センサの初期化処理・エラー処理などは省いています。

void loop() {
  float temp = hdc1000.getTemperature();
  sakuraio.enqueueTx(0,temp);
  sakuraio.send();
  delay(5000);
}

はい終わり。簡単でしょ?

まとめ

IoT、しよ?

ちなみに私は現在サイコンのIoT化に挑戦中です…

カテゴリー: 組み込み関連 | コメントする

GitLabのomniauthでhttpsにリダイレクトさせる時の設定

  • /opt/gitlab/embedded/service/gitlab-rails/config/initializers/omniauth.rb

    OmniAuth.config.full_host = Settings.gitlab['base_url'].gsub!(/http/, 'https')
カテゴリー: 未分類 | コメントする

オンボードのEthernetコントローラ(I219-V)がUbuntuで動かない時の対処

Ubuntu16.04でオンボードのEthernetコントローラ(I219-V)が動かなかったので対処法を書いておきます。

まず、問題が起きた環境を以下コマンドで確認。

$ lspci | grep Ethernet
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V (rev 31)

$ modinfo e1000e
filename:       /lib/modules/4.4.0-21-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        3.2.6-k
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     E086BB18F51C50383C26904

次に、動かない原因を下記コマンドで調べます。

$ zegrep e1000e /var/log/kern.log*
Jul 29 05:47:31 *********** kernel: [    1.089863] e1000e 0000:00:1f.6: The NVM Checksum Is Not Valid
Jul 29 05:47:31 *********** kernel: [    1.125508] e1000e: probe of 0000:00:1f.6 failed with error -5

チェックサムがあってないとか言われてますね。リビジョン上がってまだ対応していないとかでしょうか?

Intelのドライバ配布ページからドライバをダウンロード、解凍します。

nvm.cをテキストエディタで開き、e1000e_validate_nvm_checksum_generic関数を以下のように変更します。

s32 e1000e_validate_nvm_checksum_generic(struct e1000_hw *hw)
{
        return 0;
}

これでチェックサムの確認を一切行わないようになります。
(ちゃんと確認してほしい場合は正しい値を入力しましょう)

あとはビルド・インストールするだけです。

#さっきのソースのあるディレクトリに移動
$ cd e1000e/src
$ make
$ sudo make install


#現ドライバの削除
$ sudo rmmod e1000e
#新しいドライバの適用
$ sudo modprobe e1000e

#適用されたか確認
$ modinfo e1000e
filename:       /lib/modules/4.4.0-21-generic/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        3.3.4-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     759D7311A5194827E769673

#一応ネットワーク再起動
$ sudo /etc/init.d/networking restart

#今のモジュールを次回起動時に使用するように
$ sudo update-initramfs -u

カテゴリー: サーバー関連 | 4件のコメント

今更ロボミントンを振り返る その4

今回は軌道予測と打点の決定方法についてです


シャトルの軌道予測

まず、以下の文献を参考に、軌道予測の方法を考えました。

これらの文献では以下の共通点がありました。

  • ステレオカメラでシャトルの位置を検出
  • シャトルは空気抵抗を考慮した斜方投射運動としている。
  • 拡張カルマンフィルタで軌道を予測している

ステレオカメラかKinectか

ステレオカメラによる座標の計算については以下の文献に詳しく記載されており、実装比較的容易にできそうです。

しかし、

  • シャトルという高速に移動する小さな物体を正確に捕捉するには、同期信号の出ているCマウントカメラ等、高額な機材が必要
  • 奥行を正確に検出するにはカメラの間隔・輻輳角を十分に稼ぐ必要があると思われ、ロボットの本体に搭載するのは難しい
  • 会場の壁の色・照明環境・某大学の応援による振動に対応できる保証がない

等、いくつかの問題が存在したため、ステレオカメラは使用せずKinectV2で検出を行うことにしました。

シャトルの運動

シャトルの空気抵抗の係数などは以下のサイトのデータを参考にしました。

拡張カルマンフィルタ(EKF)

カルマンフィルタは離散的な誤差のある観測から、時々刻々と時間変化する量を推定するために用いられます。
例えば、カーナビではGPSによる位置情報、電子コンパスによる方位情報、及び加速度センサ・ジャイロセンサによる加速度と角速度の情報をカルマンフィルタによって統合し、車の位置・速度を取得しています。

拡張カルマンフィルタは、非線形モデルを現在の推定値の回りで線形化微分することで、カルマンフィルタを適用する手法です。

原理などは確率ロボティクスや以下のサイトを読んでください。

実装

EKFの実装に行列を用いるため、C++でEigenか、PythonでNumPyを用いる必要があります。
EKFの計算コストが少ないという利点を活かし、プログラミングが楽なPythonを選択しました。

また、実装に当たって以下のサイトのコードををパク参考にしました。

公開しているプロジェクトの、shuttle_kalmanフォルダのshuttle_kalman_node.pyshuttle.pyを用いて軌道予測を行っています。

軌道予測(EKF)に関するプログラムはshuttle.pyでクラス化、shuttle_kalman_node.pyでROSで他のノードとの橋渡しをしています。

動作結果

打点の決定方法

予測したシャトルの軌道から目標の打点を計算します。

座標変換

座標変換

元のXYZの座標系から、ラケット旋回機構の回転軸に平行な平面をX’Y’軸とする座標系に座標変換します。
同次座標でアフィン変換すればいいだけなので、

  • 旋回機構は地面に対し50度傾いている
  • 旋回中心のロボット中心からの奥行をAz
  • 旋回中心の地面からの高さをAz
  • ロボットのyaw方向の回転をθ
  • ロボットの位置をRx, Ry

とすれば以下の式で座標変換できます(テキトーに書いたので間違ってるかもしれません)

20160328_225709

打点

予測された軌道を座標変換し、z’=0平面との交点を求めます。
この交点が目標の打点となります。

打点から目標姿勢の算出

打点の座標を[ x’ y’ 0 ]、ラケットの長さがrの時、

-旋回機構の目標角度φはAsin(y’/r)
-横移動ユニットの目標位置はx’-sinφ

となります。

abs(y)が1より大きい場合や、横移動ユニットの稼働限界を超える場合は、足回りを移動させる必要があります。

動作結果

rviz


次回は通信回りや大会当日の話、負けた原因等を書こうかと

カテゴリー: ロボット | コメントする

今更ロボミントンを振り返る その3

今回はKinectやシャトル検出について書こうと思います。


シャトルの検出

とりあえずKinectV2をUbuntuで動かす

ROSを使用するためUbuntuでロボットの開発を行っていたのですが、MicrosoftはKinectV2のドライバをWindows用のしか公開していません。
そこで、非公式のライブラリlibfreenect2を使用することにしました。

ロボミントンの開発を行っていた頃は、libfreenect2も公開されたばかりで全然ドキュメントがなかったのでかなり手こずりました。
Intel GPUのOpenGLの問題に嵌り、OpenCLを使用するためにBeignetをインストールするのに嵌り、散々でした。

GitHubのissueで他の開発者達と相談したり、プルリクエスト出したり、まともに使用できるようにするのに1ヶ月以上かかりました。

KinectV2によるシャトル検出

テストプログラムの作成

Kinect V2を用いてシャトル検出を行うにあたって、以下の2つが問題となります。

  • カメラ上ではほぼ点にしか見えないシャトルを本当に検出することができるのか
  • 何メートル先まで検出できるのか

この2つを確認するために、背景差分を用いた動体検出によって、シャトルの検出を行いました。
ただし、背景差分を使用する場合、カメラ自体を移動させることはできません。
つまり、この方法では移動ロボットに搭載されているカメラでシャトルを検出することはできません。

使用したライブラリはOpenCVで、以下の手順でシャトルの座標を取得しました。

  1. 距離画像に対して背景差分
  2. 動体検出
  3. 二値化・ラベリング
  4. ラベルが1つの場合、それに関して、距離画像から座標を取得

この実験の結果、最低でも3~4m程度の奥行までは検出可能なことが分かりました。

PCLを用いたシャトルの検出

本番でシャトルを検出する際は、ロボットが移動している最中でも検出できる必要があるため、先述のものと別の方法でシャトル検出を行うプログラムを作成しました。

テストプログラムではKinectから出力される距離画像を画像として処理していましたが、本番で用いたシャトル検出のプログラムではPoint Cloud Library(PCL)というライブラリを使用し、3Dの点群として処理しました。

以下の手順でシャトルを検出しています。

  1. Kinectの距離画像から点群に変換
  2. フィールド内、高さ1.6m以上の領域の点のみを抽出
  3. クラスタリング(ラベリングみたいな感じ)
  4. クラスタが存在したらそれをシャトルとして、重心を求める。この時点では、重心はKinectから見た相対座標で表されている。
  5. ロボットの位置・姿勢からシャトルの絶対位置を求める

これは、ロボミントンにおける高さ制限を利用し、「ネットより上に位置する物体はシャトルしか存在しない」という仮定のもと、作成されています。
天井は十分無視できる高さに存在する必要があります。(一般的な教室では練習できないという問題が発生しました)

このプログラムでは最大6m先のシャトルも検出可能になりました。

GitHubで公開しているプロジェクトのshuttle_finderがこのプログラムにあたります。


次回はシャトルの軌道予測について書こうと思います。

カテゴリー: ロボット | コメントする

今更ロボミントンを振り返る その2

前回に引き続きロボミントンの振り返りです。


センシング

ロボミントンで全自動を行うのに最低限必要なデータはたった2つです。

  1. ロボットの位置・姿勢
  2. シャトルの軌道

とまあ言うのは簡単ですが、これがなかなか難しいです。

ロボットの位置推定(Localization)

GitHubで公開しているプロジェクトのlaser2locationとdeadreckoningが位置推定に関するノードです。

Dead Reckoning

2011年のロイクラトン以降、学生ロボコンではエンコーダとジャイロセンサを用いたDead Reckoningが一般的になっています。

IMG_3483

Dead Reckoningで取得できるのはあくまで相対的自己位置であり、絶対的自己位置を得るにはロボットの初期状態(位置・姿勢)を正確に指定する必要があります。
そのため、セッティングタイムで治具を使用して位置合わせをする大学が多く存在します。

また、取得できる相対位置のデータには誤差が含まれており、Dead Reckoningのみではこの誤差は修正できず、積算されてします。
つまり、長時間動作していると徐々に推定位置がズレていく問題があります。
従来のタイムアタック制の試合ではこの誤差は無視(あるいはハード的位置合わせで修正)できるものでしたが、ロボミントンには時間制限がありません。
また、サーブ前の調整時間は15秒しかなく、再度位置合わせをするのは難しいです。

そこで、Dead Reckoningと同時に、フィールドの周りにある木枠を検出することで、ロボットの絶対位置を求めることにしました。

IMG_3282

使用したセンサは北陽電機の測域センサ(LRF)、UTM-30LXです。
木枠の高さは5cmしかないため、をロボットの足元、地面すれすれに設置しました。

LRFを用いた自己位置の計算

LRFを用いた自己位置推定で有名なのはSLAMですが、今回は使用しません。
木枠が長方形状に配置されている特徴を活かし、Hough変換を用いて木枠の直線検出を行うことで、ロボットの絶対座標を計算することにしました。
ハフ変換は、画像から直線や円を検出する為によく用いられるアルゴリズムです。

ハフ変換で検出した直線を用いて、

  • フィールド左右の木枠に該当する直線との距離から、ロボットのX座標
  • フィールド前後の木枠に該当する直線との距離から、ロボットのY座標
  • 直線の傾きから、ロボットの傾き

をそれぞれ求めています。

データの統合

LRFで位置検出をする毎に、Dead Reckoningで推定した位置との加重平均を求めることで、データを統合しています。


次回はシャトルの認識について記述しようと思います。

カテゴリー: ロボット | コメントする

今更ロボミントンを振り返る その1

序文

今月3月、大学を卒業します。卒業を前に色々思い返すと、ロボコンの話をパブリックな場所にきちんと残していなかったことに気づきました。
なので、NHK学生ロボコンにおいて僕が最後に出場した大会「ロボミントン」(2015年)について、今更ですが振り返ることにします。

概要

NHK学生ロボコンは大学生・高専生(4,5回生)が出場するロボットコンテストです。
大会のルールは毎年変わるため、毎年一からロボットを作る必要があります。

今回話題にする2015年の競技、「ロボミントン」。
タイトル通りルールはバドミントンです。

この大会で私が所属していた京都工芸繊維大学ロボコン挑戦プロジェクトForteFibreは2台の(半)自動ロボットを作成し、事前のビデオ審査によってシード権を取得し大会に出場しました。
しかし、完成度不足・大会前日のトラブル等の結果、大会当日は新潟大学との初戦で敗退しました。

大会直前に撮影した動画です。

もう一台は直前までハードの修正が行われていたため動画が殆どありません…

2台のロボットのプログラムを(全て)担当しました。
以降はそのあたりを中心に記述していこうと思います。

ルール

はい。バドミントンのダブルスですね。

バドミントンとの違いは、サーブドロップゾーンという黄色いエリアが設定されていることくらいです。
サーブはそのエリアに落ちなければアウトとなります。
サーブだけで試合が終わるのを防ぎたかったのでしょう。(それなら、そもそもこんなルールにするなと思いますが…)

機体アイデア

機体のサイズ制限は直径1.2m高さ1.5mの円柱形です。

機械的要素として必要になるのは以下の3つだと考えました。

  • 全方向移動可能な足回り(オムニ?4輪ステア?)
  • 打点微調整用の機構(XYテーブル等?)
  • サーブ用のアーム

二次ビデオ審査までは、以下に記述する前衛機・後衛機の2台の開発が行われました。

後衛機

足回りは使用したことのある全方向移動の足回りはオムニホイールしかなかったので、とりあえずオムニに決定。

打点微調整用の機構については、先行研究のこのロボットを参考に、X方向のレールとラケットのロール方向(?)回転の機構を採用しました。

この機構の最大のメリットは人の手首と同じような動きができるため、色々な打ち方ができることです。
下打ち固定や上打ち固定ではワンパターンで、落下点が予測しやすいですが、この機構なら、打点さえ調整できれば相手はどこに飛ぶか分かりません。

また、X-Yテーブル・X-Zテーブル等の案があったのですが、

  • X-Y(水平方向のみ)の場合、水平に飛んでくるシャトル(ドライブショット等)に対する微調整が難しい
  • X-Z(横・縦方向)の場合、垂直に落ちてくるシャトル(ハイクリア等)に対する微調整が難しい

と考えられ、斜め方向に自由度がある打点微調整機構が優位に思えます。本当かどうかは知りません。
(実際の試合では、ほとんどの大学が山なりな軌道を描くショットしか打てなかったため、X-Yテーブルで十分だったのかもしれません)

そもそも足回りだけでフィールド全域動けるんだし打点微調整機構なんて必要ないのでは、という考え方もあります。
しかし、地面との摩擦の関係による加速・減速性の悪さ、移動方向の制限等、足回りは微調整には不向きな傾向にあります。
よって、微調整用の機構は当然必要となります。

前衛機

自動ロボットには、ネットすれすれのシャトルや敵陣地にあるネットより低いシャトルを認識できない欠点があります。
この問題を克服するために、横浜国立大学のロボットのような、ラケットを大量につけた壁ロボットをもう1台として開発することになりました。

足回りは4輪ステアリングを採用していました(が、十分な設計ができていませんでした)。

この前衛機ですが、2次ビデオが終わった後、4月いっぱいで開発は打ち切られました。
この辺りの話は次回以降に回します。

また、大会全試合を通して、ネットすれすれ球は1球あったかなかったか程度でした。後から考えるとこの案は良くなかったのかもしれません。

外部デバイスについて

発表当初のルールでは、フィールド外部にカメラなどを設置することが許されるか不明であったため、ロボット本体にKinectV2を取り付けて、ロボットの1人称視点でシャトルの軌道予測を行うようにしました。

外部デバイスを許可された後も、ソフト的に外付け可能にはしたものの、

  • 本番環境で位置合わせがきちんとできるか
  • KinectV2を外付けしても視認範囲は大して広くならない
  • そもそも返球率が向上しなかった(作りこみが甘い)
  • 通信が不安定

等の理由で実用には至りませんでした。

特に、一番初めに挙げた「本番環境で位置合わせ」は最も懸念していたことでです。
当プロジェクトで用意するフィールドは非常に雑で、精度が悪いです。
このような状態で外部デバイスを用いても、本番でうまく動くとは到底考えられませんでした。

余談ですが、フィールド作製には技術的にも人柄的にも信頼できるメンバーを採用するべきだと強く思います。
強豪校は(ハード的・センシング的・制御的に必要な必要な部分に関しては)きちんとしたフィールドを用意しています。


センシングとか制御とかに次回にまわして、今回はこの辺りまでにしておきます。
ビミョーな終わり方になってしまった…

カテゴリー: ロボット | コメントする

WordPressまわりのパーミッション

本当にいいのか…?

chown -R www-data:www-data .
chmod -R 604 .
find . -type d -print | xargs chmod 705
chmod 604 .htaccess
chmod 400 wp-config.php
カテゴリー: サーバー関連 | 1件のコメント

OpenOCDのビルド

git clone http://git.code.sf.net/p/openocd/code openocd-code
cd openocd-code
./bootstrap
./configure --enable-maintainer-mode --enable-stlink --disable-werror --prefix=/usr/local/openocd
make -j8
sudo make install
ln /usr/local/openocd/bin/openocd /usr/local/bin/openocd
カテゴリー: OS X, 組み込み関連 | コメントする

STM32F7 discovery( STM32F746G-DISCO )を使ってみる

注文殺到のSTM32F7Discoveryがついに届きました!

IMG_5130

IMG_5131IMG_5132

このDiscoveryは今までのものと違い、

  • MicroSDカードスロット(SDIO)
  • USB HS
  • Ethernet
  • 4.3インチ液晶 静電容量式タッチパネル
  • FMCに128MbitのSDRAM(※アクセス可能なのは64Mbit)
  • QSPIに128MbitのFlash
  • その他音響回り(興味なし)

と、本格的な使用を想定した構成となっています。
(F7の威力を見せ付けるための戦略でしょうね…)

STM32F429I-DISCOも衝撃的でしたが、それよりも数倍豪華ですね。
しかもお値段なんと50$

購入するなら、今はRSがよさそうです。

STM32F7DiscoveryのサンプルはSTM32CubeF7に含まれるサンプルをいくつか動かしてみました。

 

・QSPI_perf
IMG_5159
QSPIからSDRAMへ、DMA転送する際のパフォーマンス確認。
47.5MB/sってシュゴイ…

そういえば、STM32F4ではFMC上のNOR FLASHとSDRAMを同時に扱えないというファッキンなエラッタがありましたが、もう解消されているのでしょうか…

 

・LwIP_HTTP_Server_Netconn_RTOS
IMG_5153
DHCPでIPアドレスを自動で取得し、WEBサーバーとなります。
FreeRTOSで稼働しているタスク一覧をブラウザで確認できます。

・STemWin
IMG_5156
これは半分自前ですが、STemWinをFreeRTOSで動作。
タッチパネルでアイテムを選択できます。

あと、FatFsの動作確認もしました。

STM32F7用に、とりあえず開発環境を整えました。
上記サンプルをビルドできるサンプルを、GitHubに上げています。

各サンプルはブランチとして置いてあります。

現在はWinのみ対応です。
Macにも対応していく予定です…OpenOCDが面倒…

主に使用しているツールは

ST-LINK UtilityのV3.7ではQSPI Flashへのアクセス機能が追加されていますので要アップデートですよっ!

環境変数に以下の2つを追加します。

tc_path

 

あとはテキトーにmakeすればきっと多分動きます…

このmakefileは、ヘッダファイルの依存関係に対応しているので、ヘッダファイルを変更したときにmake clean→make allする必要がありません。
makefile内で設定しているフラグを変更した時は、もちろんリビルドする必要があります。

LwIP, FreeRTOS, STemWinは、makefileで使用するかを設定できます。

OS_SUPPORT = USE_FREERTOS
LWIP_SUPPORT = USE_LWIP
USE_EMWIN = 1

ここらへんをコメントアウトしたりで弄ってください。

カテゴリー: 組み込み関連 | コメントする