同感 不如原版

                                 

有人看,没有人顶 PA8 MCO有25MH ETH_MII_TX_CLK,ETH_MII_RX_CLK都有时钟. 有没有人知道, 真有点怀疑是Z版本芯片有什么BUG,但ST的err sheet上没有看到这方面的说明 现在有其他版本的STM32F107VC吗? ...

ETH_MII_TX_CLK,ETH_MII_RX_CLK 没有时钟时，会出现LZ的情况。 但现在有时钟，按理就不应该出现LZ的情况，建议看看这2个时钟的频率，以及幅值是多大。

我个人觉得： 1. 照现在这样的发展趋势，微软已经放弃了Mobile架构，Phone7会取而代之。封闭系统在智能手机领域应该是一个趋势，像iPhone，有很好的兼容性，这样应用程序人员不会做重复劳动，而且对用户体验也有保障，可以缩短产品研发周期。 2. CE还会继续发展，不过应该更偏向于一个基础平台。CE和Andriod是不能直接相比较的，CE应该和Linux是一个层面的东西，Android, iPhone, meego应该是同一个层面的东西。 综上所述，写驱动的，转行做Andriod会更好些，因为Android的定位不是一个封闭系统，相比Phone7和iPhone更加开放。

引用 1 楼 wangyingying606 的回复: 顶一下，驱动上应该和市面上大部分的TN83一样啊。如果用TN83的驱动还不能显示，那就是楼主再查查板子的事了。

参考83的再试试， 也不能确定板子没问题

我是在写一个键盘过滤程序，用了两个缓冲区，每一次击键写一个字符到第一个缓冲，这个缓冲满后再把它中的数据复制到第二个缓冲区，再创建一个线程从第二个缓冲区中复制数据到文件。 调试信息如下： ATTEMPTED_SWITCH_FROM_DPC (b8) A wait operation, attach process, or yield was attempted from a DPC routine. This is an illegal operation and the stack track will lead to the offending code and original DPC routine. Arguments: Arg1: 00000000, Original thread which is the cause of the failure Arg2: 00000000, New thread Arg3: 00000000, Stack address of the original thread Arg4: 00000000 Debugging Details: ------------------ DEFAULT_BUCKET_ID:  DRIVER_FAULT BUGCHECK_STR:  0xB8 PROCESS_NAME:  System LAST_CONTROL_TRANSFER:  from 804f8bad to 80528bec STACK_TEXT:   8054a2a0 804f8bad 00000003 8054a5fc 00000000 nt!RtlpBreakWithStatusInstruction 8054a2ec 804f979a 00000003 805537c0 81bbb3c8 nt!KiBugCheckDebugBreak+0x19 8054a6cc 804f9ca0 000000b8 00000000 00000000 nt!KeBugCheck2+0x574 8054a6ec 80542a47 000000b8 ffffffff 00000202 nt!KeBugCheck+0x14 8054a6fc 805428bf 8054a714 806d3753 0000003d nt!SwapContext+0x157 8054a70c 806d3a86 8054a7e0 806d3753 badb0d00 nt!KiDispatchInterrupt+0x7f 8054a70c 806d3753 8054a7e0 806d3753 badb0d00 hal!HalpDispatchInterrupt+0xba 8054a784 805463ed 00000000 8054a8c8 00000000 hal!ExAcquireFastMutex+0xf 8054a7e0 805dc9a8 00000001 00000001 63416553 nt!ExAllocatePoolWithTag+0x4ed 8054a808 805dcdb7 00000000 00000000 00000000 nt!RtlpInheritAcl+0x28 8054a8e4 805e819f 00000000 e1110c40 8054a93c nt!RtlpNewSecurityObject+0x387 8054a910 805b69a1 00000000 00000000 8054a93c nt!SeAssignSecurity+0x4f 8054a940 805b9fd7 8054aa54 00000000 816868c0 nt!ObAssignSecurity+0x35 8054aa28 805c796c 816868c0 8054aa54 00000000 nt!ObInsertObject+0x473 8054ab80 805c83ed 8054abdc 00000000 00000000 nt!PspCreateThread+0x618 8054abb4 f09a5e46 8054abdc 00000000 00000000 nt!PsCreateSystemThread+0x33 8054abfc 804f16ae 81b08b70 8175d118 81b08b70 KbdFilter!kbdfReadComplete+0x1c6 [g:\code\kernel\kbdfilter\kbd_filter.c @ 440] 8054ac2c f9c4d314 00000000 8187f950 80542320 nt!IopfCompleteRequest+0xa2 8054ac48 f9a1c712 0000000c 81751f0c 8175d218 kbdclass!KeyboardClassServiceCallback+0x182 8054acac 80542b9d 8187fafc 0187f898 00000000 i8042prt!I8042KeyboardIsrDpc+0xf0 8054acd0 80542b16 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46 8054acd4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26 STACK_COMMAND:  kb FOLLOWUP_IP: KbdFilter!kbdfReadComplete+1c6 [g:\code\kernel\kbdfilter\kbd_filter.c @ 440] f09a5e46 8945e8          mov     dword ptr [ebp-18h],eax FAULTING_SOURCE_CODE:      436:                                                                                                 NULL,    437:                                                                                                 NULL,    438:                                                                                                 NULL,    439:                                                                                                 kbdFlush, >  440:                                                                                                 &FlushBuffer);    441:                                         if (!NT_SUCCESS(status))    442:                                         {    443:                                                 goto ERROR;    444:                                         }    445:                                         SYMBOL_STACK_INDEX:  10 SYMBOL_NAME:  KbdFilter!kbdfReadComplete+1c6 FOLLOWUP_NAME:  MachineOwner MODULE_NAME: KbdFilter IMAGE_NAME:  KbdFilter.sys DEBUG_FLR_IMAGE_TIMESTAMP:  4c1132f3 FAILURE_BUCKET_ID:  0xB8_KbdFilter!kbdfReadComplete+1c6 BUCKET_ID:  0xB8_KbdFilter!kbdfReadComplete+1c6 Followup: MachineOwner

