MicroPython

LCD(ST7735R)のMicroPythonドライバを更新

コメントする

一年ほど前に作成（正確には修正ですが）した、160×120ピクセルのLCDのESP32（MicroPython）用ドライバにIssueが上がってきました。

pixel offsets · Issue #1 · boochow/MicroPython-ST7735

ピクセルがずれているというもので、そのこと自体は当時も気が付いてはおり、そのうち直そうと思いながらそのままになっていました。
当時のビデオでも、ずれていることが分かります。

実はArduino用ライブラリでは、既に同様のバグ修正を行っていました。

Arduino（９）　Adafruit_ST7735ライブラリの修正（aitendoの1.8型LCD用） – 楽しくやろう。

なので、この修正自体をMicroPythonで再現すれば良い事になります。
ライブラリの作りは異なるものの、LCDのコマンド体系は変わりませんから、修正はそれほど難しくはありません。

このLCDは、座標で矩形領域を指定した後、連続してピクセル書き込み命令を送ることで矩形領域を塗りつぶします。
基本的には、その矩形領域の指定部分にオフセット値を加える処理を追加すれば、描画全体をずらすことができます。
コードにこの処理を追加し、さらにオフセット値を指定した初期化メソッド（initb2）を追加して修正完了です。

added _offset and initb2() to TFT class for some blue-tab LCD modules · boochow/MicroPython-ST7735@75c155d

ベアメタル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での実装は後ほど修正する予定です。