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

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

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. code complete,doc 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方式

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

  もう少しまとめたい

 

 

 

 

 

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

 

オルガン環境を CQMAX10-FBへ移行

CQ MAX10-FBで正弦波を発生

CQ MAX10-FBに、オルガン開発環境を移植しました。

これからは、しばらくCQ MAX10-FBで何か作ってみたいなぁと。

 

どうせならハモンド・オルガンっぽい音が出るようにしたいとか、色々妄想中。

 

以前BeMicroMAX10での実装で歪バリバリだったのは、2'sをストレート解釈で聞いてたからでした。

シンクロで見ればバッチリ。

やっぱオシロ使わないとダメね。

 

↓これはデバグ後。ちゃんと正弦波になってるでしょ?

くどいようですが、ΔΣDACを実現してるので、外付けなしで、アナログ波形を出してます。

NTSCのvideo帯域くらいならなんとかなります。

 

 

こちらの記事の続きです。 

mangakoji.hatenablog.com

 

しかし、音声モニタスピーカー環境がよろしいのがなく、どれを使っても、イマイチ正弦波に聞こえなくて困ってる中。

三角波と正弦波を切り替えても。ほとんど聞き分け出来ません。TVの音響系ならハッキリ差が出るんだけど、持ってる音響セットはみんな玩具ですね。

オシロではハッキリ差があるんですが。 

これで、シンセ開発するのは厳しいなぁ。

 

実験用の良いスコアがほしい

和音の実験になる、何か良いスコアがほしい。

ハ長調で書いてあって、且つ半音のないのが必要で、ハ長調しか読めないぼくには結構厳しい条件なのよ。

平均律楽器使ってるなら、転調とかするなよ。全部ハ長調で書けよとよく思う。

昔使ってた『軍艦』のスコアがいまいち間違ってる感じで、気分がモニョる。たしか耳コピだった気がするが。

XY表示で○

さらにリサージュとか。

なにか歪んでますが、1chと2chを入れ替えても同じ歪み方なので、CQMAX10 FPGA音源オシロの1chの方が歪んでるようです。困る。

これやると、この画面でテニスとか作りたくなるね。世界初のビデオゲームっぽいやつ。

色々まとまりなく進行中。

もっそっとまとまってからGitHubにupします。

 

 

最終的に何をつくるつもりなのか...

大盛況 CQ-MAX10に移植した

もう一年も前になるのねー

 

発売してすぐ買った CQ出版のMAX10ボード。ずっと保留してましたが、

 

@s_osafne氏のTerasc DE0版のプロジェクト ファミマチャイム 「大盛況」を移植しました。

 

Githubリポジトリ

→ osafune/CQEXT_melodychime · GitHub

 

  

一昨年末にBeMAX10にも移植しましたが、その時の記事が以下

mangakoji.hatenablog.com

 

 

なんか、大盛況がボクのLチカですな。

 

 

codeはこちら。

github.com

 

enjoy!

「ヒーマンとシーラ1985」を見たよ

He-Man & She-Ra The Secret of the Sword 1985 (Uncut)

 スーパー プレ値ガール

特にやることもないので、史上一番プレ値($999!)のついたので有名な女玩で有名なシーラ、の元ネタアニメ

www.buzzfeed.com

 

映画版「ヒーマンとシーラ」を見ました。

実写版映画は日本でもTVで放映しましたが、アニメはビデオソフトにもなってなかったはず

 

セラムン

なんというか、変身シーンとかアクションのが軽やかだったり四肢が長い演出がセーラームーンぽいなぁと

男が感じるお色気というよりは、女の子が考えるカッコイイスタイルを盛ってありますよね。

アニメで、ハックスラッシュで悪を倒すすーぱーひろいんって、このへんが最初なんでしょうか?

あ、ひょっとすると「ななこSOS」が元祖なの?

シーラは、もちろんワンダーウーマンの影響なんでしょうが、アメコミアニメではスバイダーウーマンなんかもありましたね。

セラムンへのワンダーウーマンやMs.マーベルの影響について語った例って

あんま見ない気がしますね。

 

女キャラが多い!

ヒーマンの映画なのに、やたら女キャラが多いのが印象的。

シーラ以外の女性キャラがみんな変な喋り方してるのも辺でした。

