DaisySeedの接続になんとか辿り着いた

今日は、不調なテルミンのオシレータの調整から現実逃避する形で DaisySeed のオンボード LED を点滅させようと試みている。

書き込みを行う前に STM32duino の Getting-Started を参考に今一度IDE周りのセットアップを確認したところ、



STM32 CubeProgrammer のインストールが必要なことが判明、



STのサイトからダウンロードしたファイルを展開して



Contents 内のアプリケーションを右クリック open で Terminal から起動した結果、



ようやくインストーラが立ち上がってきた。

CubeProgrammer によるアップロードは、



IDE のセットアップから、DFU を選択する。



DaisySeed は USB 端子に接続しても IDE の Port タブにデバイスが表示されず、ボードに書き込みを行う際には Boot ボタンを押しながら Reset ボタンをクリックする儀式を行うことが必要で、 Arduino や Teensy とは作法が異なっている。

以上のメソッドを解説した映像を見つけた。Daisy を導入する際はこちらを参考にすればよいだろう。



今回はプログラムの書き込みが成功したようで、IDE に Start operation achived successfully と表示されたのを確認できたのだが、、、依然としてオンボードの LED は沈黙したままで、どうやら Teensuduino からデフォルトで出力されるスケッチでは LED が接続された Daisy のポートにアクセスが出来ないことが判った。

回路図でボード上の LED に接続された端子の詳細を調べてみたが、、、



端子の番号は G15 ということで、チップの pin 番号の対応表から端子の名称を逆引きしてみたものの、




PC7 = TRGIO と記述されているだけで、設定の方法が解らない。



仕方なく他のサンプルコードを調べた結果、LED ポートの指定項目に "LED_BUILTIN" との記述を発見、これを試してみたところ、正常な動作を確認することが出来た。



ちなみに、前回プログラムを書き込んだ後にシステムが起動不能に陥ったトラブルは、今回上書きしたプログラマーによって解消された可能性が高い。

ボードの動作を確認できたことに気を良くして他のスケッチを試してみたが、端子の指定が外れていてエラーが帰ってきたりするために、いまひとつ達成感が沸いてこない。　これはTeensyduino特有の現象かもしれないので、Arduino 2.0 でも動作確認を行った方がよさそうだ。

なにはともあれ、これでやっとシステム開発の入り口に立つことが出来たので、今後は暇を見つけて学習を行っていくことにしたい。

DaisyにSPI経由でオーディオのデータラインを接続する計画

不定期に連載している DaisySeed への不満を書く。

KickStarter で5個を購入したものの、今に至るまで一度もシステムを走らせておらず（Lチカ以外のコードを走らせることもままならない）、Forum のレスポンスが悪く必要な知見が得られない。しかも HAL の実装が完全ではないために動作が保証されず、問題解決のために技術情報を掘り起こす過程でやる気が失せることを繰り返している。

で、どうやら今回もそのパターンに陥りそうな雰囲気になってきているのだが、現在取り組んでいるお題は「外部からのデジタル音声データの読み込み」で、このフォーマットが使い難い I2C 故に、チップごとに異なる CODEC の導入が必要なことが判明した。　



デジタル入力に拘っている理由は SAI が DMA を使える点で、なら SPI でも良いのでは？という話になってくるのだが、これが引き出されている端子配列の制約から実現は難しいように思う。

このままではアナログで音声をハンドリングすることになりそうで、adat フォーマットによって楽器から音声データの送受信を行うことを目論んでいる手前、単純に割り切れないところがある。

ちなみに、Daisy に組み込まれていた AK4556 は旭化成の九州工場が失火した影響により、現在は wm8731 に変更されている。　つまり、手持ちの旧いデバイスでは CODEC の設定が必須な SAI 経由で外部に接続を行うオーディオチップの混成は不可能と思われる。

SPI から LCD への接続も難易度が高く、LCD のライブラリがプアな状況は引き続き継続されているようだ。　UI の実装が可能かどうか、実機でテストを行いたいところだが、そのハードルは高い。　キャラクタ LCD の他には OLED に対応しているものの、これも適合する機種が限定されている。



ST のマニュアルによると、SPI はオーディオ・データの接続が想定されていて、





頑張れば接続が可能になるかもしれない。　

