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

注：この質問では、2つのRTOSについて具体的に言及していますが、より一般的であり、以前に組み込みRTOSのCコードを記述し、MCUでソフトウェアを直接実行したことがある人なら誰でも回答できます。 組み込みRTOSの詳細を学び、そのためのアプリケーションを作成することに興味があります。現在、EmboxとRIOTを検討しています。それらはオープンソースで、モダンで、アクティブで、優れたドキュメントがあるようです。私の目標は2つのフェーズです。フェーズ1は、これらのOSをコンパイルしてMCU（おそらくAVRまたはARM）にフラッシュする方法を見つけ出すことです。フェーズ2では、単純なCプログラム（基本的にはヘッドレスデーモン）を作成します。これは、「趣味アプリ」として時間とともに進化します。次に、このプログラムを同じMCUにフラッシュ/展開することで、Embox / RIOTとその上にあるアプリで構成されるアプリスタックを正常に展開します。 最終的に行き止まりに至る道を進む前に、C /アセンブラーで書かれMCUにフラッシュされたリアルタイムアプリがRTOSを実際に必要としない理由を説明するのに非常に役立つこの記事を偶然見つけました。 。 だから今、私は本当に混乱していて、コンピューティング理論の私の基本的な理解に疑問を抱いています。私は、最初にEmbox / RIOTを使用するかどうかの決定をしようとしていると思います。 コースを継続し、両方のOS +アプリのMCUで「アプリスタック」を使用します。または 記事の警告に注意し、MCUでアプリ「ベアメタル」を実行してください 明らかに、前者はより多くの作業であるため、そのルートに進むのに十分な理由/報酬が必要です。だから私は尋ねる：これらの（および同様の）組み込みRTOSがMCU / Cアプリ開発者に提供する本当の利点は何ですか？RTOSを使用することで、Cアプリはどのような特定の機能の恩恵を受けることができますか（おそらく、車輪を再発明しないことによって？）RTOSを捨ててベアメタルに移行すると何が失われますか？ ここでは具体的な例を求めています。RTOSのウィキペディアエントリにアクセスしたときに得られるメディアの誇大広告ではありません;-)

11 c  operating-systems  real-time  arm 

背景： EBMLファイルを書き込むマイクロコントローラーCコードを書いています。EBMLは要素がネストされたバイナリXMLに似ていますが、開始タグと終了タグの代わりに、開始ID、長さ、そしてデータがあります。低電力アプリケーションの外部フラッシュにこれを書き込んでいるので、フラッシュアクセスを最小限に抑えたいと思います。決して簡単なことはないので、メモリも制限されます。 EBML要素全体をメモリに保持できる場合、その長さがわかったら、各要素の長さに戻って入力できるため、生成は簡単です。問題は、要素全体をメモリに保持できない場合の対処方法です。私が見るオプションは： 私が知っていることを書いてから、戻って長さを追加します（最も簡単ですが、必要以上にフラッシュアクセスを追加します） 書き始める前に各要素の長さを計算します（比較的簡単ですが、プロセッサ時間は長くなります） メモリがいっぱいになったらモードを切り替えて、データを調べ続けますが、すでにメモリに予約されている要素の長さを計算するだけです。次に、メモリにあるものを書き込み、戻って、中断したところからデータの処理を続けます。（これまでのところ私のお気に入りのオプション） 要素を書き込む必要があり、最終的な長さがまだわからない場合は、要素に最大または最悪の場合の長さを指定します。（上記より簡単ですが、裏目に出てスペースを無駄にする可能性があります） 質問：これは、人々が考えていた比較的一般的な問題であるように思われます。一部のデータパケットを形成するときにも発生する可能性があることを知っています。私がここで見逃している/より一般的/より受け入れられたより良いテクニックはありますか？または、私が検索できる問題のいくつかの用語？

9 design-patterns  c  file-handling  arm  firmware