linux下ARM处理器对16位FPGA的访问问题

1、linux下arm处理器对16位fpga的访问问题 有一个伴侣在调试arm和接口的时候遇到了一个惊奇的问题，向我寻求协助。 问题描述：arm用法s3c2440，fpga和arm的接口为16位，用法地址线，片选线为ncs3，操作系统用法linux-2.4测试程序为：test.cdefine fpga_address 0x18000000int main( )unsigned char *sp;unsigned short mem;int memfd;memfd=open ("/dev/mem",o_rdwr);sp=(unsigned char *)mmap(0,10000,

2、prot_read|prot_write,map_shared,memfd,fpga_address);*(unsigned short*)(sp+0x20c)=0x5678;*(unsigned short*)(sp+0x20e)=0x1234;munmap(sp,10000);close(memfd);程序解释：由于linux下对不能对物理肯定地址举行拜访，需要用法mmap函数举行内存映射;编译办法：arm-linux-gcc -o test test.c该程序在运行的时候不能正确的向fpga的地址内部写入16位的shor类型，经过规律分析仪观看，发觉在向16位的地址空间写入0x5678的

3、时候，事实上是向fpga内部写了两次，一次是:0x5656，另外一次是0x7878;同理，当写0x1234的时候，也是分为两次写入的：一次是0x1212，另外一次是0x3434。假如将上述程序修改一下，在ads下挺直编译运行，程序能够胜利。这解释程序是没有问题的，fpga对arm的接口时序也应当是没有问题的。这让我困窘不已。明明是一个16位的short类型，arm和fpga的接口也是16位的，为什么要分为两次送入，看来是编译器的问题，预备用法反汇编的工具看看源代码。在ads下，可以挺直看到反汇编后的代码，在linux下，发觉arm-linux-objdump工具也可以对目标代码举行反汇编：使用

4、为arm-linux-objdump -d -t test >aa用法>aa重定向将输出信息打印到文件中：841c: e50b0010 str r0, fp, -168420: e3a03f83 mov r3, 524 ; 0x20c8424: e51b2010 ldr r2, fp, -168428: e0833002 add r3, r3, r2842c: e3a02078 mov r2, 120 ; 0x788430: e3a01056 mov r1, 86 ; 0x568434: e5c32000 strb r2, r38438: e5c31001 strb r1, r3,

5、 1843c: e3a03f83 mov r3, 524 ; 0x20c8440: e2833002 add r3, r3, 2 ; 0x28444: e51b2010 ldr r2, fp, -168448: e0833002 add r3, r3, r2844c: e3a02034 mov r2, 52 ; 0x348450: e3a01012 mov r1, 18 ; 0x128454: e5c32000 strb r2, r38458: e5c31001 strb r1, r3, 1通过反汇编，果真看到了用法了两条strb的命令将一个16位的数据分为两个8bit的数据送出;strb命令

6、：从源寄存器将一个8bit的数据送到存储器，该字节为源寄存器的低8位。问题找到了，如何将一个16位的数据一次性的输出呢，在网络搜寻了一下，发觉有一篇文章也谈到了这个问题只要在编译的时候指明-march=armv4选项即可：用法下面的指令重新编译：arm-linux-gcc -march=armv4 -o test test.c反汇编后得到的命令为：8494: e3a02c56 mov r2, 22016 ; 0x56008498: e2822078 add r2, r2, 120 ; 0x78849c: e1a01002 mov r1, r284a0: e1c310b0 strh r1, r384a4: e3a03f83 mov r3, 524 ; 0x20c84a8: e2833002 add r3, r3, 2 ; 0x284ac: e51b2010 ldr r2, fp, -1684b0: e0833002 add r3, r3, r284b4: e3a02c12 mov r2, 4608 ; 0x120084b8: e2822034 add r2, r2, 52 ; 0x34