設計2H
設計のみ完了して、なんか、やる気が尽きてしまった。
ほぼほぼ、今まで作った回路を使えるので、
組み込みも、多分コーディング3Hデバグ4Hくらいだと思うんだけど、
GW中に完成しませんでした。
ボリュームで16Hzより16倍位の周波数をスイープ、
スイッチでx1,x8,x64,x512を切り替えて、最大130kHzまで出力する
正弦波発生器です。
出力はΔΣDACです。
で、出力している波形を周波数カウンタで測定して、周波数を表示。
と言った構成。
本当はここまでを ボリューム検出回路(VR_LOC_DET)のデモで入れたかったんだけど
ちょっとむりでしたねー。
つか、GW全部使ってもできませんでしたねー。
まあ、やる気が復活したら実装します。
多分、公開ソースを組み合わせるだけでダイジョブでしょう。
うい。
+2.5Hコーディンッグ+4.5Hデバグ+blog0.5H=43h
おとといの無産階級のBIN2DEC回路を組み込んだTM1638_LED_KEY_DRV完成しました。
この図はWIPですよ。
後から組み込んだお陰で、早すぎる最適化した部分を戻したり、色々と大変でした。
ステート足したり。
sizeも296LEから357LEと20%も大きくなってしまいました。
ただBIN2DECは77LEなので、16LE以上もコンパイラが頑張ってくれたみたいです。
でも、これでもNiosIIeよりはだいぶ小さいので、今後は活用する予定。
あと、GitHubの方のREADME.mdを直したら、この件は、本当に完成ということで。
+コーディング3H+sim1H+blog/doc+1H=5H
以前書いた超富豪コーディングな2進10進変換回路ですが、
次回の回路で使いたいかなぁと思い。
回路規模削減版を追加しました。
1桁ごとに、1ステート(EN_CK_i周期)で newX<= 2*lastX +cyの計算をします。
これを、msbから順に27bit計算します。(9999_9999は27bitなので)
計算が終わるとDONE_oを1発出力します。
富豪回路では1.5kELだったのが、137LEまで削減できました。
250MHz/29ck=8.6MHzで、富豪の11MHzに比べると、若干遅くなってますね。
どうしてもスピードを稼ぎたいなら、
2*x+cyをn段づつモジュールにして、27/nステートって方法もあるかな?
3段くらいまでは現実的な予感。
. 実は、最後のラッチをしない出力も選択できます。
次の回路でラッチをさせれば32FF節約可能。(無産階級)
parameter C_MILLIONAIREで超富豪回路と切り替えられます(0defoで新回路)
https://github.com/mangakoji/BIN2BCD
使い方はREADME.mdを見てけれ
明日は、昨日の回路にこれを組み込んで最初に考えてた回路を実装する方向で。
+debug3.5+demo追加3.0H+blog0.5H=35.5H
予定よりちょっとだけ早く完動しました。
本当は昨日完成してたんですけど、なぜかdemo動画upできなくて、blog遅延
TM1638使用のLED boardのドライバー
大体どんなプロジェクトも40H以下で完成した事ないので、これは結構簡単だったかも?
回路規模 : ほぼほぼ全部変数化して296LE(220LEくらいのつもりだったんですが、だいぶ...)
動作速度:fmax=117MHz(予定よりだいぶ遅いですな)
FPGAの3.3VはそのままTM1638に渡してOKなんですが、TM1638 LEDボードの5Vはそのまま繋ぐと、
FPGAの耐圧4.2Vなので、ヤバイです。
幸いTM1638の出力はトライステート/L出力っぽいので(TDには直接はそう書いてない)ので、
FPGA内部でプルアップします。
実測でもmax3.3Vになってるので、実際問題なさそうです。
今回使用したaitendoのLED_KEY_board K-7SEG8D1638の5pinは
それれ以下につなぎます
VCC - CQ_MAX10-JBのF1(ポリヒューズ)の5V入力側
GND-CQ_MAX10-FBのGNDpin
STB-SS_o(P130)
CLK-SCLK_o(P127)
DIO-MISO_i(P124)
こんな感じになります。
ランダム表示に見えますが、実は各digitバラバラに単純なカウントup/downしてるだけです。
よく見ていただけば、謎が解けるかと。
もちろんソース見で答え合わせしていただくのもアリかと。
さて、How to useもまとめにゃならんのですね。
block図もblog更新していなし(書いてはある
まあ、おいおい続けます。
さあ、コレ使って何作りますかね?最初考えてたものは10進化回路が必要なので、躊躇してるんですが。
'+コーディング1H+syntax check2H+debug4H+blog0.5H=28.5H
予定よりも早くデバグに入れたのは嬉しいけど、症状は重い。
やっとステートマシンが回り始めたんだけど、なぜか1ステート飛ばして止まっちゃう。
ステートマシンで書かずに、普通にカウンタで書けばよかったかな?
quartusは、ステートマシン推定ってのをしてくれる。
例えば
localparam S_0 = 0 ;
localparam S_1 = 1 ;
localparam S_2 = 2 ;
reg [3:0] STATE ;
always @(posedge CK )
if (start)
STATE <= S_0 ;
else case ( STATE )
S_0:
STATE <= S_1 ;
S_1 :
if ( carry )
STATE <= S_2 ;
S_2 : begin
if ( ~carry)
STATE <= S_0 ;の様に書くと、STATEのbit数を揃えてくれたり、レジスタをワンホットに変えて
ハザードを減らしてくれたりする。
また、ミーリーで書いてもワンホットに変換すれば、デコード値がDFF出力になるので、体外の場合、ムーアーの様に早い。
orつなぎなどでも、それに良いように書き換えてくれるので、ミーリーの記述でDFF出しの様な回路が記述できるすげえやつ。なのですよ。
そのかわり、ステートとSTATEの値がparameterで指定した値と異なる値が再配置されるで、
xilinxなど他のデバイスに異色した時に、回路構成が全く変わってしまう。
それ以上にシミュレーションツールごとに振る舞いが変わるので、結構つかれる。
ステートとSTATEの値の対応は、レポートに出てくるので、メモすればいいちゃいいんだが。
(あ、Verilog1995モードでは推定しないっぽいです。)
で、今回ヘマしたのは、ステートを使うときに
always @(posedge CK)
if ( STATE == S_1)
JUDGE <= 1'b1 ;の様に書くと、STATEとステートの対応が変わっているため、意図した分岐をする時も
しないときもある。のがこまる。
(S_0の様なリセットなシーケンスでは0がアサインされることが多そうではあるけど)
こうかかなきゃいけない。時がある。
always @(posedge CK)
case( STATE)
S_1:
JUDGE <= 1'b1 ;
endcaseendcaseがなければ、我慢できるが、コード量が多いのが気になるなぁ。
してやられた感じ。気づくのに1時間かかった。
(仕事でも引っかかった覚えが)
ただ、ステートマシンの外でも値の書き換えをしてくれてた時もあった気がするので、
切り分けがよくわかりません。が、こちらで書いとけば、どこにでもセーフポータブルかと。
+コーディング4H=21H
入力70%と言ったところ。
グロッキーなので、今日はここまで。
明日にはコンパイルできるといいな。
タイミング、後段回路の遅延を1段遅らせてたのを忘れてた。
どうやって治そうか。
まあ、前段の遅延を忘れてるよりはマシだけど。
+ブロック図5H +RTL3H+BLOG0.5H=17H
とりあえず今日はブロック図とタイムチャートで設計開始。
一部だけRTLを突っ込んでみたり。
全体はこんな構成です。
7セグエレメントを直接ドライブするモードと、HEX8桁でドライブするモードを切り替えられるように。
とりあえず10進は今回はパスする方向
本線系は、バッファのFFを減らすために、ちょっと変則的な構成を考えてるけど
コントロールしきれるかなぁ
一回の転送(8桁、LED8コ、小数点8コ、key8コ読み出し)をフレームと呼んでます。
これを1秒250回くらい(もっとたくさん出来ますが、レートを遅くして、keyのチャタリングをデチャタします。
いつもはカウンタで実装するんですが、ステートマシン表記で設計したことないんで、今回は実験的にステートマシンで設計。
でも、本当に分岐無しなんで、カウンタの方がよかったかな?
システム48MHzを12分周の2分周で、1MHzのSCLKを作ります。
システムクロックが異なる場合でも、parameter設定のみで、対応できるつもり。
システムクロック、SCLKクロック、フレームレートを個別に変更できる予定。
(ただし、不可能設定チェックはなし。マイコンだとasartionだとかでstrictに書きやすいんだけど
ハードウエアだとあんまり気にしなよな。自由すぎるんで、条件追い込めないっす。
どこまででもプラットフォーム/ペリフェラルが変わる可能性があるからねぇ。)
で、現在までの状況をこちらにupしてます。
まだまだ、コンパイルも始められませんが。
+GitHub準備1H+blog0.5H=9.5H
GWのお楽しみにGitHubでプロジェクト立ち上げました。
まだ完全なるWIP
GitHubのおかげで、やっとやりたいことができるようになった気がする。
10年前にほしかったよGitHub。ツールやデバイスは揃ってたんだもんなぁ。
Cyclone I でもできたんだからさ。
GitHubはソフトウエア以外の解説や分析なんかも徐々に集まってきてて、色々おもしろいです。
sourceforgeではできなかったんだよなぁ。
インクリメンタル更新というか、劇場的開発というか
昔のbasic時代みたいに、するにょーっとソースが見れて気持ち良い。
ざっくり環境全部が見える。
昨日のaitendo版arduino用のテストコードのリペア版はupしました
TM1638_LED_KEY_DRV/K-7SEG8D1638-SKETCH.ino at master · mangakoji/TM1638_LED_KEY_DRV · GitHub
enjoy making !
+組立1H+仕様確認0.5H+動作確認1H+blog0.5H=8H
さて組立です。
昨日組立ました。
背の低い部品から実装します。
昔は3000円くらいしたカプトンテープも1000円しないので、迷わず使っちゃいます。
1.27mmピッチはデカクて助かる。会社じゃこの半分以下がデコっす。
老眼で見えないのに..。
手に入る内は鉛入りハンダを使いましょう！水の様に流れて超便利。
鉛フリーは生クリームがせいぜいだもんなぁ。
鉛フリーは温度調整できるハンダゴテじゃないと歯が立ちませんよ?
で、完成しました。
で、一日おいて、今日は
動作確認は、aitendoのキットのページ
キースキャンI/F付き7セグ表示器キット - aitendo
のサンプルコードを使います。
サンプルコードはダウンロード/.txt->inoでは文字化けでうまく動作しないので、スケッチ開いて、コピペするか、こちらをどうぞ。
TM1638_LED_KEY_DRV/K-7SEG8D1638-SKETCH.ino at master · mangakoji/TM1638_LED_KEY_DRV · GitHub
動作させるとこんな感じ
キーマップと対応するLEDがおかしいのは、
ハード側のキーマップが、こんな感じに入れ子になってるからです。
詳しくはTD(Technical Datasheet)と
https://retrocip.cz/files/tm1638.pdf
基板図を
見てください。
はい。ここまでくれば、下の完成品を買ったのと同然です。
250円得しました(いや、250円くらい払えとも思うが)
enjoy!
考察:4H
今、色々工作に表示装置が必要なので、
itendoの、この表示装置を使おうと思ってる。
安いし、作ったら使ってもらえるかも？とか思ってさ。
買ったは良いが問題山積みで、すでにどうしようか考え中。
1. 5V- 3.3Vインターフェース
キー読み出しがあるんだよね
2.左がLSB
LEDもキーも7segも、なぜか左がlsb
7segの小数点がなければ上下逆さで解決できたが
なんで逆に実装するのよ？
3. 10進表示
10進で表示したいと思ってる。ハードで実装してる例はあまりないのでいいかなぁと。
機能のBIN2BCDはその布石。
一応小さくできそうな構成は考えてる。
が、HEXで表示しちゃったら、飽きちゃうかな?
4.仕様
これが結構難しい。
そんなかんじー。
RTL 3H, sim 1H , Blogなど2H
今、作りたい回路があるんですが、回路の中の値をリアルタイムに表示したいんですよ。
できれば16進でなく10進がいいなぁと思って、2進ー>10進変換回路を作って見ました。
色々方法があるんですが、一番単純な、BCD加算器を縦横に並べた、力技回路を書いてみました。
BCD_ADDERがBCD加算器で1桁の2値を足して、10以上になったら桁上り(cyo_o)を出す、
筆算の一桁を計算する回路です。
各bitがHのときは、それに対応した値を、筆算の様に足してゆく、だけ、の回路です。
0からの4bit目がHなら、10の位に1,1の位に6を足します。
この図では、縦方向に1の位、10の位、100の位...と並んでます。
この図では1000の位までしか書いてませんが、実際には32bitは10桁必要なので10億の位まであります。
この時、桁上りを足すのを忘れない様に。
入力の各bit分32ビット分の加算器が横に並んでます。
図では4bit目と5bit目の分のみ書いてますが、実際には列実装されています。
こちらの方向は、実は順番はどうでもいいので、実装上の緩和条件を見つけると、回路がちいさくなるかもしれません。
コンパイルしてみると、
CQ出版のMAX10-FBに搭載の(Altera MAX10:10M08SAE144C8)で、fmax=11.5MHzと
想像以上に複雑な回路で、回路規模も1.5kLEと、NiosIIマイコンよりもデカイという結果。
まさに富豪コーディング。
これならNiosII使えよ。と言った感じ。
もっとも、フラッシュにこだわらなければ、巡回に変更する方法もあります。
縦1列分で、1bitずつ巡回加算すれば、1列+コントローラで棲むので、多分200LE、33clock delay ,fmax=100MHzくらいには収まりそうな気がしますが...
ここでタイムアップ
FPGA/RTL/BIN2BCD.v内にテストベンチ TB_BIN2BCD()も同梱してあります。
ランダム値10000値入力での一致比較で完全一致してたので、bugということもないでしょう。
ソースはこちら。例によってGitHubにupしてます。(たった1 fileのためにGitHubとか、こちらも富豪
github.comhttps://github.com/mangakoji/BIN2BCD
enjoy!!
FPGAの デジタルIO pinのみで、ボリュームの位置を読み取る回路。
胃腸完成しましたので、公開させて頂きます。
こんな感じに動作します。
ごくかいつまんで言うと
1. 2種類の乱数(TPAT_P/N)を発生
2. ボリュームの位置が、TPAT_Pに近ければ、TPAT_Pに一致する割合が多く
TPAT_Nに近ければTPAT_Nに一致する割合が多くなります。
3.中間位置では、一致する確率は半々になります(乱数なので)
4.TPAT_Pだけが一致した場合はFF,T_PAT_Nだけが一致した場合は01、それ以外は中点の'h80を出力し、
それをIIRフィルターでローパス平均化して出力します。
大体5bitくらいの制度が出ています。ケースに触るだけで、そのくらい変動しますが、
CR時定数法などに比べると格段に安定しています。
ボリュームは10kohm,キャリアは48MHzであることが、キーポイントかもしれません。
実際1kohmにすると、若干中央によってしまい、読み取れる角度が狭くなります
(両端よりも遠い位置で、100%一致してしまう)
本当のことを言うと、過渡現象がよくわからず、且つ過渡現象にたよった回路なため、
なぜ動くのかよくわからない謎の回路になってます。
FPGAの入力は若干シュミット気味ですが、時定数をもったシュミットで、
且つ逆シュミットっぽく動作することもあって、本当によくわかりません。
ごらんのように、ボリュームには外付け部品をつけておりません。
ご自由にお使いください。
enjoy!
CQ MAX10-FB evaボードでFPGAのデジタルピンでボリュームの位置を読み取る方法を開発中。
FPGAのデジタルIOピンでボリュームの位置が読み取れたら、便利だと思いませんか?
ファンクション増えそうでしょ?
やってる例がないので、自分でやってますが、これが結構むずかしい。
4方式ほど試しましたが、ダメでしたが、
今日少し目が出てきました。
原因はボリュームへの電流が少なすぎて安定しなかったこと。
10kΩに変えたら、だいぶ安定しました。
========================
原理的/単純な順に
.CR時定数測定
これは最初から不安定なのはわかってたんですが、
考えていた補正回路では、ほとんど補正できないことがわかりました。
電流を増やすと、かろうじて読み取ることができました。
.FB方式
不安定で、リップルって言えない程度に発振幅が大きく、ダイナミックレンジが小さい。
ヒステリシスの問題 ?
これもボリュームの電流を増やせば、目が出そうなので、
こちらも実験したいが、定数の変更などが必要なのでおいおい。
回路規模も小さいので、これで行けるならこれで。
.MSEQ方式
パタンが単調なのか、分解能がない。
ダイナミックレンチが小さい
. WMSEQ方式
電流を増やしたらだいぶいい感じに
もう少しまとめたい
なんか、いい誕生プレゼントだった気が。いい気分。
CQ MAX10-FBに、オルガン開発環境を移植しました。
これからは、しばらくCQ MAX10-FBで何か作ってみたいなぁと。
どうせならハモンド・オルガンっぽい音が出るようにしたいとか、色々妄想中。
以前BeMicroMAX10での実装で歪バリバリだったのは、2'sをストレート解釈で聞いてたからでした。
シンクロで見ればバッチリ。
やっぱオシロ使わないとダメね。
↓これはデバグ後。ちゃんと正弦波になってるでしょ?
くどいようですが、ΔΣDACを実現してるので、外付けなしで、アナログ波形を出してます。
NTSCのvideo帯域くらいならなんとかなります。
こちらの記事の続きです。
しかし、音声モニタスピーカー環境がよろしいのがなく、どれを使っても、イマイチ正弦波に聞こえなくて困ってる中。
三角波と正弦波を切り替えても。ほとんど聞き分け出来ません。TVの音響系ならハッキリ差が出るんだけど、持ってる音響セットはみんな玩具ですね。
オシロではハッキリ差があるんですが。
これで、シンセ開発するのは厳しいなぁ。
和音の実験になる、何か良いスコアがほしい。
ハ長調で書いてあって、且つ半音のないのが必要で、ハ長調しか読めないぼくには結構厳しい条件なのよ。
平均律楽器使ってるなら、転調とかするなよ。全部ハ長調で書けよとよく思う。
昔使ってた『軍艦』のスコアがいまいち間違ってる感じで、気分がモニョる。たしか耳コピだった気がするが。
さらにリサージュとか。
なにか歪んでますが、1chと2chを入れ替えても同じ歪み方なので、CQMAX10 FPGA音源オシロの1chの方が歪んでるようです。困る。
これやると、この画面でテニスとか作りたくなるね。世界初のビデオゲームっぽいやつ。
色々まとまりなく進行中。
もっそっとまとまってからGitHubにupします。
最終的に何をつくるつもりなのか...
もう一年も前になるのねー
発売してすぐ買った CQ出版のMAX10ボード。ずっと保留してましたが、
@s_osafne氏のTerasc DE0版のプロジェクト ファミマチャイム 「大盛況」を移植しました。
→ osafune/CQEXT_melodychime · GitHub
一昨年末にBeMAX10にも移植しましたが、その時の記事が以下
なんか、大盛況がボクのLチカですな。
codeはこちら。
enjoy!
