« 2021年3月 | トップページ | 2021年5月 »

2021.04.30

PCとZYNQ Linux間のTCP/IP通信プログラム(1)

私はCosmo-ZというDAQボードの開発をライフワークにしています。Cosmo-ZはZYNQでLinuxが動いているスタンドアローンの計測器で、APIが公開されているので、Linuxのアプリを書けばオリジナルな計測が可能になる、ということでした。

現状のCosmo-ZのAPIは以下のような構造になっています。APIの詳細はこちらにあります。

Cosmozapistack

このようなAPIを公開してきたのですが、やはり、ユーザは計測プログラムはZYNQ Linuxではなく、PC上で計測をしたりアプリを作ったりしたいのではないのかとも考えてきました。

 

そこで、PCで動く計測アプリが作れるようにと考えてきたのですが、Cosmo-Z APIの1個1個の関数をRPCにするのは関数名や呼び出し規約を登録が大変だし、APIの粒度を上げて抽象的な操作をできるようにするには新たなAPIの開発が大変だし、ということであまり進んできませんでした。

実際に粒度を上げてPythonのXMLRPCで接続しようとしたり、LabViewインタフェースを作ったりもしてきましたが、どれもうまくいきませんでした。うまくいかなかった原因というのは、XMPRPCはそもそも重いし、Pythonで計測データが格納された大きな配列を扱うのはデータのコピーが何度も発生して無駄が多いし、LabViewインタフェースは図面で描くのがわけがわからなくなったりというほかに、トリガ待ちという状態でブロッキングするか否かということも大きかったように思えます。

そもそもPythonとか既存のRPCのしくみを使おうと思っていたのは、私自身のTCP/IPソケットプログラミングに対する苦手意識からなのですが、高位の言語によるAPIの開発がうまくいかなかったので、LinuxとWindowsのソケットプログラムをもういちど頑張ってみました。

 

今回の設計では、思い切って大胆にレジスタリード、レジスタライト、メモリリード、メモリライトをTCP/IP越しにできるようにしてみました。

Cosmozapistack2

つまり、粒度の低い、逆に言えばきめ細かくC言語で制御できるAPIをWindows上で動かし、メモリ操作やレジスタ操作が発生した場合にTCP/IP経由で操作するというわけです。

 

| | コメント (0)

2021.04.28

Wio Terminalを買ってみた

最近流行りのWio Terminalというのを買ってみました。

Wio1

買う前からいろいろ疑問点があったのでそれを確認してみたかったという感じです。

【疑問点(買う前)】

  • 書き込みはどうやるの?
  • USBシリアルは内蔵されているの?
  • 開発環境は?自分でコマンドラインでできるの?
  • PythonとかRUSTとか言われているけど、C/++C言語で開発できるの?

 

買ってみてすぐにわかったのですが、これはArduinoの亜種でした。だからシリアル通信もUSBもWiFiもTFT液晶もみんな、Arduinoライブラリを取り込んで使うのですね。

開発はArduino IDEを使ってやるのがデフォルトのようで、Arduino IDE上からプログラムの書き込みはできます。

また、リセットスイッチをカチカチと2回スライドさせるとUSBドライブとして認識されるようになって、uf2ファイルをここに放り込めば、そのイメージで起動するようになります。UF2ファイルはbinファイルをbossacというアプリで変換して作るようです。

USBシリアルはソフトウェアで実現されていて、TeraTermがあればほかに何もいりません。ArduinoのSerialでprintlnとかすれば、USBシリアルとしてTeraTermで通信できます。

開発環境はArduino IDEがなかなか使いづらいのですが、arduino-cliというツールがあるので、それを使えばコンパイルや書き込みなど、Arduno開発環境でできることがコマンドラインでできるようになります。神ツールだわー。

arduino-cli compile --fqbn Seeeduino:samd:seeed_wio_terminal --additional-urls https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json

Arduinocli

ソースでも配布されていますがWindows版のビルドされたexeを探して持ってきて使っています。

arduino-cliをドキュメントも読まずに使ってみているのですが、Arduinoスケッチを対象にしているので、コンパイルされる対象のファイルの拡張子は.inoのようです。<プロジェクト名>/<プロジェクト名>.inoというファイルを強制的にビルドしてしまうようです。

