PCIバスを介してVMEブリッジチップ(Tundra Universe II)への32ビット未満の読み取りを実行しようとしています。VMEブリッジチップはVMEバスに接続され、ターゲットによってピックアップされます。
ターゲットVMEアプリケーションはD32(32ビットのデータ幅読み取り)のみを受け入れ、それ以外は無視します。
VMEウィンドウにマップされたビットフィールド構造を使用する場合(メインメモリにnmapされます)、24ビットを超えるビットフィールドを読み取ることができますが、それ以下のものは失敗します。すなわち:-
struct works {
unsigned int a:24;
};
struct fails {
unsigned int a:1;
unsigned int b:1;
unsigned int c:1;
};
struct main {
works work;
fails fail;
}
volatile *reg = function_that_creates_and_maps_the_vme_windows_returns_address()
これは、構造体が32ビットとして読み取られることを示していますが、たとえばreg-> fail.aの構造体を介した読み取りが失敗すると、Xビットの読み取りに因数分解されます。(Xは16または8の場合がありますか?)
したがって、質問は次のとおり
です。a)これはどこで縮小されますか?コンパイラ?OS?またはツンドラチップ?
b)実行された読み取り操作の実際のサイズはどれくらいですか?
私は基本的にチップ以外のすべてを除外したいと思います。そのドキュメントはWeb上にありますが、PCIバスを介して要求されたデータ幅が32ビットであることが証明できる場合、問題はTundraチップのせいにすることができます。
編集:-
具体的な例、コードは次のとおりです:-
struct SVersion
{
unsigned title : 8;
unsigned pecversion : 8;
unsigned majorversion : 8;
unsigned minorversion : 8;
} Version;
だから今私はこれに変更しました:-
union UPECVersion
{
struct SVersion
{
unsigned title : 8;
unsigned pecversion : 8;
unsigned majorversion : 8;
unsigned minorversion : 8;
} Version;
unsigned int dummy;
};
そして、基本の主な構造体:-
typedef struct SEPUMap
{
...
...
UPECVersion PECVersion;
};
だから私はまだすべてのベースラインコードを変更する必要があります
// perform dummy 32bit read
pEpuMap->PECVersion.dummy;
// get the bits out
x = pEpuMap->PECVersion.Version.minorversion;
また、元のコードのように、2回目の読み取りで実際に実際の読み取りが再度行われないかどうかをどのように知ることができますか?(ユニオンを介してすでに読み取られたビットを使用する代わりに!)