技术支持这么差么？

要你们一个库文件迟迟不发，发EMAIL给你们也没有反应，要你们给个权限下载也没给，你们做这的事情就这么难？就一心想卖多少芯片，不乐于帮客户解决问题？在使用你们的芯片时遇到问题就这么难得到答复，试想，问题没解决谁敢用你们的芯片？能否提供MSN之类的支持呢？你们以库的方式保护你们的知识产权这个可以理解，但库的方式会带来使用方发现问题解决问题的难度，你们技术支持就这么难做么？一个EMAIL也懒得回，一个简单的操作也不懒得去做？

1. 希望你们能提供最新的LIB CH375LIB.ZIP 2006-03-18 1.57MB 2.9 · CH375的U盘文件级操作子程序库及相关例子源程序 支持FAT12/FAT16/FAT32的闪存盘和移动硬盘 支持MCS51/AVR/MSP430/ARM/80X86等单片机和DSP ）

2. 能否提供LIB的源程序 我使用51的芯片，想使用CH375HF6.LIB，另请问是否与CH375HF4.LIB兼容？我至少能获得哪个源代码呢（不只是LIB的库文件），我在论坛中看到有朋友已经获得，不知能否给我EMAIL一份。 MCS51 单片机的增强版子程序库，文件名是CH375HF6.LIB，可以在订购芯片或者评估板时提供。子目录是FILELIB6，提供多个示例程序。

3. 联系方式： XJW@3core.com 个人信息保护，已隐藏

你要是决的上网申请速度慢的话，你可以打电话给我们销售人员，他们会给你下载权限的，还有就上库6兼容库4，你可以放心的使用

这个项目我只能利用晚上时间做，到今天已是第4天了，昨天晚上弄到凌晨2点，昨天使用的是CH375HF4.LIB，今天晚上又用CH375HF6.LIB试过了，

程序工作过程大至如下（3-6为循环）： 1. 插入U盘 2. CH375初始化 3. CH375DiskSize( ); 4. CH375FileOpen( ); // List file 5. CH375FileCreate( ); 6. CH375FileClose( );

问题出在哪了呢？

不会是U盘兼容性的问题吧？先前一直测试的U盘型号为中科存储的金存太学士，64MB。使用CH375HF4.LIB时执行3次循环后，在第4次循环执行CH375FileCreate( )时死于库中；使用CH375HF6.LIB时执行5次循环后，在第6次循环执行CH375FileCreate( )时死于库中 后改用另一个U盘（UFD-64M），同样是64MB，测试，也会出现以上的现象，但正常的循环次数要多些

测试程序:EXAM6，稍做修改，可由串口信息看出操作过程（与上段描述稍有不同）

