[问答]

USB数据记录器很慢

659

问答对人有帮助，内容完整，我也想知道答案 0 PIC24FJ256GB106 MPLAB 8.92 MLA V2013-0615使用16GB逐字格式，格式化为4096的分配单元大小。FSCONFIG被设置为y*定义MediaSeCeTracl大小512。在大约5MB的驱动器使用之后，文件的打开和创建开始花费很长时间。例如，一个304字节的文件需要2分钟。没有数据的损坏，只是很慢地完成任务。当我用一个相同类型和格式的空棒替换拇指驱动器时，它保存了正常的文件。我很感激这里没有太多的事情要做，但是如果有人看到这样的东西，我可以提供更多的信息给DI。谢谢，谢谢。以上来自于百度翻译以下为原文 PIC 24FJ256GB106 MPLAB 8.92 MLA _v2013-06-15 Using 16GB Verbatim, formatted to 4096 Allocation Unit Size. The FSconfig is set for #define MEDIA_SECTOR_SIZE 512. After approximately 5MB of drive usage the opening and creating of files starts to take a long time. For instance a 304 byte file would take 2 minutes. There is no corruption of data, just really slow to complete the task. When i replace the thumb drive with an empty stick of the same type and format, it saves the file as per normal. I appreciate there's not much to go on here, but if anyone has seen anything like this, I can provide more info to discuss further. Thanks 0
2019-1-18 08:44:39　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × qun333 该类别下有 57 个回答。邀请回答技术发广告该类别下有 56 个回答。邀请回答 caoguiqun 该类别下有 56 个回答。邀请回答 psw30 该类别下有 44 个回答。邀请回答伊丹姿子该类别下有 41 个回答。邀请回答 uwufwjrw 该类别下有 39 个回答。邀请回答 hetao1111 该类别下有 38 个回答。邀请回答 lc123617 该类别下有 35 个回答。邀请回答欧阳大大该类别下有 32 个回答。邀请回答作死不止该类别下有 31 个回答。邀请回答 asd010 该类别下有 31 个回答。邀请回答 wy8719 该类别下有 29 个回答。邀请回答 60user92 该类别下有 29 个回答。邀请回答 ju978779 该类别下有 28 个回答。邀请回答嘻嘻爱哈哈该类别下有 28 个回答。邀请回答 haikitty 该类别下有 28 个回答。邀请回答 pol666 该类别下有 27 个回答。邀请回答 xiuzhen122 该类别下有 27 个回答。邀请回答 ueywyrsdfs 该类别下有 26 个回答。邀请回答 lhly23 该类别下有 25 个回答。邀请回答举报王国花相关推荐 • 数据记录器演示不起作用 927 • Bencklink数据记录器3 USB通信错误 2589 • PIC控制的远程数据记录器 1192 • esp8266能否发送从sd卡模块（数据记录器文件）创建的文件.xls？ 371 • Freemaster记录器不起作用怎么解决？ 556 • 怎么使用GUI数据记录器记录DMM屏幕上显示的温度读数？ 2009 • 带有SD卡和USB MSD接口的CAN数据记录器 1181 • 是否可以通过局域网获得6705B数据记录器结果 1766 • 基于ALIENTEK STM32制作的串口记录器 2021 • U1620A数据记录器无法启动 1889 1个回答

答案对人有帮助，有参考价值 0 我想添加SputtILLFN使得搜索时间更长。不幸的是，我不能没有这个，因为我USEREC.UTF16LFNFROUTHOLD在一个单独的例程中查找文件的大小（用于读取文件并通过蓝牙发送它们），令人惊讶的是，这一点要复杂得多，但与创建一个新文件的时间相比要花费一小部分时间。列表中的-好的，谢谢大家帮我理解地狱到底发生了什么，多么令人头痛。以上来自于百度翻译以下为原文 I suppose adding SUPPORT_LFN has made the searching take even longer. Unfortunately I cant do without this because I use rec.utf16LFNfoundLength to find the size of a file in a separate routine (for reading files back and sending them via bluetooth) surprisingly this is much more sophisticated but takes a fraction of the time compared to creating a new file at the end of a list. -_- OK, thanks guys for helping me understand what the hell is going on, what a headache. Cheers

2019-1-18 10:13:34 评论举报殷夏