散歩師・漫画居士のくだらなクラブ日記 避難所

ども、散歩師・漫画居士っす。散歩したり実働模型作ったりが趣味なんで、その時に思いついたこととか書くッス

30日間 スクワットチャレンジ2017

ども、ひさしぶりっす。

 

ことしも昨日から30日間スクワットチャレンジを再開しました。

なんか一年たったら、また太もも細くなって、生きるのがきつくなってきましたよ。

もう歳なんで、回復しないかもですが、やってみようかと。

 

ただし、日々のスクワット回数は、あんまり数字的に美しくないので、見直す方向で。

1. 3日やって1日休み。

2. スタートは50回

3. 毎日10%up

4. 最後は250回

5.5の倍数丸め。

が、基本ルールらしいですが、もうちょっとなんとかならんかなぁ?

 

 

去年のはこんなかんじ

mangakoji.hatenablog.com

 

 

今日は2日目で55回。

3回にわけて、なんとか完了。

最近気づいたこと

どっかに書いとかないと忘れるので。

 

・GW開けくらいから、電車混み始めた

・6月末から、電車で本を読んでる人が増えた。増えたのは文芸。

  相対的にモシモシ弄ってる人が、若干減った。

  女の子(女学生)もオッサンも

 

メガネっ娘増えてない?

  京浜東北下りだから?でも、15年前に比べても増えた気がする。

  しがらみを離れるためのメガネだけど不思議ちゃんでもなく、

  強いて言えばアラレちゃん(新版)系?

 

・祭りの美少女率

  10年くらい前をピークに若干郊外のお祭りでは、顔面偏差値70以下のコは祭り来るなよ!的な空気があったんですが、

  今日行った横浜市(東北海沿い)の祭りでは、そういう雰囲気がほとんどありませんでした。

  かなりメガネっ娘率高かったり。(一時期は本当にメガネの女子中高生いなかったんですってば)

   ・鶴見を、国分寺くらいの東京と考えるか、平塚くらいの田舎と考えるかで、だいぶ見方がかわるんですが、どうなんですかね?

 

あと、この写真の様に、世の中に若干ロボタッチから開放されてる地の部分が増えてきてる気が。

ちょっと感動してしまいました。

(まだせめぎあいですが、世相の変化は横浜は東京よりも早いことも多いんで、期待してます。)

音声帯域正弦波発振回路 その1

設計2H

 

 

設計のみ完了して、なんか、やる気が尽きてしまった。

ほぼほぼ、今まで作った回路を使えるので、

組み込みも、多分コーディング3Hデバグ4Hくらいだと思うんだけど、

GW中に完成しませんでした。

f:id:mangakoji:20170507214023p:plain

 

 

ボリュームで16Hzより16倍位の周波数をスイープ、

スイッチでx1,x8,x64,x512を切り替えて、最大130kHzまで出力する

正弦波発生器です。

出力はΔΣDACです。

 

で、出力している波形を周波数カウンタで測定して、周波数を表示。

と言った構成。

 

本当はここまでを ボリューム検出回路(VR_LOC_DET)のデモで入れたかったんだけど

ちょっとむりでしたねー。

つか、GW全部使ってもできませんでしたねー。

 

まあ、やる気が復活したら実装します。

多分、公開ソースを組み合わせるだけでダイジョブでしょう。

うい。

 

【完成】BIN2BCDを組み込んだTM1638_LED_KEY_DRV その8

+2.5Hコーディンッグ+4.5Hデバグ+blog0.5H=43h

 

おとといの無産階級のBIN2DEC回路を組み込んだTM1638_LED_KEY_DRV完成しました。

f:id:mangakoji:20170506225601p:plain

この図はWIPですよ。

 

 

後から組み込んだお陰で、早すぎる最適化した部分を戻したり、色々と大変でした。

ステート足したり。

sizeも296LEから357LEと20%も大きくなってしまいました。

ただBIN2DECは77LEなので、16LE以上もコンパイラが頑張ってくれたみたいです。

でも、これでもNiosIIeよりはだいぶ小さいので、今後は活用する予定。

 

あと、GitHubの方のREADME.mdを直したら、この件は、本当に完成ということで。

github.com

無産階級の2進10進変換回路