問題は SPI2 を使用する場合の端子の置換で、現在 USB ホストの予備端子に接続されているポートを利用することになるが、肝心の SCK2 の端子が引き出されておらず、



SPI2 は使用不能ということになった。

スワップが可能な端子を精査したところ、"AF6" を選択して SD 関連の端子を潰せば SPI3 が使えるようだ。













SPI 経由でオーディオデータのやり取りが可能になると、DaisySeed を DSP を搭載した便利な DAC として活用することが出来るので、Cube MX が吐き出したコードを参考にコーディングを行っていく。

理論上は、SPI1&3 でオーディオ信号を扱えることが判った。

ちなみに、久々に Teensyduino で Seed への接続を試みたが、相性が悪いのか「Lチカ」でさえエラーが発生して動作不能に陥ってしまうことが判明しているので、これを機会に Daisy Seed 専用の開発環境を整えて行く予定だ。

追記：

JTAG の JTDI 端子を潰して SPI6 のNSS を配置できることが判ったので、

試しにコードを出力してみた。

HALでFVCの設定を記述する。

久しぶりに CubeMX を起動して、HAL のコードを吐かせてみた。

まずは、FVC を構成する InputCapture の端子を引き出す。



32bit のカウンタを2台同時に運用できるのは Teensy よりも良い設計だ。



HAL のコードはこんな感じで、、、



Timer の初期設定からピンの割付までを行ってくれる。

32bit幅の Timer2/Timer5 の InputCapture を使用する場合、引き出せる端子は Timer2/ch4/PA3/R2 と Timer5/ch1/PA0/N3 の2本で、



DaisySeed の Pin23 と Pin32 に配列される。　元々割り付けられていた SAI2_SD_B は Pin8 に移動する。



他の機能も試しに設定を行ってみる。　とりあえずは絶対に使用するであろう機能を選別した。



microSD は 4bit 対応に。



DaisySeed のピン配置がキッチリと行われている。



LCD をドライヴするための SPI。 多分使用しないであろう SPI1_NSS を指定しない選択肢がある。





そして、外部オーディオの接続端子の分配を試みた。





SAI2 は A/Bch から SPDIF を吐かせることが可能だが、SPDIF を Ach のみに設定して、Bch で I2S を吐かせることも出来るらしい。FVC とのコンフリクトを避けるために、Bch は MCLK を吐かない設定とした。



まあ、コレが実現できれば凄いことなのだが、、、肝心の Arduino IDE はライブラリの実装レベルが怪しいために、残念ながら結果はあまり期待出来そうにない。

DaisyDuino のコードを読むと、ライブラリに pin の設定が組み込まれているために、コールされる度に設定が元に戻る可能性が高い。　故に、ライブラリを直接書き換えるしか対処法は無さそうだ。

ちなみに SAI2 の基本設定はバンク A/B がオンボード AD/DA チップと共通仕様の I2S フォーマットの入出力とされているので、これを送信 4ch に変更し、MCLK を出力しない設定のI2Sフォーマット出力に変更しなければならない。

SAI2A は SPDIF/I2S のどちらのフォーマットにも設定が可能だが、問題となってくるのは SAI2 に付加されるタイミングのオフセットで、データの同期を取るために MCLK 出力が必要とされる可能性が高く、その場合はSAI2_MCLK_B 出力を活かすために、ADC10/SAI2_SD_B が設定されている pin に、TIM2_CH1/TIM5_CH1 の何れかをアサインする方法が考えられる。

先に TIM5_CH1 の InputCapture に対応する pin の割付を決定し、、、



次に SAI2_SD_B をエントリーすると、自動的に ALT pin に割付けが行われる。



これが CubeMX から吐き出されたコード。



SPI1_NSS は、予め使用しない設定にしておく。





SAI2_A を SlaveMode にした場合、pin の設定が RX になってしまうので、これを SPDIF の TX に変更する。



これで、SAI2 は A/B 共に出力が可能となった。



ボードの予備の空き端子はこの2つ。







以上のコードは実効性がなく机上の空論に過ぎないが、ライブラリを改変する上での指標になるだろう。

最後に、一年のブランクを経た Daisyduino の総評を行うと、ライブラリの内容を散見する限り「HAL の導入」は未だ不完全であり、実用域に至るレベルの実装が進むまでの間、ハードウエアを寝かせることになりそうだ。

