Date: Sat, 10 Sep 2005 09:05:12 +0800 From: "Paul Hamilton" <paulh@bdug.org.au> To: "'Ian Smith'" <smithi@nimnet.asn.au> Cc: freebsd-questions@freebsd.org, 'Glenn Dawson' <glenn@antimatter.net> Subject: RE: Serial Port data dumping program Message-ID: <05bd01c5b5a3$b2720240$6600a8c0@w2k2> In-Reply-To: <Pine.BSF.3.96.1050910034835.6337A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian, > -----Original Message----- > From: Ian Smith [mailto:smithi@nimnet.asn.au]=20 > Sent: Saturday, 10 September 2005 3:16 AM > To: Paul Hamilton > Cc: Glenn Dawson; freebsd-questions@freebsd.org > Subject: RE: Serial Port data dumping program >=20 >=20 > Hi Paul, >=20 > catching up on a week's digests .. and seeig no further=20 > messages on this topic so far, I don't know whether you've=20 > sorted this out yet. Anyway.. >=20 <Snip> > > > >I have been using the 'minicom' port to dump the=20 > received data. =20 >=20 > I guess you mean the _transmitted_ data, right? I just=20 > grabbed the manual at http://www.seetron.com/pdf/ssc2_mnl.pdf=20 > and note that the board only _receives_ command data packets. >=20 Yes that's correct > > > >However, it doesn't seem to collect the data properly. Data=20 > > > coming in=20 > > > >should be in accordance with the SSC protocol, ie: > > > > > > > >byte 1: 0xFF // sync byte > > > > > > > >byte 2: 0x01 - 0x25f //servo address > > >=20 > > > How do you fit 0x25f into a single byte? (I count 10=20 > bits required) > >=20 > >=20 > > Yep, a typo, should have been: 0xff >=20 > 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. >=20 > > > >byte 3: 0x00 - 0x255 // servo position > > >=20 > > > Same question as above. > >=20 > > Brain thinking in hex, fingers working in decimal ;-) >=20 > Actually it's 0-254 (0x00 - 0xfe) .. 0xff would be another sync byte.=20 True. >=20 > > > >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=20 > two bytes, sync=20 > > > >and servo position. Rows 020 and 030, shows some servo=20 > > > addresses, but=20 > > > >sometimes, together! Both the mini-ssc.exe and minicom=20 > program are=20 > > > >using 9600 8n1, so why is it showing this? Is there=20 > > > something I have=20 > > > >missed in the setup of minicom? Looks like this is a=20 > serial buffer=20 > > > >problem. >=20 > Maybe flow control? Is the serial port's UART programmed to=20 > ignore CTS/RTS, and/or DTR/DSR? You say you've only wired=20 > signal ground, and TxD to RxD, but you 'normally' can't=20 > transmit unless CTS is asserted (say, by RTS), may need=20 > DTR/DSR too, and perhaps expect DCD to receive? I don't=20 > really get what you're doing with minicom - are you receiving=20 > the data on another port, or just echoing your transmitted data back? >=20 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 >=20 > paqi% hd > fgjdg kj > ^D > 00000000 66 67 6a 64 67 20 6b 6a 0a =20 > |fgjdg kj.| > 00000009 >=20 > > > >Is there a better program I could use to display the=20 > incoming serial=20 > > > >data in hex? >=20 > hd :) Again, you mean a reflection of your outgoing data, don't you? >=20 > > > >NOTE: I only use two wires, signal ground and Tx Data=20 > (connected to=20 > > > >the Rx Data). The servo does respond correctly, so I know=20 > > > the serial=20 > > > >data must be in the correct 3 byte format. >=20 > You could try 2 stop bits - they say one or more. >=20 > In the second example program in (good grief!) QBASIC in the=20 > above PDF manual, they begin by initialising the serial port thus:=20 >=20 > OPEN "com1:9600,N,8,1,CD0,CS0,DS0,OP0" FOR OUTPUT AS #1; >=20 > I gather CD0 means ignore DCD, CS0 ignore CTS, DS0 ignore=20 > DSR; don't know about OP0. Seems you need no flow control,=20 > or null-modem wiring? >=20 > Cheers, Ian >=20 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. =20 It's interesting that minicom seems to skip recording the 0x00 servo = address byte! Thanks for your help. Cheers, Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05bd01c5b5a3$b2720240$6600a8c0>