楽しくやろう。

ベアメタルRPi版MicroPythonのI2C.writetoを修正

08/16/2018 by boochow コメントする

ちょっと間が空きましたが、ベアメタルRaspberry Pi版MicroPythonのメモです。

先日、フォーラムのこちらのやり取りで、I2C.writeto()のrepeated STARTの仕様を私が間違えていたことが判明しましたので、その修正を行いました。

I2Cのrepeated START自体は、以前実装した際にケアしていました。
当時の記事は以下です。

I2Cクラスを追加（RPiベアメタルMicroPython） – 楽しくやろう。

記事中では、writeのあとreadする場合のrepeated STARTについての記載は正しいのですが、writeのあとさらにwriteする場合については間違っています。
具体的には

しかし、中レイヤのAPIでstopパラメータを使えばとすることで同等の処理が行えるはずです。

の部分です。

この「同等の処理」とは1行目の0x40のあとに2行目のbufが連続して送られることを指しているのですが、I2Cの仕様としては、このコードは

・START→スレーブアドレス→0x40→pseudo STOP
・repeated START→スレーブアドレス→bufのデータ

という信号を生成するべきなので、0x40とbufを連続して送ることはできません。

というわけで実装をちょこっと修正しました。

連続してデータをwriteする仕組みについては、現在議論されているPR4020の仕様（I2C.writeto(addr, [cmd, data])という記法を許容。cmdとdataは連続して送信される）を実装する際に役立ちそう（かつ、I2C.writeto_mem()の実装で使用している）なので温存し、新たにi2c_write_start()という関数をi2cドライバに追加しました。

i2c_write_start()は、データ長0xffffのwriteを行う（ただしFIFOには何も書かないまま）関数です。STARTビットを送り、続いてスレーブアドレスを送り、その時点でFIFOが空なら送信データ待ち（STOPは送らない）になります。
また、呼ばれたときに直前のwriteが終了していない場合にはFIFOをリセットすることによってpseudo STOPを送信させます。
ソフトウェア実装I2CにおいてSTARTビットを送信する低レイヤAPIであるstart()に似ていなくもないのですが、Raspberry PiのI2CインタフェースはレジスタにWriteかReadかを設定しないと通信を開始できないので、start()の代用にはなりません。

MicroPythonからは、I2C.writeto()を呼ぶと、
i2c_write_start(addr, stop)　→　i2c_write(addr, buf, len, stop)
の順に実行されます。

直前のI2C.writeto(buf, len, stop)において、stop=FALSEだった場合には、続くI2C.writeto()を実行する際にpseudo STOP + repeated STARTが送信されます。

たとえば

i2c.writeto(60,bytearray([0,1]),False);i2c.writeto(60,bytearray([4]))

を実行すると、以下のような信号が生成されます。

このrepeated STARTの部分を拡大すると以下のようになり、STOPへ移行していないことが分かります。

これで修正はできたのですが、残念ながらSSD1306のドライバが使えなくなってしまいました。
ハードウェアI2CでSSD1306を使うには、0x40の後に送信データをコピーするというメモリ利用効率の悪い方法を使うか、前述のPR4020の新しいAPIを使う必要があります。
PR4020の仕様が固まったらなるべく早期に実装したいと思います。

ところで、嬉しいことに先日Adafruitさんから、このベアメタル版MicroPythonについてtweetされました。

MicroPython on bare metal Raspberry Pi Zero / Zero W @boochowp #piday @Raspberry_Pi https://t.co/AHNDmHYc9a

— adafruit industries (@adafruit) 2018年8月10日

今のところ、ブログのアクセスが増えたりということは無いですが、ちょっとは知名度が上がったかも？

PlatformIO＋M5Stackを使ってみた

08/12/2018 by boochow コメントする

先日購入したM5Stack FIREですが、最近気になっていたクロスプラットフォームのIDE「PlatfomIO」をこのM5Stackで試してみることにしました。

PlatformIOはMicrosoftのエディタVisual Studio Codeのアドオンとして利用できる、クロスプラットフォームの開発環境です。
ここで、クロスプラットフォームというのはWindows/Mac/Linuxというだけでなく、Arduinoを初めとした様々な開発環境に対してもクロスプラットフォームになっています。
PlatformIOだけで、Arduinoの開発もmbedの開発も（PlatformIOでサポートされているボードならば）行えます。

とりあえずインストールしてみました。
参考にしたのは以下のページです。

PlatformIO IDE for VSCode でESP32のプログラム開発

Arduinoと違ってサンプルがインストールされないようなので、インターネットからPlatformIO対応のプロジェクトを探して、まずはビルドさせてみました。

試してみたのは以下のソフトです。
ネットラジオやゲームやオシロ、Webサーバ、天気予報、WiFiモニタなどM5Stackでできることを一まとめにしたアプリケーションです。