また、割込み禁止のメソッド一つをとっても Arduino 的な作法が取り入れられていないことから、「Arduino でも扱える」というのはあくまでも能書きであり、ポピュラリティーを得るためのオマケの機能として、、、といったスタンスで、開発に臨んでいるフシがある。

これは、可能な限り「Arduino に寄せること」に有志を含めて腐心している Teensyduino とは真逆の姿勢で、ユーザーコミュニティーの貧困さがそれに拍車をかけているようにも感じられる。　もちろん、Teensyduino にも足りないところが一杯あるのだが、Daisyduino の足り無さはそれとはレベルが違うのだ。

なお、旭化成の工場焼失の煽りを受けたのか、現在生産されているロットは AD/DA が CirrusLogic 製に変更されているようだ。

Daisyその後

お気楽に付き合えると思っていたDaisyは完全に放置状態で、一寸複雑なことをやろうとすると途端にスタックする仕様に負けて、開発に手を付ける気がしない。

ユーザーコミュニティーの規模が小さい所為なのか？ライブラリの更新があまり進んでいないようだ。　



既に手元にある資産を活用出来ないもどかしさ。　自力救済を強いられる分野が多過ぎて、ゴールには辿り着けそうにない。

そのような状況下ではあるが、Nucrelo方面に関しては最近更新が進んでいるようだ。　M7系MCUの理解が進んできたこともあり、そろそろ内容を検討する時期なのかもしれない。



既に、Arduinoに導入を完了している。



Daisy使用時には、H7系統を選択すればよい。



諦め掛けていた ClickEncoder の導入は、PITに準ずるタイマーを探せばなんとかなるか。

追記：

結局、開発環境がプアなプラットフォームは先が無さそうだということで、過去に手掛けたVinclum2やDUE等からも似たような雰囲気を感じていた。

ハードウエアの構造解析と実行可能なコードの連携が進んでいない状況では必要とされる自力救済のレベルが途端に跳ね上がってしまうのだが、ここで助けになる集合知は異なる目的を持った音楽とは別分野の人たちによってもたらされていた。　翻って、音楽系の人はあまりハードウエアそのものに関心が無さそうなのだが、ハードウエアの内容を知らない限り、持てる技術の応用は出来ない。

それにしても、単純なマルチクリックの扱いにライブラリが対応していないところに、開発環境のお寒い状況が垣間見えてしまう。　スイッチの挙動を設定するレベルから自力救済が求められるのは、開発のハードルが高すぎる。　NXP系の開発環境はより抽象化を進めたHALが解り難いというか「初見殺し」なところがあって、しかもそれがDaisyのレベルでは中途半端に実装されている点が中々に厳しい。

試しにGITにアップロードしている有志を検索してみたが、やはりハードウエアの機能を積極的に利用した製作例を見つけることが出来なかった。

Daisyの端子表を新調する

新しいpin配列に合わせた表を作成した。



同時にライブラリの自動配列表を更新しているが、ClickEncoderを導入する場合には実際にこれを使うことはなさそうだ。　余りpinは17本とギリギリで、余裕は全く無い。

第一のハードルはClickEncoderの導入で、これが成功すると朧気ながらも先が見えてくる。　ただし、その先に待っているmicroSDとLCDを実装するというハードルも決して低くはない。



念の為、基盤上のランドをチェックしたところ、DebugTrace用のpin、"PG14" が小さなランドで引き出されているのを確認できたので、



USERと表示されている "Lチカ用LED" の端子と合わせて2本の都合が付くことが判った。　

これでフリーのpinは19本となる。　LCDのBKLは何れかの端子に引き出せば良いだろう。



が、、、このままでは机上の空論なので、表に示した「余りピン」にデバイスを接続して近々実証試験を行いたいところだが、その前に FPGA & adat DAC の実験を先にやらなければならない。

KEILのインストールとその活用

Daisyで実験を行うためにCubeMXを起動しているのだが、freescaleのMCUExpressoとは使い勝手が違うのは当前として、根本的な構造が異なるTimerの扱いから学習しなければならない。

Timerの構造それ自体はNXPの方が単純に見えて判り易い雰囲気を纏ってはいるものの、



Timerを網羅するクロックの体系が複雑なために、初期設定の方法がよく解らない、、、。　



