I am attempting to receive data from the qu-bot at http://www.qu-bot.com. The robot has an ATML atmega16 microcontroller. I have written a program that runs on the robot which outputs data to its serial port. The program however stops whenever I connect to the controller. I tested this by adding a beep statement. The robot beeps as long as the program is running. The beeping stops when I connect to the robot. I tried qu-bo support and they suggested disabling the dtr flag on the serial port. I did that but no joy.
Is there anything else I can try?
[start of code running on the qu-bot]
Note:
This is written in some kind of proprietary variant of C which they call quick c.
// This code displays the uart functions.
int main(void)
{
INIT();
UART_INIT(57600);
UART_PRINT("HELLO!!\n");
DELAYS(1);
UART_PRINT("MY NAME IS QU-BOT.\n");
DELAYS(1);
UART_PRINT("HELLO!!\n");
UART_PRINT("YOU ARE USING UART SAMPLE CODES.\n");
while(1)
{
UART_PRINT("test\n");
BEEP();
DELAYS(60);
}
}
now for my python serial port reading program. I have tried this program both on raspbian and on windows 7 64bit. I am pasting the windows version. The raspbian version has a different name for the linux.
import serial
import time
ser=serial.Serial()
ser.port=8
ser.baudrate=57600
ser.setDsrDtr(False)
print 'initialized'
flag = ser.isOpen()
if flag:
print 'port already open.'
pass
else:
ser.open() # opening the port 'ser' that was just created to receive data
time.sleep(0.5)
print 'ready to read'
print ser
ser.write('a')
s=ser.read(4)
print s
ser.close()
Pranav
P.S. I have consulted the following links amongst others.
<https://learn.sparkfun.com/tutorials/terminal-basics/all>
<http://www.plainlystated.com/2013/06/raspberry-pi-serial-console/>
<http://elinux.org/RPi_Serial_Connection>
<https://learn.sparkfun.com/tutorials/terminal-basics/all>
Based on my experience in serial communications with microcontrollers the most likely cause of this problem is that when you connect the serial cable to the robot it causes a phantom byte (due to electrical noise that happens when you make the connection) to look like it's coming from the controller - either this or the controller is sending a legitimate byte to the robot. In either case it is likely that the arrival of a byte at the robot's serial port (even if it was only electrical noise mistaken to be a data byte - this is a very common occurrence) caused the robot's microcontroller to invoke the UART receive interrupt. If you don't have an appropriate UART receive handler (ISR - Interrupt Service Routine) written and linked into the correct interrupt vector then your robot's microcontroller can go off into "deep space" upon the detection of the first incoming serial data byte - and make your robot appear to "hang". If you intend to do "polled" serial communications (your code manually checks for received bytes in its main loop) instead of interrupt-driven (hardware detection of an incoming byte causes your UART Rx ISR to be invoked) then all you have to do is to disable UART interrupts and your problem should go away.
Related
I am trying to establish communications via serial port between a PC with Ubuntu 14.04LTS and my RoMeo Arduino Board (Atmega 328). The used serial interface are 2 Xbee modules, one at PC and the other at the board.
Firstly, I am trying to develop a simple program to send messages to the board and receive them back. The code I use for the Arduino board is the following:
void loop(void)
{
char msg;
if (Serial.available()){
msg = Serial.read();
msg = Serial.print(msg);
}
}
When I send a unique character, the PC receives it back correctly. However, the problem I am facing is that for longer strings, the following characters are misspelled, as I obtain back strange hex numbers, as follows:
>>> import serial
>>> ser = serial.Serial(port='/dev/ttyUSB0', baudrate=57600, timeout=0.1)
>>> ser.write('H')
>>> ser.read(1)
'H'
>>> ser.write('Hello')
>>> ser.read(5)
'H\x8b\xbd'
Thanks in advance.
EDIT: Seems like there is an overflow problem with the XBee modules, but I can not figure it out completely: The problem is solved if I wait 0.01 seconds or more between sent characters, which is a huge amount of time. Namely, the code I use now for sending a word is:
for letter in word:
serial.write(letter)
time.sleep(0.01)
However, this waiting time is only needed when sending data from the PC to the Arduino. When the communication goes the other way (Arduino sends data to PC), I do not need to sleep and bytes are correctly sent all together at 57600 bauds.
The reason why the PC could not send more than 1 character to the Arduino board was that there was an XBee module configured with different port parameters than both the other module and the pyserial instance. In this case, the communication was established in Python with the following main parameters:
Baud rate: 57600
Bytesize: 8
Parity: None
Stop bits: 1
If one of this parameters is different in one of the XBee modules, the communication will be faulty (like this case) or even impossible.
To check the XBee configuration, the Digi XCTU application can be used: With the RF modules connected to the PC, open the program and read their configuration. Once opened, it has to be made sure that the 'Serial interfacing' options are equal to the previously listed.
At the image, it is shown the menu where these options can be changed. Note that the Stop bits and the Bytesize can not be configured. The first parameter was not adjustable until the XB24-ZB versions, and the last one seems to not be possible to change.
In the case of this question, the wrong parameter was the parity, as it was set to space parity in one of the modules, instead of no parity. Thus, the first byte was sent correctly, but after it the data was not coherent. After changing this parameter, the connection run OK.
My issue is to make a serial communication between raspberry pi and another hardware. The recommended connection for this hardware is as shown on the manual, I have to connect, RX, TX, GND, RS, and CS.
But on raspberry pi we have only RX, TX so I connected RX and TX and The GNG of Pi to this hardware.
I modified Pi's parameters as shown on the link : here
Then I maked a simple python program that initialize the communication, and send data.
Here is the code :
import serial,os
port=serial.Serial("/dev/ttyAMA0",baudrate=9600)
print ('port is ok')
port.write('Command')
rcv=port.read(10)
print rcv
after running this code on pi, I got ('port is ok'), But the problem is that this hardware don't respond correctly to the command, and as respoce it gave me normally OK, but I got some extra caracter( non readable).
Is that a problem of encoding? Can some one help about this?
You need to check the baud rate on the other hardware
or make sure that the length of the received message = to the printed message.
In a serial communication, there are two important things to be careful :
The two devices have to work with the same baudrate IF the link is bidirectional.
When writing data on serial, you have to flush data just after the write().
refer to here for it.
In a lot of case, flush isn't needed, but when two different devices have to communicate, it could unlock the comm'.
If it's not efficient, try to set up your other device with the same conf (no flow control, etc)
I want to transmit AVR or Arduino etc by I2C from Raspberry pi.
I am writing in Python.
I already successeded communication using write_data() function in smbus module.
But I want to transmit multiple bytes data consecutively.
Please tell me how to transmit multiple bytes data in i2c communication.
I find write_block_data() function, but I don't understand the second parameter CMD.
What is the CMD?? Should I specify the value of CMD?
thank you.
Communicating between an RPi and an Arduino on I2C is a big mess if you are using Wire.h library. The short answer is that RPi is using a repetitive start signal while Arduino is not using it.
Repetitive start signal on I2C interface tells the slave to start answering for the call. In case of the Arduino asking and answering is in two separated calls. Therefore you cannot send block
I made two blog posts to interface the two architecture through I2C. First one is for using a remote controller PWM: http://distantorion.com/2014/10/24/rc-signals-pwm-to-i2c-with-arduino/
The second one is for driving a 128x64 LCD display on I2C: http://distantorion.com/2014/11/01/i2c-display-with-arduino/
In the second one I'm using block data in python:
bus.write_i2c_block_data(0x05,0x10,buff)
0x05 is the device address, 0x10 is the "command", buff containd the characters to display.
Regarding the commands. In I2C a slave works in a way of commands or registers. Both method looks like the same. If you are using a repetitive start signal the communication seems to be reading and writing registers. When you have no repetitive start signal, the communication looks like a command - answer system. In my example I'm sending 0x10 what is "put the characters from to the display". And 0x01 is a clear screen command, while 0x02 turns on the backlight.
I want to send some data to an Arduino through pyserial in Python. All I want to the Arduino to do is read the variable length string data from the serial port, and write it back so that Python can read it. Since I've been unable to do that, the code below only has Python sending on character. Here's the Python code:
import serial
import sys
import pywapi
import time
def main():
ser = serial.Serial(3, 9600, timeout=1)
print "Conn established"
print "Sending: %s" % "z".__repr__()
print ser.write('z'.encode("ascii"))
time.sleep(2)
print "Received: %s" % ser.read(10).__repr__()
ser.close()
Here's the Arduino code:
void setup(){
analogReference(DEFAULT);
Serial.begin(9600);
}
void loop(){
if(Serial.available() > 0)
Serial.println("x");
while(Serial.available() > 0){
Serial.print(Serial.read(), BYTE);
}
}
The output:
Conn established
Sending: 'z'
1
Received: ''
I know the code for the Arduino works because it works when data is being sent from the Arduino terminal. However, the moment I try to send anything from Python it fails. I've been struggling with this all day. Any help would be greatly appreciated.
Try increasing or removing the timeout, and set read's size to 1. You may also want to increase the sleep delay, or even implement a simple read loop.
Something like:
try:
while True:
data = ser.read(1).__repr__()
if data:
print "Received: %s." % data
else:
print "Looping."
except KeyboardInterrupt:
print "Done."
except:
raise
finally:
ser.close()
print "Closed port."
Then just use ctrl-c to stop it.
I would recommend verifying the two parts independently, using a separate serial port and serial comms software on the PC.
E.g. if your PC has two serial ports, then use a null-modem (loopback) cable to connect them. Or use com0com to make a pair of linked virtual serial ports. Run your Python software on one serial port, and a terminal program (Hyperterminal or RealTerm) on the other serial port. Manually verify the Python program's operation that way.
Then, connect your PC directly to the Arduino as usual, and use the terminal software to manually verify the Arduino software operation.
That process will allow you to narrow down the problem. Once you've verified them both, they should work well together.
Serial Port Monitor
Another method you can use is software that hooks into the PC's serial port driver, and allows you to monitor traffic on the serial port. I've used the Free Serial Port Monitor software from HHD Software in the past, and it worked well for our purposes. It allows you to monitor any of the PC's serial ports, and shows you a log (hex and text) of the serial data going over the port in both directions.
Do you need to flush the sent character out of any held serial buffer?
It may be that your character is not actually leaving the COM port and arriving at the Arduino. When you test this with the Arduino Terminal (I assume you mean the UI terminal in the development environment) you are actually sending your string + a carriage return I think, not just the character. (i.e. do you hit return after you type 'z' in your test?)
Try ser.flush() or perhaps also send a \r character. From your testing the Arduino works just fine, it's the python program that doesn't seem to be sending anything.
The reason you may have to send twice is that, if you're connecting via the USB, the first serial connection will reset the Arduino.
All right, so I am positive my Arduino circuit is correct and the code for it. I know this because when I use the serial monitor built into the Arduino IDE and send 'H' an LED lights up, when I send 'L' that LED turns off.
Now I made a Python program
import serial
ser = serial.Serial("COM4",9600)
ser.write("H")
When I run the code the LED blinks on for a second then goes back off.
However when I do each of these lines separately in the shell it works just like it is supposed to.
Any ideas?
When you open the serial port, this causes the Arduino to reset. Since the Arduino takes some time to bootup, all the input goes to the bitbucket (or probably to the bootloader which does god knows what with it). If you insert a sleep, you wait for the Arduino to come up so your serial code. This is why it works interactively; you were waiting the 1.5 seconds needed for the software to come up.
I confirmed that opening the serial port resets my Arduino Uno; I flashed a program which will blink the LED from the setup() routine -- calling open("/dev/ttyACM0") was sufficient to trigger the reset. This is IMHO a confusing and undocumented wrinkle in the serial support.
I had the same problem and it works if I add a delay of about 2 seconds from opening the serial connection to writing on it, 1 second was not enough.
Just to make it a bit more clear I'll modify the code so everyone can see what needs to be added!
import serial
import time
ser = serial.Serial("COM4",9600)
time.sleep(3)
ser.write("H")
Adding in a sleep statment helps to let the serial open up without any problems!
Assuming you are using an Arduino Uno
The USB port and the Uno serial bus exposed on pins 1 and 0 share the same RX/TX lines. I suggest getting a USB to TTL adapter like the one here so that you can communicate to the Arduino without using the USB port. The Arduino IDE has its own method for disengaging from the USB driver such that a virtual serial port can be created. Have your Ardunio use SoftwareSerial instead.
Here is an example I found on the internet where somebody had clashing bus issues.