+コーディング3H+sim1H+blog/doc+1H=5H

 

以前書いた超富豪コーディングな2進10進変換回路ですが、

次回の回路で使いたいかなぁと思い。

 

回路規模削減版を追加しました。

 

 

mangakoji.hatenablog.com

 

無産階級回路

  

f:id:mangakoji:20170504221110p:plain

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で新回路)

 

 

GitHubはこちら。

 

https://github.com/mangakoji/BIN2BCD

使い方はREADME.mdを見てけれ

 

 

明日は、昨日の回路にこれを組み込んで最初に考えてた回路を実装する方向で。

 

【動作完】FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その7

+debug3.5+demo追加3.0H+blog0.5H=35.5H

 

予定よりちょっとだけ早く完動しました。

本当は昨日完成してたんですけど、なぜかdemo動画upできなくて、blog遅延

 

TM1638使用のLED boardのドライバー

大体どんなプロジェクトも40H以下で完成した事ないので、これは結構簡単だったかも?

回路規模 : ほぼほぼ全部変数化して296LE(220LEくらいのつもりだったんですが、だいぶ...)

動作速度:fmax=117MHz(予定よりだいぶ遅いですな)

 

5V<->3.3V変換

f:id:mangakoji:20170503220015p:plain

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)

 

 

demo

こんな感じになります。

 

www.youtube.com

 

ランダム表示に見えますが、実は各digitバラバラに単純なカウントup/downしてるだけです。

よく見ていただけば、謎が解けるかと。

もちろんソース見で答え合わせしていただくのもアリかと。

 

残件

さて、How to useもまとめにゃならんのですね。

