SmileSoundで音の処理が重いのでFor文減らして軽くした。 [ds-DCCデコーダ]
さて、今月は、上旬に腰を痛めて会社休んだり、中旬に家族がコロナに罹って、そこから、家族感染が広がって（私にはうつらなかったが）、3連休は休日夜間診療所に行ったりして終わり、会社はリモートで空気読めずに苦労するし、で、今日から夏休みのはずなんだが、仕事の進みがグダグダで、休み期間中に数日、休出をしないといけないというかんじで、なんか、微妙な夏です。
まあ、ここ数年は、振り返っても、去年は確かコロナが広がっているのに、広がっていないことにされてオリンピックはするが、外に出るなと言われていたような気がするし、一昨年は恐怖の致死率を誇るコロナ蔓延のせいで夏休みもほぼ家にいた気がするので、ここ数年、ぐだぐだが続いていて今年だけではないような気もします。
で、本題です。DesktopStationさん中心に作っているデコーダーで（名前はSmileSoundで決まりなのか？）音部分を作っていました。
音部分というのは、フラッシュから音データをとってきて、それをWAVの出力に向け、12音分足し算するという計算のため、For文(計算ループ）の嵐です。
12音分の音のスピードの変換や音量の変換などもあり、現状の計算では、4096データ（44.1kHzで90.6[ms]（・・・92.9msが正しそうだが、どっか間違えたか？)）分の計算するのに、37.2[ms]かかっていて、約40％も音の波形計算に取っています。また音を出していないときも無音を12音分計算しているため、約4%消費します。（ただし、この値はコンパイルの最適化をしていない場合です）
デコーダが結構熱くなるようですが、デコーダ面積も小さく模型の中に入れるため、放熱を考えると、処理を軽くしたいとのことで、無音の時は計算を省いてくださいとの指令がきましたので、作りました。
結果としては以下のグラフのようになっています。
”現状１２音”が今のサウンドエンジン部分で、横軸が同時発音数なので、無音状態（０）で21.6[ms]、8音同時再生で37.2[ms]です。
そして、今回作った"for削減_12音”では、無音状態では0.8[ms]、8音同時再生で、30[ms]となっており、感動的に処理を減らしています。（いや、いままでどんだけ無駄な計算しているんだ？という話はありますが）
つまり誇大広告的に言うと、アルゴリズムなどの革新的な工夫により、スタンバイ状態の電力消費は当社従来比９６％改善となります。
あと、まあ、音をいっぱい出すと、発熱は今までと変わりません。なぜなら、発音時のアルゴリズムは変わっていないからです。つまり、走行音出しながら、フランジ音と、ジョイント音と、コンプレッサー音を出しながら、警笛を鳴らしたりすると、そういう時は熱くなると思います。
デコーダを床下に床下機器もどきで付けて床下機器をダイキャストでヒートシンク的に使えれば、いい感じに冷えると思いますが、そういうのは難しいですかね。
でも、３Dプリント用の金属フィラメントなかったっけ？
なお、まだ、その部分を作っただけで、デコーダのスケッチには組み込まれていないので、ちゃんと動くか確認できていません・・・。
まあ、ここ数年は、振り返っても、去年は確かコロナが広がっているのに、広がっていないことにされてオリンピックはするが、外に出るなと言われていたような気がするし、一昨年は恐怖の致死率を誇るコロナ蔓延のせいで夏休みもほぼ家にいた気がするので、ここ数年、ぐだぐだが続いていて今年だけではないような気もします。
で、本題です。DesktopStationさん中心に作っているデコーダーで（名前はSmileSoundで決まりなのか？）音部分を作っていました。
音部分というのは、フラッシュから音データをとってきて、それをWAVの出力に向け、12音分足し算するという計算のため、For文(計算ループ）の嵐です。
12音分の音のスピードの変換や音量の変換などもあり、現状の計算では、4096データ（44.1kHzで90.6[ms]（・・・92.9msが正しそうだが、どっか間違えたか？)）分の計算するのに、37.2[ms]かかっていて、約40％も音の波形計算に取っています。また音を出していないときも無音を12音分計算しているため、約4%消費します。（ただし、この値はコンパイルの最適化をしていない場合です）
デコーダが結構熱くなるようですが、デコーダ面積も小さく模型の中に入れるため、放熱を考えると、処理を軽くしたいとのことで、無音の時は計算を省いてくださいとの指令がきましたので、作りました。
結果としては以下のグラフのようになっています。
”現状１２音”が今のサウンドエンジン部分で、横軸が同時発音数なので、無音状態（０）で21.6[ms]、8音同時再生で37.2[ms]です。
そして、今回作った"for削減_12音”では、無音状態では0.8[ms]、8音同時再生で、30[ms]となっており、感動的に処理を減らしています。（いや、いままでどんだけ無駄な計算しているんだ？という話はありますが）
つまり誇大広告的に言うと、アルゴリズムなどの革新的な工夫により、スタンバイ状態の電力消費は当社従来比９６％改善となります。
あと、まあ、音をいっぱい出すと、発熱は今までと変わりません。なぜなら、発音時のアルゴリズムは変わっていないからです。つまり、走行音出しながら、フランジ音と、ジョイント音と、コンプレッサー音を出しながら、警笛を鳴らしたりすると、そういう時は熱くなると思います。
デコーダを床下に床下機器もどきで付けて床下機器をダイキャストでヒートシンク的に使えれば、いい感じに冷えると思いますが、そういうのは難しいですかね。
でも、３Dプリント用の金属フィラメントなかったっけ？
なお、まだ、その部分を作っただけで、デコーダのスケッチには組み込まれていないので、ちゃんと動くか確認できていません・・・。
2022-07-30 19:01
コメント(0)
RP2040で音の実験、SDカードから （補足） [DCCデコーダ]
音を１音増やすと１５msかかるのはちょっと遅いと思うので、
（１）SDカードの呼び出しでSPIクロックはどれくらいに設定しているか？
（２）SDカード呼び出しにDMAは使っているか？
という質問があったので、書いておきます。
と言いつつ、（２）についてはわかりません。
SPIクロックですが、多分、
SD.begin(SS,SD_SCK_MHZ(32));
のSD_SCK_MHZ(32)で、
ファイルを開いて、4KByteずつ８回Readして閉じる作業をクロックを変えながらやってみました。
結果は以下の通りだったので、なんとなく32MHzを選択しています。24MHzから75msだったので、内部では24MHzが選択されているのではないかと思います。
ファイルオープン＋(4kByte*8回=)32KByteのリード＋ファイルクローズで75msなので、いわゆる読み込みスピードとは少し異なると思いますが、427KByte/s程度と遅そうではあります。
なお、SDカードは、見かけからすると、ADATAの16GBで80MByte/sらしいです。
PicoのSDのスピードを測っている参考サイト
https://elehobica.blogspot.com/2021/03/raspberry-pi-picosdxcexfat-spi-if.html
https://community.element14.com/products/raspberry-pi/b/blog/posts/rp2040-sd-card-spi-benchmark
（１）SDカードの呼び出しでSPIクロックはどれくらいに設定しているか？
（２）SDカード呼び出しにDMAは使っているか？
という質問があったので、書いておきます。
と言いつつ、（２）についてはわかりません。
SPIクロックですが、多分、
SD.begin(SS,SD_SCK_MHZ(32));
のSD_SCK_MHZ(32)で、
ファイルを開いて、4KByteずつ８回Readして閉じる作業をクロックを変えながらやってみました。
結果は以下の通りだったので、なんとなく32MHzを選択しています。24MHzから75msだったので、内部では24MHzが選択されているのではないかと思います。
| MHz | ms |
| 1 | 343 |
| 2 | 205 |
| 4 | 133 |
| 8 | 99 |
| 16 | 85 |
| 24 | 75 |
| 32 | 75 |
| 48 | 75 |
ファイルオープン＋(4kByte*8回=)32KByteのリード＋ファイルクローズで75msなので、いわゆる読み込みスピードとは少し異なると思いますが、427KByte/s程度と遅そうではあります。
なお、SDカードは、見かけからすると、ADATAの16GBで80MByte/sらしいです。
PicoのSDのスピードを測っている参考サイト
https://elehobica.blogspot.com/2021/03/raspberry-pi-picosdxcexfat-spi-if.html
https://community.element14.com/products/raspberry-pi/b/blog/posts/rp2040-sd-card-spi-benchmark
2022-06-18 20:56
コメント(0)
RP2040で音の実験、SDカードから鳴らす。 [DCCデコーダ]
４か月ぶりですね。
仕事がいまいちで、趣味が進みませんが、メモだけ書いておきます。
Desktopstation様とＤＣＣ電子工作連合でＲＰ２０４０を使ったDCCデコーダ（SmileSound)を作っていますが、ＳＤカードの抜き差しで電車の音を変えられる据え置き型コントローラを作りたい！という話があり、ＳＤカード（内蔵のＦｌａｓｈに比べ遅い）でどれだけ、ダメになるかを試してみました。
ソースの方は現在使っているLittleFSをＳＤに変える感じで、あとはほぼ一緒です。
LittleFS.h
→SPI.h,SD.h
LittleFS.begin();
→SD.begin(SS,SD_SCK_MHZ(32));
SCKは上げて処理が速くなるようにしています。
f = LittleFS.open(inFile, "r");
→f = SD.open(inFile, "r");
という感じに機械的に変更すれば、とりあえず動きます。
pinはSPI０のデフォルトを使います。（変更方法がわからなかった・・・。）
#define PIN_SPI0_MISO (16u)
#define PIN_SPI0_MOSI (19u)
#define PIN_SPI0_SCK (18u)
#define PIN_SPI0_SS (17u)
で、それ用に適当に配線して、こんな感じです。
まあ、全体ではこんな感じで、
秋月のマイクロSDカードスロットDIP化キットを使用して、SD部分は下記のように繋ぎました。
で、元々音の処理は85ms周期で音の処理をしていますが、無音状態で15msぐらいかかります。一音増やすごとに15ms程度処理時間が増えるため、同時に4～5音出すのがやっとでした・・・。
44.1kHzで、1音当たり、音の処理に10ms、ファイルのヘッダ呼び出しに５msかかっています。
ハマったところは、最初、SDカードのファイル一覧は見れるが、中身が化けてて変というのがあり、一度、スケッチからファイルを書いたら、読めるようになりました。それとも最初にちゃんとFAT３２でフォーマットしないといけないかもですが。
まあ、最終手段で、SDカード挿した後、内蔵のフラッシュに全部コピーして、それから動かすとやれば、SDの遅い呪縛から逃れられるというのはあります。
仕事がいまいちで、趣味が進みませんが、メモだけ書いておきます。
Desktopstation様とＤＣＣ電子工作連合でＲＰ２０４０を使ったDCCデコーダ（SmileSound)を作っていますが、ＳＤカードの抜き差しで電車の音を変えられる据え置き型コントローラを作りたい！という話があり、ＳＤカード（内蔵のＦｌａｓｈに比べ遅い）でどれだけ、ダメになるかを試してみました。
ソースの方は現在使っているLittleFSをＳＤに変える感じで、あとはほぼ一緒です。
LittleFS.h
→SPI.h,SD.h
LittleFS.begin();
→SD.begin(SS,SD_SCK_MHZ(32));
SCKは上げて処理が速くなるようにしています。
f = LittleFS.open(inFile, "r");
→f = SD.open(inFile, "r");
という感じに機械的に変更すれば、とりあえず動きます。
pinはSPI０のデフォルトを使います。（変更方法がわからなかった・・・。）
#define PIN_SPI0_MISO (16u)
#define PIN_SPI0_MOSI (19u)
#define PIN_SPI0_SCK (18u)
#define PIN_SPI0_SS (17u)
で、それ用に適当に配線して、こんな感じです。
まあ、全体ではこんな感じで、
秋月のマイクロSDカードスロットDIP化キットを使用して、SD部分は下記のように繋ぎました。
で、元々音の処理は85ms周期で音の処理をしていますが、無音状態で15msぐらいかかります。一音増やすごとに15ms程度処理時間が増えるため、同時に4～5音出すのがやっとでした・・・。
44.1kHzで、1音当たり、音の処理に10ms、ファイルのヘッダ呼び出しに５msかかっています。
ハマったところは、最初、SDカードのファイル一覧は見れるが、中身が化けてて変というのがあり、一度、スケッチからファイルを書いたら、読めるようになりました。それとも最初にちゃんとFAT３２でフォーマットしないといけないかもですが。
まあ、最終手段で、SDカード挿した後、内蔵のフラッシュに全部コピーして、それから動かすとやれば、SDの遅い呪縛から逃れられるというのはあります。
2022-06-18 17:40
コメント(0)
RP2040で音の再生実験 その４ [ds-DCCデコーダ]
さて、木曜日は大雪の予報だったので、会社に行くのはやめて在宅勤務していましたが、なんか、一日中ほぼ雨でした。今日の夜から月曜の朝にかけても大雪になるかも！と言っていますが、一度外れると次は全く信じないのが経験則中心に生きている私の心、です。
で、RP2040を使ったDCCデコーダですが、ソースをオープンにしないということに決まりましたので、やったことだけ書きます。まあ、ネットの情報を組み合わせて作っていますし、そのうち音関連の部分だけ切り出して公開しましょうか？
で、RP2040のDCC用の実験ボードはいただいたのですが、音の部分については追加をたくさんしなければいけない状態ですので、問題が起きた時にどのモジュールなのか切り分けが全くできなくなるため、音部分だけ動かすモジュールを作って、ブレッドボードでデバッグをしています。
こんな感じです。RP2040 Nanoを一瞬使いましたが、ちょっとした実験には、Flash容量の少ないRaspPi Pico（＋リセットスイッチ改造してるもの）の方が使い勝手が良いので、そっちでやっていきます。
音の再生速度＝再生周波数の倍率を変更できるようにしました。せっかくなので、RP2040のinterpolator機能を使っています。この頃Googleの翻訳機能が優秀でDataSheetなんかのPDFも翻訳できるので（ページ数が多いと断られるので、必要な部分だけ抜き出しますが）、とても、楽です。
で、動画です。
「扉が閉まります」「ご注意ください」をリピートで聞き続けて、気が狂いそうです・・・。
で、RP2040を使ったDCCデコーダですが、ソースをオープンにしないということに決まりましたので、やったことだけ書きます。まあ、ネットの情報を組み合わせて作っていますし、そのうち音関連の部分だけ切り出して公開しましょうか？
で、RP2040のDCC用の実験ボードはいただいたのですが、音の部分については追加をたくさんしなければいけない状態ですので、問題が起きた時にどのモジュールなのか切り分けが全くできなくなるため、音部分だけ動かすモジュールを作って、ブレッドボードでデバッグをしています。
こんな感じです。RP2040 Nanoを一瞬使いましたが、ちょっとした実験には、Flash容量の少ないRaspPi Pico（＋リセットスイッチ改造してるもの）の方が使い勝手が良いので、そっちでやっていきます。
音の再生速度＝再生周波数の倍率を変更できるようにしました。せっかくなので、RP2040のinterpolator機能を使っています。この頃Googleの翻訳機能が優秀でDataSheetなんかのPDFも翻訳できるので（ページ数が多いと断られるので、必要な部分だけ抜き出しますが）、とても、楽です。
で、動画です。
「扉が閉まります」「ご注意ください」をリピートで聞き続けて、気が狂いそうです・・・。
2022-02-13 14:46
コメント(0)
モノレールとか、ライブの席ガチャの話。 [その他]
RP2040の実験は進んでいますが、リピート再生するとか、フローにするとかの段で、音のところにこんなバグがあるから直してみたいなところをこまごまとやっているので、ソースとしてお見せするものはありません。
Nagodenさんから、RP2040用のデコーダ開発ボードが届きましたので、ブレッドボードは卒業して、そっちで開発をやっていこうと思います。
と、これは今回の本題ではなく、今日は声優のライブに行っていました。ZeppHanedaでやっていたのですが、浜松町からモノレールで行きました。神奈川県民になってから、羽田空港へは、京急や高速バス、車なんかで行っていたので、なんか、乗るのは20年ぶりぐらいでしょうか？
モノレールの軌条は古びていましたが、車両の速度計とかが液晶で新しいことに驚きました。
そして、オミクロン株のせいでとても空いていて、並ばずに運転席後ろに陣取れました。
で、ZeppHanedaから羽田空港の端の方を見ると、なんか飛行機がたくさん止まっていました。航空会社大変そうと思いました。
SelectionProjectというアニメのライブを見ていました。メインの楽曲の音域が広くてよいし、物語も面白かったので、見に行くことにしました。
さて、で本題です。ライブの席です。
コロナ禍になってから、立ち見ライブがなくなり、基本的に席があるようになりました。
ライブの席は抽選ですが、自分の席が悪いと、なんか、関係者はいいところに座っているとか、ファンクラブの偉い人だと前にいるんじゃないかとか、なんか思ってしまっていました。
どうなのかを確認すべく、ファンクラブに入っているもの、入っていないものも含めて、一昨年９月からから今年の１月まで、行った１１件のライブについて、会場を正規化（縦方向は1階、2階、3階で連続して数えて正規化。一番前を1列目とする。横方向は座った列で左から正規化）したときにどういう風に偏っているかを見てみました。縦も横も正規化後の値が０．５になると、真っ当に抽選されているのねと考えられます。
で結果は以下の通り。
縦は0.49で、1階、2階、3階を連続で考えた時に、ほぼ前後の真ん中が当たっている。横方向は0.44で、中央より少し左側が当たる傾向があったとなりました。
席ガチャとして、損していないこと（当たっているのがいつも後ろの方じゃないこと）がわかって私は満足でした。
それでは。
Nagodenさんから、RP2040用のデコーダ開発ボードが届きましたので、ブレッドボードは卒業して、そっちで開発をやっていこうと思います。
と、これは今回の本題ではなく、今日は声優のライブに行っていました。ZeppHanedaでやっていたのですが、浜松町からモノレールで行きました。神奈川県民になってから、羽田空港へは、京急や高速バス、車なんかで行っていたので、なんか、乗るのは20年ぶりぐらいでしょうか？
モノレールの軌条は古びていましたが、車両の速度計とかが液晶で新しいことに驚きました。
そして、オミクロン株のせいでとても空いていて、並ばずに運転席後ろに陣取れました。
で、ZeppHanedaから羽田空港の端の方を見ると、なんか飛行機がたくさん止まっていました。航空会社大変そうと思いました。
SelectionProjectというアニメのライブを見ていました。メインの楽曲の音域が広くてよいし、物語も面白かったので、見に行くことにしました。
さて、で本題です。ライブの席です。
コロナ禍になってから、立ち見ライブがなくなり、基本的に席があるようになりました。
ライブの席は抽選ですが、自分の席が悪いと、なんか、関係者はいいところに座っているとか、ファンクラブの偉い人だと前にいるんじゃないかとか、なんか思ってしまっていました。
どうなのかを確認すべく、ファンクラブに入っているもの、入っていないものも含めて、一昨年９月からから今年の１月まで、行った１１件のライブについて、会場を正規化（縦方向は1階、2階、3階で連続して数えて正規化。一番前を1列目とする。横方向は座った列で左から正規化）したときにどういう風に偏っているかを見てみました。縦も横も正規化後の値が０．５になると、真っ当に抽選されているのねと考えられます。
で結果は以下の通り。
縦は0.49で、1階、2階、3階を連続で考えた時に、ほぼ前後の真ん中が当たっている。横方向は0.44で、中央より少し左側が当たる傾向があったとなりました。
席ガチャとして、損していないこと（当たっているのがいつも後ろの方じゃないこと）がわかって私は満足でした。
それでは。
2022-01-30 22:21
コメント(0)
RP2040で音の再生実験 その３ [DCCデコーダ]
気づいたら、１月も半分が終わっていますね。昨日はトンガの噴火が原因で、携帯から津波注意報が何回も流れていたようですが、私は気づきませんでした。理由は、ハーゲンダッツのラムレーズンを半分食べたのですが、アルコールがきつすぎて、寝込んでいたせいです。
さて、RP2040での音の再生実験ですが、細々と続けています。（時間はすごいかかっています）
動画として見せられるようなものはありませんが・・・。
やることは、
（１）PWMレジスタにDMA伝送する機能の追加。
（２）DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）
（３）LittleFSでのサウンドデータアクセス
でしたが、もちろん全然できていません。
前回、（３）をやってみたものの、LittleFSでデータアクセスすると、処理量が増えるためか、同時発音が増えるとともに、音が揺れて遅くなるという現象があり、オシロで見ていてもPWM変更の割込みがずれまくります。
で、原因はタイマーでした。
https://github.com/khoih-prog/RPI_PICO_TimerInterrupt
を使っていたのですが、もしかしたら使い方が悪いだけかもですが、割込みの呼ばれ方が、割込み処理が終了したら、XX us後にまた割込みが入るというもののようで、いろいろと処理が立て込んでくると、音用のサンプリングクロックが遅くなっていたようでした。
調べていったら、もともとpico SDKにある、repeating_timerで十分で、
https://qiita.com/keyyum/items/3ce448c098c546dced20
に、わかりやすく書いてありましたが、-の値を入れると設定したタイマー周期で呼び出してくれることがわかりました。音も揺れなくなったし、コンパイルのWarningも出なくなったし、早速乗り換えました。
https://raspberrypi.github.io/pico-sdk-doxygen/group__repeating__timer.html
メモですが、デバッグしているときに、割込みに時間がどのくらいかかるのかというので、Arduino標準のdigitalWriteを使ってPinに出力を出してオシロで見ていたのですが、RP2040には、gpio_putという高速な命令があります。
一回の時間を計ってみたら、
digitalwrite：672ns
gpio_put：39ns
と17倍速いです。
というかDigitalWriteを使うと、割込みの時間を計っているつもりがdigitalWriteの時間を計っているような状態になっていました・・・。割込み内の処理（PWMの切り替えとBuffferの切り替え）は
500ns~600nsぐらいで、なんか工夫しないでも十分速いです。
次に、音のRepeatの話です。Esuと同様のものを目指すなら、音が終了した後に継ぎ目なく、次の音を入れないといけませんが、そこをBufferでとなると、配列のどこからどう入れるかというので、音の継ぎ目が・・・と試行錯誤しながらできました。順序回路で作り直しました。４４KHｚでも、サイン波のなかに、1個だけ唐突に０とかが入っていると、継ぎ目音として聞こえます。
ということで、現在、の出来は、
・100ms周期程度のバッファ（Ach,Bchの2ch)
・モノラル同時8音の発声
・44kHz 8bit（DAC（PWMだけど)を10bitとしているので、元音は8bitでよいのかなあと思っている。44kHzなら125MHzなので、11bitぐらいまでなら可能。I2S使うなら16bitも可能かと思うけど）
・同じファイル／違うファイルで継ぎ目のない、継ぎ目再生
が可能となりました。
次は、
・フローファイルに基づいて、音をだす（警笛のStart,Repeat,Endみたいなところ）
・各音のボリューム機能（ interp機能でとても速くできそう。）
https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__interp.html
・音階を変える機能（できると、疑似音の和音での遷移ができるが、必要かどうかは不明）
・べた書きしたもののクラス化。
あたりです。
今回のスケッチになります。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test2_752_31.zip
なお、前回までA0ピンにPWMを出していたのですが、デバッグ中の不注意で１２Vを入れてしまい、A0~A３が死んでしまいましたので、現在D4に出しています・・・。
あと、Core1で実行すると、グダグダになります。（割込みとかも守られないし、それに合わせて音もとぎれとぎれ、・・・。なぜでしょう。）
（１）、（２）のDMA関係はArduinoでのPIOのコンパイル環境がまだなさそうですので、誰かが作ってくれてからにしようかなあと思います。
さて、RP2040での音の再生実験ですが、細々と続けています。（時間はすごいかかっています）
動画として見せられるようなものはありませんが・・・。
やることは、
（１）PWMレジスタにDMA伝送する機能の追加。
（２）DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）
（３）LittleFSでのサウンドデータアクセス
でしたが、もちろん全然できていません。
前回、（３）をやってみたものの、LittleFSでデータアクセスすると、処理量が増えるためか、同時発音が増えるとともに、音が揺れて遅くなるという現象があり、オシロで見ていてもPWM変更の割込みがずれまくります。
で、原因はタイマーでした。
https://github.com/khoih-prog/RPI_PICO_TimerInterrupt
を使っていたのですが、もしかしたら使い方が悪いだけかもですが、割込みの呼ばれ方が、割込み処理が終了したら、XX us後にまた割込みが入るというもののようで、いろいろと処理が立て込んでくると、音用のサンプリングクロックが遅くなっていたようでした。
調べていったら、もともとpico SDKにある、repeating_timerで十分で、
https://qiita.com/keyyum/items/3ce448c098c546dced20
に、わかりやすく書いてありましたが、-の値を入れると設定したタイマー周期で呼び出してくれることがわかりました。音も揺れなくなったし、コンパイルのWarningも出なくなったし、早速乗り換えました。
https://raspberrypi.github.io/pico-sdk-doxygen/group__repeating__timer.html
メモですが、デバッグしているときに、割込みに時間がどのくらいかかるのかというので、Arduino標準のdigitalWriteを使ってPinに出力を出してオシロで見ていたのですが、RP2040には、gpio_putという高速な命令があります。
一回の時間を計ってみたら、
digitalwrite：672ns
gpio_put：39ns
と17倍速いです。
というかDigitalWriteを使うと、割込みの時間を計っているつもりがdigitalWriteの時間を計っているような状態になっていました・・・。割込み内の処理（PWMの切り替えとBuffferの切り替え）は
500ns~600nsぐらいで、なんか工夫しないでも十分速いです。
次に、音のRepeatの話です。Esuと同様のものを目指すなら、音が終了した後に継ぎ目なく、次の音を入れないといけませんが、そこをBufferでとなると、配列のどこからどう入れるかというので、音の継ぎ目が・・・と試行錯誤しながらできました。順序回路で作り直しました。４４KHｚでも、サイン波のなかに、1個だけ唐突に０とかが入っていると、継ぎ目音として聞こえます。
ということで、現在、の出来は、
・100ms周期程度のバッファ（Ach,Bchの2ch)
・モノラル同時8音の発声
・44kHz 8bit（DAC（PWMだけど)を10bitとしているので、元音は8bitでよいのかなあと思っている。44kHzなら125MHzなので、11bitぐらいまでなら可能。I2S使うなら16bitも可能かと思うけど）
・同じファイル／違うファイルで継ぎ目のない、継ぎ目再生
が可能となりました。
次は、
・フローファイルに基づいて、音をだす（警笛のStart,Repeat,Endみたいなところ）
・各音のボリューム機能（ interp機能でとても速くできそう。）
https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__interp.html
・音階を変える機能（できると、疑似音の和音での遷移ができるが、必要かどうかは不明）
・べた書きしたもののクラス化。
あたりです。
今回のスケッチになります。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test2_752_31.zip
なお、前回までA0ピンにPWMを出していたのですが、デバッグ中の不注意で１２Vを入れてしまい、A0~A３が死んでしまいましたので、現在D4に出しています・・・。
あと、Core1で実行すると、グダグダになります。（割込みとかも守られないし、それに合わせて音もとぎれとぎれ、・・・。なぜでしょう。）
（１）、（２）のDMA関係はArduinoでのPIOのコンパイル環境がまだなさそうですので、誰かが作ってくれてからにしようかなあと思います。
2022-01-16 17:30
コメント(0)
RP2040で音の再生実験 その２ [DCCデコーダ]
今日は箱根駅伝でした。沿道での感染はお控えくださいと主催者が案内していたような気がするので、見に行きませんでしたが、テレビで見ると、観戦者がいっぱいですね。まあ、オミクロン株って重症化しないようですし、リスクは低いってことですかね。
で、本題ですが、年末に、やあさんさんから、以下のメールが・・・。面倒なので、ほぼ原文を書いてしまいますが、
ーーーーーーーーーーー
RP2040となり機能が増えているので、以下の２つの対応を順次、やっていければと思ってます。
【DMA伝送】
（１）PWMレジスタにDMA伝送する機能の追加。
（２）DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）
→割込みごとにPWMを書いているとCPUが食われるので、それを自動化する。DMA化することで同時発音数をさらに増やせるのではと。
あとのちのちのサウンドシーケンス（LokProgrammerのブロック図の状態遷移の実行）を実装するには必須になります。
【ファイルシステム対応】
（３）LittleFSでのサウンドデータアクセス
（４）LittleFSのファイルシステムに置くバイナリデータの作成ツールDSwav2の修正、バイナリ出力機能の追加（やあさんさんの仕事です）
ーーーーーーーーーーー
で、音声ファイルを１６MByteも入れられる、Nano RP2040も送っていただいたので、さっそく実験です。
（１）は難しいので、（３）、（２）の順に進めています。
まず、（３）「LittleFSでのサウンドデータアクセス」ですが、1音だと、事前にファイルをオープンして、割込み中にファイルアクセスしてもとりあえずは音が出ましたが、複数音だと、うまくできませんでした。ということで、LittleFSを使ってのファイルアクセスはできましたが、現状のPWM割込み部分にすべて詰め込もうとすると、全然ダメです。
次に（２）「DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）」ですが、最初リングバッファ作って・・・と半日ほど考えましたが、なんか良い案が思いつかずに眠気だけが出てきてたので、それはやめて、字面通りの方法をとることにしました。ただし、現状は以下のいくつか制約付きです。
・もちろんＤＭＡ非対応です。
・バッファの最初からしか音は鳴らせない（将来的には、オフセットをつけて、バッファの途中からならすことも考えようかとは思う）
・バッファの途中でファイルが終わったらあとは無音（そのうちリピートモードを実装しようかとは思う）
。音のｃｈは６ｃｈとする（Ｆｏｒ文を追加するだけで処理時間が間に合えば音の数は増やせるが・・・）
スケッチです。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test75.zip
まあなんとなく作れましたが、音の周波数やバッファの大きさによって、制御がバグったりしたので、ＰＷＭの割込みと、バッファ制御計算部分にどのくらいの時間かかっているのかオシロで確認しました。
ところで、ＰＷＭの制御は、bool TimerHandler1(struct repeating_timer *t)
で行っており、中身はバッファA、バッファBの切り替えと1byteずつ音を出していくという作業をしています。
また、バッファ制御計算部分は、void manage_wave()
で、行っており、この関数はLoop()から呼ばれ、バッファが切り替わっているフラグをつかんだら動きます。各ｃｈについて音を鳴らすフラグが立っていたら、音をコピーし始めます。バッファ分だけファイルからPWMのバッファへコピーします。次に呼ばれたときに音の再生が終わっていなければ、またバッファ分だけコピーします。
で、まずはPWMの制御がどのくらいの時間かかっているのかオシロで確認しました。
デバッグ用に出力ピンを設定して、黄色い波形のパルスが立っているところがPWMの制御を行っているところで、1.13us程度で終わっています。ただし、このインターバルに問題がありました。
なんか、踏切の音は低いし、車内放送の声が低くて暗いなと思っていたら、出力周波数が微妙に低かったです。
Setup()のITimer1.attachInterruptInterval(TIMER1_INTERVAL_us, TimerHandler1);
の、TIMER1_INTERVAL_usで割り込みのインターバルを設定しているのですが、実出力からみると、+5usのインターバルになるようです。インターバルは下記で設定しているのですが、-5usするように直しておきました。これで、車掌さんの声もやる気がみなぎるようになりました。（最初の方の#define）
//44k 22->17
#define TIMER1_INTERVAL_us 17
//32k 31 -> 26
//#define TIMER1_INTERVAL_us 26
//16k 62 -> 57
//#define TIMER1_INTERVAL_us 57
//8k 125 -> 120
//#define TIMER1_INTERVAL_us 120
次に、バッファ制御計算部分ですが、こちらは、
void manage_wave()で行っています。
こちらもデバッグ用に出力ピンを設定して、オシロで青いパルスが立っているところが処理中です。
バッファは８KHｚの時に１０２４Ｂｙｔｅとして、一秒に7回ぐらいは反応してくれるようにしております。
バッファ数は下記で定義しています。（最初の方の#define）
//#define BUF_LENGTH 32768
//#define BUF_LENGTH 16384
//#define BUF_LENGTH 8192
#define BUF_LENGTH 4096
//#define BUF_LENGTH 2048
//#define BUF_LENGTH 1024
また、周波数によって、読み出すファイルを変更しています。（Setup()内）
//String dir = "/8kHz_8/";
//String dir = "/16kHz_8/";
//String dir = "/32kHz_8/";
String dir = "/";
ルートフォルダに44KHz版を入れています。
この時、同時発音数を振って、処理時間のパルス幅を確認した表が以下になります。
44KHz、バッファサイズ4096で6音同時に出したとき、35.1ms処理にかかり、インターバルに対する処理の占有率は32％程度となります。（ただし、この後に、PWM制御の割込みインターバルがおかしいことを見つけたため、もう少し占有率は高いかも）
まあ、まだバッファ制御計算部分は適当に書いていて、速くできそうな感じはあるので、あまり気になるところではありません。
あと、波形を見ていて気になったのが、音が揺れることがあるのですが、PWM制御の割込みを見てみると不安定です。黄色いパルスで真ん中のパルスでトリガーをかけてそろえているが、右のパルスが二重に見えている→パルスが揺れている。
なんか、バックグランドでこそこそ他の処理が動いている感があります。
例えば、今回のスケッチに入れているvoid serialEvent()
をトリガーに確認してみると、その前後で、PWMの割込みが数クロック消えるのが見えました。
また、Core1は使っていないからいいかなあと思って、Setup1(),loop1()にスケッチを移してみてみたら、PWM制御の1.13usが大きく間延びすることもあるなど、やばそうな現象が見られました。
まあ普通に考えて、割込み内では、ほかの割込み禁止！の命令を入れるべきだよなあとそういえば思い出しました。なんて命令だろう・・・。
PWMのところはPIO化か？ちょっと敷居が高そうだけど、そのうち。
今後ですが、16bitのWav対応、音の切れ目ないリピート、二つの音をシームレスにつなげる方法などをやっていこうかと思います。
で、本題ですが、年末に、やあさんさんから、以下のメールが・・・。面倒なので、ほぼ原文を書いてしまいますが、
ーーーーーーーーーーー
RP2040となり機能が増えているので、以下の２つの対応を順次、やっていければと思ってます。
【DMA伝送】
（１）PWMレジスタにDMA伝送する機能の追加。
（２）DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）
→割込みごとにPWMを書いているとCPUが食われるので、それを自動化する。DMA化することで同時発音数をさらに増やせるのではと。
あとのちのちのサウンドシーケンス（LokProgrammerのブロック図の状態遷移の実行）を実装するには必須になります。
【ファイルシステム対応】
（３）LittleFSでのサウンドデータアクセス
（４）LittleFSのファイルシステムに置くバイナリデータの作成ツールDSwav2の修正、バイナリ出力機能の追加（やあさんさんの仕事です）
ーーーーーーーーーーー
で、音声ファイルを１６MByteも入れられる、Nano RP2040も送っていただいたので、さっそく実験です。
（１）は難しいので、（３）、（２）の順に進めています。
まず、（３）「LittleFSでのサウンドデータアクセス」ですが、1音だと、事前にファイルをオープンして、割込み中にファイルアクセスしてもとりあえずは音が出ましたが、複数音だと、うまくできませんでした。ということで、LittleFSを使ってのファイルアクセスはできましたが、現状のPWM割込み部分にすべて詰め込もうとすると、全然ダメです。
次に（２）「DMA用のバッファ(0.5秒分x2？）の定義の追加、バッファに書き出す処理の追加（今の割込みごとを、0.5秒分まとめてガツンと書くなど）」ですが、最初リングバッファ作って・・・と半日ほど考えましたが、なんか良い案が思いつかずに眠気だけが出てきてたので、それはやめて、字面通りの方法をとることにしました。ただし、現状は以下のいくつか制約付きです。
・もちろんＤＭＡ非対応です。
・バッファの最初からしか音は鳴らせない（将来的には、オフセットをつけて、バッファの途中からならすことも考えようかとは思う）
・バッファの途中でファイルが終わったらあとは無音（そのうちリピートモードを実装しようかとは思う）
。音のｃｈは６ｃｈとする（Ｆｏｒ文を追加するだけで処理時間が間に合えば音の数は増やせるが・・・）
スケッチです。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test75.zip
まあなんとなく作れましたが、音の周波数やバッファの大きさによって、制御がバグったりしたので、ＰＷＭの割込みと、バッファ制御計算部分にどのくらいの時間かかっているのかオシロで確認しました。
ところで、ＰＷＭの制御は、bool TimerHandler1(struct repeating_timer *t)
で行っており、中身はバッファA、バッファBの切り替えと1byteずつ音を出していくという作業をしています。
また、バッファ制御計算部分は、void manage_wave()
で、行っており、この関数はLoop()から呼ばれ、バッファが切り替わっているフラグをつかんだら動きます。各ｃｈについて音を鳴らすフラグが立っていたら、音をコピーし始めます。バッファ分だけファイルからPWMのバッファへコピーします。次に呼ばれたときに音の再生が終わっていなければ、またバッファ分だけコピーします。
で、まずはPWMの制御がどのくらいの時間かかっているのかオシロで確認しました。
デバッグ用に出力ピンを設定して、黄色い波形のパルスが立っているところがPWMの制御を行っているところで、1.13us程度で終わっています。ただし、このインターバルに問題がありました。
なんか、踏切の音は低いし、車内放送の声が低くて暗いなと思っていたら、出力周波数が微妙に低かったです。
Setup()のITimer1.attachInterruptInterval(TIMER1_INTERVAL_us, TimerHandler1);
の、TIMER1_INTERVAL_usで割り込みのインターバルを設定しているのですが、実出力からみると、+5usのインターバルになるようです。インターバルは下記で設定しているのですが、-5usするように直しておきました。これで、車掌さんの声もやる気がみなぎるようになりました。（最初の方の#define）
//44k 22->17
#define TIMER1_INTERVAL_us 17
//32k 31 -> 26
//#define TIMER1_INTERVAL_us 26
//16k 62 -> 57
//#define TIMER1_INTERVAL_us 57
//8k 125 -> 120
//#define TIMER1_INTERVAL_us 120
次に、バッファ制御計算部分ですが、こちらは、
void manage_wave()で行っています。
こちらもデバッグ用に出力ピンを設定して、オシロで青いパルスが立っているところが処理中です。
バッファは８KHｚの時に１０２４Ｂｙｔｅとして、一秒に7回ぐらいは反応してくれるようにしております。
バッファ数は下記で定義しています。（最初の方の#define）
//#define BUF_LENGTH 32768
//#define BUF_LENGTH 16384
//#define BUF_LENGTH 8192
#define BUF_LENGTH 4096
//#define BUF_LENGTH 2048
//#define BUF_LENGTH 1024
また、周波数によって、読み出すファイルを変更しています。（Setup()内）
//String dir = "/8kHz_8/";
//String dir = "/16kHz_8/";
//String dir = "/32kHz_8/";
String dir = "/";
ルートフォルダに44KHz版を入れています。
この時、同時発音数を振って、処理時間のパルス幅を確認した表が以下になります。
44KHz、バッファサイズ4096で6音同時に出したとき、35.1ms処理にかかり、インターバルに対する処理の占有率は32％程度となります。（ただし、この後に、PWM制御の割込みインターバルがおかしいことを見つけたため、もう少し占有率は高いかも）
まあ、まだバッファ制御計算部分は適当に書いていて、速くできそうな感じはあるので、あまり気になるところではありません。
あと、波形を見ていて気になったのが、音が揺れることがあるのですが、PWM制御の割込みを見てみると不安定です。黄色いパルスで真ん中のパルスでトリガーをかけてそろえているが、右のパルスが二重に見えている→パルスが揺れている。
なんか、バックグランドでこそこそ他の処理が動いている感があります。
例えば、今回のスケッチに入れているvoid serialEvent()
をトリガーに確認してみると、その前後で、PWMの割込みが数クロック消えるのが見えました。
また、Core1は使っていないからいいかなあと思って、Setup1(),loop1()にスケッチを移してみてみたら、PWM制御の1.13usが大きく間延びすることもあるなど、やばそうな現象が見られました。
まあ普通に考えて、割込み内では、ほかの割込み禁止！の命令を入れるべきだよなあとそういえば思い出しました。なんて命令だろう・・・。
PWMのところはPIO化か？ちょっと敷居が高そうだけど、そのうち。
今後ですが、16bitのWav対応、音の切れ目ないリピート、二つの音をシームレスにつなげる方法などをやっていこうかと思います。
2022-01-02 20:10
コメント(0)
RP2040で音の再生実験 [DCCデコーダ]
お台場のヴィーナスフォートが来年の３月で閉店ということで、12/29に見納めに行ってきました。若い頃はよく行きましたが、近ごろは、外国人観光客も増え、また子供向けの施設でもないような気がしたため、足が遠のいていました。まあ、中はあまり変わっておらず、記憶を思い出しつつ適当に３６０度カメラで写真を撮っておきました。
で、本題ですが、やあさんさん、なごでんさんと次期DCCデコーダに向けて話し始めていて、Raspberry Pi Pico RP2040でDCCデコーダー作るときにちゃんと音が出せるかどうかの確認を始めました。
今まで使っていたDIYデコーダに使用していたATMega328P(1Core,8bit,8MHz,32kbyte)に比べ、raspberry pi Picoに搭載されているRP2040は2Core、32bit、125MHz,Flash２MByteとそれぞれのスペックがCore２倍、CPUビット数４倍、動作クロック１５倍、メモリ６２倍と、掛け算すると今までの約７０００倍の可能性があることになります。（ほんとか？）
今まであった制約は、
・効果音は、メモリが足りないので長時間のクオリティの高い音をでファイルが入れられない。（頑張って8kHzで４秒ぐらいだった）クロックが低いため、同時発音数を一音に限った。
・モーター疑似音も、音の長さが取れず、大きさの調節が難しく、和音も出せず、結果として音が残念になっていた。
です。
今回RaspberryPicoで、ArduinoIDEでコンパイルでき、ライブラリも使えるものは使えるらしいということで、適当なスケッチを作り、音を出してみました。
あとで大体忘れるので、過程も書いておきます。
やあさんさんの記事を参考に環境構築します。
具体的には、RP2040開発環境をArduinoIDEに入れます。
「ファイル」→「環境設定」
追加のボードマネージャで
https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
を指定して、
Raspberry Pi Pico/RP2040をインストール。１．９．９を入れました。
ArudinoにRaspberryPiPicoを認識させる方法ですが、最初のおまじないとして、
①リセットボタンを押しながらUSBケーブルを挿して、PCにPicoをストレージとして認識させる。
（このときCOMポートとしては認識しない。）
②この状態で、スケッチを書き込むと、IDEから認識されるものがCOM4(Raspberry pi pico)のような表記となり、この後は認識されています。
次からは、何も考えずにスケッチは書き込めるようになりました。
Comポートをシリアルモニタとかで開きっぱなしにしていると、書き込み時にエラーが出ました。
次に音を出すための割込みですが、今までのモノはATMega328P専用で作っていて当該bitをいじってやっていましたので、そのまま流用できません。RP2040のタイマー割込みを確認すると、二つあるそうです。
高レベルAPIのpico_timeとhardware_timerの２種類が用意されているようですが、
https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__timer.html#details
https://raspberrypi.github.io/pico-sdk-doxygen/group__pico__time.html#details
なんか、スケッチを動かすと、comポートが認識されなくなり、どうやらちゃんと動かないです。
ということで、RPI_PICO_TimerInterruptを使います。
https://www.arduino.cc/reference/en/libraries/rpi_pico_timerinterrupt/
私の時は、RPI_PICO_TimerInterrupt １．１．１でした。
ソースは以下のようです。
https://github.com/khoih-prog/RPI_PICO_TimerInterrupt
とりあえず、これで割り込みができるようになりました。
次に音をどう出すかですが、流行りので行くとI2Sで出す！だと思うのですが（それ用のPIOとかも世の中のライブラリにあるようですし）、まあ、デバッグとかも考えると、PWMで出して、LPFかけて、アンプで増幅していいか？ということにしました。
具体的には、基板のA0端子からPWMを出して、それを昔作ったアンプ基板３８６でLPF＋増幅して、スピーカーから出すことにしました。アンプ基板３８６は１２V必要なので、PicoとGNDだけ共通にして、別電源から１２V供給しています。
で、今回の実験環境はこんな写真になります。
スケッチはこちらになります。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test5.zip
スケッチの操作方法は0～6 をSerialで送信すると、その音がなり、ｃで音を消します。
スケッチで使用している音源は、
https://desktopstation.net/sounds/mp3.html
の
・サウンドパック・日本版 R3 (Mar 20, 2014)
・185系 特急踊り子 (2021/5/31)
から拝借して、Wav変換して使用してます。
動画は以下です。
で、本題ですが、やあさんさん、なごでんさんと次期DCCデコーダに向けて話し始めていて、Raspberry Pi Pico RP2040でDCCデコーダー作るときにちゃんと音が出せるかどうかの確認を始めました。
今まで使っていたDIYデコーダに使用していたATMega328P(1Core,8bit,8MHz,32kbyte)に比べ、raspberry pi Picoに搭載されているRP2040は2Core、32bit、125MHz,Flash２MByteとそれぞれのスペックがCore２倍、CPUビット数４倍、動作クロック１５倍、メモリ６２倍と、掛け算すると今までの約７０００倍の可能性があることになります。（ほんとか？）
今まであった制約は、
・効果音は、メモリが足りないので長時間のクオリティの高い音をでファイルが入れられない。（頑張って8kHzで４秒ぐらいだった）クロックが低いため、同時発音数を一音に限った。
・モーター疑似音も、音の長さが取れず、大きさの調節が難しく、和音も出せず、結果として音が残念になっていた。
です。
今回RaspberryPicoで、ArduinoIDEでコンパイルでき、ライブラリも使えるものは使えるらしいということで、適当なスケッチを作り、音を出してみました。
あとで大体忘れるので、過程も書いておきます。
やあさんさんの記事を参考に環境構築します。
具体的には、RP2040開発環境をArduinoIDEに入れます。
「ファイル」→「環境設定」
追加のボードマネージャで
https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
を指定して、
Raspberry Pi Pico/RP2040をインストール。１．９．９を入れました。
ArudinoにRaspberryPiPicoを認識させる方法ですが、最初のおまじないとして、
①リセットボタンを押しながらUSBケーブルを挿して、PCにPicoをストレージとして認識させる。
（このときCOMポートとしては認識しない。）
②この状態で、スケッチを書き込むと、IDEから認識されるものがCOM4(Raspberry pi pico)のような表記となり、この後は認識されています。
次からは、何も考えずにスケッチは書き込めるようになりました。
Comポートをシリアルモニタとかで開きっぱなしにしていると、書き込み時にエラーが出ました。
次に音を出すための割込みですが、今までのモノはATMega328P専用で作っていて当該bitをいじってやっていましたので、そのまま流用できません。RP2040のタイマー割込みを確認すると、二つあるそうです。
高レベルAPIのpico_timeとhardware_timerの２種類が用意されているようですが、
https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__timer.html#details
https://raspberrypi.github.io/pico-sdk-doxygen/group__pico__time.html#details
なんか、スケッチを動かすと、comポートが認識されなくなり、どうやらちゃんと動かないです。
ということで、RPI_PICO_TimerInterruptを使います。
https://www.arduino.cc/reference/en/libraries/rpi_pico_timerinterrupt/
私の時は、RPI_PICO_TimerInterrupt １．１．１でした。
ソースは以下のようです。
https://github.com/khoih-prog/RPI_PICO_TimerInterrupt
とりあえず、これで割り込みができるようになりました。
次に音をどう出すかですが、流行りので行くとI2Sで出す！だと思うのですが（それ用のPIOとかも世の中のライブラリにあるようですし）、まあ、デバッグとかも考えると、PWMで出して、LPFかけて、アンプで増幅していいか？ということにしました。
具体的には、基板のA0端子からPWMを出して、それを昔作ったアンプ基板３８６でLPF＋増幅して、スピーカーから出すことにしました。アンプ基板３８６は１２V必要なので、PicoとGNDだけ共通にして、別電源から１２V供給しています。
で、今回の実験環境はこんな写真になります。
スケッチはこちらになります。
https://desktopstation.net/wiki/lib/exe/fetch.php/timer_test5.zip
スケッチの操作方法は0～6 をSerialで送信すると、その音がなり、ｃで音を消します。
スケッチで使用している音源は、
https://desktopstation.net/sounds/mp3.html
の
・サウンドパック・日本版 R3 (Mar 20, 2014)
・185系 特急踊り子 (2021/5/31)
から拝借して、Wav変換して使用してます。
動画は以下です。
2021-12-30 10:48
コメント(0)
今年もそろそろ終わりですね・・・。
お久しぶりです。
ここ。数年、仕事が忙しくて、何か、人生いまいちです。
それはさておき、
Desktopstation様で、プレゼント付きのDCCアンケートしていますので、ぜひお答えいただいたらと思います。
年末年始は、電子工作をしようかと思っています。多分。
ここ。数年、仕事が忙しくて、何か、人生いまいちです。
それはさておき、
Desktopstation様で、プレゼント付きのDCCアンケートしていますので、ぜひお答えいただいたらと思います。
年末年始は、電子工作をしようかと思っています。多分。
2021-12-24 20:15
コメント(0)
PLCの勉強をするか？ [その他]
土曜日に秋葉原に行ったら、山手線の内回りが池袋、大崎間で運休ということで、電光掲示板の電車の到着時間表示がかなりアバウトになっていて、珍しいのでみんな写真をとっていました。
外回りの電車の一部が大崎折り返しのようで、外回りで時々大崎行が来ていました。（上野駅）
内回りは１０分毎ぐらいに来ていて、池袋行でした。写真撮っている人がたくさんいました。
で、本題ですが、少し前に、ラズパイでPLCみたいな記事をどっかで見かけたと記憶があったのですが、このごろ、会社でPLCのラダーをなんとなく把握しておかないといけないような仕事があるので、PLCの勉強をやってみることにしました。
ラズパイでPLC ハード&開発環境編という本が出ていたので、買いました。ついでに、秋葉原の秋月電子に行って、基板と、部品セットを買ってきました。（基板は、CQ出版に手紙を送ると、タダでもらえるそうですが、この土日でやりたかったので、基板も買いました）
で、組み立てましたが、一か所やらかしました。４０ピンのラズパイに繋ぐピンソケットですが、シルクがおもて面にあるので、そっちにハンダ付けしたら間違いでした。正しくは、裏面に実装すべきもので、ヒートガンでソケットを溶かしながら取っ取って、リードの穴を一つずつ爪楊枝で開けて、裏面から新しいソケットを入れて・・・と半日仕事になってしまいました。
ということで、勉強しようとPLCのラダーの勉強をしようと思います。本の最後は鉄道模型の自動運転という章もありました。
あとは、ツクモにCore i7-9700Fの未使用品が23800円で売っていたので思わず買ってしまいました。今のPCはCore i5-8400で、なんとなく遅いなあと感じていたので。家に帰って載せ替えてみましたが、まあ、なんとなく早くなった気はするけど、そんなに変わらないかもです・・・。自己満足ですかね。
外回りの電車の一部が大崎折り返しのようで、外回りで時々大崎行が来ていました。（上野駅）
内回りは１０分毎ぐらいに来ていて、池袋行でした。写真撮っている人がたくさんいました。
で、本題ですが、少し前に、ラズパイでPLCみたいな記事をどっかで見かけたと記憶があったのですが、このごろ、会社でPLCのラダーをなんとなく把握しておかないといけないような仕事があるので、PLCの勉強をやってみることにしました。
ラズパイでPLC ハード&開発環境編という本が出ていたので、買いました。ついでに、秋葉原の秋月電子に行って、基板と、部品セットを買ってきました。（基板は、CQ出版に手紙を送ると、タダでもらえるそうですが、この土日でやりたかったので、基板も買いました）
で、組み立てましたが、一か所やらかしました。４０ピンのラズパイに繋ぐピンソケットですが、シルクがおもて面にあるので、そっちにハンダ付けしたら間違いでした。正しくは、裏面に実装すべきもので、ヒートガンでソケットを溶かしながら取っ取って、リードの穴を一つずつ爪楊枝で開けて、裏面から新しいソケットを入れて・・・と半日仕事になってしまいました。
ということで、勉強しようとPLCのラダーの勉強をしようと思います。本の最後は鉄道模型の自動運転という章もありました。
あとは、ツクモにCore i7-9700Fの未使用品が23800円で売っていたので思わず買ってしまいました。今のPCはCore i5-8400で、なんとなく遅いなあと感じていたので。家に帰って載せ替えてみましたが、まあ、なんとなく早くなった気はするけど、そんなに変わらないかもです・・・。自己満足ですかね。
2021-10-24 13:27
コメント(0)
