Arduino2.0を試す

新たに公開されたArduino2.0で「TeensyがBoardManagerによってサポートされる」というアナウンスが本家から発せられたので早速試してみたのだが、、、



何故かライブラリのコンフリクトが多発してコンパイルを完了出来ない。

原因は、SdFatとGFX_Library_for_Arduinoで、現在 Tennsyduino1.57 で使用している Arduino_GFX と SD とコンフリクトが発生してしまうようだ。



しかも、追加されたライブラリの影響を受けて、ライブラリ・フォルダを共有しているTeensyduinoでもコンパイルが通らなくなってしまった。

Arduino2.0のアラートに不具合が指摘された SdFat と GFX_Library_for_Arduino を削除することで、とりあえず問題は解決するのだが、、、



やはり専用のTeensyduinoを使った方が安全との結論に達している。

一方、本家のTLでは、コンフリクトやメモリ管理の問題は認識されていないようで、やはり自分のやっていることが特殊なのかもしれない。

ただし、今後は開発ツールの主流がJAVAに依存しない新版Arduinoに移行していくと予想されるので、出来るだけ早い段階でプログラム側に変更を行って対処するのが得策と思われる。

そこで、試しにプログラムの書き直しにトライしてみたのだが、



直すべき項目は一通り判明していて、、、





なんとかコンパイルを通すところまでは辿り着けた。

が、残念ながらArduino2.0ではRAMの扱いが破綻してしまい、乗り換えが困難なことが判った。　



新しいライブラリに於いては、表示系のデータの扱いがSDカードの直接読み出しから一旦RAMにストアする形式に変更された可能性が高く、これが破綻に至った原因と思われる。

つまりトラブルの発生は、GFX_Library_for_Arduinoに起因することになる。　RAMの消費対策としては、mallocにbufを展開して、そこにデータをストアする、もしくはPRGMEMから直接データを読み出す方法が考えられるが、実行のハードルは高そうだ。　

今後は、開発元のArduino_GFXのアップデートも警戒の対象にすべきだろう。

ちなみに現在使用している Arduino_GFX のヴァージョンは 1.15 で、流石にこれは少々旧過ぎる感があり、この機会により新しいヴァージョンを試すことにした。

まず、ヴァージョンを最新の Ver.1.28 に上げた状態で、、、



IDEをTeensyduinoに変更した場合に、メモリ管理の問題が解決しないことを確認した。　



次に、ヴァージョンを 1.25 まで落とした場合でも、同様の不具合が発生した。



RAM管理の破綻が発生するライヴラリ Arduino_GFX_Library.h は、ポート指定の記述に SCK/MISO/MOSI の設定項目が書き加えられている。



ちなみに、jpegに処理を行う過程で参照するファイルを敢えて「旧いもの」に設定した場合、



読み出す画像に不具合が出るものの、メモリの破綻それ自体は発生しない。

jpeg画像が正常に表示されるかどうかの見極めは簡単で、Arduino_GFX_Library.h の設定項目に SCK/MOSI/MISOが含まれないヴァージョンを使用するとよい。



現状で、画像表示に問題が発生しない最新のヴァージョンは、1.21 ということになった。



以上の状況証拠から、不具合が発生する原因は "JpegFunc.h" にあり、このファイル内のメモリの割振りによって、破綻が生じている可能性が高い。

不具合の発生は、自分の用法のようなメモリの消費がカツカツなケースに於いて発生するので、次のアップデートでこの問題が解消される可能性は低いだろう。

STM32F407ZET6ボード

去年の年末辺りからTeensyへのオルタナティヴとなりそうなボードを探っていたのだが、高性能なSpresenseは敷居が高すぎるうえに今のところ開発に必要なデータが揃わない。

そこで、まずは手軽に試せそうな　STM32F407ZET6　を搭載したボードをArduinoに対応させてみた。



単価は1.3k程と激安だが、オーバークロックさせない素の状態では168MHzと処理能力はシステムクロックを最高速に設定したTeensy3.6の2/3位になるだろうか。　Spresenseとは違って、出せるpinを全て引き出している構成がとても好ましい。

Brand: Unbranded/Generic
Markings: STM32F4XX STM32_F4XX V3.0 1606

