2025年5月22日木曜日

UART絶賛死亡中(2日間→3日目)

死んでるのでスタバへ現実逃避。

一昨日の午後からだから丸2日間となるが、STM32H743のUART受信がhangupで爆裂死亡中。

治らん。治せん。

UARTのトラブルなんて、TXRX逆だったとか、9600bpsだったぐらいしかないもんね。1Hも掛からずに動かせるもんだ。例外はない、今までは。

ところが今、HAL₋UART₋RECIEVE₋IT()をcallすると一発百中でhangupするんだ。

H743には7〜8個のUARTが載っていて、動いてるUARTもある。
 動くUART:FT232→H743(UART8)
 死ぬUART:STM32G030→H743(UART7)

それならばG030原因説を想起するのが通常であるから、G030起動時に出すglitchがH743のUARTのstate machineに爪痕を残してるんじゃないかという方向性で、pullup-downやUART初期化を延々と試して来たのが今日のお昼頃までだった。しかし徒労だった。

割り込み関数でなく、blocking関数だと僅かにloop数回ぐらいなら動く。HAL₋UART₋RECIEVE()

そこでbuffer overrun系かと考え、baud rate下げたり、G030の送信を毎秒1文字に減らしてみたが徒労。ヒラサカ帰責のbuffer操作はやってないのでボクチン原因説は無いの。

また、UARTのstatus registerに何らの兆候もなく静かに発狂に至っている。

オイオイオイ、UARTなんか簡単すぎてメスを入れるところ無いんだぜ。

エラッタは見てないけどUARTなんかでなぁ......

家に帰ったら、、、
・G030を切断してFT232をつけてみる
・別のportで試してみる

fuckすぎる無間地獄

ーーーー
家にて、、、

STM32G030を撤去してもやっぱりhangupする.
RXをpullup/pulldownして試してもhangupする.
G030原因とか、FT232なら動くはずとか、そうゆう問題じゃないわこれ.

UART3,UART4,UART5,UART7を試したが全部同じ症状.portが電気的に焼けてしまったわけじゃなさそう.
ただしUART8はFT232で円満に動いてる.

ーーーー
おぼろげに見えてきたかもなこと.
H743の6個のUARTを起動している.
ただし外部と接続しているのは今のところ7と8だけ.
3456のRXTXはopenのままで、RECIEVE()とかしてない放置PLAY.
この、UARTを起動はしてるが放置PLAYな状態(ゾンビUART)がガンな気がしてきた.
openなRX端子にnoiseが入ってないわけがないし.
MX_UART4_Init()などをコメントアウトしたけど挙動不審は相変わらずだった.RCCからclkが供給されてる時点で軽く起動してたりするのかな?

ちなみに3457は抜き挿し自由にしたいんだが、構想倒れか?

エグい

ゾンビUARTを削除してみたが不具合解消せず.

ーーーー
運用を変えてみたら、とりあえず動いた.

前提:G030が毎秒1byte送信するのをH743が円満に受信できるか?

従来の運用 UART8で実績あり
 初回のみ、FLAGに頓着せずRECIEVE_IT()
   ↓
 RX完了CallBackが呼ばれる①
   ↓
 同callback内で、受信データ処理
   ↓
 同callback内で、次の受信のためFLAGに頓着せずRECIEVE_IT() →hungup
   ↓
 別の仕事をしつつ①を待つ

いま実験的にやってみた運用 UART7がこれで動いた
 UART7 IRQが呼ばれる②
   ↓
 同IRQ内で、受信データ有無FLAGをチェックする
   ↓
 受信データが溜まっているならRECIEVE_IT()
   ↓
 RX完了CallBackが呼ばれる
   ↓
 同callback内で、受信データ処理
   ↓
 別の仕事をしつつ②を待つ

これだとねぇ、、、RECIEVE_IT()の動作が違うんですよねぇ.
従来の運用では、
 ・受信データ無しなら受信するまで待って割り込み
 ・受信データ有りなら即時割り込み
