Date: Sat, 10 Sep 2005 05:15:49 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Paul Hamilton <paulh@bdug.org.au> Cc: freebsd-questions@freebsd.org, Glenn Dawson <glenn@antimatter.net> Subject: RE: Serial Port data dumping program Message-ID: <Pine.BSF.3.96.1050910034835.6337A-100000@gaia.nimnet.asn.au> In-Reply-To: <20050905120037.1608A16A421@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bdug.org.au> > Subject: RE: Serial Port data dumping program > To: "'Glenn Dawson'" <glenn@antimatter.net>, > <freebsd-questions@freebsd.org> [..] > > -----Original Message----- > > From: owner-freebsd-questions@freebsd.org > > [mailto:owner-freebsd-questions@freebsd.org] On Behalf Of Glenn Dawson > > Sent: Monday, 5 September 2005 5:19 PM > > To: Paul Hamilton; freebsd-questions@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1050910034835.6337A-100000>