（怠惰な場合はTL; DRの下部を参照してください）

こんにちは、私は物理コンピューティングを扱う新しい（プロトタイプ）プロジェクトを構築することを計画しています。基本的に、私はワイヤーを持っています。これらのワイヤはすべて、同時に電圧を読み取る必要があります。各ワイヤの読み取り値の差が数百マイクロ秒を超えると、ワイヤが完全に台無しになります。Arduinoは約114マイクロ秒かかります。したがって、待ち時間が読み取りの精度を歪める前に、私が読み取ることができるのは2本または3本のワイヤです。

ですから、私の計画は、一連のATTinysの「マスター」としてArduinoを使用することです。arduinoはスペースがかなり狭いですが、小さなものに比べると巨大な遊び場です。ATTiny13Aには、1kのフラッシュROM（プログラムスペース）、64バイトのRAM、および64バイトの（耐久性がなく低速の）EEPROMがあります。（サイズだけでなく価格もこれを選んでいます）

私のシステムのATTinysはあまり効果がありません。基本的に、マスターからの信号を待ってから、1本または2本のワイヤーの電圧を読み取り、RAM（または窮屈な場合はEEPROM）に保存するだけです。そして、データ用に1本のワイヤーだけを使用してマスターに送信します（それ以上のスペースはありません！）。

これまでのところ、私がしなければならないのは、（組み込みのADCを使用して）簡単な電圧読み取りコードを実装することだけです。しかし、私が心配しているこのコミュニケーションビット。そのような制約の中で通信プロトコル（1本のワイヤーを使用するだけです！）を実装することさえできると思いますか？

TL; DR：1k未満のプログラムスペースと64バイトのRAM（および64バイトのEEPROM）で、1-Wire通信プロトコルを実装することは可能だと思いますか？フィットさせるためにアセンブリにドロップする必要がありますか？

現在、WiringライブラリにリンクしているArduinoプログラムが8kを超えていることを知っているので、少し心配しています。

私が取り組んでいるコードは、ホスト環境と自立環境の両方でビルドできるはずであり、後者の場合のいくつかのstdlib関数のプライベート実装を提供します。

通常のワークステーション/ビルドサーバーでGCCだけでこれを確実にテストできますか？GCCを使用して自立環境用にコンパイルする

• 「-ffreestanding」オプションは有望に見えましたが、組み込みを無効にし、STDC_HOSTEDマクロを適切に設定する「のみ」のようですが、それでもすべてのシステムヘッダーを提供します。

• オプション「-nostdinc」は制限が厳しすぎます。自立型の実装に必要なヘッダー（特にstddef.hとlimits.h）を引き続き使用したいと思います。

ここで何が欠けていますか？

ああ、私は今のところGCC 4.4.3を使用していますが、「すぐに」4.5.0にアップグレードします。

フリースタンディング環境 (基本的には ARM ボード) で実行する C++ コードを書いています。つまずきのブロック、つまりグローバル静的コンストラクターに遭遇したことを除いて、それはうまくいっています。

私の理解では、.ctors セクションには各静的コンストラクターへのアドレスのリストが含まれており、私のコードでは、このリストを反復処理して、各関数を呼び出します。しかし、バイナリのこのセクションは実際には完全に空であることがわかりました! Google は、「.ctors」(EABI のもの) の代わりに「.init_array」を使用することを指摘しましたが、何も変わっていません。

静的コンストラクターが存在しない理由についてのアイデアはありますか? 関連するリンカー スクリプトと objdump の出力は次のとおりです。

--

arm-elf を対象とした GCC コンパイラ (4.4.1) を使用しています。

更新: 出力バイナリも__static_initialization_and_destruction_0、これまでに見たことのないシンボルでいっぱいです。

更新 2: これは、コンパイルされたオブジェクト ファイル (メイン バイナリにリンクされている) の objdump からの抜粋で、.ctors セクションはそのままです。

以下のそれぞれの異なる標準の独立した部分を実装するコンパイラは、どのように異なる必要がありますか？それらすべてをサポートするために必要なモード（たとえば、コマンドラインフラグによって指定される）の数はどれくらいですか？