ヒーマンのアニメ映画は、もう一本あるんですが、そちらもシーラ物らしく、本来のヒーマンのメインターゲットの男子はどう思ってたんでしょうね?

つか、この映画、女の子見たの?

 

 

その他

スケルターいいかんじにヤなやつで、いい感じでした。

 

あれだけ振っといてオッコが出ないのは、それ自体がギャグなんですかね?

 

 

なんて、とりとめもなく感想

外国のノート法 : 箇条書き日記 Bullet Journal

さて、外国のノート法のご紹介、

 

mangakoji.hatenablog.com

 

 まずは、Bullet Journal(バレット ジャーナル)をご紹介。

箇条書日記くらいの意味でしょうか。(Bulletは弾丸の意味もありますが)

公式ではBuJoと短縮するみたいです。

 

 このノート法は、ブルックリン在住のRyder Carroll(ライダー・キャロル)氏の考案で、学習障害のある氏が編み出した、ToDoList、スケジュール、ミーティングLog健康管理など、様々な情報を集約して、日記的に管理する方法です。

頭のとっちらかった人が今何をすべきかpick upするのに向いた方法で、それは彼自信が学習障害者であったことで証明されています。

 また、プレーンのノートにテンプレを書くところから説明されているため、様々なノートを使うことができます。日本でも、モレスキンKOKUYO計測野帳ほぼ日手帳で実装してる人がいます。

 また、記録出来る情報も、ユーザーが勝手にカスタマイズしやすく、様々なノートがupされてて、とても一つのメモ法とは思えないレベルです。

こんなカンジ。ノート法の世界もオープンソース時代に突入なのです。

bullet Journal - Google 検索

目次

箇条書日記 Bullet Journalとはどのようなものか?

gigazineの記事がよくまとまっているので、詳細は、こちらを御覧ください

gigazine.net

 

どのようにすればよいのか?

 実際の方法はこちらのサイトが、日本語でよくまとまってます。こちらをご覧ください。

emirakb.hatenablog.jp

何が箇条書日記Bullet Journalか?

これらの記事から読み取れる、箇条書日記の定義を

1)ノートのページ毎にページ数が振ってある

  このページ番号で、すべてのデータをリンクします。

2)INDEX(目次)ページがある

3)Monthly(月次)/weekly(週次)ページがある

4)dayly(日次)ページがある

  日次レビューでこのページにTodoを記載します。細かい情報はページ番号でリンク

5)dayly logに、色々な箇条書アイコン(key)を使って、行動管理

  ToDo自体は、この日次ページに記載します。

--key 新バージョン

  . ToDo(task)

        X done(complete) 

  ○ event

  - memo

       <,> key

  toDo taskは完了の他に、> 次に持ち越し ,<次の機会に持ち越し

  があり、仕掛りやretry処理にも対応可能です。

 -- key 旧バージョン

    [] ToDo(task)

        X done(complete) の他に、

  o event

  . memoなど、通情のToDo内にジャンジャン箇条書で書き込んでしまうのが

      普通のmemo法と異なるところです

6)Future log(want to do)がある

        将来やりたいことなどを記録しておくページです

        これは、オプションかもしれません。 

 

オモシロ・ポイント

- これらを駆使することで、GTDに近いことができることになり、頭がスッキリします。

- daylyページに、メモ的なるものを書き込んでしまうため、ToDoとメモを分離したい人には向きません。

        -> しかし、ページ番号リンクがあるため、混乱はしません。

 

- keyは実装にまかされているため、人によって異なりますが、新バージョがおすすめ。

 

 

リンクなど

こちらが本家です。

 

bulletjournal.com

 

GIGAZINEの記事です

gigazine.net

 

これが、新バージョン(キーが異なります)

How to Bullet Journal

新しいこのバージョン動画はあんまり広がってないみたい。

 

 

箇条書日記法Bullet Journalを作り出したライダー・キャロル氏のインタビュー。機械翻訳ですが、一応日本語ですよ。

www.livescribe.com

 

私のノート法「テセウス・ノート」

そのうち私の メモ法「テセウス・ノート」についてもご紹介しますので、乞うご期待

 

 

mangakoji.hatenablog.com

 書き始めました--180206t

 

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

 あ、忘れてましたが、30日間スクワットチャレンジですが、

 