arduino-cliが呼び出しているコンパイラはarm用のgccなので、拡張子をcやcppにしたり、ライブラリを追加できるようなやり方を調べてみたいですね。 

 

結論を言うと、Wio TerminalはC/C++言語で開発可能なマイコンボードとして使えそうです。

私がいま構想中のプロジェクトでは、ネットワーク接続ができてスマホから操作できるハードウェアをたくさんの人に低価格で配布したいのですが、そういったプラットフォームとして最適と言えると思います。

| | コメント (0)

2021.04.27

双方向レベル変換IC ADG3308が発振する

なひたふは最近レベル変換ICとしてAnalog DevicesのADG3304やADG3308というの使ったのですが、このたびADG3308が発振するという現象に遭遇してハマったので、悪い事例(Bad knowhow)として紹介します。

ADG3304/3308は双方向のレベル変換ICで、FPGAの3.3Vを周辺ICの1.8Vなどと変換してくれたり、ADC用のコントロール信号のための信号分離に活用することができるとても便利なICです。対応している電圧は1.15V~5.5Vとワイドです。

最大の特徴はなんといっても双方向バッファでありながら自動切換えであること。DIRピンがないのです。そのため1ピンごとに双方向に切り替え可能なバッファをしてくれます。

 

動作原理を簡単に言えば、信号のエッジを見て動作しているようです。

ADG3308を使った回路としてこのような回路を作りました。

Adg3308_20210427184401

ところが、この回路は発振しました。

データシートによるとVCCA<VCCYでなければならないそうで、つまりAの側の電圧はYよりも常に低くないといけないのです。(またENはY側の電圧基準で動きますので、上の回路はその意味でもよくない)

そのことを知らずにFPGAのI/O 3.3VをADCの5Vに変換しようとしたら見事に発振しました。しかも300mAくらいの電流を消費して基板が熱くなります。大変間違った設計でした。

発振の波形をご覧ください。

Adg3308_osc1

最初はADC用のクロックが出ているな・・と思ったのですが、これはCS信号でした。

Hを出力しているだけなら発振しないようですが、3.3VのFPGA側がLレベルになると発振します。

Adg3308_osc2

今回は試作としてパターンカットでVCCYにも3.3V電源を供給することで動作できましたが、基板を作り直すときにはVCCY=1.8Vにしないといけないですね。データシートによればVCCY=VCCAでもぎりぎりOKなようですが、Y側の信号入力に3.3V以上(4.0Vとか)がくるとやっぱり発振します。

ADG3308は便利なICなのですが、VCCY≦VCCAの条件には気を付けてください。

| | コメント (0)

2021.04.26

遅いDAコンバータから鋭いパルスを出す方法

DAコンバータにはセトリングタイムやスルーレートというのがあって、狙った電圧がピタっと出せるわけではありません。

スルーレートによって立ち上がりは坂道になるし、狙った電圧に振動しながら落ち着くのでセトリングタイムというのがあります。

一般に1MHz帯域クラスのDAコンバータでは急峻な立ち上がり波形を作ることができませんが、任意の電圧の矩形波を出すために高速DACを使うのもコストや電力の面で得策ではありません。

そこで、DACの出力をちょっと細工してみました。

Dac_pulse

このように低速なDACでありながら立ち上がり時間が5nsを切っています。

50オームの終端を外して、時間軸を拡大してみるとリンギングはしていますが狙った電圧が出ています。

Dac_pulse2

どういう回路かというと、こんな回路になっています。

Dac_pulse_circuit

一般的には、低速のDACの出力は下の図のようにマイクロ秒オーダーの時間がかかるので台形になります。

Dac_slow

そこで、DACから出力された電圧をコンデンサに溜めておいて、アナログスイッチを使って出力につなぐようにすると、瞬時に立ち上がる電圧が得られるというわけです。オシロで測った限りでは5nsくらいの立ち上がり時間でしたが、実際にはもっと鋭いかもしれませんね。

設計通りに動いたので、ちょっと嬉しかったですね。

 

| | コメント (0)

2021.04.21

ZYNQのLinuxでCAN通信をするには(後編)

LinuxでCANを使うには、カーネルのビルドで

CONFIG_CAN=y
CONFIG_CAN_RAW=y
CONFIG_CAN_BCM=y
CONFIG_CAN_GW=y
CONFIG_CAN_RCAR=y

を設定するそうですが、上の4つはxilinx_zynq_defconfigの設定ではデフォルトでONになっています。CAN_RCARはReneas R-CARのドライバなので無くても構いません。なくても影響ありません。

CANを認識するにはデバイスツリーにも書かなければなりませんが、hsiを使ってデバイスツリーを作っているのであれば

&can0 {
status = "okay";
};

という記述が追加されているので、自動的にCANが有効になっているデバイスツリーが作られます。

こうして、Linuxが起動するときに、

CAN device driver interface
・・・
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20161123 t)
can: netlink gateway (rev 20130117) max_hops=1

という起動メッセージが流れて、CANが使えるようになったことが示されます。

Linuxが起動したら、最初に

apt install can-utils

で、CANユーティリティをインストールします。

ip a

でIPのインタフェースを見てみると、

Can_ip

と、このようにcan0というインタフェースが出現していました。

2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can

たしかにcan0はIPの中にいるのですが、canの上にIPを乗せてTCP/IPで通信できるわけではありません。

canとタイプしてTABを押してみると、can-utilsの中にある

can-calc-bit-timing cangen cansend canbusload cangw cansniffer candump canlogserver canfdtest canplayer

というプログラムが出てきますが、動作確認に使うのはcansendとcandumpです。

まず、

ip link set can0 type can bitrate 10000000

でビットレートを設定します。ビットレートはどこまで上げられるかはわかりませんが、1MbpsではOK。10MbpsではNGでした。

 

ビットレートの設定が終わったら、

ip link set can0 up

もしくは

ifconfig can0 up

でリンクをアップさせます。

そうしたら2台の装置をつないで、片方の装置で、

cansend can0 123#456789

のようにしてデータを送ります。#の前は識別子というCANのノード番号で、#の後ろは最大8バイトの送りたいデータです。データは16進数で書きますが偶数個書かないといけません。

もう一方の装置では

candump -c -c -tA can0

としてCANバスの内容をダンプするようにしておきます。-cがダブっている理由はわかりませんがhelpにそう書いてあるので2回書いています。-tAは絶対時刻で表示するというものです。

その結果を示します。

Candump

このように、片方の装置から送った最大8バイトのデータがもう一方の装置に送られました。

 

最初、通信ができたときには感動したのですが、can-utilsにあるcansendとcandumpはこのくらいのことしかできません。

っていうかCANの標準フレーム自体が8バイトまでのデータしか送ることができません。大きなデータを転送したいときにはどうしたらいいんでしょうね?この上にさらに独自のプロトコルを乗せるのでしょう。

たった8バイトしか送れないって効率悪そうじゃないですか!?

 

いろいろ疑問は尽きないのですが、自分のプログラムの中からCANを使うにはSocketCANというネットワークスタックを使うのが一番簡単なようです。SocketCANを使えばTCP/IPで使うようなsocketやbindといった関数に、新たなプロトコルファミリPF_CANというのが使えるようになって、readとかwriteを使ってフレームを送ることができるようになるようです。

それでも8バイトまでのCANの標準フレームの送受信なので、その上のプロトコルは独自に実装することになるのでしょう。

いや、でも、8バイトって厳しい・・

 

| | コメント (0)

2021.04.20

ZYNQのLinuxでCAN通信をするには(前編)

ZYNQのLinuxでCANを使う方法がわかったので紹介します。

CANを使うにはまず、PSの設定でCANを有効にします。

Can1

MIOからCANのポートが出てくるので、これをCANドライバにつなぎます。

Can2

CANドライバというのはLVCMOSやTTL、LVCMOS18といったFPGAに馴染みのあるロジック信号をCANのレベルに変換してくれるICのことです。私はLinear TechnologyのLTC2875を使いました。

Can3

このドライバは何でもよいのですが、高速CANと低速CANというのがあって、通信したい相手と合わせておきます。(危ないところだった)

15pFのコンデンサはデータシートどおりです。このLTC2875にはRSという端子があって、これをLにしないと動作してくれません。

 

高速CANの波形は下記のWikipediaの画像のように、0をドミナント、1をリセッシブといって、ドミナントのときに差動ドライバが駆動されるようになっています。

Can4