あと、Daisyを不便に感じるポイントは、PINOUT表にPWMの扱いを含めたPinに配置が可能な機能の情報が明示されていないところだろうか。



一方、ARMが提供するKEILは遥かに理解しやすいコードを吐いてくれる。　



ただし、このソフトはWindows専用なので、MacにVMを導入しなければならない。

VMは既にParallelsとVMWareを試していて、ParallelsにはVM上でUSB接続のライターを通して実際にFPGAのプログラミングを行えた実績がある。　今回は、フリーのVMを見つけたので実験を行う感覚でこれをインストールすることにした。



Win10をisoイメージからインストールして挙動を観察しているが、



処理速度は実用域ギリギリな雰囲気で、Parallelsとは比較にならなかった。



さて、そのKEILだが、残念ながらBoardSpecificな仕様なために、H750系統の搭載されたBoardがリストアップされていない時点で殆ど参考にはならなかった。　



前回KEILによってコードを参照出来たのはF475関連のボードが存在したためだが、7XXシリーズよりも参照出来る項目が充実していた。この参照コードによって複雑なクロック系の設定を行う上でのヒントが得られそうだったのが、７XXシリーズはRTOS系の事例が多く、何故か基本的なハードウエアに関する情報がリストアップされていない。

これは、必要とされるパッケージの取得に失敗しているのが原因なのだろうが、何れにしても750系統のチップは対象外なのが残念だ。

Board 毎に参照できるExampleの事例を調べている過程で偶々Cube系のコードにも遭遇したが、



例を見ても判るように、羅列されるコードからは内容の判別が難しいように感じる。

その後、Win7が走るThinkpadにDLしていたSTM32系列のチュートリアルを発掘した。　



これをWin10が走るVM環境に移植して、基本的なTimerの構造を確認できるようになった。　VMの解像度は初期設定のままでは狭くて使い難いので、GuestCDからドライバをインストールして解像度を上げている。　ただし、この処置には副作用があって、あからさまに動作が遅くなってしまうのが難点だ。

開発環境が整ってきたので、これからTimerの解析を行っていく。



まず、MCUに搭載されているタイマーのうち、32bit幅のカウンタを持っているTIM2とTIM5を使って、InputCaptureを行うことを考えている。

freescaleとの構造の違いは、InputCaptureの機能が並列化されていることだろう。これは制御が簡単な構造で、歓迎すべきポイントと言える。





InputCaptureの構造はこんな感じ。



Timer同士が複雑なルーティンで接続されているが、今回これは使用しない。



一方、ClickEncoderを使用するためには、定常的にインターラプトを行う単純な構成のTimerを活用する必要がある。



Timer13/14の構造がより単純なので、これを使用するとよさそうだ。





インターラプトの作法などTeensyとは文法が異なるので、初期設定は一からやり直す形になる。

CubeMX上にDaisyのPin配列をマッピングする

CubeMXにDaisyでリザーヴされているPINをマッピングしているのだが、端子の配分に余裕が殆ど無く、DACの追加は厳しいかもしれない。



端子の配列を試しながらアサインが可能な音声出力ポートの検討を行った結果、SAI2_SD_AをSPDIFに設定すれば2ch分の音声信号を送出できるようだが、この場合はDACとの間にSPDIFの復調回路を挿入しなければならない。　SPDIFの信号を直結できるDACがあれば事は簡単に済むのだが、、、。



その他の方法としては、SAI2のMCKをオンボードDACが接続されているSAI1のスレーヴに設定することで、端子の消費を節約出来そうだ。　



WCK=LRCKが出力できれば、AL-1201に音声データの出力を直結できる可能性がある。



アサインが可能な端子の配列を検討する過程で、上記の方法ではSAI2_AのWCKをどうやっても割付けられないことが判明した。　よって、SAI2_Aの使用を諦めて "SAI2_B” に出力を変更せざるを得なくなったのだが、SAI2_SD_B端子にはTIM5とのコンフリクトが発生している。　これを回避するにはTIM5のInputCaptureをCH1からCH4に変更して、SAI2_FS_BとSAI2_SD_Bの出力が可能となるように、端子の構成を組み直さなければならない。　



実のところ、ST系のInputCaptureに関してはまだよく構造が判っていないので、この変更が有効かどうかはいまのところ確かではない。



