Back
[20:34:31] <anton02> My serial bluetooth device spec states that if I send "AT" to it, it should respond with "OK". This is a method to test it. To do this would I just need to run USART_Transmit('A'); followed by USART_Transmit('T'); Here is what USART_Transmit() looks like
http://codepad.org/9CNK4k0i
[20:37:45] <Casper> you also need an enter
[20:39:50] <anton02> Casper: sorry?
[20:39:58] <Casper> AT\n
[20:40:13] <Casper> 3 bytes
[20:40:15] <anton02> oh
[20:40:17] <anton02> thanks
[20:42:29] <Casper> "AT" is not a command per se, it's more a command header if you want
[20:42:31] <anton02> Casper: Actually specs says you shouldn't do that. Set the UART device c onnected with the BT module to 9600bsp, 1 stop bit, non-flow control, now user can send the AT command to the device, take the basic AT command "AT" for example, you can send it to the BT module , and the BT module will response with "OK", pleas e note, there is no " \r \n" characters after the "AT" command. You just need to send "AT", the HEX value is "41 54", you c
[20:42:50] <Casper> it basically mean: "attention, a command for you is comming up"
[20:43:04] <Casper> o.O
[20:43:11] <Casper> so they violate yet another specs...
[20:52:15] <anton02> i wonder if im meant to use #define USART_BAUDRATE or #define BAUD
[21:32:36] <myself> Wow, yeah, that's awful. It's not even a spec, just a de facto standard based on how Hayes modems worked. I guess it probably got standardized in a few CCITT specs along the way, but at its core it's just a custom.
[21:33:04] <myself> But there's still no excuse to be so recklessly clueless as to break if you should include a carriage return.