Specs:
STM32F407ZET6 ARM Cortex M4
168MHz, 210 DMIPS / 1.25 DMIPS / MHz
1.8V - 3.6V operating voltage
8MHz system crystal
32.768KHz RTC crystal
2.54mm pitch pins
JTAG/SWD header
512KByte Flash, 192 + 4 KByte SRAM
3x SPI, 3x USART, 2x UART, 2x I2S, 3x I2C
1x FSMC, 1x SDIO, 2x CAN
1x USB 2.0 FS / HS controller (with dedicated DMA)
1x USB HS ULPI (for external USB HS PHY)
Micro SD
Winbond W25Q16 16Mbit SPI Flash
RTC battery CR1220
1MB SRAM footprint, unpopulated (IS62WV51216-1M)
1x 10/100 Ethernet MAC
1x 8 to 12-bit Parallel Camera interface
3x ADC (12-bit / 16-channel)
2x DAC (12-bit)
12x general timers, 2x advanced timers
AMS1117-3.3V: 3.3V LDO voltage regulator, max current 800mA
Micro USB for power and comms
Yellow user LED D1 (PF9) active low
Yellow user LED D2 (PF10) active low
Yellow power LED D3
2x jumpers for bootloader selection
Reset button, Wakeup button, 2x user buttons K0 (PE4) and K1 (PE3)
2x30 side pins + 2x16 bottom pins + 1x4 ISP pins
2x16 FMSC LCD Interface
NRF24L01 socket
M3 mounting holes
Dimensions: 95.1mm x 74.6mm

ボード側のピン接続はこうなる。

<-----+
|_1 _2| Pin 1 = 3v3
|_3 _4| Pin 4 = GND
|_5 _6|
|_7 _8| Pin 7 = SWDIO
|_9 10| Pin 9 = SWCLK
|11 12|
|13 14|
|15 16|
|17 18|
|19 20|
<-----+

当初はボードが認識されずにあれこれ試行錯誤を行っていたが、単に配線が外れているだけだったという何時ものマヌケぶりを発揮してしまった。

凡ミスを防ぐために、書き込みケーブルには専用のコネクタ付きのものを購入したほうが良さそうだ。

今回は、Arduino IDEからBlinkLEDを書き込んで、ポートアサインの確認を行った。　



Pinナンバーは数字単体ではなく、回路図にあるようにPF9と記述すれば良いようだ。　コンパイルには結構な時間が掛かっている。　単なるBlinkに数分掛かるようではこの先が思いやられてしまう。



ボードへのデータの書き込みはST-Linkを介して行うことになる。　ST-Linkはファームウエアやドライバのアップデートを確認出来るUtilityを併用すると便利だ。



何れは使用するであろう直アサインの記述は、MCUのアプリケーションデータで確認する必要がある。

STM32F4シリーズは、カウンタの構造などチップの構成がTeensyで使い慣れたFreeScaleのMCUとは大幅に異なるので、これからデータブックを読み込んでいかなければならないが、もしかするとST製のM3を搭載した　Due　に近い命令体型なのかもしれない。

追記：

KeilにExampleコードを引っ張ってきて検討しているところだが、Timerの構成はFreescaleのものと比べて複雑な印象がある。　あまりに項目が多くて選択肢がつかめないので、予め必要とされる機能を選択した使用例を探した方が早道だろう。



基本的にはリングカウンターの瞬間値を入力PINのアップエッジでキャプチャー出来れば良いだけなのだが、入力信号の分周まで出来てしまうのが便利なのかどうか？　構造をよく理解していない現時点では何とも言えないがが、もしかするとコード側にも根本的な構造の改変が必要になるかもしれない。

Arduino関連の資料2冊を購入する

値段は少々高価かったが、バーゲン価格になっていたのを機に在庫ラストを思い切って購入。　

A4サイズ/3cmと分厚い外観に圧倒されるも、中にはDigitalFilter等の有用な情報が詰まっていた。



後日こちらも購入している。　記事の内容が殆ど被らないところが興味深い。

ArduinoIDE1.6.12でDueにスケッチのアップロードが行えない件

Dueへのアップロードが行えない問題は、このメソッドで解決するらしい。

具体的には、platform.txt内の記述、

tools.bossac.upload.pattern="{path}/{cmd}" {upload.verbose} --port={serial.port.file} -U {upload.native_usb} -e -w {upload.verify} -b "{build.path}/{build.project_name}.bin" -R

を、、、

tools.bossac.upload.pattern="{path}/{cmd}" {upload.verbose} --port={serial.port.file} -U {upload.native_usb} -e -w -b "{build.path}/{build.project_name}.bin" -R

に書き換えて、対応できるという。

他にも、別のファイルを改修するこんな記事を発見している。

後ほど、ファイルを書き換えて実験してみよう。

USBマウスの製作

昨日は、軍用ラップトップのジャンクを復活させるために、マウスとキーボードの仕様を解析していたので、OpenTheremin関連の作業はポリ音源化のコードを書くのみで、現物系の作業はお休みした。