ドミナント(支配)のほうが強いわけですね。I2Cなどとの類似で考えると、Lのときは強くオープンドレインで引いて、Hがプルダウンで弱く開放するようなイメージだと思いますが、それを差動でやっているようです。

CANにはHiとLowの信号線があって、Hiのほうは中心電圧から上に振れます。実際の波形は下の図のとおり。CANのバス側はこのような差動信号となっています。120Ωで終端するとかありますが、細かいので省略します。

Can_bus

一方、CANのFPGA側は普通のロジック信号です。

Can_logic

CANの波形はこの程度の長さの「フレーム」で送るのですが、'1'が5回連続するともう一個'1'を挿入するビットスタッフィングが行われたりしますので、若干伸び縮みします。

また、CANの通信では、送信ノードがフレームを送って、それを別の受信ノードが受け取ってエラーなく受け取れたときに、レシーバが「ACK」ビットを駆動します。上の波形の中のどこか1ビットに「ACK」が入っています。例えるならI2CのACKのように、1つのフレームの中で受信ノードがバスを駆動してきます。(そのため、ACKの前はリセッシブになっている)

だから、「受信できたよというパケットのようなもの」を受信側が返す必要はないし、送信側はACKが戻るまで延々とフレームを繰り返し出し続けます。言われなくても再送するようです。なるほどね。

Wikipediaによると下記のような波形になっているようです。標準フォーマットでは8バイトまでしか送れませんが、拡張フォーマットでは64バイトまで送れるそうです。

CRCがありますね。CRCを計算して正しく受信できていれば誰かがACKを返すのでしょう。

Can_frame

あと、速度を合わせるためのクロックはないので、それぞれが通信速度を合わせておかなければなりません。

CANの物理層に関しては説明はこれくらいです。

次はLinuxでどう扱うのかを説明します。

| | コメント (0)

2021.04.14

福島処理水のトリチウム放出と、韓国の月城原発の本当の問題点

福島の処理水をトリチウムを海に流すなという声に対して、韓国はもっと流しているという反論があるようですが、この問題を深く掘り下げてみることにしました。

ツイッター界隈でよく目にする図があるわけですが、

Sankei

 

この図表によれば、

  • 韓国の月城原発が毎年136兆ベクレル
  • フランスの再処理施設で毎年1京ベクレル
  • カナダの原発で毎年495兆ベクレル

とあります。それに対して福島の処理水に含まれるのは全部で1000兆ベクレルだそうですが、全部放出したとしても、世界的に見ればそれほど多いわけではありません。トリチウムで1000兆ベクレルというのはわずか20グラムくらいだそうですね。東京ドーム一杯分くらいある処理水の中に、トリチウムはヤクルト1本分くらいです。海の水は東京ドームより多いのです。

そもそも自然界でトリチウムは毎年7京ベクレル発生しているし、米英仏露中が行った核実験によるトリチウムが180京ベクレルくらいはまだ残って海や大気にあるので、福島の処理水を全部排出しても汚染は0.1%も増えません。

兆とか京とかすごい単位が並んでいますが、アボガドロ数の原子が13年で半分なくなるわけですから、それくらいはあるでしょう。

 

  

福島の処理水に含まれるトリチウムを流したからといってどうってことないし、韓国の月城原発の垂れ流す量でさえ微々たるものです。

 

ですが、韓国の月城原発については調べてみると、いろいろ不可解に思えることが出てきます。

そもそも、なぜ月城原発はこんなにたくさんのトリチウムを出すのかということです。

それは、CANDU型の原子炉だからです。CANDU炉というのは冷却に重水を使った原子炉で、濃縮しないウランをそのまま燃料として使えて、メインテナンスで止める必要がないというメリットがあります。しかし、重水に中性子があたってトリチウムが発生しやすいのと、廃棄物でプルトニウムが多く作られてしまうというデメリットがあります。

Candu

中国の秦山原子炉もCANDU炉ですが、それまで濃縮ウランによる核兵器しか作れなかったのが、CANDU炉によってプルトニウム型の兵器を作れるようになったといわれています。

Taizan

インドの核兵器もCANDU炉で作ったプルトニウムです。

要は、CANDU炉は兵器級プルトニウムに直結しています。

 

核燃料の廃棄物から燃え残ったウランやプルトニウムを再び燃料にするため取り出すことを再処理と言いますが、生成物が異なるので再処理のやり方が普通の軽水炉と異なってきます。