botofancalin/M5Stack-MultiApp-Advanced: A M5Stack firmware made on PlatformIO

ZIPファイルとしてダウンロードし、解凍してフォルダをPlatformIOから開けば準備OKです。
ビルドはウインドウ左下のチェックマーク、M5Stackへの転送はその隣の矢印マークをクリックします。

無事、動作が確認できたので、今度は自分でもプロジェクトを作ってみました。

新規のプロジェクトで、開発ボードを選択するのですが、現時点で507種ものボードがサポートされています。
そして、M5Stack FIREもその中に含まれています。（Huge update for ESP32 dev/platform: Debug, PSRAM, Embedding Binary Data – Announcements – PlatformIO Community）

プロジェクト作成時にボードとしてM5Stack FIREを指定すれば、ツールチェインは適切に自動選択されます。
さらに、M5Stack用のArduinoライブラリがPlatformIOにも用意されているので、それをインストールします。

M5Stack by Zibin, M5Stack · Libraries · PlatformIO

インストールは、PlatformIOのLibrariesアイコンをクリックし、検索窓にM5Stackと入れればライブラリが見つかるので、クリックします。

すると、ライブラリの詳細とインストールボタンが出てきますので、インストールすれば完了です。

このライブラリを自分のプロジェクトで使用するには、platform.iniファイル（プロジェクト作成時に自動で生成されます）に以下の記述を追加します。

lib_deps =
     # Using library Id
     1851

     # Using library Name
     M5Stack

     # Depend on specific version
     M5Stack@0.2.2

     # Semantic Versioning Rules
     M5Stack@^0.2.2
     M5Stack@~0.2.2
     M5Stack@>=0.2.2

今回は、以前Arduino用に作成したブロック崩しを移植してみました。
LCDが縦横逆ですが、解像度自体は変わりませんので、LCD、サウンド、ボタン周りの修正で済みました。
(2018/8/14追記：画面が縦横逆なのは修正しました)

コードは以下にアップロードしてあります。

boochow/breakout-m5stack

PlatformIO、なかなか良いです。何といってもエディタがVS Codeなのが良いですね。
デバッグ機能は有償らしいですが、そのうちどんなものか調べてみようと思います。

Nucleo-F767ZI + SSD1306（I2C）の接続

08/11/2018 by boochow コメントする

以下のやり取りで、MicroPythonのI2C APIについて一部誤解していたことが分かりました・・・

Pyboard + SSD1306 – Page 3 – MicroPython Forum

以下を実行すると、スレーブアドレスaddrのデバイスに対してbuf1とbuf2を連結したデータが送られると思っていたのですが

i2c.writeto(addr, buf1, False)
i2c.writeto(addr, buf2)

そうではなく、I2Cバス上では「start bit + addr + buf1 + restart bit + addr + buf2 + stop bit」が送られるのでした。
データとしてはbuf1とbuf2はaddrで分断されてしまい、連結することはできません。

分断せずにデータをつなげて送るには、低レイヤAPIのi2c.write(buf)を使えば実現可能ですが、低レイヤAPIはI2Cのソフトウェア実装でしかサポートされていません。
このため、writeto()において送信データのリストを受け取れるようにする仕様拡張が以下で検討されています。

docs/library/machine.I2C.rst: Extend writeto to support a list of bufs. by dpgeorge · Pull Request #4020 · micropython/micropython

この仕様が実現されると、writeto(addr, [buf1, buf2])という記法が可能になるようです。

以下、STM32（Nucleo-F767ZI）のMicroPythonでSoftware I2CとHardware I2Cの確認をしたのでメモです。
OLEDをI2Cで接続しました。

この接続で、Hardware I2Cを使用する場合のコードは以下のようになります。

import machine
i2c=machine.I2C(1)

同じ接続でSoftware I2Cを使うこともできます。
この場合はピンをGPIOとして使用し、以下のようなコードになります。

import machine
pscl = machine.Pin('B8', machine.Pin.OPEN_DRAIN)
psda = machine.Pin('B9', machine.Pin.OPEN_DRAIN)
i2c = machine.I2C(scl=pscl, sda=psda)

両者はいずれも同じAPIを持ちますが、

>>> dir(i2c)
['__class__', 'init', 'readfrom', 'readfrom_into', 'readfrom_mem', 'readfrom_mem_into', 'readinto', 'scan', 'start', 'stop', 'write', 'writeto', 'writeto_mem']

Hardware I2Cの場合は実装されていないメソッドを呼ぶとエラーが返ります。

>>> i2c.write([])
Traceback (most recent call last):
  File "", line 1, in 
OSError: I2C operation not supported

ベアメタルRaspberry Piでの実装は後ほど修正する予定です。