<div>Sorry in advance for piping in so late in the discussion... </div><div><br></div><div>Windows and Linux serial implementations are very different in design from a buffering standpoint. In simple terms, the windows serial was a afterthought whereby serialtty in linux is as simple as reading and writing. No controls can be expected to be near flawless to seamlessly work between these platforms. </div>
<div><br></div><div>To keep it short... As long as you are not doing visual work (qt,gtk,etc), cross compiling with fpc is very well built. I have a Ubuntu 10.10 virtual machine (vmware) I use for (i386/arm9) linux cross compiling that you can use if you want it. Its out of the box functionality. Just send an email to <a href="mailto:tgatliff@gatliff.com">tgatliff@gatliff.com</a> if you want a copy of it. I am currently having issues getting the qt sdk (4.6.3) interfacing, and would smile greatly for anyone who would want to join efforts to solve the problems. Otherwise, I will just keep working away at it...</div>
<br><div class="gmail_quote">On Tue, Feb 15, 2011 at 4:45 AM, Bo Berglund <span dir="ltr"><<a href="mailto:bo.berglund@gmail.com">bo.berglund@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 15 Feb 2011 00:49:56 +0000, Paulo Costa <<a href="mailto:paco@fe.up.pt">paco@fe.up.pt</a>> wrote:<br>
<br>
>On 14/02/2011 19:32, Bo Berglund wrote:<br>
><br>
>First one thing, your message subject is too broad:<br>
</div>Sorry about that, I just meant to ask about the way the Tx and Rx<br>
buffers are handled since I did not find any property for them to be<br>
set...<br>
<div class="im"><br>
>Are we talking about the RX or thr TX buffer?<br>
</div>Both really.<br>
<div class="im"><br>
>Then, are we talking about the component, the library or the OS buffers?<br>
>And then are we talking about Windows 32, 64 bits or Linux?<br>
>It is hard to answer for all cases...<br>
</div>I have turned to FPC/Lazarus because I need the software to be<br>
portable between Windows, Linux and embedded Linux on ARM. I had the<br>
impression that I did not have to bother with the distinctions you are<br>
making (write once compile everywhere...).<br>
<div class="im"><br>
>Synaser is blocking both for writing and reading.<br>
>The SdpoSerial component creates a thread to listen and generates an<br>
>event when bytes are received. So reading can be non-blocking.<br>
>The write methods are direct calls to the Synaser ones and they are<br>
>blocking.<br>
<br>
</div>Does that mean that until all of the bytes have left the serial port<br>
the Write does not return to my program? This is exactly why I asked<br>
about the buffers...<br>
<div class="im"><br>
>> So I need to know in the case of SdpoSerial that it is possible<br>
>> without data loss to write a string of 1 Mbytes size.<br>
><br>
>In a blocking way (the function will only return when most of the bytes<br>
>are already sent), all bytes will be transmitted.<br>
<br>
</div>What does "most" mean? And do you mean when they have actually left<br>
the UART on to the RS232 wires?<br>
<div class="im"><br>
>> I also need to know how I can examine the progress of the transfer so<br>
>> I can control a progress bar or similar on screen while the transfer<br>
>> is running.<br>
><br>
>For that, you must break your transmission in small block and use the<br>
>completion of each transfer to signal the progress.<br>
<br>
</div>Are you really sure that the Write in SdpoSerial is blocking? So there<br>
are no internal transmit buffers that receive the data and then the<br>
call returns and the work is done by a transmit thread????<br>
<div class="im"><br>
>> While the transfer runs my program sits and waits for an ACK coming<br>
>> back from the other end after it has checked the checksum. That is a<br>
>> loop with Application.Processmessages, Sleep and a timeout...<br>
><br>
>I don't know if that is an option but I would break such big<br>
>transmission in smaller packets each one with its own checksum...<br>
<br>
</div>I can do that for the general memory transfer function because it is<br>
defined such that the sender defines what address range is to be sent.<br>
But it will add handshaking overhead to the transfer.<br>
<br>
The instrument protocol for this is as follows:<br>
Memory transfer:<br>
Tx: <command byte><destination address><number of bytes><br>
Rx: ACK (if the instrument can receive the data, NAK otherwise<br>
Tx: <length of data><binary data><checksum><br>
Rx: ACK if all bytes received and checksum is OK, NAK otherwise<br>
(Of course if not all bytes according to the length are send the<br>
instrument waits forever for the remaining data so there will be no<br>
NAK in this case).<br>
<br>
But file transfers are different, they can only be transferred<br>
complete.<br>
And I cannot change the protocol...<br>
<font color="#888888"><br>
<br>
--<br>
Bo Berglund<br>
Developer in Sweden<br>
</font><div><div></div><div class="h5"><br>
<br>
--<br>
_______________________________________________<br>
Lazarus mailing list<br>
<a href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a><br>
<a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus" target="_blank">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a><br>
</div></div></blockquote></div><br>