From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cc65ab136f46904d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Alex Mentis" Newsgroups: comp.lang.ada Subject: Re: GNAT.Serial_Communications Date: Thu, 14 Apr 2011 13:15:29 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Injection-Date: Thu, 14 Apr 2011 13:15:29 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="TfaOIE1E70h9psK9x8LxRg"; logging-data="29855"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+haDLaphNfbBvs6h3K9CS/ljMiebkspYI=" User-Agent: XanaNews/1.19.1.320 Cancel-Lock: sha1:pqpF0OuvQOf7C5HBS17qTsn43Bk= Xref: g2news1.google.com comp.lang.ada:18792 Date: 2011-04-14T13:15:29+00:00 List-Id: tonyg wrote: > Its actually blocking on top of the write. Also I've discovered after > much experimentation that the writes are not doing the job when it > does not block up. Usually it blocks up after 3-4 write attempts. I > expect I need to discover what is happening at the other end of the > wire, but its my first experience of using a serial port for anything. > > I suspect there is an option I am not engaging in the setting up of > the port. I am using the gpl version so I was thinking there could be > a bug that is not in the gnat pro version, but I don't want to be a > bad craftsman :) and gnat are usually pretty much on top of stuff like > that from previous experience, but then again its a relatively new > addition to the gnat compiler and no ones perfect. But.... its usually > me..... > > Saying that though I am successfully reading from the port the > incoming messages although they do appear in sections and I have to > keep re reading the port to get the full message... I'm not exactly sure what you mean by "blocking on top of the write," but if I understand correctly, your calls to Write are outputting the data correctly up to a point. You're just missing the tail end of the data, right? If my understanding is correct, I suspect that you are sending the data faster than it is being read by the destination, causing the input buffer to fill up. Once it is full, all the new data will just be ignored. When you finally get around to reading the data from the port, the only data available for you to read is that which is in the buffer. While Write did actually send everything as it should have, some of it got discarded for lack of buffer space. Since you haven't received all the data you expected, though, it appears like Write stopped working. Your statement that the "writes are not doing their job when it does not block" suggests to me that your "electronics" are not actually taking the data out of the input buffer and using it, resulting in both the discarding of input described above and lack of action on the data actually received. You are using a USB port, and I understand that USB transmission is relatively harder than RS-232/UART transmission (which is what I was doing with my Bluetooth transceiver). It may be that you need to make a call to the device driver for the receiving device, telling it that data is available to read, in order to cause it to read the data, but I'm just guessing now. HTH, and good luck! I'd be interested to hear what the solution is when you do get it figured out. Alex