現時点でリザーヴされた端子の状況は、こんな感じになっている。



喫緊の課題は、PWM端子のアサインと、LCDの接続の可否を確かめることだが、このボードは、どちらかというとギターシンセ向きのデバイスかもしれない。

ギターシンセを構築する場合に、従来設定していたVolumeAntに対応するのが「ペダル入力」と”Envelope”で、InputCapture1ch分を廃止してAD入力から制御信号をサンプリングすることになる。

ちなみに、Envelopeはギターシンセのキモなので、入力端子はPitch/Envelope/VolumePedalの3つに増える。AD2chのみで賄うことも可能だが、InputCaptureは構造が単純な上に性能が一番高いらしいので、いまのところはここに「コンパレータで整形したオーディオ信号」を入力するのがベストの手法だろう。

ギターシンセの運用に関しては、アタックを殺す以外にエンヴェロープは極力いじらない方向で考えている。　楽器の特徴はエンヴェロープによって決まるので、これをADSRにしてしまうとギターでシンセを駆動する意味がなくなる。　ギターでピアノっぽい音を出したい人も居るのだろうが、所詮はキワモノに過ぎず、あまり意味のない行為だったように思う。

Daisyのライブラリが新調されていた

暫定で行った、ロータリーエンコーダーを追加するための修正ポイントを例示しておく。

Daisyの新しいライブラリは変更点が多く、過去に追加したロータリーエンコーダ関連の記述はすべて無効となった。



まず、判り易い変更ポイントとして、DaisyDuino.hが、Utilityフォルダを参照することになった。



一方、DaisyDuino.cppでは、デフォルトで仕様が想定されているエンコーダーが単体なので、これを2個対応に変更する。



ハードウエア毎にインターフェイスの設定が異なるので、個別に対応を行っている。



コントローラーの総数は、この部分で設定を行うようだ。



こちらは、ハードウエア別の設定箇所。



基本的にはPodに対応するだけで良さそうなのだが、一応こちらにも手当を行っておく。



ProcessDigitalControlで、デバウンスの設定を行っているようだ。



DaisyPod.hでは、インターフェイスに対応する端子を設定する。



DaisyPod.cppでも、端子の設定を行うようだ。



エンコーダーの初期化ルーティンに、追加分のエンコーダを記述する。



ProcessDigital Control　にも項目を追加しておく。

9月13日追記：

CubeMXを新調した。　



TIM2/CH1のコンフリクトは、InputCapture端子をTIM2/CH2に変更することで解決できるかもしれない。

TIM2/CH2 は SAI2_MCLK_B = P31 に変更が可能、
TIM5/CH1 は SAI2_SD_B = P32 に従来通りにアサインする。

ClickEncoderの導入には、freescale版のPITに準ずるFreeRunを繰り返す単純な構造のTIMERを設定すれば良いのだが、



STMのTIMERはfreescaleのそれとは根本的に構造が異なるため、サービスマニュアルの解析から始めなければならない。

DaisyDuino

GitHubに新たな項目が新設されているのを発見した。



https://github.com/electro-smith/DaisyDuino

Arduino IDEでスケッチを試してみたが、コンパイルは問題なく通るようだ。

DaisyPOD関連のライブラリを改装して、









ロータリーエンコーダを複数個展開できないか試す予定。

その後のDaisy

Daisyのコンパイル・エラーの原因を探っていると、「参照するファイルが不在」とのアラートが出ていて、今一度ライブラリ内のファイルを点検したところ、必要なファイル群が存在していないことが判明した。

LibralyのZipFileを自動登録するコマンドでは、「空のフォルダ」がインストールされるようだ。

件のフォルダには、Git内のリンクを辿って別のファイル群を追加する必要があったのが、



そのような指示はWiki内には見当たらず、、、



本来参照されるべきファイルの不在によって、エラーが返っていた、、、という間抜けな結末だった。

ファイルの補充後は、



無事にコンパイルを完了しているが、



書き込み後は、相変わらず「起動不能」のアラートが出ている。　

稼働状態を確かめるため、テンプレートのフリースペースに設定されていたLoop内にBlinkを書き込んでみたところ、これが正常に作動していることから、プログラム自体は「ほぼ正常に」起動しているようだ。