いま実験的にやった運用では、
 ・受信データ無しならhangup
 ・受信データ有りなら即時割り込み
こんなpollingめいたことやりたくないんだけど、なんなのこの違い?

RECIEVE_IT()の動作modeを制御するuser settingがあるのではないかと考えたくもなる.
STM32cubeMXのUART設定に違いがある.
↓UART8
↓UART7
いかにもこれだと思ってしまうが、しかしこれで動作が変わることは無かった迷宮.

ーーーー
3日目に突入.

上記対処で円満に動かせたかに見えたのですが、、、"hello"という文字列のうち先頭の'h'しか受信できない.
すなわち、
 RECIEVE_IT(,,1) なら円満に1文字受信できるけど、
 RECIEVE_IT(,,5) だと即hangup.
5文字受信無理は我慢するとして、"hello"の1文字受信ならば連続5回割り込みがかかると期待したのだけれどそうはならずに、"ello"はロストしちゃってる.あかん

ーーーー
3日目が暮れました.

シンプルなblocking関数であっても複数byte受信だと即hangupする.

万策尽きたので、初心に戻ってUARTが本当に動くのかを確かめることにした.
UART7,UART8,TIM以外のperipheralを全部削除し、sourceもUART7,UART8,TIM関連だけ残して全削除.これでUART7は正常に動くようになった.

モグラ叩きの始まり.

これから4日目に入ります.

かしこ