そのマウスというかポインティングデバイスがクセモノで、ポインターによって平面の上下左右方向に掛かる圧力を感圧素子が検知して、抵抗値をアウトする仕組みだった。　配線は黒がコモンで、隣の緑から順に下・右・上・左に圧力が掛けられた場合の抵抗値（変化は減少方向）が出力される。　抵抗値の変化はかなり急峻で、数ＭΩから20kΩ前後に数値が急変する。　そのため、ソフト側の加速度設定は必要が無いかもしれない。

この素子からマウスを実現するためにArduino/LeonardoをUSB HIDデバイスに仕立てあげるスケッチを見つけたが、単純にVRポットを２つ組み合わせた構造のものを対象にしているため、件のポインティングデバイスに応用するためには改造が必要となる。

ポインティングデバイスの出力はそのままでは使えないので、Rail to RailのOpAmpで抵抗値の変化を電圧値に変換し、これを４つのアナログポートに出力する。　Arduino側は、入力を４chに増やしつつ、負の変化をカウントするために新たな関数を追加しなければならない。　XY変化量のフルスケールは１０２４段階ということなので、これを５１２ずつ正負の値に分離してオフセットを掛ければなんとかなるだろうか？？？

expansion boardが届いた

Teensy用のexpansion boardが届いたので、早速ピンの実装を行った。



Teensy3.2の外周のピンを固定した後に、内側のダブルカラム状態のピンを取り付けるのは至難の技だった。

ブレッドボードで試作を行う場合は、ボードの端子配列の性格上、Teensy3.2の裏側に表面実装するピンを取り付けられない為に今回のような顛末に至ったのだが、expansion boardそのものを変換ソケットとすれば、最初からTeensy3.2に全てのピンを取り付けられる。

リセット端子のパターンが脆いのには要注意で、案の定pinの接続時に剥離をやらかしてしまったが、この製品は基盤の銅箔がかなり薄い代物なので、加熱には細心の注意が必要だ。 剥離に対する手当は、辛うじて残された配線パターンの切り端にハンダをメッキして端子を接続し、ブラブラ状態のそれをUV硬化タイプのエポキシ樹脂で固定したが、これはこの場所にピンを使用する場合には必ず必要な手当だろう。

もう一枚予備で購入したexpansion boardにはピギーバック用のコネクタを取り付けておいた方が良さそうだ。

TeensyからMCP系DACにデータを送信するコードの覚書き

昨日からテストしているMCP4921へデータを送るためのサブルーチンはこんな感じにまとまった。

