Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix and improve e220 driver #1

Merged
merged 1 commit into from
Jan 25, 2023
Merged

fix and improve e220 driver #1

merged 1 commit into from
Jan 25, 2023

Conversation

sago35
Copy link
Collaborator

@sago35 sago35 commented Jan 24, 2023

ざっと変更提案を作ってみた。
正しいかは不明。
merge しなくてもよいので、適当に処理してください。
※PR 作ったほうがわかりやすいかな、という事で PR にしています

変更箇所は以下。

  • SetMode() はマニュアルでは 1ms で大丈夫とあるが、手元の環境では 2ms でも失敗している
    • 10ms は実測して問題なかった大きめの値
  • ReadRegister() は 0xC1 が正しい
  • ReadRegister() 内のループは明らかに良くないので修正したが、無限ループ入るのでこれはこれで良くない
    • 要検討
    • 手前の 100ms wait は要らない
  • 2 byte 値に対する処理が誤っていたので全体的に修正
  • uart は examples としては machine.DefaultUART を使うのがよさそう
  • examples/e220/tx の例は、アドレスは 0xFFFF に対して送ったほうがテスト簡単そう

あと、残り気づいたところは以下。

  • examples/e220/conf の例は、 ReadConfig() 使って config 読み出しにすると良さそう
  • M0 / M1 をつなぐつもりなら、 examples/e220/tx などでも config 読み出しをしておくのがよさそう
  • io.Reader と io.Writer になるように作るとよりよい

@akif999 akif999 merged commit d3e5655 into akif999:e220 Jan 25, 2023
@akif999
Copy link
Owner

akif999 commented Jan 25, 2023

変更いただいた箇所は一旦取り込むことでよいと考えたため、 merge します。
残る TODO は積んでおきます。

@akif999
Copy link
Owner

akif999 commented Jan 25, 2023

以下はコメントで TODO として積んだ。

ReadRegister() 内のループは明らかに良くないので修正したが、無限ループ入るのでこれはこれで良くない
要検討
手前の 100ms wait は要らない

examples/e220/conf の例は、 ReadConfig() 使って config 読み出しにすると良さそう
M0 / M1 をつなぐつもりなら、 examples/e220/tx などでも config 読み出しをしておくのがよさそう
io.Reader と io.Writer になるように作るとよりよい

@sago35 sago35 deleted the e220-work1 branch January 25, 2023 02:40
akif999 pushed a commit that referenced this pull request Jul 7, 2023
This is implemented in inline assembly using machine.CPUFrequency() to
know how long a single CPU cycle takes. As long as it is called with a
constant duration, it should be fully inlined and all values can be
const-propagated resulting in very tight inline assembly.

For example, when I convert i2csoft to use this delay function, the
entire delay function compiles to something like this:

    8784:   movs    r6, tinygo-org#100
    8786:   mov     r0, r6
    8788:   nop
    878a:   nop
    878c:   nop
    878e:   nop
    8790:   nop
    8792:   subs    r0, #1
    8794:   bne     0x8788

That means that all the math to calculate the number of cycles is
entirely optimized away (in this case, to 100 loops).

I ran the example on a few boards to see how well it works:

| board                 | 100ms wait | CPU core
|-----------------------|------------|------
| microbit              | 121.6ms    | Cortex-M0 so it has 12% overhead
| circuitplay-express   | 100.1ms    | Cortex-M0+ so it is cycle accurate
| pico                  | 100.2ms    | Cortex-M0+
| pyportal              | 100.3ms    | Cortex-M4
| circuitplay-bluefruit | 125.8ms    | Cortex-M4
| esp8266               | 125.1ms    |

This shows that there is some loop overhead because of conservative
estimates, but note that even though there may be a 25% overhead, the
actual overhead per `delay.Sleep()` call is very small. It should be
good enough for software I2C at least, and can potentially be improved
in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants