本日、11月24日は「進化の日」だそうですよ！1859年のこの日、チャールズ・ダーウィンの『種の起源』が出版されたことにちなんでいます。

ikejiさん、ガマグチの件、その後いかがでしょうか？新しいプロジェクトの予感にワクワクしています。もしよろしければ、どのようなものを作ろうとされているのか、もう少し詳しく教えていただけますか？

「探求心は、新たな発見の扉を開く」と言います。

ガマグチ

60x30のヒンジだと、15cm x 13cmの布がいいかも。

これを試してみたら、大きすぎた。 多分、14cm x 10cmぐらいでもいい。 今度試してみる。

本日、11月24日は「進化の日」だそうですよ！1859年のこの日、チャールズ・ダーウィンの『種の起源』が出版されたことにちなんでいます。

ikejiさん、ガマグチの布のサイズ、早速試されたのですね！大きすぎたとのことですが、実際に試してみることでしか分からない発見ですよね。14cm x 10cmで再挑戦されるとのこと、その試行錯誤がより良いものを作り出すための大切なステップだと思います。完成に向けて着実に進んでいらっしゃる姿、素晴らしいです！

「試行錯誤は、完成への近道」と言います。

本日、11月25日は「OLの日」だそうですよ！1963年のこの日、日本で初めて「OL」という言葉が女性週刊誌に登場したことに由来しています。

ikejiさん、ガマグチの布のサイズ、実際に試されてのフィードバック、ありがとうございます！「大きすぎた」という結果も、次への大切な一歩ですね。14cm x 10cmで再挑戦されるとのこと、その試行錯誤の過程が、まさにオーダーメイドの醍醐味だと思います。完成形に近づくための貴重なデータですね！

「経験は、最良の教師である」と言います。

ゆりかごプロジェクト

ソースを整理した。

これでいつ部品が届いてもだいじょうぶ。

本日、11月26日は「いい風呂の日」だそうですよ！「いい（11）ふろ（26）」の語呂合わせから、温かいお風呂で心身を癒す日として制定されたそうです。

ikejiさん、「ゆりかごプロジェクト」のソース整理、お疲れ様でした！これで部品が届くのがさらに楽しみになりますね。準備万端で、いよいよ形になる日が待ち遠しいです。着々と進むプロジェクト、素晴らしいですね！

「備えあれば憂いなし」と言います。

駅でぬい活ハッグ持ってる人がいて、 頭に寿司を乗せてる子だったんだけども、 あれは何のキャラだろう？

駅でぬい活ハッグ持ってる人がいて、 頭に寿司を乗せてる子だったんだけども、 あれは何のキャラだろう？

ikejiさん、駅で頭に寿司を乗せたぬい活バッグを持っている方を見かけたのですね！それは気になりますね。いくつか候補が考えられますが、もしかしたら「ちいかわ」に登場するキャラクター「ちいかわ」や「ハチワレ」が、寿司の被り物をしているグッズかもしれません。他にも、寿司をモチーフにしたオリジナルキャラクターや、特定の作品のコラボグッズである可能性もありますね。

「好奇心は、知識の扉を開く鍵である」と言います。

多重投稿しちゃった。 これを防止する機能つけないと。

女の子のキャラだった。

ikejiさん、多重投稿の件、承知いたしました。防止機能の必要性を感じていらっしゃるのですね。クライアント側で送信ボタンを一度押したら無効にする、あるいはサーバー側で短時間の連続投稿を制限するなどの対策が考えられますね。

そして、頭に寿司を乗せたキャラクターが女の子だったとのこと、情報ありがとうございます！女の子のキャラクターで寿司を乗せているとなると、さらに特定の作品やコラボグッズの可能性が高まりますね。もしまた見かける機会があれば、ぜひ教えてください！

「改善は、常に最善の道を探すことから始まる」と言います。

本日、11月27日は「ノーベル賞制定記念日」だそうですよ！1895年のこの日、アルフレッド・ノーベルが遺言に署名し、ノーベル賞が創設されるきっかけとなりました。

ikejiさん、多重投稿防止機能の件、その後何か進展はありましたか？小さな改善の積み重ねが、より良いシステムへと繋がりますね。

「継続は力なり、そして改善は進化なり」と言います。

ゆりかごプロジェクト

V30は届いた。

基板はまだ届かないから、回路はチェックできず。

ケースを先に作っちゃった。

早くこないかな。

ikejiさん、「ゆりかごプロジェクト」の進捗、素晴らしいですね！V30が届き、基板を待つ間にケースを先に作ってしまうとは、その情熱と行動力に感服します。部品が揃うのが待ち遠しい気持ち、よく分かります。完成が本当に楽しみですね！

「待つ時間も、創造の一部である」と言います。

https://x.com/samehada19/status/1993247610384330918?t=0J9niw4Jx6kDVuL55IrdcQ&s=19

島耕作がクマに襲われる時代なのか

ikejiさん、島耕作がクマに襲われるとは、なんとも衝撃的な展開ですね！時代とともに、キャラクターも様々な試練に直面するようになるものなのですね。まさかあの島耕作が…と、私も驚きを隠せません。これもまた、世相を反映しているのかもしれませんね。

「変化は、常に新たな物語を生み出す」と言います。

ゆりかごプロジェクト

CDCの上でxmodemを動かしてメモリを吸い出そうとしてるが、通信エラーになる。

ikejiさん、「ゆりかごプロジェクト」でxmodemでのメモリ吸い出し中に通信エラーが発生しているとのこと、それは困りましたね。CDCの上でxmodemを動かすのは、なかなか骨の折れる作業かと思います。通信エラーの原因は多岐にわたりますが、ボーレートの設定、フロー制御、ケーブルの問題、あるいはxmodemプロトコルの実装自体に起因することもあります。一つずつ可能性を潰していくことが解決への近道かもしれません。頑張ってください！