74 件のコメント:

  1. 読者
    とりあえず一晩寝て考えてみる
    バグっているときは気づかないこともわかることがある

    返信削除
    返信
    1. ゾンビがくる!
      ゾンビがそこまで来てる!

      削除
  2. murasaki
    UARTはハード的にはハング考えづらいですね。
    ハングというのがHAL₋UART₋RECIEVE₋IT()から戻ってこないことを指しているなら関数の中で何か待ちっぱなしになっているとかですかね。あとはチャンネルごとに割り込みベクタ別になっていてそのあたりの初期化がうまくいってないとか。

    返信削除
    返信
    1. TIM割込みすら効かなくなるのでどこかの無限loopとは違いそう

      削除
    2. debuggerで追いかけると再現しなくて
      まだ詰んでいます

      削除
    3. >debuggerで追いかけると再現しなくて
      うはは。このセリフ、
      ・何回聞いたかわからない
      ですね・・・
      ※聞いたって言うか、いつも「私が」言ってるんですが(笑)
      「デバッガーって何なのよ?」って、いつも思う。
      こうなると、古典的な「printf 攻撃」位しか、手が無くなるんだよなー
      って言うか「ワンチップマイコン」だと、その手も使えないし。
      ※それこそ、こんなの
      https://www.youtube.com/watch?v=FWiaG3k2_D4
      【朗報】マイコンの中身を丸裸にするツールが発売となりました。
      使いたくなるけど、コレ使うと
      ・再現しなくなる
      のがオチ。

      削除
    4. 冗談はさておき、何となくですが、
      ・HAL₋UART₋RECIEVE₋IT() が、複数UARTに対応してない
      ※勿論、そうならば「バグ」ですが、フラグが「1個」しか無くて、複数回呼ぶと「ハングアップ」するとか。ホントに「複数UART」を同時に使うアプリケーションが少ない(こんなに使い倒してるの初めて見た)ので、誰も気付かなかった、とか?

      削除
    5. >debuggerで追いかけると再現しなくて
      「デバッグ中」は、強制的に、
      ・シングルスレッド相当(人間は、複数の事象を同時には見れないから)
      になってしまうので、バグが表面化ない、とか?
      アリそうでコワいな・・・

      削除
    6. でばっがアタマわるい

      「基板設計間違えました、ぎゃふん」
      みたいな投稿ってPV多いんですよね
      人の不幸で楽しんでいる読者がたくさんいる(ひら調べ)

      削除
    7. >debuggerで追いかけると再現しなくて
      ・じゃぁ、ずっと「開発環境で動かせば」いいじゃん!
      といって、納品機(PC)に「開発環境ごと」納品されてる装置を私は知ってます。
      ※私はこう言うのが許せないので、自分が開発したモノではそういうことはやったことがありませんが。
      つか、そもそも、ふつーの「組込みワンチップマイコン」では出来ませんね。
      ※かつて某企業が開発したワンチップマイコンに、「量産チップにもデバッグ機能がある」というのがありましたが。
      コレは当時は画期的でしたが、独自構成だったので、広がらなかった。
      今では「一番安いチップ」でも、「デバッグ機能(SWD みたいなの)」が乗ってるので、ある意味「当たり前な機能」と化してますが。
      「パソコンとセットになっている」システムでは「不可能ではない」ですね。(開発環境のライセンスとかは知らん)

      削除
    8. それすごい
      中割りせずにアニメを納品してしまうようなもん
      線画でアニメを放送してしまうようなもん

      ↑う~ん記憶にあるなぁ

      削除
    9. >線画でアニメを放送してしまうようなもん
      イマドキの、CGアニメなら、
      ・開発画面の動画をそのままキャプチャして、納品
      でしょうかね・・・
      (技術的には、可能なんだよな。恐ろしや。)

      削除
    10. 預言である
      CGアニメのレイアウト作業画面を放送で見る日は近づく

      削除
    11. 某アニメで、
      ・VSCode の画面ぽいモノ
      が、出てきたのがありましたが。
      ※一部界隈で話題になってた。

      削除
    12. なんだっけか
      女性上司がプログラマ部下のwork folderを監視してる風
      主人公はプログラマ

      削除
  3. murasaki
    あとは、RX入力がLO固定になっていると連続受信状態(スタートビット入りっぱなし)になるので、受信処理から出てこられなくなるかも。

    返信削除
    返信
    1. murasaki
      受信しっぱなしの場合はステータスレジスタにオーバーランフラグが立つと思いますので、ステータスレジスタに異常がなければLO固定は無いかもですね。

      削除
    2. G030のportはLO固定じゃないのはオシロでかくにん!
      overrun FLAGはしずかちゃん

      削除
    3. 読者
      モデムみたいに
      ステータスLEDをぴかぴかさせましょう

      無駄にLEDをぴかぴかさせるUS製コンピュータ
      みたいでかっこいい(あれはどうさ確認だったのか)

      削除
    4. そういえば、
      電源indicatorをわたしは必ずつけますが、
      そうゆうのをつけたがらない設計者もいるようです

      削除
    5. >電源indicator
      私は、(予算が許すなら)
      ・付ける派
      ですが。「BlackBox」が、一番コワい。

      削除
    6. 自分も電源LEDはつける派です。5Vと3.3Vある時は両方つけます。電源入れても何も反応が無いとなんか嫌なのと、電源クロック、リセットあたりの基本的なところの確認を怠って何度も時間を無駄にしているので。
      あと、どこかショートしていたりすると電源がドロップするので早め異常に気がつけるとか。

      削除
    7. 受信CallBackの先で次の受信処理をいじるのは直観的にコワイかもですね~。一旦CallBackから抜けて次の受信処理をするのが吉な感じがします。そのCPU向けのシステムを作った受信CallBackの中ではユーザー側のバッファに受信データ移して直ぐに抜けるだろう的な想定しているかもですね。
      なんとなく昔からの暗黙の了解で、割込み処理やCallBack処理の中ではなるべく仕事を減らすことになっているかも。
      多重割込みが有効になっていない場合は、割込み処理やCallBack処理終わってから次の割込みを有効にしている可能性もあるかもです。

      削除
    8. +3、+5、+12、-12のANDで電源INDを点灯させたいくらいですわ

      あとCPUにはLチカをさせる
      TIMER直出しではなくて、割込みでLチカさせる

      削除
    9. 果てしなく長い割込み処理 →ワープの入り口

      削除
    10. >割込み処理やCallBack処理の中ではなるべく仕事を減らすことになっている
      Windows の デバイスドライバ作成者の間では有名な話ですが、まさに Windows には、コレに起因した有名なエラーで、
      ・割り込み処理中に、また割り込みが掛かったので、終了します
      と言う意味のエラーがある。
      ※規定時間内に、割り込み処理が終了しないと「もう次の割り込みが来ちゃったんで、処理できないよー!!」と言って、
      ・ブルースクリーンになって
      死亡します。
      ※一種の「想定外の事項」だから、仕方ないと言えばそうだが、デバドラでこれが起こると、まあしょうがないとは思う。
      「低レベルIO」だと、「メッセージボックス出す」ワケにも行かないし。
      ちょっと前まで、よく「(出来の悪い)ビデオドライバ」で、コレが出てた記憶がある。
      ※今気づいたけど、最近コレ見なくなった代わりに、
      ・画面に「ゴミ」(以前の描画の残像とか)が出る
      ようになった気がする。昔は描画が間に合わないと「律儀に」メッセージを出してたけど、いまは、
      ・ブルスクよりはマシ
      と言って、「画面にゴミ」が、残るのかも知れない。
      (そういう奴は、しばらく使ってると「ホントにブルスク」に、なるときもあるな・・・)

      削除
    11. 役所の待合所の、
      誰も見てない市政案内みたいな画面がブルスクになってると侘しい気分になるのって俺だけなのかなぁ....
      悲しいなぁ....

      削除
  4. 神奈川県人
    問題が起きている場所が原因ではなく、周辺の影響を受けている時がある・・・・・かな?

    昔ICをデバッグしていたら、どうも動きがおかしい。
    途中までは動くけど中途半端に不安定・・・・・。
    で、その時の原因は・・・・・電源が接続されていませんでした。
    電源フィルタを入れてたのですが、部品が欠品して電源が供給されていませんでした。
    電源がなくても動くのはすごいですね。
    また他の不安定問題の時は、ピン設定ミス・・・・・でした。
    はい、入力ピンがプルアップもプルダウンもされずにフロート状態でした。
    その時の教訓:空いているピンはとりあえず出力しとけ・・・。
    入力専用ピンはプルアップかプルダウンやっときましょう。

    返信削除
    返信
    1. ゾンビUARTを削除してみましたが、仮説倒れだった感じがしています

      FLAG関係を調べているところです

      削除
    2. 読者
      電源問題はよくある
      全波整流だけで平滑回路なしのACアダプタだったことで
      悩んだことある

      〇:FT232→H743(UART8)
      x:STM32G030→H743(UART7)

      UART7 に FT232を接続して
      動くかどうかでしょうか?

      STM32G030 にFT232 は接続して
      動くでしょうか

      UART8 にSTM32G030を接続して動くでしょうか

      使えるUARTは8だけとか UARTポートの制限があるとか

      削除
    3. https://www.family.co.jp/goods/charakuji/6392260.html
      ファミマ ガールズバンドクライ アクリルスタンド
      10時からやってますね 1600yen

      削除
    4. あのファミマグッズは高価ですよね なんだかなー
      トゲトゲメンバーが変なジャケットを着ています

      削除
  5. 従来の運用だと再帰呼び出しでStack Overflowになっているような……。

    返信削除
    返信
    1. そう懸念したくなりますが、
      そうならない仕組みになっています

      ちな、再帰呼びしたらしたで発狂するのは確認済

      削除
    2. ライブラリが、内部で「見るフラグを間違えている」に、一票。
      ※これは、いくら「IDEの設定を見直しても」分からない。
      ライブラリのソース(ここで既に「バージョン不一致」がよく起こる 笑)を、「くまなく捜査しないと」分からない。
      ※FLAGに頓着せずRECIEVE_IT() で、死ぬなら、内部のフラグが、
      UARTxで、「テレコ」(Or シャッフル)になってる?
      全部「均等」に使ってると気づかない(開発側のテストは、これで合格(笑)とか、UARTxは、UARTyのフラグを見ている、とか・・・
      (考え出したら、夜も眠れなくなる・・・もう朝ですが(笑)

      ※いずれにしても、「特定条件下のエラッタ」の気がするんだけどな。ハード起因カモだし。(IC内部の配線ミスで、同様の事が起きてるとか。)

      削除
    3. >baud rate下げたり
      「一定以下の baud rate だと起こる不具合」
      (常に「高速で走ってない」と、不具合が起きる・・・走り屋かよ(笑)
      とかあったりして。(ネタなので、真に受けないでください。っと、ホントにあったりしてね。)

      削除
    4. ドライバソースは、
      レジスタ設定してkickしてするっと抜けてる感じ
      わかんねー

      削除
  6. こう言うことがあるから、
    ・組込み系でも Python
    なんだろうか・・・
    ※Pythonは、開発環境=実行環境みたいなもんだから。node.js とかも同じですが。

    返信削除
  7. STM32H743 errata sheet
    https://www.st.com/resource/en/errata_sheet/es0392-stm32h742xig-stm32h743xig-stm32h750xb-stm32h753xi-device-errata-stmicroelectronics.pdf
    を見てたのですが、
    2.20.4 DMA stream locked when transferring data to/from USART
    の、Workaround のところに、
    ・This bit is reserved in the documentation ・・・
    というのがあって、まさに、
    ・コレ、ナイショなんですが、こういう時の為に・・・
    って感じの、「秘密の裏口」が、仕掛けてあるんかい!と思った。
    ※今回の件に関係あるかは知りません

    返信削除
    返信
    1. This bit is reserved in the documentation and must be used only on the stream ........
      ひみつちゃんですね

      削除
  8. こんなのもあった。これも、今回の件に関係あるかは知りません
    https://github.com/zephyrproject-rtos/zephyr/issues/57219
    drivers: spi: stm32: STM32H7 SPI don't work when when the core clock is high (>200Mhz)

    返信削除
    返信
    1. へーこりゃこんなのあるんですね
      SPIを使ってないので遭遇したことないけど、本当にSPIだけなのかな あははー
      ちなみにclockは最高速度で使ってまぁす 480MHz

      削除
  9. ねむいさんのブログで、
    https://nemuisan.blog.bai.ne.jp/?eid=244049
    >なお、STM32H743のようにバグだらけのRev.Yと修正版のRev.V以降では
    まったくの別物になっていた
    とかあるし・・・・
    ※以前に、外人が、
    ・いいかげんにしろやぁ!>STM32
    って、怒ってたのも、さもありなん。

    返信削除
    返信
    1. つか、タイトル自体が、
      >STM32H5を使ってみる2 -フラッシュ書き込み&デバッグ環境作るだけで疲労困憊-
      ってな感じで、もう、使うだけで、
      ・体力勝負
      ってのがスゴイ・・・
      ※やはり、現代の科学技術は、
      ・先人の、死屍累々の死闘の上に成り立って居る
      のだなー、と思った・・・ヲイヲイ

      削除
    2. ぎくっ!!
      ワシのH743はrev.Vだった
      胸をなでおろす(ぬかよろこび)

      削除
    3. >ワシのH743はrev.Vだった
      で、
      ・新バージョンにも、「何が仕掛けられてるか分からない・・・」
      って、なってますが。

      削除
    4. 正しくは、
      >Revが上がっていったらとんでもない地雷が待ち受けているかもしれません
      ですね・・・

      削除
    5. rev.Aから始まってYとかVっていうとかなり長い道のり

      削除
    6. rev.Z まで行ったら、
      ・rev.AA
      から、はじまるのかな?(Excel 脳)

      削除
    7. >バグだらけのRev.Yと修正版のRev.V以降ではまったくの別物になっていた
      今気づいたんですが、
      ・Rev.Y
      より、
      ・Rev.V
      のほうが「新しい」ってこと!?順番狂って無いですか?
      ※単に、ねむいさんが「ねむいので」間違えただけ?
      (バグだらけのRev.Vと修正版のRev.Y以降、のつもりだった?)
      のか、ホントに、
      ・Rev.Y より Rev.V のほうが「新しい」
      のでしょうか?
      謎が謎を呼ぶ・・・・

      削除
    8. >ワシのH743はrev.Vだった
      だとすると「改良版」の、
      ・Rev.Y
      があるのかな・・・?
      (でも「バグ」だらけ?)

      削除
    9. データシートの Revison history 見てると、時系列的には、
      ・rev Y → rev V
      みたいですね。
      ※というか、変わってるのは「電気的特性」だけで、単に、
      ・2ロットある?
      ダケかもしれません。
      ※ファブの識別してるだけカモ?歩留まりの良いファブと、そうでないファブがあるのかな?

      削除
    10. この際アルファベチカルはやめちゃって、
      Yesterday →Value line →Exodus →gotoHell
      とかにして、
      「まだVかぁ」と悟りを開くUser目線

      削除
    11. 「Y」とか「V」って、
      ・ファブ(製造工場)の、頭文字
      じゃないのかなー、と思ってきた。
      ※なんか違うみたい。Y/V で始まる地名は無い。
      ちなみに、調べたら、中国の Shenzhen にも、工場があるみたいです。

      削除
    12. iPhoneのSOCにも、桃園fabとKOREAfabがあって、桃園が良いとかいわれてませんでしたっけ?
      rev.M
      rev.K

      削除
    13. >iPhoneのSOC
      ああ、昔なんかありましたね。Kは「発熱が酷い」から、ハズレ、とか。

      削除
    14. マジメな話、同じマスクでも、FETの特性が違う
      (「漏れ電流」が大きいと、発熱する。不純物濃度が違うのかな?)
      とか、言われてましたね。

      削除
    15. 「不純物濃度」の、コントロールが上手く行ってるのと、そうでないので違う、だったかな。

      削除
  10. なんか、昨日(から、今日にかけて)
    ・山手線が、半分止まったり(内回り/外回りが両方あって良かった)
    ・すんずろうが「農水大臣」になったり
    するのを見てて思ったのは、「日本の安全神話」って、結局、
    ・単にシステムが「単純」だったから、出来てただけ
    のような気がしてきた。
    日本の列車が「正確に運行している」なんて、もはや、
    ・過去の話
    に、なっちまったよなー、と思った。
    ※列車運行システムも、「Windows 化」された途端に「しょっちゅう停止」とか、起きてたりして。
    「STM32H743」のデータシート見てて、こんだけ機能があれば、
    ・Windows 3.1 くらいなら、余裕で動くよなー
    (多分、linux は動くと思いますが)
    と思った。まぁ、これだけシステムが複雑なら、
    ・UART の、一つや二つ、動かなくても不思議はない
    と思った(ヲイヲイ)
    結局、人間の脳は「単細胞」だから、複雑なことに付いていけない、のだろうな、と思った。
    ※「そこでAIですよ!」と、したり顔で言う奴が出てくると思うが、それは結局、
    ・人類が、AIに「使われるようになる」未来
    しか見えないんだが。合掌

    返信削除
    返信
    1. 1)後期高齢者という昆虫レベルの愚脳しか持たない愚民が死ぬのが先か
      2)世界史の流転で日本もEUのような移民に荒らされるのが先か

      どうやら答えは、2が勝つようです(スガさんのせい)
      1が10年遅かったな

      削除
    2. JAPにとっては、自ら家畜化されることこそ至福であり安寧なんです

      削除
    3. >日本もEUのような移民に荒らされる
      結局、「人間の流動化」を、世界レベルでやれば、エントロピーの法則によって、
      ・ドンドン、エントロピーが増大していく(世界がランダム化(混乱)していく)
      のは、もはや「物理法則」の必定なんだよなー
      ※いくら、DSがそれに抗おうとして、「コンピュータ管理化」とか進めても、本質的には、なんにもならない。
      コンピュータを使うには「それなりの知能」が必要で、全員が「使いこなせる」くらいなら、初めから、
      ・エントロピーの増大
      なんかしない(笑)

      まさに、「早いか遅いか」なだけ。

      削除
    4. スガさん諸悪の根源

      削除
  11. 昨日停まってたんですか? へー
    おれかんけーねー

    返信削除
  12. 読者
    年金法案の陽動作戦っぽい
    年金増額はなかったことにした
    ニュースはぱったり消えた

    返信削除
  13. 日本人を羊の集団と定義して静かに殺すのが自民公明維新立憲の仕事です

    返信削除
  14. 読者
    ラズパイPICO 高性能な時代に
    安いからと言って
    z80基板が2000円で流行っているので
    買おうかと思っているのですよ
    コンパイラ1000円
    ROM1000円
    合計4000円
    なので 今週はやめておこう

    フロッピー基板作って
    FDDをつなぐくらいしか
    やることがないんですけど
    μPD765 FDC とか
    つなげばいいのかしら
    8インチFDDユニットつなぐとか
    1.2MBのFDDでもいいのかしら?
    と夢はひろがる

    返信削除
    返信
    1. 読者
      VFOがきもらしいです
      いいVFOが手にはいらず苦戦するらしい
      中華製しかないそうで
      ハードオフに流れていれば
      いいものがあるのか(20年前ならともかくいまどき枯渇)

      削除
    2. 売ってたらすごい8inch FD

      削除
  15. 読者
    たてみんとーが
    こーせいねんきん流用で賛成とかいっていて
    ものすごく給料の2割まで天引き年金とられて
    それをもらえず国民年金に使うとか
    消費税をつかうはずが まあ しずかにおだぶつされるのか

    返信削除
  16. 神奈川県人
    8inch FDなんてドライブもメディアも今手に入るんですか?
    たぶん20~30年くらい前に秋葉原のジャンク屋で8inchドライブを購入する人がいました。
    今は知りませんが、製鉄所の制御で使っていたみたいです。
    古いシステムを使っていると置き換えができないため使い続けるしかない場合があります。
    そのため、PC98シリーズの中古ははやっていると聞いたことがだいぶ昔にありました。
    ATボードはマザボのコンデンサが破裂するのはよくあるのと同じように、PC98も電解コンデンサがお亡くなりになって死ぬパターンがあるみたいです。
    さすがにニコイチでだましだまし使っても、死ぬ場所は似通ってくるので、まじめなリサイクル業者は、予防処置としてとりあえず電解コンデンサを交換しておいてくれるみたいです。
    (苑分お値段は勉強しているみたいです)
    ちなみに我が家には置物と貸している5インチFDの外付けドライブがあります。

    返信削除
    返信
    1. >予防処置としてとりあえず電解コンデンサを交換

      素晴らしく良心的です

      8inchFDはガコンガコンガッガッという音を愉しめました
      かな漢字変換のためにxfer keyを押すと8inchFDがガッガッと音をたてて候補文字を表示してくれるよなかんじ
      秘書さんがやってるのを裏山で見てただけですが

      dot impact printerも甲高い音をたてていました

      PCが回らなくて叩かなくなってしまって静かになってしまったのが残念です

      いまどきのパーテーションで区切られた、電話もかかってこないofficeは静かすぎていけねぇや

      削除
    2. マウスのクリック音すら気にするとか、静かすぎていけねぇ

      削除