カナダは天然ウランが豊富で、放射性廃棄物を捨てる土地もあるので、ワンスルーといって再処理をしない方式ですからCANDU炉が経済的にも良いわけです。

経済性の問題からCANDU炉は日本では導入しませんでした。CANDU炉を導入しないということは国際社会に対して核武装は目指していないというアピールにもなると私は考えています。

韓国も日本と同じくウランは輸入に頼っていて土地もないのに、なぜ導入したのでしょうね?

 

なお、世界中で産業用や研究用に流通しているトリチウムの量は年間100gくらいだそうで、そのほとんどはカナダで作られています。CANDU炉がすごい賢いのか、アメリカやロシアは輸出しないだけなのかはわかりません。トリチウムを海に流している国の上位は、イギリス、フランス、アメリカです。中国とロシアは不明。

トリチウムの用途は、平和じゃない目的としては核弾頭の小型における「ブースト」で必須の材料となります。初期のころの核分裂型の爆弾ではなくて、ミサイルに積んで飛ばしたりするには核兵器を100kgくらいまで小さくして威力を上げる「核の小型化」という技術が必要なのですが、トリチウムがなければつくれません。トリチウムとプルトニウムが多く作られるというデメリットは、核武装を目指す国にとっては都合がよいわけです。

 

問題は、なぜ韓国がそんなトリチウムとプルトニウムが多く作られるCANDU炉を持っているのかということです。韓国の月城原発の1~4号機がCANDU炉で、1983年から1999年にかけてつくられたそうですが出力は70万kwです。同時期に作られた日本の刈羽柏崎原発は沸騰水型で110万kWです。しかも経済的にもよくないCANDU炉をなぜ作ったのか、謎ですね。

そういえば、1994年にアメリカのクリントン大統領は北朝鮮に軽水炉を2機プレゼントしました。軽水炉の廃棄物に含まれるプルトニウムは濃縮して兵器転用するのが難しいので苦渋の策だったと思うのですが、もしかすると何か関係があるのかもしれませんね。1990年代、国際的にどういう合意があったのか。当時、高校生~大学生であった私にはわかりません。

 

さて、ウランを核分裂させればいくらかの割合でウランからトリチウムが発生します。重水炉では重水からもトリチウムが発生するので、軽水炉よりも多くなります。CANDUやHWRという炉が重水炉です。

イギリスのAGRというのはガス冷却炉で、発生したトリチウムがステンレスの菅からトリチウムが漏れていく(水素は鉄をすり抜ける)ので排出量が多くなっています。 

日本の場合は軽水炉(PWRまたはBWR)なのでそれほど発生する量は多くありません。

Sekai

再処理施設のトリチウムが桁違いに多いのは、燃料集合体を砕いて粉砕するときに被覆管の中に閉じ込められていたトリチウムが出てくるからで、新たにトリチウムを作っているわけではありません。そういえば日本も再処理工場を建設していたのですが、まだ完成していないはずですね。完成すれば1京ベクレルくらい出るはずですが、新型転換炉ふげんも、高速増殖炉もんじゅも計画が止まったので、再処理をする意味がなくなってしまいました。再処理工場は永遠に完成しないかもしれません。逆にそれが核不拡散の証でもあります。

 

韓国がなぜ、トリチウムとプルトニウムを多く作るCANDU炉を持っているのか、脱原発や、反原発、反核兵器を訴えかけている人は、そこに注目してみてください。

 

| | コメント (0)

2021.04.13

Artix-7用のFPGA拡張ベースボードの販売を再開

特電のArtix-7ボードやSpartan-6ボードに挿して、LAN接続やHDMI出力をおこなうためのボード

「FPGA拡張ベースボード」

の販売を再開しました。

1405790433_fextbase_top

Artix-7にMicro Blazeを入れてLinuxを動かしたり、ハードウェアでLANからイーサネットのパケットを出すDDoSを体験してみたりといったことができます。USB-UARTが付いているので、ソフトウェアプロセッサの動作を試してみたり、ユニバーサルエリアにちょっとした回路を組んでみるのに最適です。

Extbase

全部で残りは8個です。

ご注文はオンラインショップで承ります。

