MicroPython

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

コメントする

ちょっと間が空きましたが、ベアメタル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されました。

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

Nucleo-F767ZI + SSD1306（I2C）の接続

コメントする

以下のやり取りで、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での実装は後ほど修正する予定です。

M5Stack + uPyCraftはいい感じに使えます（uPyCraftがv1.0に！）

コメントする


M5Stack + クラウド経由の編集は今ひとつな感じでしたので、以前も紹介したuPyCraftをM5Stackと一緒に使ってみました。
uPyCraftも、もともとESP32ベースのボードをターゲットにしていますので相性はバッチリでした。

また、uPyCraftも久しぶりに使ったら、だいぶデザインが変化してバージョンも1.0になっていました。
エディタが使いやすいのでお勧めです。

なお、冒頭の画像の例題は、M5Stack FIREのpsRAMを試すべく、大きな画像（557x862xRGBのRAWデータ）を一気にファイルからロードし、それをLCDに描画してみたものです。（LCDのほうが狭いので一部しか表示されていませんが。）