1. ISO / IEC 9899：1990
2. ISO / IEC 9899：1990 + ISO / IEC 9899 TCOR1
3. ISO / IEC 9899：1990 + ISO / IEC 9899 TCOR1 + ISO / IEC 9899 AM1
4. ISO / IEC 9899：1990 + ISO / IEC 9899 TCOR1 + ISO / IEC 9899 AM1 + ISO / IEC 9899 TCOR2
5. ISO / IEC 9899：1999
6. ISO / IEC 9899：1999 + ISO / IEC 9899：1999Cor。1：2001（E）
7. ISO / IEC 9899：1999 + ISO / IEC 9899：1999Cor。1：2001（E）+ ISO / IEC 9899：1999Cor。2：2004（E）
8. ISO / IEC 9899：1999 + ISO / IEC 9899：1999Cor。1：2001（E）+ ISO / IEC 9899：1999Cor。2：2004（E）+ ISO / IEC 9899：1999Cor。3：2007（E）
9. ISO / IEC 9899：2011

私は次の機能を持っています。

実行可能なリターンタイプ、または呼び出す方法が見つからないように思われるので、これと同じように呼び出すことができるようにしたいと思います。

'f'、'arg'、および'param'を;として指定します。

誰かがヒント、あるいは解決策を手に入れましたか？

注：コードは次の場所にあります。リンケージ

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.htmlの GCC ドキュメントでは-ffreestanding、独立した環境は-fno-builtin. フリースタンディング環境とは何か、またはそれがどのように機能するかを正確に誤解している可能性がありますが、ビルトインは通常、ライブラリ関数を呼び出す代わりにインライン コードを発行するため、標準ライブラリが欠落している可能性があるフリースタンディング環境には理想的であるように思えます。機能がないか、完全に欠落している場合さえあります。

では、自立型環境でビルチンを使用したくないのはなぜでしょうか?

簡単な質問:

次の 2 つのアセンブリ プログラムがあるとします。

1:

2:

(最初のファイルで宣言されている) を 2 番目のファイルから呼び出すことはできadd10ますか、またはその逆でしょうか? もしそうなら、どうすればそれを行うことができますか？（実現不可能であっても）

注: これはベア メタル上で実行され、ファンシーな NT 呼び出しでは実行されません!

ありがとう。

編集: Windows で NASM を使用しています。

私は常に、位置独立コード (PIC) の生成は、基本的にコンパイル対象の CPU にのみ依存すると考えてきました。ただし、GCCのドキュメントでこれを読んだ後：

386 の場合、GCC は System V の PIC をサポートしますが、Sun 386i の PIC はサポートしません。

（PICを作成する機能はオペレーティングシステムに依存すると述べています）、私は疑問に思いました：

オペレーティング システムが存在しない場合、GCC は独立した環境用の位置に依存しないコードを作成できますか?

私が持っている質問は、主にセクション 4、パラグラフ 6に関連しています。

準拠する実装の 2 つの形式は、ホスト型と独立型です。適合するホストされた実装は、厳密に適合するプログラムを受け入れるものとします。

私が理解しているように、これはファイルシステム、割り当てられたメモリ、およびスレッドを備えた典型的なアプリケーション環境を構成しています...

準拠する独立した実装は、ライブラリ条項 (条項 7) で指定された機能の使用が標準ヘッダー 、、、、、、、、、および の内容に限定されている厳密に<float.h>適合するプログラム<iso646.h>を受け入れるものとします。<limits.h><stdalign.h><stdarg.h><stdbool.h><stddef.h><stdint.h><stdnoreturn.h>

...そしてこれは、標準のファイルシステム、割り当てられたメモリまたはスレッドを持たない、典型的なカーネルお​​よび/または組み込みの最小限の環境を構成します(とりわけ)。

準拠する実装には、厳密に準拠するプログラムの動作を変更しないという条件で、拡張 (追加のライブラリ関数を含む) を含めることができます。

これにより、ホストされた実装に、ホストされた実装または独立した実装と自称する自由が与えられたかのように見えます。ファイルシステム、割り当てられたメモリ、またはスレッド (とりわけ) に関しては、これらは拡張カテゴリに分類されるため、単に実装することができます。毎回エラーを示す値を返すインターフェース。ほんの数例を挙げると：

• fopen、fgetsそしてmalloc戻ることができますNULL
• fprintf、fscanf、fputcおよびfgetc返すことができますEOF
• thrd_create戻ることができますthrd_error（「リクエストを受け入れることができなかった」ことを示します）

これは、セクション 4、パラグラフ 6 が与える区別が事実上無意味であることを意味します。ホストされた独立した実装でこれらの関数の実際の機能レベルを保証する要件はありますか? たとえば、上記の関数は、対応する失敗値以外の値を実際に返すことができる必要がありますか?