串口输出信息 ===================================================== 第一次循环 ----------------------------------------------------- Wait Udisk Ready ? DiskSize TotalSize = 62 MB Open List file /* Create Write Close Erase Take out

第n次循环（屈指可数的几次） ----------------------------------------------------- Wait Udisk Ready ? DiskSize TotalSize = 62 MB Open List file /* Create Write Close Erase // 不再继续，死于库中。可能出现的现象之一：U盘文件系统被破外（UFD-64M），将这个U盘插入计算机后，机器变得很慢（试过两台机），格式化U盘很慢，约3~4分钟；可能出现的现象之二：U盘中原有的某文件消失，U盘可在计算机中操作 =====================================================

测试，继续中……

发现死于以下两条函数： 1. CH375FileCreate( ); 2. CH375FileErase( ); 创建相同文件名的文件时是否也会执行此函数？

问题在哪呢，死于库中 大概是一个标志位的判断处无法过去

C:0x21BD 22 RET C:0x21BE AF27 MOV R7,0x27 C:0x21C0 AE26 MOV R6,0x26 C:0x21C2 AD25 MOV R5,0x25 C:0x21C4 AC24 MOV R4,0x24 C:0x21C6 EC MOV A,R4 C:0x21C7 4D ORL A,R5 C:0x21C8 4E ORL A,R6 C:0x21C9 4F ORL A,R7 C:0x21CA 6056 JZ C:2222 C:0x21CC 8F4F MOV 0x4F,R7 C:0x21CE 8E4E MOV 0x4E,R6 C:0x21D0 8D4D MOV 0x4D,R5 C:0x21D2 8C4C MOV 0x4C,R4 C:0x21D4 E527 MOV A,0x27 C:0x21D6 24FF ADD A,#0xFF C:0x21D8 F527 MOV 0x27,A C:0x21DA E526 MOV A,0x26 C:0x21DC 34FF ADDC A,#0xFF C:0x21DE F526 MOV 0x26,A C:0x21E0 E525 MOV A,0x25 C:0x21E2 34FF ADDC A,#0xFF C:0x21E4 F525 MOV 0x25,A C:0x21E6 E524 MOV A,0x24 C:0x21E8 34FF ADDC A,#0xFF C:0x21EA F524 MOV 0x24,A C:0x21EC E4 CLR A C:0x21ED F548 MOV 0x48,A C:0x21EF F547 MOV 0x47,A C:0x21F1 F546 MOV 0x46,A C:0x21F3 F545 MOV 0x45,A C:0x21F5 7F4C MOV R7,#0x4C // 回到此处 C:0x21F7 E4 CLR A C:0x21F8 FD MOV R5,A C:0x21F9 120798 LCALL C:0798 C:0x21FC EF MOV A,R7 C:0x21FD 6001 JZ C:2200 C:0x21FF 22 RET C:0x2200 E548 MOV A,0x48 C:0x2202 2401 ADD A,#0x01 C:0x2204 F548 MOV 0x48,A C:0x2206 E4 CLR A C:0x2207 3547 ADDC A,0x47 C:0x2209 F547 MOV 0x47,A C:0x220B E4 CLR A C:0x220C 3546 ADDC A,0x46 C:0x220E F546 MOV 0x46,A C:0x2210 E4 CLR A C:0x2211 3545 ADDC A,0x45 C:0x2213 F545 MOV 0x45,A C:0x2215 300EDD JNB 0x21.6,C:21F5 // 此处无法继续向下，在此循环 C:0x2218 12259A LCALL C:259A

库里的东西我是不想去深入研究了，会要人命的，想要你们提供这个库的源码，碰了一鼻子的灰，你们的销售非得要我买你们2K个CH375才会免费提供源码，或花900RMB来购买。我现在灰头灰脸的，碰上这问题无法继续下去了。钱我是不会出的了，我的程序没调试成功，没有找到问题在哪也许一个也不会再买了。不知你们能否提供技术支持，至少能给我一段与CH375FileErase( )函数相关的代码，请尽快回复（我看你们对EMAIL与对帖子的回应总是比较的迟钝，或者说是不怎么重视，那种你们认为有量的公司也许例外）。在写这些东西的时候，我已经在考虑使用SYPRESS的SL811了，不是我不相信国产的芯片，我想说的是你们的技术支持，这种以LIB库封装了的技术支持做得让我们做开发的太难做了。 至少一种奇怪的现象是问你们技术支持能否提供些资料，回答竟是找销售的，你们销售是卖芯片的还是提供技术支持的？你们是卖开发板还是卖文件系统的还是卖芯片的？ 与你们销售打电话很窝心了，有很多想骂人的话咱就不说了，也不是想骂谁，就觉得你们这种做法是与客户过不去，更是与自家公司过不去，你们老大的观念有问题，你们是设计、生产芯片的公司，希望不要仿效周立功的做法，他们是专卖芯片的，他们的芯片是PHILIS等芯片巨头公司生产的，他们的芯片不愁卖不出去，我就不信你们的芯片也不愁卖不出去，你们究竟是靠卖芯片赚钱？还是想赚那点本应该由你们提供技术支持的那点文件系统的小钱？这样做下去你们会失去很多客户的。一个弱小的公司服务不要太死板了，否则只有死路一条。 乱说了一通，不想浪费我的口水了，说错了的地方，你们可以解释，也请不要骂我。这两天我的问题解决不了，我可能会没那么再关注这个论坛了，我一直希望国产的芯片公司快速成长起来，忠心的祝愿你们生意越来越好

讲得都有道理啊，如果不提供库的源代码的话，想学好这块芯片确实难了，还有如果把整个子程序库搬进去的话，最后生成HEX文件是很大的，很耗费单片机的ROM。找块便宜的都不够容量了。我也十分渴望能得到贵公司的子程序库源代码。 我的邮箱是： panzhx◎126.com

有道理，支持，我比你惨多了，快一个月了，我的项目还没完，调用CH375DiskReady( ); 程序总是停在这个地方，void xQueryInterrupt( void ) /* 查询CH375中断并更新中断状态 */ { 。。。。 while ( CH375_INT_WIRE ){ /* 如果CH375的中断引脚输出高电平则等待 */

} xWriteCH375Cmd( CMD_GET_STATUS ); /* 获取当前中断状态,发出命令后至少延时2uS */ CH375IntStatus = xReadCH375Data( ); /* 获取中断状态 */ if ( CH375IntStatus == USB_INT_DISCONNECT ) CH375DiskStatus = DISK_DISCONNECT; /* 检测到USB设备断开事件 */ else if ( CH375IntStatus == USB_INT_CONNECT ) CH375DiskStatus = DISK_CONNECT; /* 检测到USB设备连接事件 */ }

