タグ付けされた質問 「error-correction」

USBには、USB-CDCデバイスとUSBホスト間で送信されるデータのサービス品質保証がありますか？ ノイズの多い状況（自動車の診断ポートなど）で従来のRS232を使用している場合、不良ビットが頻繁に発生するため、プロトコルにとってチェックサムが重要です。そのようなプロトコルを純粋なUSBアプリケーションに適応させる場合、チェックサムと関連するエラー処理ルーチンを安全に省略できますか？ 参考のため、Atmelが提供するUSB-CDCフレームワークでAT91SAM7S256を使用しています。 更新： この問題についてGoogle-Fuをもう少し試したところ、イーサネットエミュレーションと状態のCDCサブクラスについて説明している次の記事が見つかりました。 カプセル化されたイーサネットフレームは、USBケーブルを介して、宛先MACアドレスから始まり、フレームチェックサムの直前で終わります。（USBは信頼できるトランスポートであるため、フレームチェックサムは必要ありません。） プログラムが十分な速度でデータをポーリングできない場合、高スループットのバーストデータ（webcam？）を対象とする一部のデバイスクラスはバッファーを満杯にしたくない場合があるため、USB-CDCは一般的なUSBではなく信頼性の高いトランスポートを意味する場合があります。 私はまだこれに関する追加の確認をお願いします。

13 usb  rs232  usb-device  error-correction 

アプリケーションでSPI周辺機器を使用しています。周辺機器は、15データビットとエラー検出用の偶数パリティビットを含むパケットを返します。 したがって、すべてゼロで、すべて1が両方ともパリティチェックに合格します。 これは、私のマイクロコントローラーが最も一般的なタイプのエラーを検出できないことを意味します：接続されていない周辺機器 この場合、受信ビットはすべてゼロであり、パリティチェックに合格します。 周辺機器の製造業者が奇数パリティを実装するのと同じくらい簡単だったと仮定して、私の質問は次のとおりです。この場合、なぜ偶数パリティを使用することを選択したのですか。この場合、最も一般的なタイプのエラーをキャッチできないという事実を補うために、偶数パリティには他の利点がありますか？

12 microcontroller  error-correction  peripheral  parity  bit-error 

Androidカーヘッド/インフォテインメントユニットのアフターマーケットを購入したいと思います。しかし、システムソフトウェアが破損した場合に再インストールする方法はないと思います。そのため、フラッシュメモリにデータがどのくらい続くか心配です。 私は10年や20年のような古い数字を見つけましたが、それは今日のMLCとは異なり、8ビットマイクロコントローラーにある大きな単一レベルのセル用です。 SanDiskによると、 MLCフラッシュのデータ保持は、SLCフラッシュよりも桁違いに低いです。 JEDEC JESD218A規格によれば、25Cでのデータ保持は101週間である必要があります。別の情報筋によると、「フラッシュメモリは、コントローラーに時々電源が入っており、侵入するビットエラーをスキャンして修正する場合に、データを最も適切に保持します。」 つまり、ここで提案されているように、DRAMと同じようにスクラブ/リフレッシュします。 46倍のデータ保持！信じられないが、これは今日すべてのフラッシュメモリデバイスに実装されていますか？ しかし、単一のセルに対して、更新/スクラブまたはECCを行わない、生のデータ保持時間はどれくらいですか？101週* 46 = 89年は、本当であるには良すぎるように聞こえます。 また、エラー訂正によりどの程度改善されますか？ 明らかに、修正なしの最初のエラーが発生するまでの時間は、ギガバイトデバイスでは非常に低く（幾何学的分布に従っているか？）、個々のセルの平均時間の近くにはありません。エラー訂正は、集合ビットの保持時間を単一の未訂正セルの場合とほぼ同じ時間に引き上げますか？それともそれ以上に改善しますか？

8 flash  error-correction  flash-memories  nand-flash