void MCP_OUT(uint16_t value){ //start of sequence
cli();
CS01_OFF;
SCK01_OFF;
//send the 12 bit sample data with dac config data on 4bit MSB
for(int k=15;k>=0;k--){
SCK01_OFF;
SI01_out = ((value & (1<>k;
if(SI01_out == LOW)
{
SI01_OFF;
}
else
{
SI01_ON;
}
SCK01_ON;
}
CS01_ON;
// LDAC01_OFF;
SI01_OFF;
SCK01_OFF;
// LDAC01_ON;
}

データを送る側では、

　temp_val = (datax | 0x7000 );
　MCP_OUT(temp_val);

のように、出力をコンフィグデータでラッピングしてから送信する。

送信するdataxが16bit幅以上の場合は、予め上位の不要なbitをシフトして桁合わせを行っておくこと。

なお、チップ内蔵DACのアウトプット A14 に出力するのは遥かに簡単で、

analogWrite(A14,(int)value);

と記述するだけだが、こちらも事前に桁合わせを確実に行う必要がある。
続きを読む

Teensy3.2のNOP時間を計測する

ラジオテスト用のオシロは、入力レベルに問題があって、これは多分使用しているプローブが原因と思われるが、電圧が異常に低く表示されてしまう。

が、とりあえず波形の観測はなんとか行えたので、NOP1発の信号幅を計測してみた。



ところが、理論的にはCPUの処理1サイクルのクロックが計測されるはずが、アウトプット端子の物理的な制約が生じたのか、最高速度はコードをどう弄っても2.5us止まりだった。　

一方、遅延時間の設定を行うためにfor文を使用する場合には、繰返しと判定のプロセスが介入する分の遅延が発生するようで、クロックの最高速度はNOP単体の倍以上遅い8usとなった。

何れの波形もデューティーサイクルが狂ってしまうのが特徴だが、8usの方はまだ矩形波の綺麗な形を保っていた。

一方、出力端子の物理的な制約を受けない「内部回路で繰り返し処理を重ねる方法」を使って実際の速度を計測したところ、for文でNOP2発を回した時の1秒に相当する回数は約８００００００カウントだった。　これは、1.25usの遅延を意味するが、内部処理を行う場合はこの時間を目安にタイミングを測っていけば良いだろう。



DACへのデータを読み出す場合は、出力ポートにダイレクトアクセスを行いつつプロセスを踏まえてタイミングを管理する出力構造なので、基本的には齟齬が発生する可能性は低いと思われる。 ただし、速度が低速なDACを使用する場合は、データの確定時間そのものを管理する必要があり、この場合はローカルでNOPを使った調整を行えば良いだろう。

FTMの稼働状況を解析する

FTMの状態を可視化するために、シリアルポート経由でPCにデータの状態を反映させてみたところ、カウンタ自体は動作しているものの、カウンタの値を取り込むためのトリガーが全く動作していないことが判った。

問題の発生が、ポートのコンフィグを行うレジスタに起因するのか、FTMの設定そのものに瑕疵があるのか、明確には判らないが、どうもコンフィグレベルで何かがおかしい様に感じる。

場当たり的な問題の解決方法としては、カウンタの瞬間値を汎用レジスタに格納するオリジナルではINT0で行われていた方法をattatchInterruptを使って実現するだけなのだが、せっかくハードウエアに実装された機能が使えないのは勿体無いので、これまたTeensyのフォーラムに質問を投げることにした。

Arduino＠CorTexM系チップが搭載されたボードのDirectPortAccessに関して

今日はArduino工作の初歩の初歩、LEDチカを出力ピンにデータをダイレクトアクセスして実行するスケッチを使って、コンパイルの実験を行っていた。



スケッチはご覧のように小学生の高学年レベルで楽勝な内容ではあるが、これがArduinoMega等AT328系のボードでは動作を確認できた。



出力ピンにデータのダイレクトアクセスを行う意味は、異なるボード毎に通訳を行う「通常の命令セット」よりも格段にスピードが稼げることにあり、その分ボードの種類毎に違ったポート/ピン番号を入力する必要が生じる。

ところが、DueやTeensy等のCorTexM系ボードで同様の操作を行ったところ、コンパイルは通るものの、機能を全く実現できないことが判明した。

これは、すでに去年末の段階においてDue上で確認していた不具合だったが、全く修正が行われていない案件であり、早速Teensyのフォーラムに一件を書き込んでおいた。

まあ、クロックがAT328よりも5倍以上速いM3やM4で、時間を稼ぐ必要があるのか？と言われたらソレまでで、実際 digitalRead(Write)Fast なる命令セットも存在するわけだが、「マージンは稼げるところで稼ぐべき」という考え方も一面で真実と言えるので、もちっと粘ってみることにする。

追記：

その後、GPIOに直セスアクセスする命令セットを思い出して試してみたところ、、、



出力は可能だったものの、入力のPDIR（PortDataInputRegister）は相変わらずの動作不能だった。

9月27日追記1：

フォーラムに質問を投げたところ、マクロセットの使用を提言する回答をもらった。

記述は以下のように行う。　bitの指定が必須ではあるが、ボードによって異なるGPIOのグループを参照しなくて良い点が便利だ。


#define LED_ON (CORE_PIN13_PORTSET = (1<<5))
#define LED_OFF (CORE_PIN13_PORTCLEAR = (1<<5))


ついでに入力レジスタにアクセスする

#define buttonState GPIOD_PDIR & (1 << 7)

および

#define buttonState (CORE_PIN5_PINREG & (1<<7))

の動作を確認した。　＆　を取るのは、ポートレジスタにおける目的するBitの状態を抽出するため。

次に、ピンへの入力でLEDの点灯を行うスケッチに関して。

当初は回路の物理的な不備（DigitalPinがハイインピーダンスで放置）が原因と思われたが、

if(state1 == HIGH) {LED_ON};

とした場合、相変わらずLEDが点灯しない。

判定回路を

void loop() {
state1 = buttonState;
　　if(state1 == LOW) {LED_OFF;}
　　else {LED_ON;};
}

と判定の条件を反転することで、PINの読み込みを確認出来た。　

なお、プルダウンを行う前のピンの状態はかなり不安定で、全ての入力は予めソフト上でプルダウンしておくべきだろう。

今回は同時に attachInterrupt の動作確認を行った。

attachInterrupt(buttonPin01, blink, RISING);

この場合、blink がインターラプトのディスティネーションで、

void blink() {
LED_ON ; // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
LED_OFF ; // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

のように、分岐先に処理を記述しておく。分岐先のサブルーチン化の手法がいまいち解らず、これの解明が今後の課題。

9月27日追記2：

AttatchInterrupt の状態判定を HIGH / LO 何れかの継続状態に設定することでサブルーチンのループ化が可能と解った。



これを RISING / FALLING に設定すると、サブルーチンの処理は単発に行われ、ループは発生しない模様。

Arduino＠USBH_MIDIが更新される

ArduinoでUSBホストを実現できるUSBH_MIDI関連のファイルが更新されたので、以前トライしてダメだったiRigのキーボードのマウントに再挑戦することにした。

スペース効率の改善を考えて、今回はLeonardoにスケッチを書き込んでみる。





結果は、KORG系とiRig系は問題なく認識できたが、LaunchPadMiniは相変わらず沈黙状態だった。

LaunchPad系では、LaunchPad"S"専用のスケッチが発表されており、期待値が高かったのだが、残念ながら前述したようにUSBH_MIDIでは未だ認識が行えず、LaunchPadMiniのスタンドアロン化はまたもや見送りとなった。

ただ、Hubを通すと認識できるという話もあるので、とりあえず激安い2又のHubを購入して様子を見ることになる。

今回、iRigが使用可能になったことは大きな進歩で、以後、動作する機種は限定されてはいるものの、USB系の楽器をワイヤレスで使えることになった。

ArduinoベースのPitchToMidi回路に関する覚え書き

数年前に作り掛けて放置していた案件を今一度検討する。

元ネタはこの記事で、Arduinoを使ってPitch検出を行い、対応する midi note を出力する仕掛けで、作者からコードと製作マニュアルのセットを購入した。

製作マニュアルではシリアル出力ポートに関する言及が曖昧だったので、コードを調べ直したところ　AFSoftSerial SSerial(9);　という記述がそれに該当する。　要は、D9（チップの 15番ピンに相当する） からLCD駆動用のシリアルデータが出力されている。　

なお、Arduinoのスケッチは拡張子が .pde の時代の産物なので、現行版ではコンパイル不能。　コードを書き換えるのが億劫なのでこのまま放置しているが、チップを焼く場合は、旧アルファ版 arduino0023 のIDEをインストールしなければならない。　複数台を製作するような場合は、念のためにコンパイル済のバイナリコードを保持しておいたほうが良いだろう。

今回は、製造に手間がかかるプリント基板を自作せずに、ユニバーサル基板に回路を組む方向で作業を進めている。



ユニバーサル基板で回路を製作する場合、電源関連とグランドの配線が煩雑になってしまうが、単品を製造する場合はエッチングと孔開けを省略できるこの方法が一番だろう。

Teensy＠Portへのダイレクト・アクセスを行う

Teensyが到着したので、Port直結のテストを行った。

その前に、ドライバーのインストールが必要だが、実機を接続せずにアプリをインストールした場合、USB/Serialが認識できずに躓く。　対処法は、アプリのインストーラーを管理者権限で起動して、ドライバーをインストールすることで解決する。

で、Port管理の実験。

まず、出力系は問題なく動いたが、入力系はDueと同様にアウトだった。もしかすると、IDE1.6.5特有の問題かもしれない。

記述は、(GPIOD_PDIR & (1 << 7))　としたが、全く反応無し。

試しに、digitalReadFast(portNumber) を試したところ、こちらはまともに反応した。

ということで、当面の間、読み出しはdigitalReadFastを使わざるを得ない雰囲気だ。

ArduinoDue＠IDEのバグが疑われる案件

実験の結果、最新IDE環境下のArduinoDueにおいて、 REG_PIOD_PDSR が稼働しないことが判明。　

#define buttonState1 (REG_PIOD_PDSR & (1 << 7))

では、入力信号は認識されない。

Teensyで使用不能な g_APinDescription を使った実験では、データを拾えていることから、ハードウエア上の問題は発生していないことが確定している。

一方、REG_PIOｘ_SODR / REG_PIOｘ_CODR を使った出力コントロールは以下のコードで問題なく行えていて、　

#define _ON REG_PIOA_SODR = (1 << 13) // LED pin D13
#define _OFF REG_PIOA_CODR = (1 << 13) // LED pin D13

ポートや、= (1 << n)　を変更して、出力端子の指定をやり直した場合も、動作を確認出来ている。　以下に、Buttonスケッチを改定したテスト用のスケッチを記す。

const int buttonPin = 11; // the number of the pushbutton pin
const int ledPin = 13; // the number of the LED pin

const int bufPin = 16; 　// buffers for testing the output routine
const int buf2Pin = 8;

// testing the g_APinDescription

inline void digitalWriteDirect(int pin, boolean val){
if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
else g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;
}

inline int digitalReadDirect(int pin){
return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);
}

#define LED_ON REG_PIOB_SODR = (1 << 27) // direct assign to LED pin D13
#define LED_OFF REG_PIOB_CODR = (1 << 27) // direct assign to LED pin D13

#define _ON REG_PIOA_SODR = (1 << 13) // direct assign to test pin out
#define _OFF REG_PIOA_CODR = (1 << 13) //

//#define buttonState1 (REG_PIOD_PDSR & (1 << 7)) // does not works

int buttonState = 0; // variable for reading the pushbutton status
int buttonState1 = 0;
int buf = 0;
int buf2 = 0;

void setup() {
pinMode(ledPin, OUTPUT);
pinMode(buttonPin, INPUT);

pinMode(buf2Pin, INPUT); // additional data buffers
pinMode(bufPin, OUTPUT);
}

void loop(){
buf = digitalReadDirect(11); // reading the data directly from the ports
buf2 = digitalReadDirect(8);

buttonState1 = buf2; // testing the external pin routine
buttonState = buttonState1;

// buttonState = (REG_PIOD_PDSR & (1 << 7)); //does not work

if (buf == HIGH) {
// digitalWriteDirect(ledPin, HIGH); // pin assignment with g_APinDescription
_ON;
}
else {
// digitalWriteDirect(ledPin, LOW); // pin assignment with g_APinDescription
_OFF;
}
if (buttonState == HIGH) {
// digitalWriteDirect(ledPin, HIGH); // pin assignment with g_APinDescription
LED_ON;
}
else {
// digitalWriteDirect(ledPin, LOW); // pin assignment with g_APinDescription
LED_OFF;
}
}


やはり、Teensyは実機で実験しないと、結果がわからないが、IDE側で発生している問題の可能性が高い。

Teensy＠導入前のまとめ：

昨日からリサーチしているTeensy関連のトピックをまとめた。

１）命令セットはM3とは別物で互換性はない。　

２）なので、当然ながらダイレクトアクセスな命令は以下の様に書き直し。

#define led 13 // LED on D13
#define LED_ON GPIOC_PSOR = (1 << 5) //Teency3.2 GPIOC 5
#define LED_OFF GPIOC_PCOR = (1 << 5) //Teency3.2

#define buttonPin01 5 // Button Pin on D5
#define buttonState GPIOD_PDIR & (1 << 7)

３）その他、Dueとは微妙に関数が異なる。

便利な　g_APinDescription　は使用不可だった。

４）スペース（ASCIIコード）に敏感。　Arduino本家系で無視されてたのが、Teensyでは不具合を指摘される。

不用意にタイプしている場合は、

warning: backslash and newline separated by space

と、即座にerrorが出される。

５）電源は3.3Vだが、デジタル系の入力だけ5Vまで許容出来る。

６）速読み（書き）関数、digitalRead(Write)Fastは実装済みな模様。

７）ASM命令でNOPが可能。　1NOPあたり45ns程度のディレイが発生する。

__asm__ __volatile__("NOP");

８）本家と同じく、端子の連番とポートの並びに関係性はない。



９）回路図によるポートの確認が必須だが、本家のような表は用意されていない。



１０）インターラプトの遅延が気になる場合は、こちらも直アクセスが可能だが、使用頻度の高そうな4bit幅のアドレスの設定方法がイマイチわからず。（多分、オフセットを掛けるのだろうが）



１１）とりあえず、LEDチカチカで、直アクセス系の命令セットの動作確認を行い、、、

#define led 13 // LED on D13
#define LED_ON GPIOC_PSOR = (1 << 5) //Teency3.2 GPIOC 5
#define LED_OFF GPIOC_PCOR = (1 << 5) //Teency3.2

#define buttonPin01 5 // Button Pin on D5
#define buttonState GPIOD_PDIR & (1 << 7)

uint8_t state1 = 0;
volatile int state = LOW;
　
void setup() {
　
pinMode(led, OUTPUT);
pinMode(buttonPin01, INPUT);
attachInterrupt(buttonPin01, blink, RISING);
}
void blink() {
state = !state;
}　

void loop() {
state1 = buttonState;
if(state1 == HIGH) {LED_ON;}
else {LED_OFF;};

// if(state == HIGH) {LED_ON;}
// else {LED_OFF;};

LED_ON ; // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
LED_OFF ; // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

１２）次に手持ちのDACを接続して、単純な信号源をソースとしたバースト信号伝達の実験にトライする。

/*---------------------------------------------------------*/
/* AD420 Serial Input 16bit DAC example */
/* original code written by Vincenzo Pacella - www.shaduzlabs.com */
/*---------------------------------------------------------*/

//arduino output pins
#define LATCH 7
#define CLOCK 8
#define DATA 9

uint16_t j=0;

void setup()
{
pinMode(DATA, OUTPUT);
pinMode(CLOCK,OUTPUT);
pinMode(LATCH,OUTPUT);

digitalWriteFast(DATA,LOW);
digitalWriteFast(CLOCK,LOW);
digitalWriteFast(LATCH,LOW);
}

void writeValue(uint16_t value){
　　　　 //start of sequence
digitalWriteFast(LATCH,LOW);
digitalWriteFast(CLOCK,LOW);

//send the 16 bit sample data
for(int i=15;i>=0;i--){
digitalWriteFast(DATA,((value&(1<>i); //tck > 300ns

__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");

digitalWriteFast(CLOCK,HIGH);

;
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");

digitalWriteFast(CLOCK,LOW);
}
　　　//latch enable, DAC output is set
digitalWriteFast(DATA,LOW);
digitalWriteFast(CLOCK,LOW);
digitalWriteFast(LATCH,HIGH); //tll > 80ns

__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");
__asm__ __volatile__("NOP");

digitalWriteFast(LATCH,LOW);
}

void loop()
{
//a 0 to 5V triangular waveform
for(j=0;j<65535;j+=5){
writeValue(j);
}
for(j=0;j<65535;j+=5){
writeValue(65535-j);
}
}

１３）ADATとFPGAとの連携を、これも単純な信号源をソースとしたバースト信号を使って実験するが、信号管理のタイミングは外部供給によるSCK/WCKで行う。

といった感じでしょうか。

Arduino＠MidiLibraryの仕様変更について

Arduino/1.01時代に書いたスケッチが、最新版では動かなくなった。

アラートは以下のように表示された。

midiReader2x24e.ino: In function 'void setup()':
midiReader2x24e:27: error: 'MIDI' was not declared in this scope
midiReader2x24e.ino: In function 'void loop()':
midiReader2x24e:38: error: 'MIDI' was not declared in this scope
'MIDI' was not declared in this scope

解決法は、void setup();　の前に

MIDI_CREATE_DEFAULT_INSTANCE();

と記述すれば良い。

事前にインクルードファイルの記述を、

#include ＜midi_Namespace.h＞
#include ＜midi_Settings.h＞
#include ＜midi_Defs.h＞
#include ＜MIDI.h＞
#include ＜midi_Message.h＞

としておくと、なにかと便利そうではある。

接続するLCDについて、一部電源端子の極性が異なっているものが存在することに注意。仕様を確かめないで接続した場合、LCDコントローラーが損壊する。

参考までにebayで安価に仕入れられる中国製LCDの仕様を以下に記録しておく。　このモデルはMotorMix等に使用した実績があるが、端子の配列はより一般的なものと思われる。

ArduinoDue＠DirectAccessのコマンドの間違いが発覚する。

今日はDueTimerを使ったSamplingClock生成実験の過程でLEDチカを行っていたのだが、実効速度の向上を目指してポートへのダイレクトアクセスを試みたところ、コレがどうやっても上手く行かない。　

とりあえず、LEDの点滅は行えたということで、ポートへのダイレクトな書き込みは問題なく行えていたものの、配置したスイッチに動作が反応しない。　これは、現状のコードではアサインを失敗しているということになるので、

#define BUTTON_STATE REG_PIOC_PSDR = 0x1 << 26

Dueのポートにダイレクトアクセスを行う記事の検索をかけたところ、ここで以下のように表記を単純化出来るコードを発見した。　

//accessing from the ports by digitalReadDirect/digitalWriteDirect.

inline void digitalWriteDirect(int pin, boolean val){
if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
else g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;
}

inline int digitalReadDirect(int pin){
return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);
}

digitalRead(Write)Directと表記することで、簡単に高速化が行える。　コンパイルも通ったが、いろいろとやらかしてそうなので、頭を冷やした後にコードを精査しなければならない。

ついでにTimerを使ったTheremin用のReferenceOscillatorの実験を行った。　スイッチングをダイレクトアクセスで行うことで、400kHz前後の周波数に対応させている。　映像では200kHzから500kHzの間をsweepさせているが、高調波の存在が少々気になった。　オシロスコープで波形を観測していないのでなんとも言えないが、やや怪しげな雰囲気ではある。

TimerをOscillatorとして使うのには目的があって、温度/湿度センサーとの組み合わせによって、搭載しているアナログなOscillatorの周波数ドリフトを相殺できないか？という発想だ。理想はDDSだが、そこまでの精度を要求しないレベルで、実用度を確かめていきたい。

ArduinoDueをDualBoot化する

最近、発表されたLinnStrument Expressive MIDI ControllerはArduinoDueがプラットフォームということで、プロの現場においてAruduinoDueを使ったMIDI機器の開発が始まったようだ。

OpenThereminにもMIDI化が行われていて、GaudiLabsのサイトにファイルがアップロードされていた。　Dueへの対応はまだ進んでいないが、取り敢えずコンパイルだけ通ったものをアップロードしておく。

openThereminOnDue1028_15.zip

ArduinoDueをMIDI楽器として使用するには、USBインターフェイスのファームウエアを書き換える必要があるということで、avrdudeとArduinoUno等の組み合わせで、書き換えを実行する。



詳細はこちらのサイトに記載されているが、

http://radikalbytes.com/?p=17

今回はHexファイルの読み出しで躓いたので、その辺り経過を記録しておく。

作業には、書き込み用のスケッチをアップロードしたArduinoが別途必要で、今回はArduinoUnoを使用した。　手順は本家サイトの記事を参考にしたが、avrdude.exeのConfigFileは、予め実行ファイルと同じ階層に移しておいた方が良いようだ。

https://www.arduino.cc/en/Hacking/Upgrading16U2Due

コマンドを打つときにバックスラッシュが使えない日本語環境では、UniCode上で同配列の"Yen"を代用することになるが、日本語対応のアプリケーションが「スラッシュ」を代用できて仕舞うところに罠があった。

例えば、C:\Users\xxxx>cd C:/Program Files/Arduino/hardware/tools/avr/bin/　と打っても　C:\Program Files\Arduino\hardware\tools\avr\bin>　のように変換/修正されるので、問題は発生しない。　

ところが、C:\Program Files\Arduino\hardware\tools\avr\bin>avrdude.exe -C avrdude.conf -c a
rduino -P com22 -b 19200 -p m16u2 -vvv -U flash:w:dual_boot_Due.hex:i　のように、実行ファイルが絡んだ場合、読み込むファイルのアドレスを設定する部分flash:w:dual_boot_Due.hex:iのスラッシュがバックスラッシュとして認識されず、参照すべきファイルの位置を見失ってしまうことになる。



今回は、実行ファイルと同じ場所にHexファイルを置いて、スラッシュを使わない形で場所を指定することで難を逃れた。 作業を単純化するためには一連のファイルを別のフォルダーに実行ファイルごとコピーして作業環境を構築した方が良いだろう。





追記：　ファームウエアの改変後、 Atmega 16U2 PB4 pin (JP5.1) を GNDに接続して、無事MidiDviceとして認識させることが出来た。　次に、DueをProgrammingPort経由で再接続したところ、不明のデバイスとしてドライバーがインストールされなかった。　不具合を回避するには、NativeUSBportに繋ぎ直してPCにDueを認識させればよい。　手間が掛かる方法としては、DeviceManagerからProgrammingPort用のドライバーを手動で設定し直すことも可能だが、その場合には無駄にUSBHubを経由させないほうが良いようだ。　

以下に、コマンドプロンプトの表示をコピーしておく。






続きを読む

nanoKey2 と Arduino/USBHOST

昨日3200円で購入したKorgNanoKey2をArduinoベースのUSBHOSTに接続したところ、問題無く認識できた模様。　これでWiFi化が夢ではなくなった。



筐体が薄いので、Etherwaveとの連携が可能になるかもしれない。　これは無理してもう1台飼っておくべきだったか。　

USB機器から出力されたDataStreamが、Arduinoによってシリアルデータに変換されている。

USB_HOST_SHIELDの実装

製作をペンディングしていたArduino用USB_HOST_SHIELDの動作を確認できた。



事前に以下のLibraryをDLしてIDEに登録しておく。

https://github.com/felis/USB_Host_Shield_2.0/archive/master.zip

https://github.com/YuuichiAkagawa/USBH_MIDI

実験の結果、学研nsx-39の動作を確認できたが、iRigやNovationLaunchPadMiniの接続はアウトだった。

GitHubにアップされている対応表に、動作を確認する記述はない。

動かない理由は、件のインターフェイスの属性がオーディオ・ストリーミング・インターフェース・サブクラス(AS : AudioStreaming interface subclass)であると予想している。ヒントはこのサイト↓

http://d.hatena.ne.jp/pcm1723/20141216/1418744836#seeall

に書かれているように、デバイスクラスの扱いにあるのかもしれない。

追記：

mbedと同じく、旧型のUSBデバイスの接続を確認できた。mbedの試験で多重入力時に頻発したフリーズは発生せず、動作は安定してるようだ。

mbedと同じく、ファームウエアがUSB2.0世代のmidi機器のUSBディスクリプションに対応できていないが、誰か接続に成功した人はいるのだろうか。