From owner-freebsd-questions@FreeBSD.ORG Fri Sep 9 19:16:06 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4514C16A41F for ; Fri, 9 Sep 2005 19:16:06 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCFA43D49 for ; Fri, 9 Sep 2005 19:16:03 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id FAA13759; Sat, 10 Sep 2005 05:15:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 10 Sep 2005 05:15:49 +1000 (EST) From: Ian Smith To: Paul Hamilton In-Reply-To: <20050905120037.1608A16A421@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org, Glenn Dawson Subject: RE: Serial Port data dumping program X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 19:16:06 -0000 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" > Subject: RE: Serial Port data dumping program > To: "'Glenn Dawson'" , > [..] > > -----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