ちなみに、先日発覚したBlinkのExampleで発生するエラーは、今回のファイルを追加したことによって解消した模様。

なんにせよ、音を出して確認するためには、取り急ぎ実験用のプラットフォームをでっち上げる必要がある。

追記：

IMEの切り替えがトリガーとなって、Arduino IDE 1.8.13 がいきなり落ちる現象が発覚している。

追記２：

Arduino関連のファイル取得は、個別に行わず一括でダウンロードすれば解決する模様。

Download the Daisy Arduino libraries here. Once downloaded, unzip the file.

Daisy@Arduinoの開発環境について

DaisySeedのオンボードLEDが点灯しないのは、Pinの設定がライブラリで行われていなかったことが原因と判明。



EEPROMの消去も同様に動作不能で、こちらもアドレス設定のミスマッチが疑わしい。



ポート設定を、pinMode(ledPin, OUTPUT); とすることで、オンボードLEDを認識させることが出来たが、Arduinoの開発環境ではExsampleCodeを始めとして、この手の初歩的な設定がきちんと行われていない可能性が高い。　



これはあくまでも個人的な見解ではあるが、このボードはオンライン上でプログラミングを行うことを前提にしているフシがあって、Arduino環境下の開発は今後もお留守である可能性が高そうだ。

mbedが性に合わなかった原因は、このオンライン上でプログラミングを行うスタイルにあったのだが、Arduinoもゆくゆくはオンライン化の方向を模索しているようだ。Teensyはその点で地に足がついている思想なのが良い。　

Daisyがオンラインに拘る理由は、OS依存によって発生するであろう問題の解消とUserの情報を吸い上げたいという意思によるものと想像しているが、IDEのオンライン化はブラウザ依存という更に間抜けな局面をクリアすることが出来ない。

要は開発者側の「やる気の問題」に見えてきたのだが、Arudinoのライブラリがまともなものに書き直されるまでは使い物にならない。　このまま開発環境の整備に進展がなければTeensy陣営の覇権は安泰だろう。　

DaisySeedはハードウエアの素材が良さそうなだけに大変に勿体無く思うのだが、ソフトウエアの運用は思想ベースに依るものなので、あまり期待はできそうにない。

ArduinoIDEでDaisySeedのプログラミングを行う

ArduinoからDaisySeedにデータをアップロードするには、まずSTのProgrammerをインストールしなければならない。　



STのサイトからDLしたファイルを解凍し、右クリックでパッケージを開いて





Terminalでコマンドを叩き、



インストーラを起動する。



プログラマーのインストールを完了した後に、手順通りボードに delay(); を使ったLチカのスケッチをアップロードしたところ、アップロード自体は出来るものの、再起動後のボード上でプログラムエラーが発生、LEDは発光せず沈黙したままだった。

次に delay(); を使用せずに milles(); で点滅を制御するスケッチをアップロードしたところ、これもボード側でエラーが発生して正常な動作が行われない。　もしかすると、コンパイルの設定が問題と考えて、設定を SmallestCode から Fastest に変えて再コンパイルを行ったところ、IDEでボード側のエラーが検知されるものの、とりあえずLチカは達成出来た。



いまのところ不具合の原因を確定できないが、delay(); の実装が行われていない雰囲気もあって、挙動はかなり怪しい。

CubeMXの導入について

なかなか導入ができなかったCubeMXがやっとインストールできたので、備忘録を残す。

このソフトウエアはJavaが必須なので、事前にこれをインストールしなければならない。
既にインストール済の場合はSystemPreferencesに項目が存在するので、それをクリックしてまずはアップデートを行う。



が、Javaを最新版に更新した後に、インストーラをクリックしても全く受け付けられない場合が報告されていて自分も同じ状況にハマってしまった。　仕方がないのでForumのスレッドを検索して調べると、Terminalを使った対処法が紹介されていたのだが、これも上手く行かない。



で、賢い人が、そもそもJDKをインストールしなきゃダメなんじゃないの？と書いていて、、、



早速これをインストールしたのだが、アイコンをクリックしても無反応な状況は変わらない。



もしやと思って、コンテンツを開示してフォルダ内のリンクをクリックしたところ、アプリケーションが認識されてインストールが始まった。