block図もblog更新していなし(書いてはある

まあ、おいおい続けます。

 

さあ、コレ使って何作りますかね?最初考えてたものは10進化回路が必要なので、躊躇してるんですが。

 

 

GitHub

github.com

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その6

'+コーディング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 ;
            endcase

endcaseがなければ、我慢できるが、コード量が多いのが気になるなぁ。
してやられた感じ。気づくのに1時間かかった。
(仕事でも引っかかった覚えが)

ただ、ステートマシンの外でも値の書き換えをしてくれてた時もあった気がするので、
切り分けがよくわかりません。が、こちらで書いとけば、どこにでもセーフポータブルかと。

GitHub - mangakoji/TM1638_LED_KEY_DRV: TM1638 LED KEY board driver and test demo. now tooo early WIP.

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その5

+コーディング4H=21H

 

入力70%と言ったところ。

グロッキーなので、今日はここまで。

明日にはコンパイルできるといいな。

 

 

タイミング、後段回路の遅延を1段遅らせてたのを忘れてた。

どうやって治そうか。

まあ、前段の遅延を忘れてるよりはマシだけど。

 

 

GitHub - mangakoji/TM1638_LED_KEY_DRV: TM1638 LED KEY board driver and test demo. now tooo early WIP.

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その4

+ブロック図5H +RTL3H+BLOG0.5H=17H

 

とりあえず今日はブロック図とタイムチャートで設計開始。

一部だけRTLを突っ込んでみたり。

 

全体はこんな構成です。

 

ドライバ本体の入出力ポート

f:id:mangakoji:20170429221855p:plain

7セグエレメントを直接ドライブするモードと、HEX8桁でドライブするモードを切り替えられるように。

とりあえず10進は今回はパスする方向

 

 

本線系のブロック図

 

f:id:mangakoji:20170429221920p:plain

本線系は、バッファのFFを減らすために、ちょっと変則的な構成を考えてるけど

コントロールしきれるかなぁ

 

 

 

1 Frameのシーケンス

f:id:mangakoji:20170429222012p:plain

一回の転送(8桁、LED8コ、小数点8コ、key8コ読み出し)をフレームと呼んでます。

これを1秒250回くらい(もっとたくさん出来ますが、レートを遅くして、keyのチャタリングをデチャタします。

いつもはカウンタで実装するんですが、ステートマシン表記で設計したことないんで、今回は実験的にステートマシンで設計。

でも、本当に分岐無しなんで、カウンタの方がよかったかな?

 

 

1 byteのシーケンス

f:id:mangakoji:20170429221955p:plain

 

クロック分周の概念

f:id:mangakoji:20170429221939p:plain

システム48MHzを12分周の2分周で、1MHzのSCLKを作ります。

システムクロックが異なる場合でも、parameter設定のみで、対応できるつもり。

システムクロック、SCLKクロック、フレームレートを個別に変更できる予定。

(ただし、不可能設定チェックはなし。マイコンだとasartionだとかでstrictに書きやすいんだけど

ハードウエアだとあんまり気にしなよな。自由すぎるんで、条件追い込めないっす。

どこまででもプラットフォーム/ペリフェラルが変わる可能性があるからねぇ。)

 

 

 

で、現在までの状況をこちらにupしてます。

github.com

 

まだまだ、コンパイルも始められませんが。

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その3

+GitHub準備1H+blog0.5H=9.5H

 

 

GWのお楽しみにGitHubでプロジェクト立ち上げました。

まだ完全なるWIP

github.com

 

いいよGitHubいいよ

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 !

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その2

+組立1H+仕様確認0.5H+動作確認1H+blog0.5H=8H 

さて組立です。

組立

昨日組立ました。

 

背の低い部品から実装します。

昔は3000円くらいしたカプトンテープも1000円しないので、迷わず使っちゃいます。

カプトンテープ - aitendo

1.27mmピッチはデカクて助かる。会社じゃこの半分以下がデコっす。

老眼で見えないのに..。

手に入る内は鉛入りハンダを使いましょう!水の様に流れて超便利。

鉛フリーは生クリームがせいぜいだもんなぁ。

鉛フリーは温度調整できるハンダゴテじゃないと歯が立ちませんよ?

 

 

で、完成しました。

 

 

動作確認

で、一日おいて、今日は

動作確認は、aitendoのキットのページ

キースキャンI/F付き7セグ表示器キット - aitendo

のサンプルコードを使います。

http://aitendo3.sakura.ne.jp/aitendo_data/product_img/aitendo-kit/AKIT/TM1638-7SEG8D/K-7SEG8D1638-SKETCH.txt

サンプルコードはダウンロード/.txt->inoでは文字化けでうまく動作しないので、スケッチ開いて、コピペするか、こちらをどうぞ。

TM1638_LED_KEY_DRV/K-7SEG8D1638-SKETCH.ino at master · mangakoji/TM1638_LED_KEY_DRV · GitHub

 

 

動作させるとこんな感じ

youtu.be

キーマップと対応するLEDがおかしいのは、

ハード側のキーマップが、こんな感じに入れ子になってるからです。

詳しくはTD(Technical Datasheet)と

https://retrocip.cz/files/tm1638.pdf

基板図を

f:id:mangakoji:20170426212938p:plain見てください。

 

 

はい。ここまでくれば、下の完成品を買ったのと同然です。

250円得しました(いや、250円くらい払えとも思うが)

www.aitendo.com

 

さて、これをFPGAでコントロールするわけだ。

 

enjoy!

 

FPGAでitendoの8桁7seg+8LED+8キー表示ユニットを使うWIP その1

考察:4H

 

今、色々工作に表示装置が必要なので、

itendoの、この表示装置を使おうと思ってる。

安いし、作ったら使ってもらえるかも?とか思ってさ。

www.aitendo.com

 

買ったは良いが問題山積みで、すでにどうしようか考え中。

 

問題

1.  5V- 3.3Vインターフェース

FPGAトーク一方なら、そのまま繋げばOKだけど、

キー読み出しがあるんだよね

 

2.左がLSB

  LEDもキーも7segも、なぜか左がlsb

  7segの小数点がなければ上下逆さで解決できたが

  なんで逆に実装するのよ?

 

3. 10進表示

 10進で表示したいと思ってる。ハードで実装してる例はあまりないのでいいかなぁと。

 機能のBIN2BCDはその布石。

 一応小さくできそうな構成は考えてる。

 が、HEXで表示しちゃったら、飽きちゃうかな?

 

4.仕様

 これが結構難しい。 

 

 

そんなかんじー。

超富豪な2進10進変換回路

2進→10進変換回路 BIN2HEX

RTL 3H, sim 1H , Blogなど2H

今、作りたい回路があるんですが、回路の中の値をリアルタイムに表示したいんですよ。

できれば16進でなく10進がいいなぁと思って、2進ー>10進変換回路を作って見ました。

 

色々方法があるんですが、一番単純な、BCD加算器を縦横に並べた、力技回路を書いてみました。

 

構成

BCD加算器

BCD_ADDERがBCD加算器で2桁の値を足して、10以上になったら桁上り(cyo_o)を出す、

筆算の一桁を計算する回路です。

各bitがHのときは、それに対応した値を、筆算の様に足してゆく、だけ、の回路です。

入力の1bit分

0からの4bit目がHなら、10の位に1,1の位に6を足します。

この図では、縦方向に1の位、10の位、100の位...と並んでます。

この図では1000の位までしか書いてませんが、実際には32bitは10桁必要なので10億の位まであります。

この時、桁上りを足すのを忘れない様に。

 

それを32bit分

入力の各bit分32ビット分の加算器が横に並んでます。

図では4bit目と5bit目の分のみ書いてますが、実際には列実装されています。

こちらの方向は、実は順番はどうでもいいので、実装上の緩和条件を見つけると、回路がちいさくなるかもしれません。

 

f:id:mangakoji:20170423211433p:plain

 

速度、回路規模

コンパイルしてみると、

CQ出版のMAX10-FBに搭載の(Altera MAX10:10M08SAE144C8)で、fmax=11.5MHzと

想像以上に複雑な回路で、回路規模も1.5kLEと、NiosIIマイコンよりもデカイという結果。

まさに富豪コーディング。

これならNiosII使えよ。と言った感じ。

 

もっとも、フラッシュにこだわらなければ、巡回に変更する方法もあります。

縦1列分で、1bitずつ巡回加算すれば、1列+コントローラで棲むので、多分200LE、33clock delay ,fmax=100MHzくらいには収まりそうな気がしますが...

ここでタイムアップ

sim

FPGA/RTL/BIN2BCD.v内にテストベンチ TB_BIN2BCD()も同梱してあります。

ランダム値10000値入力での一致比較で完全一致してたので、bugということもないでしょう。

 

ソース

ソースはこちら。例によってGitHubにupしてます。(たった1 fileのためにGitHubとか、こちらも富豪

github.comhttps://github.com/mangakoji/BIN2BCD

 

enjoy!!

FPGAでボリュームの位置を読み取る方法

FPGAの デジタルIO pinのみで、ボリュームの位置を読み取る回路。

胃腸完成しましたので、公開させて頂きます。

 

 

 

github.com

 

動作

こんな感じに動作します。

 


20170416_120825.mp4

 

原理

f:id:mangakoji:20170416200013p:plain

ごくかいつまんで言うと

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 FPGAのデジタルピンで ボリュームの位置を読み取る WIP

CQ MAX10-FB evaボードでFPGAのデジタルピンでボリュームの位置を読み取る方法を開発中。

 

FPGAのデジタルIOピンでボリュームの位置が読み取れたら、便利だと思いませんか?

ファンクション増えそうでしょ?

やってる例がないので、自分でやってますが、これが結構むずかしい。

 

4方式ほど試しましたが、ダメでしたが、

今日少し目が出てきました。

原因はボリュームへの電流が少なすぎて安定しなかったこと。

10kΩに変えたら、だいぶ安定しました。

 

ボリューム位置検出アイディア

========================

原理的/単純な順に

 

.CR時定数測定

  これは最初から不安定なのはわかってたんですが、

  考えていた補正回路では、ほとんど補正できないことがわかりました。

       電流を増やすと、かろうじて読み取ることができました。

 

.FB方式

  不安定で、リップルって言えない程度に発振幅が大きく、ダイナミックレンジが小さい。

  ヒステリシスの問題 ?

  これもボリュームの電流を増やせば、目が出そうなので、

  こちらも実験したいが、定数の変更などが必要なのでおいおい。

  回路規模も小さいので、これで行けるならこれで。

 

.MSEQ方式

   パタンが単調なのか、分解能がない。

 ダイナミックレンチが小さい

 

. WMSEQ方式

  電流を増やしたらだいぶいい感じに

  もう少しまとめたい

 

 

 

 

 

なんか、いい誕生プレゼントだった気が。いい気分。