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