タグ付けされた質問 「freertos」

非同期シリアル通信は今日でも電子機器に広く普及しているため、私たちの多くはそのような質問に時々出くわしたと思います。電子デバイスDと、PCシリアル回線（RS-232または同様のもの）で接続され、継続的に情報を交換する必要があるコンピューターを検討してください。すなわち、PCそれぞれコマンドフレームを送信しており、それぞれステータスレポート/テレメトリーフレームで応答しています（レポートはリクエストへの応答として、または独立して送信できます-ここでは実際には関係ありません）。通信フレームには、任意のバイナリデータを含めることができます。通信フレームが固定長パケットであると仮定します。X msDY ms 問題： プロトコルは継続的であるため、受信側は同期を失ったり、進行中の送信フレームの途中で「結合」したりする可能性があるため、フレームの開始（SOF）がどこにあるかはわかりません。Aデータは、SOFに対する相対的な位置に基づいて異なる意味を持ち、受信したデータは破損する可能性があり、永久に破損する可能性があります。 必要なソリューション 短い回復時間でSOFを検出するための信頼性の高い区切り/同期スキーム（つまり、再同期に1フレーム以上かかることはありません）。 私が知っている（そして使用している）既存のテクニック： 1）ヘッダー/チェックサム -事前定義されたバイト値としてのSOF。フレームの最後のチェックサム。 長所：シンプル。 短所：信頼できません。不明な回復時間。 2）バイトスタッフィング： 長所：信頼性が高く高速な回復で、どのハードウェアでも使用可能 短所：固定サイズのフレームベースの通信には適していません 3）9番目のビットマーキング -各バイトに追加ビットを追加します。SOFでマークされたSOF 1とデータバイトには次のマークが付けられ0ます。 長所：信頼性が高く、高速な回復 短所：ハードウェアサポートが必要です。ほとんどのPCハードウェアおよびソフトウェアでは直接サポートされていません。 4）8番目のビットマーキング -上記の一種のエミュレーション。9番目ではなく8番目のビットを使用し、各データワードに7ビットのみを残します。 長所：信頼性の高い高速リカバリは、どのハードウェアでも使用できます。 短所：従来の8ビット表現と7ビット表現の間のエンコード/デコードスキームが必要です。やや無駄だ。 5）タイムアウトベース -定義されたアイドル時間の後に来る最初のバイトとしてSOFを想定します。 長所：データオーバーヘッドなし、シンプル。 短所：それほど信頼できません。Windows PCなどのタイミングの悪いシステムではうまく動作しません。潜在的なスループットのオーバーヘッド。 質問： 問題に対処するために存在する他の可能な技術/解決策は何ですか？上記のリストで簡単に回避できる短所を指摘できますか？システムプロトコルをどのように設計しますか（または設計しますか）？

24 serial  communication  protocol  brushless-dc-motor  hall-effect  hdd  scr  flipflop  state-machines  pic  c  uart  gps  arduino  gsm  microcontroller  can  resonance  memory  microprocessor  verilog  modelsim  transistors  relay  voltage-regulator  switch-mode-power-supply  resistance  bluetooth  emc  fcc  microcontroller  atmel  flash  microcontroller  pic  c  stm32  interrupts  freertos  oscilloscope  arduino  esp8266  pcb-assembly  microcontroller  uart  level  arduino  transistors  amplifier  audio  transistors  diodes  spice  ltspice  schmitt-trigger  voltage  digital-logic  microprocessor  clock-speed  overclocking  filter  passive-networks  arduino  mosfet  control  12v  switching  temperature  light  luminous-flux  photometry  circuit-analysis  integrated-circuit  memory  pwm  simulation  behavioral-source  usb  serial  rs232  converter  diy  energia  diodes  7segmentdisplay  keypad  pcb-design  schematics  fuses  fuse-holders  radio  transmitter  power-supply  voltage  multimeter  tools  control  servo  avr  adc  uc3  identification  wire  port  not-gate  dc-motor  microcontroller  c  spi  voltage-regulator  microcontroller  sensor  c  i2c  conversion  microcontroller  low-battery  arduino  resistors  voltage-divider  lipo  pic  microchip  gpio  remappable-pins  peripheral-pin-select  soldering  flux  cleaning  sampling  filter  noise  computers  interference  power-supply  switch-mode-power-supply  efficiency  lm78xx 