mangakoji.hatenablog.com


実は最終日にくじけて昨日まで持ち越しました。


2日休んでやっと回復。
32日目にやっと250回コンプしました。

 

もう2週間以上前ですね。

 

なんちゃってスクワット且つ朝夕に分けて250回でしたが。
だいぶ太ももに血が詰まってるカンジがします。

太ももはいい感じに戻ったんですが、問題は細モモだな。

【書評】「悟らなくたって、いいじゃないか 普通の人のための仏教・瞑想入門」

 みなさん、瞑想してますか?

私は1993年くらいから断続的にやってます。

ヴィッパサナは2005年くらいからです。

と、言っても、リトリートに参加するわけでもなく、当時は本もなく、サイトで読んだ記事を、見よう見まねでやってました。

一番やってた時でも、1日45分くらい。

 最近は週に1回か、満員電車で、サマタ系の瞑想をするくらいですが。

 

目次

 

 

最近はメディアで紹介されてる瞑想

昔は、ほとんどメディアに登らなかった瞑想ですが、2005年前後にも、に一度だけ、TVでヴィッパサナ瞑想が紹介されて、あー、本当にあるんだーみたいなカンジでした。禅以外の瞑想。

 

最近はgoogleが取り入れたのを引き金に、だんだんとTVに紹介されるようになって、今はブームっぽいですね。

 

特に気づき系の瞑想、ヴィッパサナやフローやマインドフルネス瞑想が紹介されてるようです。

 

 

 

 

なんというか、この本は、「そうそう、そうなのよ!」という事が多くて、シックリきました。

 

悟らなくたって、いいじゃないか 普通の人のための仏教・瞑想入門 (幻冬舎新書)

悟らなくたって、いいじゃないか 普通の人のための仏教・瞑想入門 (幻冬舎新書)

 

 

 

1) ヴィッパサナのラベリングの問題

 ラベリング法、うまく行く人はうまく行くそうですが、ラベル自体が感情の強化につながるので、よくないこともあるんじゃないかと。

私自身は、妄想からある程度離れられるようになってから、観察しないと、振り回されるだけなんじゃないかとおもます。

特に、苦しみの脳回路の強化に働き、条件になるんじゃないかとおもってましたが、ちゃんとそのことについて、言及してました。

 

2)やっぱり応病与薬

 何度か「抜苦与楽」だよ。そのためには、応病与薬、症状や今までの人生や目指すトコロにあった瞑想方法や説法が必要だよね。と。

そのためには、瞑想を習う側に、どんな瞑想があって、何に効くのか、どこに落ち着くのか?というマッピングが必要だよね。いまはそれが整備されてなくて、

瞑想でかえって苦しむという人が現れているのがこまったことだと。

 教えてもらう方が、選り好みするなんて。と思われるのも恐縮ですが、やっぱり私もマッピングが必要なんだよなぁと思いました。

 

 3)過度に集中しない

 ぼくがヴィッパサナで最も驚いたのは、瞑想に浸っている状態でも。息をしたり、回りを見回したり、回りを観察できること。そして、瞑想がすすめば、多分瞑想したまま生き続ける、生活することもできる。ということ。

 更に言うと、瞑想状態で生きることを勧める人すらいることでした。

この本には、過度に集中すべきでないことが推奨されていて、瞑想状態、観察モードに切り替えて生きることすらも薦めています。

実際それがgoogle的にはマインドフルネスでフロー状態なのでしょう。

そのためには、過度に集中した状態ではなく、

むしろ、瞑想状態を浅く保つことの方が重要で、それは、ボクには相性がいいなぁと思いました。 

気づき(ヴィッパサナ)系の瞑想

  本や雑誌では、瞑想には、大別して「慈悲」「集中」「気づき」の3種類があるというのも紹介されてるんですが、なんだか、TVでは、全てを集中瞑想として紹介されているようで、そこがちょっと気になります。

  googleの瞑想の紹介を見ると、いきなり気づきの瞑想を紹介していて、集中から入ったぼくからすると「その順番だと、妄想が静まらなくて、気付きどころじゃないだろ?」と心配です。

 異論もいろいろありそうですが、やっぱり王道で「慈悲」→「集中」→「気づき」の順番にやるのが近道なんじゃないかなぁと。

 

なんかとりとめがないですが。