非常需要源文件，可他们不给。如果我的问题解决不了，我也要换芯片了。

恼火。

我试了EXAM6的程序，U盘插拔了10几次都是一样的，没有出现你说的那种情况啊！你如果操作错误的话它会提示错误代码的，你就试下我给你发的文件看可以不可以，要是可以的话，那就说明你改的软件有点问题了。

多谢回复，EMAIL已收到，我中午回去试，下午会有结果

1. 我硬件设计的片外RAM地址: 0000H~7FFF

2. CH375的地址由CPLD(XC9572XL 注：3V低压器件)实现，定义在: 0x8000 - 0x8001 COMMAND Addr: 0x8001 DATA Addr: 0x8000

3. 故定义CH375端口地址如下: #define CH375_CMD_PORT_ADDR 0x8001 /* CH375命令端口的I/O地址 */ #define CH375_DAT_PORT_ADDR 0x8000 /* CH375数据端口的I/O地址 */

4. 与你们的文件不同之处仅在CH375的端口地址 #define CH375_CMD_PORT_ADDR 0xBCF1 /* CH375命令端口的I/O地址 */ #define CH375_DAT_PORT_ADDR 0xBCF0 /* CH375数据端口的I/O地址 */

问题(问题一)出在这么？我没有通读你们提供的所有文档，是否0x8000-0xBCEF地址之间你们还有其它方面的定义？如果有定义，并有文档说明，那是我的问题，没有仔细阅读你们的文档(项目做得太匆忙了，各文档只是快速流览了一遍)；如果不是，那根本问题在哪呢？

5. 我修改CH375的端口地址为0xBCF1与0xBCF0后，测试插拔U盘几十次，没有出问题，但至插拔U盘82次左右，出现如下问题： 程序在以下语句等待，U盘插入后没有反应，芯片ACT脚外接LED不亮，程序复位运行后亦如此 while ( CH375DiskStatus != DISK_CONNECT ) xQueryInterrupt( ); /* 查询CH375中断并更新中断状态,等待U盘插入 */ C:0x286A 20B2FD JB INT0(0xB0.2),xQueryInterrupt(C:286A) // 程序在此地址死等 C:0x286D 90BCF1 MOV DPTR,#CH375_CMD_PORT(0xBCF1) C:0x2870 7422 MOV A,#0x22 C:0x2872 F0 MOVX @DPTR,A C:0x2873 534F80 ANL 0x4F,#P0(0x80) C:0x2876 E54F MOV A,0x4F C:0x2878 6003 JZ C:287D C:0x287A E4 CLR A C:0x287B F54F MOV 0x4F,A C:0x287D 90BCF0 MOV DPTR,#CH375_DAT_PORT(0xBCF0) C:0x2880 E0 MOVX A,@DPTR C:0x2881 F54F MOV 0x4F,A C:0x2883 E54F MOV A,0x4F C:0x2885 B41604 CJNE A,#0x16,C:288C C:0x2888 752E01 MOV 0x2E,#0x01 C:0x288B 22 RET

芯片硬复位（重新上电）后又正常 出现这个问题(问题二)的原因是什么？是否是插拔误操作引起？我需再做类似的测试

