がじぇるね岡宮です。
#2021/4/19 Wire, SPI, pinModeの修正をしました
ちょっと趣味も兼ねてRAを触り初めまして、EK-RA4W1用にArduinoスケッチができるプロジェクトを作ってみました。FSP上で実装していますが、ピンが競合するとコード生成できない部分もあり、まだ最小構成の実装です。ご興味あればお使いください。
本来はUSB一本でフラッシュ書き込みとシリアルモニタをできるようにしたいところですが、J-Linkの方はRTT Viewerなるもので入出力するで、ソフトの起動とか煩わしいので、もう一本のUSBでSerialが扱えるようになってます。なので、書き込みとシリアルモニタを行う場合はmicro USBが2本必要です。
スケッチは今のところe2studioでのみ行えます。以下はイメージです。
以下、簡単な手順です。
1. 以下のzipをダウンロードしてください。
ra4w1_sketch_20210419.zip
2. zipをアーカイブファイルとしてインポートしてください。
3. プロジェクトルートの "configuration.xml" を開きコード生成を行って下さい。
4. arduinoフォルダ内の"sketch.cpp"を開いてください。このファイル上でArduinoスケッチができます。デフォルトサンプルはLチカとHelloが出力されるものです。Tera Termなどを使ってシリアル出力が確認できます。
5. ビルド後、デバッガ接続してダウンロードし、RUNしてください。この辺は普通の操作なので詳細は省きます。
デフォルトサンプルでは以下のようにHelloが出力されます。Serialの受信にはDTCを使っているので、結構軽やかに動くとは思います。FSPが殊の外簡単だったのでやってみました。
今のところ以下を実装してます。
- digitalWrite
- digitalRead
- analogWrite (ピン3, 5だけ対応してます。その他はSPIと競合したり、諸々のFSPの仕様でその他のピンはやめました)
- analogRead (ピンA4, A5にはアナログ端子がデフォルトの回路でつながってないので実装してません)
- attachiInterrupt (ピン2だけ実装してます。ピンが競合すると出力できないので。ピン2はユーザスイッチとシェアされてます。割り込み番号0で両方のピンが活性化されます)
- Serialクラス (Serial はUSB、Serial1はピン0, 1です)
- SPI class
- Wire class
このArduinoライブラリと一緒にBLEスタックのサンプルが動くことは確認済みですが、BLEのサービスをどう実装しようか迷っており、実装していません。
[Updates]
-2021 April 19: IICを修正(タイムアウト)、SPIを修正(通信完了処理)、PORT(兼用端子の処理)
チョコです。
>2Mbps～3Mbpsがデフォルトのようです。
Mbpsですか、120MHzのRX65nならできそうですね。
32MHzのRL78で考えると、UARTの電気的特性には5.3M（MAX）とありますが、それは単にハードとしてのUARTの動作速度で、スタートビットの検出と動作マージンを考えると6倍程度のサンプリングでは不安があります。16倍程度で考えるとせいぜい2Mbpsが限度です…
岡宮さん、こんにちは。NoMaYです。あと、トラディショナルなやり方としては、以下のようなやり方ですね。(1) 多重割り込みを許可する(2) UART受信割り込みの割り込み優先度を上げるその上で、以下でしょうかね。(3) DTC＋ここまでの話のリングバッファ＋上記、の組み合わせでCPUサイクルの消費も抑えるなお、FreeRTOSに、Cortex-M、RX、PIC32、などではconfigMAX_SYSCALL_INTERRUPT_PRIORITY割り込み優先度という概念があって…
岡宮さん、こんにちは。NoMaYです。FTDIは専用のWindowsデバイスドライバですので、吸い上げ能力がWindows標準のCDCドライバより増強されている可能性もありますね、、、(ただ、そもそもESP8266からバーストで例えば256バイトとか送信されてくるものなら、受信リングバッファは256バイトは確保しておくのが安全/必要だと思います、、、WindowsはマルチタスクOSですので、タイムスライスが割り当てられていないタイミングでは書き込みツールはデータを吸い上げられないですので…
岡宮さん、こんにちは。NoMaYです。あと、トラディショナルなやり方としては、以下のようなやり方ですね。(1) 多重割り込みを許可する(2) UART受信割り込みの割り込み優先度を上げるその上で、以下でしょうかね。(3) DTC＋ここまでの話のリングバッファ＋上記、の組み合わせでCPUサイクルの消費も抑えるなお、FreeRTOSに、Cortex-M、RX、PIC32、などではconfigMAX_SYSCALL_INTERRUPT_PRIORITY割り込み優先度という概念があって、その割り込み処理内でFreeRTOS APIを呼ばないならば上記のトラディショナルなやり方がそのままやれるような機構が用意されています。手前ミソな話ですが、実は、私は今、FreeRTOSの公式ソースでは残念ながらRL78ではサポートされていない上記のconfigMAX_SYSCALL_INTERRUPT_PRIORITY割り込み優先度を多少なりとも扱えるようにFreeRTOSのRL78依存部を改造して、その改造結果を利用したサンプルプログラムを作成しているところなのでした。チョコさんのアドバイスのチェイン転送を活用してはどうかという可能性も追ってみますが、上に書いたやり方をまずサンプルプログラムにしてみようと思い始めたところです。(昨日、今日、のこのスレッドでイメージが沸いて来ました、、、)
NoMaYさん、こんにちは。GR-ROSEでは実は1024にしています。1024ぐらいにしないと、確かESP8266のフラッシュ書き込みができないことがありました。ただ、最新のESPの書き込みツールだとUSB側の処理が追い付いてない可能性があり、ちょっと課題のひとつなのですよね。。
#else /*__RX600__*/ #define SERIAL_BUFFER_SIZE 1024#endif/*__RX600__*/
追記：USBの可能性を疑ったのは、下段の構成に返るとフラッシュ書き込みがOKになるからです。
PC－(USBーSerial)ーESP ※NG
PCーFTDIー(SerialーSerial)ーESP ※OK
岡宮さん、こんにちは。NoMaYです。＞ GR-ROSEでは実は1024にしています。1024ぐらいにしないと、確かESP8266のフラッシュ書き込みができないことがありました。ESP8266への書き込みで受信リングバッファサイズを大きくしないといけないのは何か不思議ですね、、、書き込みツール側で書き込まれたデータが正しいか検証出来るように書き込まれたデータがリードバックされて来るとか？FTDIのFT232はUART側の受信データバッファサイズが384か512ではなかったでしたっけ、、、[追記]ちょっと不思議なところはありますが、デバッグの第一歩は、受信リングバッファオーバーフローか受信オーバーランか、はたまたどちらも起きていないのか、確認することでしょうか、、、
NoMaYさん、こんにちは
そうですね。GR-ROSEのRAMが大きいのでデバッグせずに増やしてしまったわけですが、やりたい優先度としては以下ですかね。結局GR-ROSE内部のバケツリレーが間に合っていないことが原因と思います(バッファを増やすとOKなため)。FTDI内のバケツリレーに負けているということなのですよね。。
①リングバッファのDMA/DTC化による割り込み占有率の低減
②USBの処理軽減(できるか自信ありません)
③シリアル送受信エラーのデバッグ
まぁでもESPのファーム書き換えだけのためにバケツリレーを早くするのは、全体としての優先はちょっと低く、どちらかというとROS2の次の世代のライブラリや、AWS IoTの最新版やAzure OSへの対応などの方が高いかなと思ってます。でもRAが楽しくなってきたのでどうしようかなぁとか。
岡宮さん、こんにちは。NoMaYです。FTDIは専用のWindowsデバイスドライバですので、吸い上げ能力がWindows標準のCDCドライバより増強されている可能性もありますね、、、(ただ、そもそもESP8266からバーストで例えば256バイトとか送信されてくるものなら、受信リングバッファは256バイトは確保しておくのが安全/必要だと思います、、、WindowsはマルチタスクOSですので、タイムスライスが割り当てられていないタイミングでは書き込みツールはデータを吸い上げられないですので、、、)あと、女房と畳は新しい方が良い、という辺りでしょうか？私は、あまたのCPUアーキテクチャが存在したことを知っている世代なので、あまりARMコアだから/Cortexコアだから、というので興奮しないのですよね、、、
はは、私もコアへのモチベーションはそんなにないのですが、これまでGR系でBluetoothの企画をやると純正コンパイラのリンクサイズ制限に悩まされてきたので、標準がGNUのRAはその辺を気にしなくてよい解放感に満ちているといった感じです。