完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
你好,我有一些RN48的实验和观察分享,请告诉我如果你有解决方案或回答这些疑问。谢谢,--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------重写RN861缓冲区有哪些?如果是,缓冲区的大小是多少?RN878需要多长时间清除它的缓冲器(如果有的话)?我应该多久写一次新信息,或者等待多长时间?如果RN准备好接收下一条信息,我怎么知道呢?我假设硬件流控制应该指导我,当它准备好了,什么时候我应该停止写,但这似乎不起作用……我已经在我的项目侧的RNS48的RTS线路上应用了一个下拉电阻(下面解释),这条线在D期间没有改变它的状态。AT---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------E硬件流控制开启。子板单元是中心,它扫描并启动连接到我的项目板。配置过程工作良好($ $,SS,C0,SR,8000…),也建立正确的连接。两个单元都可以通过透明的UART来交换消息,这些消息在字节计数10到20个ASCII字符中是很小的。当我从外围设备向中心模块发送大量数据时,问题就发生了。每行(到UART缓冲器),我的项目MCU花费一些时间来构造下一行,然后发送新的线路。任何输出线的字节数不超过64个字符,因此,我不会连续地流出100个字符或1000个字符。例如,我的输出文件中的第60行出现在我收到的文件的第12行。托尔!我开始使用透明NUART模式下的RN861而不进行任何流量控制。这是一个很好的连接方式,并通过两种方式进行良好的数据传输。然后我开始使用硬件流控制,在重新启动后,在我的项目板上的RN878将发送%ReBooG%,然后它没有回复它,它没有接受任何命令(没有$$,没有任何其他东西),所以我检查RN的RTS输出。4871,大约200MV,不完全是逻辑低。我认为这可能会阻碍我的MCU UART写任何东西,所以我应用了1KOHM的下拉。虽然在数据表中没有提到关于下拉,但是在使用这个电阻器之后,我的设置工作在硬件流控制上。正如我前面提到的,使用流量控制的东西看起来很好,但是我注意到了批量传输的问题(上面提到过)。我把1K电阻器改为100K,认为1K的下拉太强,但是这个新的电阻也不起作用。在进行通信时,我仍然没有看到RTS线路上的任何电平漂移,如果我拆下,RN将停止在H/W流量控制中工作。--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以上来自于百度翻译 以下为原文 Hi, I have some RN4871 experiments and observation to share, please let me know if you have solutions or any answer to these queries. Thanks, ------------------------------------------------------------------ observing out of order uart communication(Explained below), I wonder is it possible that I am overwriting the RN4871 buffer some how? > if so what is the buffer size? > how long does RN4871 take to clear out its buffer (if any)? how often should I write new info, or how long to wait? > how would I know, if RN is ready to receive next line of info? > I assumed hardware flow control should guide me regarding when it is ready and when should I stop writing, but that does not appear to work... > I have applied a pull down resistor on RTS line of RN4871 on my project side(Explained below - below), that line did not changed its state during data transfer. ------------------------------------------------------------------ ------------------------------------------------------------------ I am using RN4871 modules, one is soldered on my project board and another on PICTAIL Daughter board. I have set them up to operate in transparent UART mode with hardware flow control turned on. Daughter board unit is central it scans and initiates connection to my project board. The configuration process works fine ($$$, SS,C0, SR,8000 ...), also the connection is established correctly. Both units can exchange messages over transparent UART, these messages are small in byte counts 10 to 20 ASCII characters back and forth. The problem occurs when I send bulk of data from my peripheral to central module. by bulk I mean, I am sending a file, line-by-line(ending in 'n'), after sending out each line (to UART buffer) my project MCU takes some time to construct next line and then send out that new line. number of bytes in any outgoing line does not exceed 64 chars, so, I am not streaming out 100's or 1000's of characters continuously. > This bulk transfer is not working fine, on the receiving end error like not receiving all the data bytes in same order. for example line number 60 in my outgoing file appears in line 12 in my received file. > or some lines are over written by content of some other lines ------------------------------------------------------------------ ------------------------------------------------------------------ Pull-down resistor! I started using RN4871 in transparent uart mode without any flow control. It was working fine making connections and doing good data transfer both ways. Then I started using hardware flow control, the RN4871 on my project board after reboot would send %reboot% and then it just did not reply it did not took any command (no $$$ not any thing else) So I check RTS output of RN4871 and it was around 200mV, not exactly logic-low. I though this might be blocking my MCU UART from writing anything out, so I applied a pull down on 1KOhm. Though nothing is mentioned in datasheet regarding pull down but after using this resistor my setup worked with hardware flow control on. As I mentioned earlier using flow control things seemed to work fine but I noticed the problem of bulk transfer(above mentioned). I replaced 1k resistor to 100k thinking 1k is too strong pull-down but this new resistor did not work either. I still do not see any level shifts on RTS line during ongoing communication, if I remove pull down the RN will stop working in h/w flow control. ------------------------------------------------------------------ |
|
相关推荐
6个回答
|
|
|
|
|
|
我回复了我自己的帖子,这是一个更新的情况,但我不能看到它的线程。
以上来自于百度翻译 以下为原文 I replied to my own post, it was an update on the situation but I can not see it in thread. |
|
|
|
嗨,你在RN878上使用哪种固件?当做
以上来自于百度翻译 以下为原文 Hi, Which firmware to you use on RN4871 ? Regards |
|
|
|
|
|
|
|
我在听你的信息。我用RN52很长时间了,现在刚开始用RN871U。我有两个突破板,每个RN48 71U。然后我安装每个面包板上的突破。我使用TARA术语VT。我使用命令数据SeET.CMD MODess中的示例启动连接过程,C0FI获得Mac CMAC的扫描响应,以及lt;0,1>&“Mac”。我把一个LED放在P02上,不知道眨眼是什么。我的目标是有两个MCU通信,第三个是智能手机。罗杰
以上来自于百度翻译 以下为原文 I'm following your information. I've been using RN52 for a long while and now just started with the RN4871U. I have two breakout boards with each RN4871U. I then mounted the breakouts each on bread boards. I use the Tera Term VT. I started the connection process using the example in the command data sheet. CMD mode SS,C0 F I get the Scanning response for the MAC Enter the MAC C, <0,1><"The MAC"> err You see I'm just getting started. I put an LED on P0_2, not sure what the blinking is all about. My goal is to have two MCU communicating and third a Smart phone. Roger |
|
|
|
嗨,RogerI am使用C,0,& lt;MAC - 12 char & gt;这不总是在第一次尝试中连接。我必须尝试它的一段时间或重新启动设备中的一个并重新启动或改变我的蓝牙模块的位置,然后它们最终与消息流连接。侧类似,C0SR,8000 / /用于H/W流量控制在我的情况下& GT;在外围设备上,1 / /重新引导完成以上配置步骤& GT;然后在主机侧边框上使用主机侧边框/扫描,012345 67 89ABCI在PIC尾板上检查RN878(我不使用RN48 71U)当它闪烁时,它被连接到P0E2,意味着蓝牙正在开启。
以上来自于百度翻译 以下为原文 Hi Roger I am using C,0, This does not connect always in first attempt I have to try it couple of time or reboot one of the device and start again or change the position of my bluetooth modules then they eventually connects with message StreamON > I hope you are configuring both sides similar SS,C0 SR,8000 // for h/w flow control in my case > on peripheral side R,1 // rebooting after done with above configuration step > And then use these on host side F // scanning on your host side C,0,123456789ABC I checked on Pic tail board for RN4871 (I am not using RN4871U) LED1 is connected to p0_2 when this is blinking it means bluetooth is on |
|
|
|
只有小组成员才能发言,加入小组>>
5129 浏览 9 评论
1984 浏览 8 评论
1914 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3149 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2212 浏览 5 评论
698浏览 1评论
586浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
467浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
603浏览 0评论
495浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-3 08:21 , Processed in 1.408963 second(s), Total 89, Slave 72 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号