告知です．
コミケ99にて当社のDDC/DACを頒布いたします．
日付 2021年12月31日（金） 東地区 テ－４０ｂ 東５ホール
サークル名 bangflat
コミケにお越しの際はお立ち寄りいただけますとありがたいです．
商品紹介ページを作りました．
ーーーー
STM32でDCC/DDCを作ろう！ AK4495でDSDを聴こう！ INDEXページへ
今週と来週はチクチクと仕事が入っています．昨日は熱中症で倒れるかと思いました．やたらと蒸し暑い非常階段にいたとき、立ち眩みが激しくてフラフラしました．やばー
戦争中に南方戦線へ送られた兵隊さん達は、気温40度に達しようかという環境で栄養不足で強行軍、しかも雨が降るわ軍靴の中は水虫でしかもマラリアみたいな状況だったわけでしょう．鉄砲一発も撃たずにわたしゃ死んじゃうさ．よわ～
本日はエアコンの効いた部屋でDSD改造をしています．
このブロック図のように改造しなくちゃいけません．data flowがPCM/DSDの２種併存するので改造に手間がかかります．
SPIは、SPI1とSPI3を使うことにしました．なんとSPI2は使えませんでした．USB-HS interface(ULPI)に強制的にアサインされるpinがSPI2と衝突しているからです．SPI3がフリーでよかったですよ．もしもSPI3も別の機能と衝突してたらDSDが実現不可能、デバイス変更を余儀なくされてギャフンと言ってしまうところでした．
------
STM32のI2Cでトラブルが発生しました．
AK4495のPCM/DSD切り替え等のためI2Cバスを使います．AK4495のregisterは10bytesぐらいあって、PLAY開始時にバタバタっと設定します．最初のうちI2Cは正常動作なのだけれど、数回I2C経由でAK4495を設定した後にI2Cが謎のhungup．
I2Cをhard resetしても回復しません．
net情報にも同様のトラブル事例が在り、それらを読むとI2CのSCK/SDAの電圧に着目せよ的なコメントが多いんです．つまり、STM32-AK4495間のhand shakeが不正だとSTM32 I2Cのステートマシンが事故ると言ってる．
ホンマかいな？ hard resetが効かないステートマシンなんかやめてよ、と思いつつ検証．
ですがSCK/SDAに原因があるのは本当だったようです．
当初、SCK/SDAのpull-up抵抗を10kΩにしていましたら、波形がなまっていてヘロヘロでした．（SCK=400kHzにて）
この波形じゃ動くわけないわと、最終的に2kΩにして波形改善したら、I2Cはいつでも正常動作するようになりました．
この波形じゃ動くわけないわと、最終的に2kΩにして波形改善したら、I2Cはいつでも正常動作するようになりました．
あーでも然るべきときにhard resetするようにはしといたけど、気味悪いんで．
------
さらに重箱の隅へ入ります．
32bitモードのとき、１サンプリングに4bytes要するのは明らかです．
24bitモードなら１サンプリングに3bytesを要します．なのでdescriptorにも3bytesと記述するのが正しいと考えられます．でも、descriptorに4bytesと記述してもwin10 UAC2.0 driverで正常に動きます．24bitなのに4bytesとdescriptorに記述した場合には下位byteをゼロ埋めでwin10は送信してくれてるみたいです．
16bitモードなら１サンプリングに2bytesを要します．ところが今までわたしはdescriptorに4bytesと記述していました．その記述ですと、win10 サウンドデバマネに16bitの選択肢が登場しません．
descriptorに2bytesと記述したら下図のとおり16bitも選択肢に登場するようになり正常化しました．
Windowsはsystem messageが淡泊なのでこういう不具合が判らないったらないわ．
descriptorに2bytesと記述したら下図のとおり16bitも選択肢に登場するようになり正常化しました．
Windowsはsystem messageが淡泊なのでこういう不具合が判らないったらないわ．
//----- Audio Streaming Format Type Descriptor 2.0 ------
// bLength : 0x06 (6 bytes)
// bDescriptorType : 0x24 (Audio Interface Descriptor)
// bDescriptorSubtype : 0x02 (Format Type)
// bFormatType : 0x01 (FORMAT_TYPE_I)
// bSubslotSize : 0x03 (3 bytes)
// bBitResolution : 0x18 (24 bits)
かしこ
うちの業界でもI2C結構使ってますが、ホントひどいインターフェースですね。仕様はちゃんと読んでませんが。オフィス環境でもノイズ乗りまくりで、しかもスレーブ側のコントローラーがやたら謎のハングアップをするという。復旧にはクロックラインをポートに設定しておまじないみたいなパルスを入れてやらないといけないです。
返信削除こんな素人が作った様なインターフェースが普及しているのが不思議〜。
事故るステートマシン、ヒェッ
削除自分でlogic書くか、自分でsoft書くか、と今回も何度も思いました．
実際にverilog書いてもそんなに大変じゃないんですけどね．
>SCK/SDAに原因がある
削除これはもう、完全に「ハードの問題」でしょう・・・
※多分クロック1MHz(もっと低くてもダメ？)を超えたら、「クロック/データ分離作戦」は、
破綻しちゃいますよ・・・当たり前のように「隣のビット」を、拾っちゃいそうですｗ
※これならまだ「非同期シリアル」のほうがマシです。
こっちだと、うまくいけば数十メガまでスピード出るし。
>こんな素人が作った様なインターフェース
まぁ、作ったのは「素人」じゃないと（信じたいと）思いますが、こんな、
・差動バスでもなく
・まともなドライバもない（プルアップ？だけ）
ようなインターフェースは、そもそも「プリント基板内の数センチの通信」
（しかも、そんなにスピードは出さない）だったハズが、いつのまにか、
「基板間、しかも高速通信」に使われるようになって、そんなの最初の設計者からすれば、
「想定外」以外の何物でもないんでしょうね・・・
※せめて、RS-485のように「差動オプション」でも有れば良かったのにね。
「RS-485」は、差動でしかも「Ｎ対Ｎ」の、バス型通信もできちゃうという凄い規格です。ドライバの値段が高いのが玉にキズですが。
slaveのAK4495を変なstateで止めてしまうとmasterのstateが事故る....のかしら？
削除なんかもうアホくさくて思考停止の放置プレイで見ないふりでぇす．
SPIはもちっとしっかりしている気がするんですけどね．
SDカードのIFって基本的にSPIだったかしら？？？
RS422はよくお世話になりました。工場現場のノイズ環境で数十mの距離を1Mbpsくらい余裕で通せたので大変助かりました。RS485はついぞ使う機会はありませんでした。
削除I2Cはボード内の通信ならわかりますね。それをハーネス引き廻してランプやモーターのドライブに使いまくっているうちの業界がおかしいのかも。
♪またひとつ、イーサネットが偉く思えてきた♪
削除>ハーネス引き廻してランプやモーターのドライブに使いまくっている
削除凄い使い方をしてますね・・・ 多分、GND入れても「バス構造でも３本線」で済むからなんでしょうが。
（ちなみに RS-485も、線の数は同じで済みます、が、上にも書きましたがドライバが結構高いんだよね・・・）
Wikipediaの項 https://ja.wikipedia.org/wiki/I2C
にもありますが、私がこの規格を最初に知ったのは 1980年代の半ばで、まさに
「フィリップスのＩＣのマニュアル」でした。「２本線(基板内だからGNDは考慮しない)で、バス配線ができるなんてスゲー！」
と思った記憶があります。
※当時、クロックのエッジを巧妙に使ってバスの調停をしてるところは、さすがと思った。
なので、このブログで「I2C」の単語を聞いたときは、
「まだこんな規格生きてたの！？」と思った次第です。
>2004年8月に特許が失効しており (Wikipedia より)
だから、「みんな使うように」なったんでしょうね・・・
（と同時に「粗悪品」も増える運命、の法則）
小さなICにはなにかとI2Cがペタペタと貼られていたりします．datasheetを読んで「あっI2Cだ便利でイイネ」と一応思いはしますがそれも動いてくれればのはなし....
削除ご安全に！
>それも動いてくれればのはなし....
削除前に「Arm CPU」の所でも書きましたが、やはり
「世界で一番、I2Cを使ってる」のは、
「Made in China 謹製のIC」
なんでしょうね・・・・
（そして、「世界で一番、トラブルが多く」なる、の法則）
>descriptorに2bytesと記述したら下図のとおり16bitも選択肢に登場するようになり正常化しました
削除こと「Windows」って、世界でもっとも使われてるＯＳの一つ、の割には、こういう
「Undocumented」な仕様が、いっぱいあるんですよねぇ・・・
※その昔、ズバリ「Undocumented Windows」という本がありました。洋書です。
MSDNというんでしたか、MSにお金を支払ってwindowsの開発者情報をもらう仕組みがあるらしいので、一般user向けのerror logはスカスカに留めているんでしょうねぇ．深い部分はMSDNに加入してないヒトにはさっぱりです．
削除中華様は万が一ARMを使えなくなったらRISC-Vに乗り換えるのでしょう．
削除soft面では、Linuxは長期的に見ればUSのIT覇権を削ぐ結果をもたらすと思います．
いまUSは中華様に対して次の攻撃をmixしています．
１）情報遮断、開発させない
２）生産設備を与えない
３）買わない
１と２は時間が経てばなんらかの方法でキャッチアップできてしまうので、３が究極の手段かな．
日本は「開発させない」で封じ込まれました．
４）相互に市場開放 ←この良き日は来るのでしょうか？
>MSDNというんでしたか、MSにお金を支払ってwindowsの開発者情報をもらう仕組み
削除昔居た会社で、このＭＳＤＮサブスクリプションに加入してましたが、コレも結局、
「ＣＤやＤＶＤが大量に送られてくる」だけで、あまりそういうことは教えてもらえませんです。
（ＵＳ式の「資料送るから、自分で調べてね！」パターン。ただ、メディアの量も半端ないので、メディアの整理だけで、仕事になるくらい。）
※但し、「インシデント」と言って、「ＭＳに直接質問できる（回数制限あり。確か４回くらいだった。それ以上は有償）」仕組みがあって、
「どうしてもわからない時」は、直接質問できました。
これは勿論日本語で出来るのですが「込み入った質問」になると、
「ＵＳ本社に問合わせ中です」といって、なかなか返事がない時もあったりします。
※ちなみに、これは割と昔の話で、現在では基本的にはＭＳＤＮの内容は大半Ｗｅｂに公開されてるので、「調べる気になれば」調べられます。
（ただし、検索キーワードにたどり着くまでが大変。思いもよらないところに、答えが書いてあったりします。）
※多分、上の「descriptorに2bytesと記述・・・」も、どこかにあるんじゃないかな。ただし「これをそのまま」検索しても出てこないと思いますが。
（サンプルに「解説抜き」であったりとか。まぁ、ある意味で「Undocumented」ではある）
ＭＳも、昔と違って自社製品に「オープンソースプロダクト」を取り入れたりしてるので（VisualStudioも、あるバージョンからGitに標準対応してるとか）
「契約者のみに情報公開」は、特許絡みでもない限りないと思いますよ。
>中華様は万が一ARMを使えなくなったらRISC-Vに乗り換えるのでしょう
削除もう、その兆候は出てますね。「中華ＡＲＭ全盛期」は、とっくに過ぎてる感じ。
（多分、３，４年前の「中華タブレット」の頃がピークかも？）
※RISC-Vも、「使われてナンボ」なので、願ったり叶ったりですね。
元々が、ＧＮＵじゃないけど「命令セットが自由にできない」ところから来てるんで。つか、ARM IP の「金払っても、命令セットを弄れない」って、何なんでしょうね・・・
>Linuxは長期的に見ればUSのIT覇権を削ぐ結果
削除まぁ、「ＡＲＭにしろＬｉｎｕｘにしろ」発祥がＵＳじゃないですからね・・・
※ある意味ＵＳは「美味しいところを吸ってた」だけかもしれない。
真の「ＵＳ発祥」のメーカは、「Intel」と「Microsoft」くらいです。
※ちょっと前まで、この２社は「Wintel」といわれて「我が世の春」を謳歌してましたが、
パソコンがスマホになったとたんに、２社とも凋落しつつあります。
ここで、ＥＵ発祥の「ＡＲＭ」と「Ｌｉｎｕｘ」に、地位を奪われつつあります。
※スマホのＯＳ「Android」は、カーネルはLinuxそのものなので、「Linuxの一種」です。
そうなんですよね．
削除wintelはいつまで君臨していられるのでしょう？
大型乗用車だけしか作れないUS三大自動車メーカーとwintelが似て見えます．
小型車を器用に作る日系自動車メーカーと中華SOC屋が似て見えます．
ま、情報遮断、製造装置遮断、買わない、は戦争中なら通用しますけど、戦争が終わったらいずれ中華様に追いつかれるように思います．かつての日本のように．
だとするとMSDN情報はわたしも既に目にしている筈ですね。英文和訳調なMSのページは何度も見てます。役立った事はあまり無いですけど。
削除一つ気になったのですが、LRクロック生成するときに別のチップ通してますがi2s＿wsって名前のピンなかったでしょうか？それがLRクロック出てるはずなんですが
返信削除言われてみてdatasheetを確認したところ、いまわたしが開発中の使い方であれば外付けロジックは不要で、STM32から出て来るLRCKを使えるかもしれないと考えを改めました．
削除いままでわたしがSTM32 I2Sが出すLRCKを使えないと断定していた理由はこの一文です．
The devices embed a dedicate PLL (PLLI2S) that allow them to achieve audio class performance. In this case, the I2S master clock can generate all standard sampling frequencies from 8 kHz to 192 kHz.
この文はI2Sは最高で192kHzだという結論になっています．
しかしこの文の正確な表現は、内蔵clk genを使うのであれば192kHz maxだと言ってます．
現在開発中の使い方では外部bitclkをI2Sへ入力するのですから、上の文の192kHzには制限されない．そのように理解を改めました．
したがってLRCKの外付けlogicは不要になる可能性が高いです．
とはいえ、master clock生成のためのFPGA/CPLDはどのみち必要ですから、部品数は減りません．verilog codeの削減は可能．
削除再度訂正、これが最終回答です．
削除STM32F205を使う限り、ここで開発中の仕様には内蔵I2Sをそもそも使えません．なのでSTM32が出すLRCKも使えません．
事情：
STM32のI2SはSPIのサブ機能です．
STM32F205には３つのSPIと２つのI2Sがあります．
SPI1 I2Sなし 高速 32bit384kHzでつかえるのはSPI1だがSPI1にはI2Sがない
SPI2 I2S2 低速 32bit192KHzがmax
SPI3 I2S3 低速 32bit192kHzがmax
LRCKを使わなかったというよりもI2Sを使ってないんです．ざんねん．
32bit 384kHzを目標仕様としています．
削除設定見ている感じだとマスタークロックを外部から入力したら行けそうな気がするんですが私もまだよくわかっていません。取り敢えず色々試してる状態です。
削除とりあえず設定で入力できる設定があるって言うのはほぼ確定だと思います。i2sの設定もあっちこっち散らばっているのでマイコンによるというかんじですが、私が使おうとしているマイコンにはその機能があるようです。
削除STM32F205ではAPBの最高clockに制限されるとSPI仕様のどこかに書いてあります．
削除APB clockはCPUによりけりですので、高速CPUなら限界突破できるかもしれません．
ちなみにCPU clockは、205=120MHz、405=168MHzですので、もっと速い品種もあると思います．
STM32CubeMXの画面では、外部clk入力は「Slave TX」などの名称で登場するようです．
削除レジスタ仕様はあまり読み込んでません．