IDEを起動してまず行うことは、使用するチップの選択で、プロジェクトを生成するとチップのフットプリントが現れる。



チップをドライヴするクロックの設定は別のタブを開いて行う。



列挙された機能を選択して、ピンの割振りと昨日の設定を行うのだが、これが上手くいかない。



何故かピンのコンフリクトが発生するのだが、これはハードウエアの制限なのだろう。あと、GPIOのコンフィギュレーションが行えず、どうやってもpinを入力端子に設定することが出来ない。



作業がスタック気味になってきたので、以前導入にトライしたものの、CubeMXと同様の不具合が発生したためにインストールを諦めていたMCUExpressの起動を行ったところ、こちらもすんなりと稼働状態に持ち込むことが出来た。



このアプリの操作感はCubeMXよりも良いのだが、コードを吐き出させると無駄にライブラリを参照するクセがあり、回路の検討は行えるものの、実用には至っていない。　

何れにしても自分のスキル不足が問題と思われるが、それにしても、、、である。

DaisySeedについて

KickStarterでPledgeしたオーディオ専用マイコン、DaisySeedがそろそろ届く頃合いなので、前準備を行っている。



まずは、LaVoixskiに対応させることを目指して、搭載されているMCU”STM32H7”のマニュアルを読んでいるのだが、pinのALTを設定する項目になかなか辿り着けない。

Wikiが立ち上がっていたので、サンプルコードを調べてみたところ、現時点ではFrequencyCounterに該当するライブラリが存在していないようだ。　従って、周波数の測定を行うためのカウンタを選択し、独自に設定を行わなければならないが、今回はTeensy4.1と同様により精度が高い32bit幅のTIM2とTIM5の使用を目指すことにした。





GPT=汎用タイマーのトリガ入力は以下のポートに引き出されている。　TIM2/5が32bit幅で、残りの汎用タイマーTIM3/4/12/13/14/15/16/17は16bit。

















対応表によると、複数の端子が該当しているが、



基板の回路図を見ると、D22とD25をALT1/2に変更することでカウンタのトリガ入力をアサインできるようだ。



黄色がTIM2_CH1／青がTIM5_CH1の入力端子で、何れもカウンタの幅は32bit。

赤紫のポートは個別に使用が可能なTIM12/13/14/15/16/17、緑のポートはTIM3_CH1/CH2とTIM4_CH1/CH2。



ALTを設定するコマンドは、GPIO関連の項目にそれらしいものを見つけた。



まず、GPIOの属性を設定するモードでALTに対応させた後、、、



該当するポートのALTの選択を個別に行う。

ボードに設定されているデフォルトの状態が不明だが、まずはALT対応に変更するための正しい記述法を見つけ出さなければならない。

オンボードに24bit幅のオーディオDACが搭載されているので、MixOutにはこれを使用する。残りの1〜2chは外部に出力することになるが、何れにしても信号のバイアスを変更するアナログ仕立てな非線形回路の追加が必須となる。MCUをマウントする基板にはオーディオ回路を追加することになるだろう。

Teensyとの棲み分けは端子の拡張性を考慮して、ADAT出力はTeensy／アナログオーディオはDaisyと出力形態で判断することになるか。

LEDをドライブするPWM出力はGPT12〜17を使用することを想定しているが、信号のアサインが可能な端子は、D9&D10、D11、D12、D13&D14、D16、D18、D19、D29 の計8本（＆は並列ペア）で、LED2個分は確保できそう。　外部オーディオDACとの通信にはSAI2の端子群を使用する。　他にUSER_LED端子が使用可能なので、ラインは合計9本となる。

コンパイルを含めたDaisy上の動作確認が行えていない現段階では机上の空論に過ぎないが、DAC分のコスパの良さでコスト面はDaisyに軍配が上がるので、なんとかシステムの移植を完遂させたいところだ。

追記：

ハードウエアに依存するTimer系の実装が全く行えないだけでなく、avr系のライブラリは全く受け付けられず、Cli();Sei();も使用できないことが判った。

関連するHardwareTimerというClassの存在を確認しているのだが、ボードに該当するH7には対応しておらず、関数も認識されない謎仕様だった。　

自分の技量ではいまのところは全く刃が立ちそうになく、ライブラリが充実するまでLaVoixskiの移植に関してはペンディングとなってしまった。