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