STM32F407およびLAN8720AイーサネットPHYを使用するPCBを立ち上げようとしています。フレームの送信に問題はありませんが、イーサネットフレームを受信できません。 ハードウェアのセットアップ 私はSTM32F4に25 MHz水晶を搭載しており、25 MHzクロック出力ピンをREF_CLK_OUTモードのLAN8720Aに駆動し、50 MHzクロックをRMIIインターフェイスの一部としてSTM32F4に駆動します。 ジャック/磁気は一般的な部品です。これがデータシートです： ソフトウェア 私は最新アップデートのSTM32CubeMXを使用して、FreeRTOS、lwIP、およびETH周辺機器ドライバーを含むSTM32プロジェクトのSystem Workbenchを生成しています。生成されたコードには実際には触れていません。そのため、lwIPスタックはFreeRTOSスタック内で初期化されます。 実験 ボードのlwIPが10.0.0.2静的IP用に構成され、コンピューターのUSB-to-Ethernetドングルが10.0.0.1静的IP用に構成されているので、2つのデバイスをイーサネットケーブルで直接接続し、ボードが接続しようとします。コンピューターのポート80でサービスに。Wiresharkを使用してボードとコンピューター間のやり取りをキャプチャします（コンピューターで実行され、USB-to-Ethernetコンバーターにバインドされています）。 フレームを受信できないという問題があるため、このARPの問題を 回避することはできません。ご覧のように、Stmicroe（ボード）はARPパケットを送信できます—私のコンピューターで聞こえます—私のコンピューターからの応答は聞こえないようです。 、それはARPパケットを爆破し続けるので。 どちらのデバイスも255.255.255.0マスクで構成されており、両方とも10.0.0.1（コンピューター）のゲートウェイアドレスで構成されています。ARPテーブルがめちゃくちゃになり、コンピューターがARPパケットを無視することを聞いたことがありますが、ボードが最初に作成した要求に応じて、ボードが自分のコンピューターによってアドレス指定されたARPパケットを無視することは想像できません。 そこで、lwIPのethernetif.cファイルを調べてHAL_ETH_GetReceivedFrame_IT(&heth)、エラーが返されていることに気づきました。この関数は、(heth->RxDesc->Status & ETH_DMARXDESC_OWN)1ではなく== 0であるためエラーを返します。これは、DMAバッファーが現在MAC周辺機器用に準備されており、まだ何も受信していないことを意味すると解釈します。 さらに、HAL_ETH_IRQHandlerが呼び出されないことを確認しました。 PHYの問題？ この時点で、自分のPHY自体に問題があるのではないかと思いました。 さらに調査するため、Saleae Logic Pro 16を関連するすべての信号に接続しましたが、TX0 / TX1とRX0 / RX1の両方の回線に大量のトラフィックがあることに気付きました。次に、25 MHzの入力クロックを使用した一部のRXトラフィックのキャプチャを示します。 RX_ERRは、50 MHzのクロック出力（明らかにSaleaeのようなデバイスで明らかに困難なもの）をキャプチャしようとしない限り、常に低いです。 —ピンは機能しているように見えます）。 次のステップ タスクでが呼び出されたHAL_NVIC_EnableIRQ(ETH_IRQn);後、ETH割り込みを手動で有効にしてみましたtcpip_init()がMX_LWIP_Init()、問題が解決しないようです。イーサネット割り込みルーチンが呼び出されることすら想定されているかどうかは、完全にはわかりません。これは、まったく新しい設計を実現する上で困難なことです。システムの適切な動作を判断するのに苦労しているため、セットアップの違いを判断できます。 以前にSTM32 / STM32CubeMX / FreeRTOSなどを使用したことはありますが、STM32のイーサネットペリフェラルを使用したことはありません。これに関する私の唯一の経験は、常に組み込みで動作するように見えるカスタムの組み込みLinuxシステムに関するものだけです。これは私にとって新しい領域です！ どこかに愚かなチェックボックスか、Ethernet_EnableReceive()呼び出しを忘れた魔法の関数があると確信していますが、それを明示的に有効にする必要があることを示唆するドキュメントを実際に見つけることはできません。インターネット上に表示されている投稿はすべて無関係です。問題。 誰かが何かアイデアがあれば、私はいくつかの助けが欲しいです！ 補遺：FreeRTOSを取り除く 物事を排除するために、FreeRTOSプロジェクトコンポーネントを削除し、ベアメタルプロジェクトに戻りました。メインループでは、を呼び出しますMX_LWIP_Process()。この方法では、割り込みの必要性はなくなりますが、問題は解決されません。それでもフレームを受信できません。これにより、STM32CubeMXによって生成されたETH HALコードに何かがあると思います。 解決 誰かが将来この質問に出くわした場合に備えて、問題はRXD0ピンとRXD1ピンが反転していることが判明しました。ロジックアナライザーでトラフィックを確認できたのはこのためですが、MCUでデコードされませんでした。 誰かが指摘したように、私が使用した磁気は非対称であり、auto-MDI-Xには使用しないでください。何の問題もありませんでした。私は2つのことの1つが起こっていると予想します：-磁気は実際には他の方向では機能しませんが、私が持っているすべてがauto-MDI-Xを使用しているため、私のボードは本質的には機能する構成で固定され、他のデバイスはオンですケーブルはその信号を一致するように向けます。-磁気は、イーサネットの実行が短い場合に適切なシグナルインテグリティを提供しますが、長期間の分析では、より長い実行でのパケットドロップまたは問題の発生率が高くなります。 …

