問題タブ [freertos]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
embedded - 埋め込みターゲットからホストへの通信
次の問題があります。
いくつかの通信インターフェイスを介して PC と通信できるマイクロコントローラー: RS232、USB が存在します。イーサネットは使用できません。ソフトウェアは、オプションの組み込み OS を備えたベアメタルです。
ハードウェアは、任意のマイクロコントローラーおよび物理通信インターフェイスに適用できるため、重要ではありません。
複数の通信チャネルが同時に必要です。
- 単純なコンソールの場合は 1 - デバッグ目的: uC <-> PC
- ADC から PC へのリアルタイム サンプルを取得するための 1: uC -> PC
- PC から DAC にリアルタイム サンプルを送信する場合は 1: PC -> uC
- 1 取得/変換、開始/停止などのさまざまなパラメータを設定: uC <-> PC
理想的には、RS232 または USB (推奨) を使用する物理インターフェイスを 1 つだけ使用する必要があります。
単一の物理チャネルで異なるチャネルを多重化するためにすでに利用できるものはありますか? メッセージ パッシング、リモート プロシージャ コール。
c - FreeRTOS セマフォ
xSemaphoreTake() 関数に関するFreeRTOS API リファレンスhttp://www.freertos.org/a00122.htmlの抜粋を次に示します。
私の質問は次のとおりです。ここにセマフォが既にありますか、それとも
次のxSemaphoreTake( xSemaphore, (portTickType) 10 )
ように明示的に呼び出す必要がありますか?
c - tftp を使用してファイルをアップロードできないのはなぜですか?
スタックサイズを維持するために、複数回の繰り返しでファイルをアップロードするときに、毎回接続を確立する必要がありますか?
calloc failed エラーが発生しました。
マルチスレッドでfreertosを使用しています。
embedded - 苛立たしい FreeRTOS xQueueCreate() の制限
queue
を使用して、UART ISR からバックグラウンド タスクに文字をバッファリングしようとしています。キューの長さを 512 バイトにしたい。unsigned portBASE_TYPE
サイズ引数の型は xmega256a3 ではシングル バイト ( ) であるため、これは残念ながら不可能char
です。キューの最大サイズが で変動する理由はありますportBASE_TYPE
か? uint16_tではなく?
他の人が同じ制限に達したかどうか、またそれに対して何をしたか、興味があります。
c - xmega256a3 で FreeRTOS の tickless サポートを実装するのに苦労しています
FreeRTOS の xmega256a3 ポートで動作する tickless サポートを取得するのに苦労しています。周りを見回して、ボンネットの下をよりよく理解しようとしていると、次の行が にあることに驚きましたvTaskStepTick()
。
私はオンにしていませんがconfigASSERT
、オンにした場合、それは定期的に問題を提起することになると思います. xTicksToJump
はデルタ時間ですがxNextTaskUnblockTime
、コードを正しく読めば絶対ティック時間ですか? 私はそれを間違えましたか?
ドキュメントの例に基づいてパターン化された私のスリープ機能は、次のようになります。
誰かがそこに明らかな問題を見つけたら、私はそれを聞きたいです. それが示す動作は興味深いものです。テストのために、2000 ミリ秒遅延する単純なタスク ループを実行してから、スコープで監視できるピンを単純に切り替えます。そこにいくつかのprintfを関数に追加すると、最初の関数が正しく実行されますが、終了するとすぐに再入力されますが、値は65535に近くなります。それは忠実に待ってから、次のものを再び正しく取得し、次に間違って(長く)、交互に行ったり来たりします。
embedded - マルチタスク環境でウォッチドッグに餌を与えるための戦略
いくつかの埋め込みコードをFreeRTOSに移動した後、ウォッチドッグに関する興味深いジレンマが残りました。ウォッチドッグタイマーは、私たちのアプリケーションの必需品です。FreeRTOSを使用することは、私たちにとっても大きな恩恵です。アプリケーションがよりシングルタスクである場合、タスクがタイムリーに論理的に進行していることを確認できるように、ロジックフローのタイムリーなポイントでウォッチドッグにフィードしました。
ただし、複数のタスクがある場合、それは簡単ではありません。あるタスクは、何らかの理由で進行せずに拘束される可能性がありますが、別のタスクはうまく機能し、ウォッチドッグを幸せに養うのに十分な進歩を遂げています。
1つの考えは、ウォッチドッグにフィードするためだけに別のタスクを起動し、他のタスクが定期的にインクリメントするいくつかのカウンターを使用することでした。ウォッチドッグタスクがチェックされると、すべてのカウンターが他のすべてで進行しているように見えます。タスク、もしそうなら、先に進んでウォッチドッグに餌をやる。
このような状況で他の人が何をしたのか知りたいですか?
macos - MacでのAVRマイクロコントローラーとの相互作用
最近ATiny84マイクロコントローラーを購入しましたが、snowleopardを実行しているMacbookProからコードをアップロードできるかどうか疑問に思いました。具体的には、cファイルとFreeRTOSを実行できますか?
gcc - gccを使用したSTM32F4でのFreeRTOSスタックの破損
stm32f4discoveryボードでFreeRTOSを実行しようとしています。summon-arm-toolchainをインストールし、コードをコンパイルするためのMakefileを作成しました。Makefileは次のとおりです。
FreeRTOSデモプロジェクトのフォルダCORTEX_M4F_STM32F407ZG-SKのプロジェクトを変更しました(既存のタスクを削除して独自のタスクを作成します)。主な機能は次のとおりです。
FreeRTOSConfig.hでconfigMINIMAL_STACK_SIZEを4096として構成しましたが、タスクスケジューラが起動し、SampleTask0関数が呼び出されると、コードは正常に機能します。タスクコードは次のとおりです。
タスク1の機能は、異なる情報を出力することを除いて、タスク0とほとんど同じです。これらのコードはコンパイルされ、バイナリをボードに書き込んだ後、SampleTask0が期待どおりに機能しません。USART3を介して文字を送信するDebugPrintf関数は、「Tas」のみを出力し、その後すべてが停止します。gdbを使用してコードをトレースし、コードを段階的に実行すると、「Task 0 running」が出力されましたが、タスク関数に戻ると( "while(delay){delay--;}"の前に)エラーが発生しました。
アドレス0xa5a5a5a5のメモリにアクセスできません
main.c.のSampleTask0(pvParameters = 0x0)。
FreeRTOSドキュメントによると、各タスクのスタックは作成時に0xa5バイトで埋められます。スタックに何か問題があるのではないかと思います。configCHECK_FOR_STACK_OVERFLOWを2に設定してスタックオーバーフローの検出を有効にしましたが、これが発生したときにフック関数が呼び出されていませんでした。
CORTEX_M4F_STM32F407ZG-SKのstartup_stm32f4xx.sは、EWARMツールチェーン用に作成され、STWebサイトからダウンロードしたSTM32F4-Discovery_FW_V1.1.0のスタートアップファイルに置き換えました。したがって、スタックが破損する可能性がありますが、これについてはよくわかりません。誰かがこれについてアイデアを持っていますか?
c - Cスレッドでの自己インクリメントは安全ですか?
FreeRTOS(FreeRTOSV7.4.0 \ FreeRTOS \ Source \ tasks.c)でいくつかのコードを見つけました:
タイプが「長い」タイプである「portBASE_TYPE」であるため、保護する必要がないと明示的に言われています。私の理解では、このタイプへの自己インクリメントはアトミックであると想定しています。しかし、それを分解した後、私は証拠を見つけることができませんでした、それは単純なロード->追加->ストアです。それでは問題ですか?
operating-system - ラウンドロビン スケジュールでタスクが正しく動作しない
STM32F4DISCOVERY ボードで FreeRTOS を実行しており、次のコードがあります。
ここで、vTask1 は次の関数です。
vTask2 のコードはほぼ同じです。
プログラムを実行すると、LED0 と LED3 が常にオンになっていることがわかり (それらの切り替えは私の目には速すぎますが、これは問題ありません)、「共有リソース」である LED2 が非常に速く点滅しています。問題は次のとおりです。呼び出しの順序を逆にするとxTaskCreate
、同じ状況になり、LED2 の点滅動作が大幅に遅くなります。タスクは同じ優先度を持つ必要があり、したがってラウンド ロビン スケジュールに従う必要があるため、なぜこのようなことが起こるのでしょうか? 彼らは同じ時間を得るべきではありませんか?異なる順序で作成しただけで動作が変わるのはなぜですか?
前もって感謝します。