6. 能否提供你们LIB库（CH375HF6.LIB）的头文件以供参考？以便对库中变量的定义有所了解，最好是能提供源码了，这样大家用过一次之后，感觉可以的话，还有可能用第二次第n次，完全掌控程序的所有资源对我们放心大胆的使用你们的芯片是有帮助的，如果芯片没什么BUG，工程师们会喜欢使用这个芯片的

首先需要明确的是你的地址完全取决于你的硬件电路，你如果出现地址问题的话，那可能是你的译码电路有关系，同时，你在插拔U盘的时候要注意你的U盘插拔之间的时间不能太短，太短的话可能有影响。

地址的定义，译码电路的设计我是比较有把握的，如果真是地址的问题，我会用示波器再来仔细观察各关键信号的波形，我一直没有怀疑到地址硬件译码这块去，再说我的译码电路的地址也很简单，0x8000 - 0x800F为外围器件地址。译码电路的设计，0x8001与0xBCF1对外部器件的操作地址是一样的，0x8000与0xBCF0对外部器件的操作地址是一样的。今天我并没有对CPLD做任何修改，只是改了那两个我从未怀疑过的CH375端口地址（例子程序中的0xBCF1与0xBCF0），对这四个地址的操作我晚上用示波器做仔细比对。

至少有些进展了！ ：）

测试中……

U盘插拔120次没有出现问题。晚上继续，我会仔细检察我的译码电路（CPLD）。前几天因ISE7.1的BUG害我在这上面花了差不多两个晚上，后安装SP4后基本解决问题，如果再不行我用ISE6.3来做，希望我写的一些东西对正在做CH375的朋友有一些参考价格，多谢hcn！

为便于分析问题，能否提供LIB库（CH375HF6.LIB）的头文件以供参考？

头文件就是CH375HF6.H啊

知道了，所有的定义都在里面么（应当有些头文件只包含在库中吧，我做过库并有包含库的项目，程序也有50K左右）

最好能给份LIB库的源代码，也许你们的源码也不完全由自己开发的吧，也有来自网上的东西吧

今后使用过程中还有可能会出现一些问题，无源码解决问题太慢了，而且还要不停的来麻烦你们。

昨天晚上又测了一个晚上，用泰克100M的示波器测的

我的硬件，地址译码上是使用了A15，A3，A2，A1，A0 也就是说 0x8000 - 0x8010 - 0x8020 - 0x8030 …… 0xFFE0 - 0xFFF0 是一样的 DATA_Addr 0x8001 - 0x8011 - 0x8021 - 0x8031 …… 0xFFE1 - 0xFFF1 是一样的 CMD_Addr 0x8002 - 0x8012 - 0x8022 - 0x8032 …… 0xFFE2 - 0xFFF2 是一样的 0x8003 - 0x8013 - 0x8023 - 0x8033 …… 0xFFE3 - 0xFFF3 是一样的 …… 0x800E - 0x801E - 0x802E - 0x803E …… 0xFFEE - 0xFFFE 是一样的 0x800F - 0x801F - 0x802F - 0x803F …… 0xFFEF - 0xFFFF 是一样的

比较了地址0x8000与0xBCF0，0x8001与0xBDF1这两对地址对CH375操作的波形是完全一样，为什么我定义端口地址为0xBCF0,0XBDF1或0xFFF0,0xFFF1都没有题，而定义为0x8000,0x8001就会死于库中呢(可能还有些地址不能用)，并且对于这种情况，怎么分析调试下去？如果有源码就可跟踪下去，从而找出问题所在（不排除是我的软硬件问题）

我希望今天能找到问题的根本原因，并继续做下去，要不就算用你们提供的地址来做，做出来的东西有可能会存在BUG的

800X和BXXX地址是否效果相同，要看你如果产生CH375的CS以及A0 如果是用P2.7反相产生CS、用P2.0作为A0则一样（除非还有其它外围使用P2.6-P2.2之间的一根线做片选冲突） 另外，硬件电路如何构成也有关系，如果是临时搭的电路且连线较长２０ＣＭ以上，信号线间会有干扰不稳定 频繁测试硬件插拔，要求硬件电路有电流限制措施（实测刚插盘时峰值冲击电流几安培），抗干扰措施， 还有连接和断开的时间不要短于１秒（要考虑插拔时的抖动、上电延时、有的ＵＳＢ插座还偶你接触不良...）

[Emot]27[/Emot]0