Serial Port data dumping program
Paul Hamilton
paulh at bdug.org.au
Fri Sep 9 18:05:17 PDT 2005
Hi Ian,
> -----Original Message-----
> From: Ian Smith [mailto:smithi at nimnet.asn.au]
> Sent: Saturday, 10 September 2005 3:16 AM
> To: Paul Hamilton
> Cc: Glenn Dawson; freebsd-questions at freebsd.org
> Subject: RE: Serial Port data dumping program
>
>
> 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..
>
<Snip>
> > > >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.
>
Yes that's correct
> > > >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)
Yes I was confused about what the starting address was. After looking at
the bytes being sent from the Windows program, I could see the correct
starting address was 0.
>
> > > >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.
True.
>
> > > >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?
>
This is what I thought as well. I had a serial port breakout box wired
inline and configured pretty well as you mention. Once I had found the
Windows mini-ssc program, I then 'just for a lark' pulled one jumper wire at
a time, until I found that it was working as a straight through cable!
<snip>
> 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
>
Ah, hd! Yes this is a nice program. No byte re-ordering I have noted it
down :-)
I don't know if you saw one of my other threads "C program to write to the
com port" which is now resolved. I started this thread to help with the
troubleshooting of the serial data coming from the C Program.
It's interesting that minicom seems to skip recording the 0x00 servo address
byte!
Thanks for your help.
Cheers,
Paul
More information about the freebsd-questions
mailing list