I need to use the RN4871 bluetooth module to control my MCU, so CoolTerm can be used to let it enter the Command Mode in UART. After entering the command codes on my coolterm window, I didn't receive the feedback . Here is what I wanted: https://microchipdeveloper.com/ble:rn4870-app-example-smartphone-basic-demo
I did check the lines between RS232 and my board (RX and TX) and ajusted its options about Coolterm.
Related
In my application, I specifically want to power off the mouse (if connected), Hence to do that I have to change the file permissions for the file named "autosuspend" and "level" and write to it in
/sys/bus/usb/device/the-folder-for-mouse.
How do I find out the folder name for the the-folder-for-mouse?
The same question asked be me over here but unanswered.
You could try
lsusb
or you can monitor input events from USB and other devices via:
evtest
which will also tell you the device path (e.g. mouse and keyboard, as well as power button, etc.) in /dev/input/event*. You might need to install the evtest package for that.
My program begins like this:
#!/usr/bin/env python
import sys
from serial import Serial, EIGHTBITS, PARITY_NONE, STOPBITS_ONE
SERIAL_DEVICE = '/dev/ttyUSB0'
ser = Serial(SERIAL_DEVICE, timeout=2, baudrate=9600, bytesize=EIGHTBITS,
parity=PARITY_NONE, stopbits=STOPBITS_ONE)
The next part of the program sends something to the device and then expects a response. When I run it after reboot, it doesn't find the response it is expecting and terminates with an error (this is correct behavior apart from the fact that it doesn't see the response it expects).
However, if I run minicom and talk to the device through minicom, it works fine. If then I close minicom and run the program, it runs fine. The minicom configuration has an empty initialization string and I always exit without reset.
Needless to say, minicom has the same settings AFAICS. It also has hardware control on, but I did try rtscts=True as an argument to Serial() and saw no difference (and even if I had an error in the arguments, this doesn't explain why after executing minicom the program works properly).
The symptom you have is an indication that your program is not initializing the serial terminal to the proper mode that it requires.
minicom has the same settings AFAICS
Seems like you choose to guess rather than gather actual data.
Use stty -a -F /dev/ttyUSB0 before and after using minicom.
The major difference is that the termios mode is probably canonical by default (after the reboot), and minicom leaves it in non-canonical mode.
Try using stty raw -F /dev/ttyUSB0 before starting your program.
I am connected on my embedded device with the serial port and would like to start my custom binaries on boot and be able to see the output generated.
My /etc/inittab file contains:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
console::respawn:/usr/bin/mybinary
With this configuration, I can see the output of mybinary in the serial console but It is difficult/impossible to connect (insert login and password) to getty because of the interference of the output generated.
I tried to switch the output in inittab to another not used tty (tty10) like this:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
tty10::respawn:/usr/bin/mybinary
And now I can connect but how can I see the output generated to /dev/tty10 ?
I tried cat /dev/tty10 but nothing is shown.
I know the question is old, but it has no answers at all for crying out loud.
Remember that a TTY is both an output device and also an input device -- by cat'ing from it you're reading input from the terminal which means the keyboard, NOT the screen.
I don't know if there's a parallel in other *nixes, but Linux systems have /dev/vcsX and /dev/vcsaX character devices (nodes c,7,0+X and c,7,128+X respectively) for each /dev/ttyX device - these are mirrors of the data currently on the output of the TTY device (ie. the screen part of the TTY, not the keyboard part). These will give you what you're looking for. The vcsaX devices will give you a displaybyte+attributebyte pair (i.e. the foreground/background text colour -- see other references for more information on text attribute bytes) for each character on the screen, while the vcsX devices give only the displaybyte for each character. Of course it's a raw stream/dump so if the row and/or column count of your terminal doesn't match that of the the TTY you're dumping then you'll need to parse the data and reformat it to match.
tl;dr: use "cat /dev/vcs10"
Hope that helps.
I want to change the pairing code of a device. It's a chinese clone of a MiniELM327 adapter with a Bluetooth interface. If I power it up through its OBD2 connector supplying 12V, the whole device is on. Through the Bluetooth Serial Port I can communicate with the ELM327 chip and send AT Commands, receiving correct answers.
But that is not what I want to do. I want to change the pairing code of the bluetooth interface itself.
The module is a RG-BT10-10 from Redgoo based on a Beken BK3211 chip. I have the datasheet and the command set (not sure if it's the right one). Unfortunately it is all in chinese and the customer support is in chinese too (they use automatic translators).
www . redgoo.com.cn/product/20131106105822750.pdf
www . redgoo.com.cn/product/20131130122844243.pdf
www . belon.cn/Uploadfiles/psd/BK3211datasheetv1.2.pdf
I tried to contact the manufacturer and they said that I have to send the following commands:
AT+EN1 (enter command mode)
AT+PIN****
AT+EN0 (exit command mode)
and then reset the module.
I bought a ftdi-based USB-to-UART converter at denkovi.com
www . denkovi.com/usb-to-uart-ftdi-serial-interface-adaptor
Then I wired the pins on the USB-to-UART with the corresponding contacts on the RG-BT10-10 (Tx and Rx are switched of course).
According to the datasheets, the parameters are:
Baud Rate: 38400
Parity: None
Data bits: 8
Stop bit: 1
And the AT commands should be terminated with \r\n that is CR+LF if I'm not mistaken.
No information on flow control. The RTS pin on the board is not even soldered, meaning that it's not used during device normal operation.
From here on, I'm lost. I tried with several programs (Hyperterminal, Putty, Tera Term etc.) to send the AT command which should yield an "OK" but no response has ever arrived.
To be clear, if I fiddle with the wires (like grounding and releasing RTS or turning the RG-BT10-10 on and off) I sometimes get some chars so the flow of data from the module to the computer physically works.
Is there some basic theory I'm missing? I can't get enough information from the manufacturer (language barriers...). And I believe that I have all the hardware that I need, so I just have to understand how to set it correctly :)
Thank you very much for your help!
I had exactly your problem. No response to AT from PuTTY or HyperTerminal at 9600 Baud (which is correct/default for the SPP-CA).
All I would see is:
+READY
+PAIRABLE
when powering up.
I then tried the Serial Monitor that comes with the Arduino IDE, www .arduino.cc/download_handler.php?f=/arduino-1.6.7-windows.exe. Changed line endings to "Both NL & CR" and at 9600 Baud, it came to life:
AT
OK
AT+VERSION
+VERSION=+BOLUTEK Firmware V2.2, Bluetooth V2.1
I hope this helps someone.
You can also use Putty to send
Ctrl+M : Carriage Return(“\r”)
Ctrl+J : Line Feed(“\n”)
This worked for me in getting a response:
AT [CTRL-J]
OK
I have a bluetooth remote that is paired with my linux box, when active, this remote is visible at /dev/input/event13.
I have a small C program that open this device and read directly from it, which works fine.
Now, my problem is that this remote goes to sleep after a few minutes of inactivity and /dev/input/event13 disappears. It reappears as soon as I press a key on my remote.
I put the output of udevadm here: https://gist.github.com/9fff2f0d7edef1050060.
I use the following code (small ruby ext I wrote), to read from the device: https://gist.github.com/b403d538eb6a8627e2bd.
I thought of writing an udev rule that would start my program when my remote is added and stop it when it is removed. I read the udev documentation, but I couldn't figure it out how to do it. I'm open for suggestion.
After some digging and a lot of frustration I did the following:
I put into /etc/udev/rules.d/99-rmote.rules
KERNEL=="event*", SUBSYSTEM=="input", ACTION=="add|remove", ATTRS{name}=="TiVo Keyboard Remote", RUN+="/home/kuon/handleConnect.rb"
And in handleConnect.rb I check the ACTION environment variable and I start/stop my daemon accordingly. Quite simple in the end and it works well.