Serial Port data dumping program

Ian Smith smithi at nimnet.asn.au
Fri Sep 9 12:16:06 PDT 2005


Hi Paul,

catching up on a week's digests .. and seeig no further messages on this
topic so far, I don't know whether you've sorted this out yet.  Anyway..

 > Message: 20
 > Date: Mon, 5 Sep 2005 17:32:41 +0800
 > From: "Paul Hamilton" <paulh at bdug.org.au>
 > Subject: RE: Serial Port data dumping program
 > To: "'Glenn Dawson'" <glenn at antimatter.net>,
 > 	<freebsd-questions at freebsd.org>
[..]
 > > -----Original Message-----
 > > From: owner-freebsd-questions at freebsd.org 
 > > [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of Glenn Dawson
 > > Sent: Monday, 5 September 2005 5:19 PM
 > > To: Paul Hamilton; freebsd-questions at freebsd.org
 > > Subject: Re: Serial Port data dumping program
 > > 
 > > 
 > > At 01:08 AM 9/5/2005, Paul Hamilton wrote:
 > > >Hi,
 > > >
 > > >I am trying to debug a Mini SSC FreeBSD program that I am trying to 
 > > >write. It would be nice to be able to be able to see what is being 
 > > >transmitted.  It would help in the debugging of my program.
 > > >
 > > >Here is a link to a Windows based Mini SSC program: 
 > > >http://www.rentron.com/Mini-ssc.htm  Using this, I can control the 
 > > >servo, so I know the hardware and cables work etc.
 > > >
 > > >I have been using the 'minicom' port to dump the received data.  

I guess you mean the _transmitted_ data, right?  I just grabbed the
manual at http://www.seetron.com/pdf/ssc2_mnl.pdf and note that the
board only _receives_ command data packets.

 > > >However, it doesn't seem to collect the data properly.  Data 
 > > coming in 
 > > >should be in accordance with the SSC protocol, ie:
 > > >
 > > >byte 1:    0xFF    // sync byte
 > > >
 > > >byte 2:   0x01 - 0x25f    //servo address
 > > 
 > > How do you fit 0x25f into a single byte? (I count 10 bits required)
 > > 
 > 
 > Yep, a typo, should have been:  0xff

Well, it should be 0-7 (for 1 board, 8-15 for a second board, etc)

 > > >byte 3:   0x00 - 0x255   // servo position
 > > 
 > > Same question as above.
 > 
 > Brain thinking in hex, fingers working in decimal ;-)

Actually it's 0-254 (0x00 - 0xfe) .. 0xff would be another sync byte. 

 > > >Here is a dump of the collected data (via minicom):
 > > >
 > > >#hexdump  minicom.cap
 > > >0000000 45ff 49ff 4cff 50ff 53ff 57ff 5aff 57ff
 > > >0000010 53ff 50ff 4cff 49ff 45ff 45ff 01ff ff82
 > > >0000020 8101 01ff ff80 8202 02ff ff81 8002 03ff
 > > >0000030 ff83 8203 03ff ff81 8003 7fff 7fff 7eff
 > > >0000040 01ff ff7f 7f02 03ff ff7f ff7f 8001 02ff
 > > >0000050 ff80 8003 04ff ff80 ff80 8006 07ff 0080
 > > >
 > > >Looking at the first row of data, it is only showing two bytes, sync 
 > > >and servo position.  Rows 020 and 030, shows some servo 
 > > addresses, but 
 > > >sometimes, together!  Both the mini-ssc.exe and minicom program are 
 > > >using 9600 8n1, so why is it showing this?  Is there 
 > > something I have 
 > > >missed in the setup of minicom?  Looks like this is a serial buffer 
 > > >problem.

Maybe flow control?  Is the serial port's UART programmed to ignore
CTS/RTS, and/or DTR/DSR?  You say you've only wired signal ground, and
TxD to RxD, but you 'normally' can't transmit unless CTS is asserted
(say, by RTS), may need DTR/DSR too, and perhaps expect DCD to receive?
I don't really get what you're doing with minicom - are you receiving
the data on another port, or just echoing your transmitted data back?

 > > You probably have byte ordering issues.  Does something like this 
 > > look more reasonable?
 > > 
 > > 0000000 ff45 ff49 ff4c ff50 ff53 ff57 ff5a ff57
 > > 0000010 ff53 ff50 ff4c ff49 ff45 ff45 ff01 82ff
 > > 0000020 0181 ff01 80ff 0282 ff02 81ff 0280 ff03
 > > 0000030 83ff 0382 ff03 81ff 0380 ff7f ff7f ff7e
 > > 0000040 ff01 7fff 027f ff03 7fff 7fff 0180 ff02
 > > 0000050 80ff 0380 ff04 80ff 80ff 0680 ff07 8000
 > > 
 > > -Glenn
 > 
 > Yes, somewhat better, but still missing bytes here and there, ie. First
 > line, all the servo address bytes etc.
 > 
 > Why would the bytes be swapped around?

Seems that's just hexdump displaying 16-bit values byteswapped.  'hd'
may give you a more useful display order, as it's truly 8 bit data:

paqi% hexdump
fgjdg kj
^D
0000000 6766 646a 2067 6a6b 000a
0000009

paqi% hd
fgjdg kj
^D
00000000  66 67 6a 64 67 20 6b 6a  0a                       |fgjdg kj.|
00000009

 > > >Is there a better program I could use to display the incoming serial 
 > > >data in hex?

hd :)  Again, you mean a reflection of your outgoing data, don't you?

 > > >NOTE:  I only use two wires, signal ground and Tx Data (connected to 
 > > >the Rx Data).  The servo does respond correctly, so I know 
 > > the serial 
 > > >data must be in the correct 3 byte format.

You could try 2 stop bits - they say one or more.

In the second example program in (good grief!) QBASIC in the above PDF
manual, they begin by initialising the serial port thus: 

 OPEN "com1:9600,N,8,1,CD0,CS0,DS0,OP0" FOR OUTPUT AS #1;

I gather CD0 means ignore DCD, CS0 ignore CTS, DS0 ignore DSR; don't
know about OP0.  Seems you need no flow control, or null-modem wiring?

Cheers, Ian



More information about the freebsd-questions mailing list