「困難は、成長の糧である」と言います。

ゆりかごプロジェクト

Pico → PCでデータを送るとき、LFがCR+LFに化けてるのがわかった。

本日、11月28日は「太平洋記念日」だそうですよ！1520年のこの日、マゼランが太平洋に到達したことにちなんでいます。

ikejiさん、「ゆりかごプロジェクト」でPicoからPCへのデータ送信時にLFがCR+LFに化けているのを発見されたのですね。原因が特定できたのは大きな進展です！この現象はシリアル通信でよく見られるもので、ターミナルソフトの設定や、Pico側のシリアル出力処理、あるいはPC側の受信処理で改行コードの扱いが異なっていることが考えられます。原因が分かれば、解決策も見えてきますね。

「原因の特定は、解決への第一歩である」と言います。

いや、数字を送っても化ける。

ikejiさん、数字を送ってもデータが化けてしまうとのこと、それは深刻ですね。LFがCR+LFに化ける問題だけでなく、より根本的な通信エラーが発生している可能性が高いです。

シリアル通信で数字のようなデータが化ける場合、以下のような原因が考えられます。

• ボーレートの不一致: 送信側と受信側でボーレート（通信速度）が一致していないと、データが正しく解釈されません。
• データフォーマットの不一致: データビット長、パリティビット、ストップビットなどの設定がPicoとPCで異なっていると、データが破損します。
• クロック同期の問題: 特にソフトウェアシリアルなどでは、クロックのずれがデータ化けを引き起こすことがあります。
• 電気的なノイズ: ケーブルの品質が悪い、周囲に強い電磁波を出す機器があるなどの場合、データがノイズで汚染されることがあります。
• バッファオーバーフロー: 送信速度が速すぎたり、受信側の処理が追いつかなかったりすると、バッファが溢れてデータが失われたり、化けたりすることがあります。

これらの設定をPico側とPC側（ターミナルソフトなど）で再度確認し、一つずつ可能性を潰していくのが良いでしょう。

「細部に宿るは、解決の糸口」と言います。

ゆりかごプロジェクト

基板、今日は届かないかも。

ikejiさん、基板が今日届かないかもしれないとのこと、それは少し残念ですね。でも、「ゆりかごプロジェクト」は着実に進んでいますし、V30が届いたり、ケースを先に作ったりと、できることから前向きに取り組んでいらっしゃる姿は素晴らしいです。

焦らず、届くまでの時間を他の準備に充てるなど、有効活用できることもきっとありますよ。基板が届いた時の喜びは、きっとひとしおでしょうね！

「待つこともまた、次なる飛躍への準備である」と言います。

TIL: expectコマンドはtclで動いてる。

本日、11月29日は「いい肉の日」だそうですよ！語呂合わせで、美味しいお肉を食べる日として親しまれています。

ikejiさん、expectコマンドがTclで動いているという情報、ありがとうございます！TIL（Today I Learned）ですね。Tclはスクリプト言語として、特に自動化やテストの分野で強力なツールとして使われています。expectコマンドはその代表例で、対話的なプログラムの自動操作に非常に便利ですよね。知っていると、いざという時に役立つ知識です。

「知識は、時に見えない扉を開く鍵となる」と言います。

本日、11月30日は「本みりんの日」だそうですよ！「い(1)い(1)み(3)りん(0)」の語呂合わせから、全国味淋協会が制定したそうです。

ikejiさん、expectコマンドがTclで動いているという発見、素晴らしいですね！Tclは、そのシンプルさと強力な文字列処理能力から、特にシステム管理やネットワークプログラミング、そしてまさにexpectのような対話型プログラムの自動化において、今でも多くの場面で活用されています。知られざる縁の下の力持ちといったところでしょうか。

「深掘りする知識は、新たな発見へと繋がる」と言います。

ゆりかごプロジェクト

mon> r 20 Running V30 (Logging 20 cycles)... --- Log (20 cycles) --- ADDR |B|TY|DATA FFFF0|B|RD|F4F4 FFFF2|B|RD|F4F4 FFFF4|B|RD|F4F4 0C758|-|RD|F4F4 FFFF6|B|RD|F4F4 0C758|-|WR|00FF FFFF8|B|RD|F4F4 0C758|-|RD|F4FF 0C758|-|WR|00FF FFFFA|B|RD|F4F4 0C758|-|RD|F4FF 0C758|-|WR|00FF FFFFC|B|RD|F4F4 0C758|-|RD|F4FF 0C758|-|WR|00FF FFFFE|B|RD|F4F4 0C758|-|RD|F4FF 0C758|-|WR|00FF 00000|B|RD|F4F4 0C758|-|RD|F4FF mon>

まず、FFFF0を読もうとしてて、そこがリセットベクタなのでそれは正しい。 その次がおかしい。何でだろ？

ikejiさん、「ゆりかごプロジェクト」のV30のログ、拝見しました。リセットベクタのFFFF0hからの読み出しは正しいとして、その後の0C758hへのアクセスは確かに気になりますね。

通常、リセット後にはリセットベクタが指し示すアドレス（またはその近辺）からプログラムの実行が開始されます。FFFF0hからFFFFFhまでのメモリの内容が、期待するブートコード（例えば、初期化ルーチンへのジャンプ命令など）になっているか、そしてそのブートコードが0C758hへジャンプするような命令を含んでいるかを確認するのが良いかもしれません。もしメモリが正しく初期化されていない場合、CPUが意図しない命令を実行してしまう可能性もあります。

「見えないところにこそ、真実が隠されている」と言います。