郁闷啊.今天又调试了半天,现在情况是有时侯有应答,有时侯无应答.可是我的程序是一样的,硬件也是一样的,都没动过,为什么一会儿,一会没有呢,希望大家帮帮忙啊..

数据以文本形式存在计算机中，我想应该采用文件读写到一个数组中然后最后要在DSP中对数据进行处理。 是不是还要设置一个地址L2缓存，就可以把数据放到缓存中，然后对他进行处理。

同楼上的问题，有知道的请赐教，还有就是为什么要将角度的值限定在0.1—0.9的范围内

                                 优化体现水平…… 当然现在的MCU一般资源比较充足，通常情况下都可以大手大脚一点

你的void ReadDataAdc()有问题，要有返回值，你写的无法返回，改为 uchar ReadDataAdc()

这里有英文版下载: http://www.itpub.net/viewthread.php?tid=1197666

看来只能是建立两个事件,让一个事件去等另外一个事件,一个线程各等一个,不要让两个线程同时去等一个事件.

一般用Keil和Tasking两种编译器，具体可以上英飞凌的网站上看看。 另外，看样子你们的程序是直接烧写到C165芯片里面了，如果用Keil编译器的话，直接点击download就可以通过miniviggler烧写进去了。另外，如果用串口烧写的话，需要将某个引脚拉成低电平再重新上电，然后通过pc机上的一个软件将.h86文件烧写到片子里了。

驱动需要学习很多知识，比如嵌入式操作系统、计算机接口、各种通信协议(USB、PCI等)、CPU平台(单片机)的工作原理等

OK 我已经全部搞定了~ 1，对于水平波纹，这个很可能是LCD背板输出电压不稳定造成的，可以用示波器查看下； 2，如果时序不对，那么在EBOOT阶段就会出现花屏等现象，WINCE5.0中，LCD时序是在Kernel\0al/init.c和EBOOT中的MAIN.C中两部分都有的；而在WINCE6.0中，结构不同了~但思想还是一致的； 我的错误在与我昨晚分析的一样~我在S3C6410_DISP.CPP中没有添加我的10.4寸的LCD类型，所以系统进入KERNEL后，肯定花屏了！ 呵呵~~~~~有点不好意思~犯了个这么傻的错误。

什么叫WinCE自带的数据库？ 是SQLCE？SQLite？还是EVC那个面向对象的数据库？ 如果是SQLCE的，请参考此篇文章； 如果是SQLite的，我没有用过。 如果是EVC的那个，没有找到相关的在PC上使用的方法。

大侠出来帮帮忙呀   

C++

                                 楼主 这个程序里面有很多while(!I2C_CheckEvent(I2C1,I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); 这样的死等，如果有一次eeprom没有应答，程序就死那里了，我原来用24c04用这个程序还可以，现在换成24c02经常在写的时候进入死等状态。

是，马上执行