i have connected my 3pi roboter over the pd1 and pd0 pins to FTDI USB to RS232_PCB converter which provides 5V TTL level.
here ist the link for the DataSheet : ftdichip.com/Documents/DataS … B_V130.pdf
the connections is PD0(RXD)-> FTDI TX
PD1(TXD)-> FTDI RX
GND 3PI -> FTDI GND
so have installed the virtual comport driver to access via serial comport to the 3pi robot.
i used a simple routine over Win32 API Visual C++, to send bytes to the 3pi robot.
the communication between 3pi and the FTDI USB->RS232 establish without problems and i can send byts to the 3pi.
The problem is when i send byte as char -> 0x42 … the 3pi receives and shows completly different data like 0x47.
i have tested all settings and baudrates and delay options on both sides and i had no luck.
who can help me ?
here an example code of C++
…
…
…
char send_byte=0x42;
do{
ComWrite(1,send_byte);
Sleep(10);
}while(stay);
and the 3pi source code
int main()
{
lcd_init_printf();
clear();
serial_set_baud_rate(19200);
unsigned char buffer=0;
while(1)
{
serial_receive(&buffer,1);
printf("%c %i",buffer,buffer);
delay_ms(100);
clear();
}
return 0;
}
First, you are using the background receive function, which will eventually put some data in that buffer, but probably not before the printf() command is run. Instead, I think you should take out the delay() and use serial_receive_blocking(), which will wait until a byte is received.
Now, I can’t actually see why this would be causing your problems. Can you send data from the 3pi to the computer? Do you get exactly one byte on the 3pi for every byte sent by the computer? Does it work better at a really low baud rate, like 1200?
so the delay is out but i have tested all possible baudrates and nothing has been changed.
i have used now the serial_send_blocking() function to send bytes to the computer and it is really strange,
it shows the same different character as it 3pi does but it does not the character which i have send!
for example when i send 0x42 from 3pi --> pc
example buffer = 0x42 -> the pc receivies it as ‘>>’ and 175 decimal
for example when i send from pc -> 3pi
example buffer = 0x42 -> the 3pi receivies it as ‘>>’ and 175 decimal
int main()
{
lcd_init_printf();
clear();
serial_set_baud_rate(1200);
unsigned char buffer=0x42;
while(1)
{
serial_send_blocking(&buffer,1);
// print_character(buffer);
}
C++ to receive the data
---------------------------------
ComInit(); //Com-Schnittstelle öffnen
ComOpen(1,1200,P_NONE,S_1BIT,D_8BIT); //Com-Schnittstelle initialisieren
fflush(stdin);
int auswahl;
char send_byte=0x20;
unsigned char recv_byte;
do{
recv_byte=ComRead(1);
printf("%c = %i",recv_byte,recv_byte);
getch();
recv_byte=0;
}while(stay);
ComClose(Verbindung); //Com-Port Close
ComExit(); //Com-Porst Exit
return 0;
}
Hello,
I looked at the datasheet that you linked from your first post, and this part definitely doesn’t provide a TTL-level signal. It’s supposed to generate RS-232 level signals directly, which means it can’t work with your 3pi (and could damage it!) You should be able to verify this with a voltmeter on the TX line.
Instead, if you have a Pololu AVR Programmer, you could use its built-in serial port, which does output a 3pi-compatible signal. Or you could get a Pololu USB-to-Serial Adapter.
your are right , the ftdi support told me the same !
the USB RS232 converter converts it in RS232 level(Header) and not TTL.
can you tell me which TTL level the 3PI supports 3.3V or 5V ?
The 3pi runs at 5V, so if you have a choice, go for a 5V adapter. However, you could also go with a 3.3V adapter like the Pololu USB-to-Serial Adapter if you make sure that it can withstand the 5V output from the 3pi.
, the ftdi support told me the same !