https://www.tokudenkairo.co.jp/quote/detail.php?pid=289

 

 

 

 

 

| | コメント (0)

2021.04.12

RXマイコンの在庫をヤフオクに出品しました。

世界的な半導体不足に加えてルネサスの工場火災によって、RXマイコンの供給が枯渇していると聞きます。

特電にはRXマイコンのうちRX62NとRX63Nの100pinの在庫があります。もう使用することもないかと思っていたのですが、昨今の半導体不足により、急ぎで必要とされている方がいらっしゃいましたらお譲りします。

【RX62N】

Raxinoなど、自社製品の製造に使用した残りで、現物を数えた限りでは13個あります。

  • RX62Nマイコン
  • 正式型番R5F562N8BDFP#V0
  • コア RX600 32bit 100MHz
  • ROMサイズ 512kB
  • RAMサイズ 96K x 8
  • 100ピンのQFPパッケージで14mm×14mmです。
  • 13個で15,000円(税別)

https://page.auctions.yahoo.co.jp/jp/auction/n501023373

Rx62n

【RX63N】

GR-SAKURAなどの製造に使用した残りで、現物を数えた限りでは149個あります。

  • RX63Nマイコン
  • 正式型番R5F563NBDDFP#V0
  • コア RX600 32bit 100MHz
  • ROMサイズ 1MB(1M x 8)
  • EEPROMサイズ 32K x 8
  • RAMサイズ 128K x 8
  • 100ピンのQFPパッケージで14mm×14mmです。
  • 149個で150,000円(税別)

【使用上のご注意】

いずれも新品未使用ですが、保存状態はそれほど良くはありません。開封されている状態で8年ほど当方の倉庫に保管されていたので、実装前にベーキングはしたほうが良いと思われます。

現物優先でノークレーム・ノーリターンでお願いします。

価格やその他条件は交渉次第です。

 

| | コメント (0)

2021.04.02

今年度の方針

今年度(・・と言っても特電は4月末で決算なので今年度ではないのですが)の方針は、特電の製品と他社製品の連携がうまく取れるようにしていきたいと、ふっと思いました。

このアイデアは1~2年前から思っていたことなのですが、MITOUJTAGを外部のツールから連携して操作できるようなインタフェースを設けたりとかいうこと、です。MITOUJTAGをDLLにするとかでもいいし、CORBAとかDCOM/COM+なんでしょうかね???よくわかりませんが、外部からMITOUJTAGを通じてバウンダリスキャンを実行したり、基板検査を実行したりすることが容易にできるインタフェースを設けるということです。

それと同時に、OpenOCDとも連携して、MITOUJTAGからOpenOCDを通じて各種CPUのデバッグができるようにといった拡張も考えていきたいです。

 

Cosmo-Zに至っては、いままでは「Cosmo-ZはLinuxが動いている高速ADボードだから、ZYNQのLinuxで動くプログラムを組めばカスタマイズ可能」という触れ込みだったのですが、お客様が求めているのはZYNQのLinuxで動くことじゃなくて、PCから計測できることだろうと今さらながら気が付いてきました。

PC上で動くC#やCのプログラムと連携して「普通のDAQ」として動くような改良をしていきたいと思います。

 

自分ひとりでできることには限りがあるので、外部の洗練された仕組みを使ってインタフェースする、というのを目指していきたいと思っています。

まずはCosmo-Zの改良から始めます。

 

| | コメント (0)

2021.04.01

浅草寺にお参り

ふぅ・・・。何とか年度末を無事に過ごすことができました。

部品の入手も、パズルのピースが埋まるようにぴたっと入手できました。

資金繰り的にもギリギリだったけど間に合いました。3月の売掛金で4月の支払いも大丈夫そうです。

住宅ローンも、用意できた頭金がギリギリだったけど、本当にギリギリで足りました。

納期とかも、一日一日が機械仕掛けの人形のようにぴたりぴたりと仕入れた部品が届いたり、実装が上がったり、納品したりと、不思議なくらいうまくいきました。

ここまで幸運なことが続いたのは、きっと神仏のご加護があったに違いないと思い、今日は浅草寺にお礼参りに行ってきました。隅田川沿いは桜が咲いていて綺麗でしたよ。

 

 

| | コメント (0)

« 2021年3月 | トップページ | 2021年5月 »