9 stm32  freertos  lan8720  lwip 

モノのインターネットプロジェクトで使用するオペレーティングシステムを評価していますが、次に進むための最良の方法がわかりません。 32k RAMとCC2520 802.15.4トランシーバーを備えたTM4C123GH6PM MCUを使用していますが、システムがすでにそれらのドライバーを提供しているとしたらすばらしいでしょう。 システムは、ドットマトリックス画面を描画し、ユーザー入力に反応する1つの（インタラクティブな）タスクを実行します。設定とアプリケーションデータをspiフラッシュに保存します。モジュール間でデータを同期し、モジュールからセンサーデータを抽出してゲートウェイに転送し（rplが頭に浮かびます）、またゴシップでOtAファームウェアの更新を配布するために、複数のモジュールのメッシュ（802.15.4に基づく）があります。ファッションのように。同様に、メモリを大量に消費するアプリケーションも実行しています。 これまでのところ、これらのシステムを調べてきました。 RIOT： 長所 優れたハードウェア抽象化 小さな足跡 とても活発で親切なコミュニティ 完全な802.15.4 / 6LoWPANスタック 短所 不安定であり、根本的な変化をまだ受けている まだ競合状態/クラッシュが含まれています ファイルシステムのサポートなし いくつかのネットワークプロトコル Contiki： 長所 成熟したシステム、商用製品で使用 多くの有用なプロトコルを備えた完全な802.15.4 / 6LoWPANスタック ファイルシステムのサポート cc2520サポート 短所 開発が古くなっている 「成長した」コードベース、たくさんのビット腐敗 品質の悪いTiva Cポート 最新のプラットフォームのサポートはほとんどありません 非プリエンプティブスケジューリングはアプリケーションに問題を引き起こす可能性があります FreeRTOS： 長所 少し追加の複雑さ 使いやすく信頼性の高いスケジューラ 多くの製品で使用される成熟したプロジェクト たくさんのポート 短所 ファイルシステムなし ドライバーのハードウェア抽象化なし/ハードウェアドライバーなし ネットワークスタックなし 動的メモリの使用率がやや高い NuttX： 長所 非常に機能が豊富で、ほとんどLinuxのように感じますが、まだ小さいです ファイルシステムのサポート …

8 cortex-m  rtos  freertos  contiki-os