[NTLK] NCX problem

Don Zahniser dzahniser at rochester.rr.com
Tue Aug 24 08:03:21 EDT 2010


Hi, Matthias -

Your explanation below doesn't sound as though it is specifically  
applicable to the problem I am seeing; at the point of crash, I've  
never gotten to the point of trying to initiate a connection between  
the Newton and NCX.

However, it does shed light on a possible explanation for the  
occasional failure of a connection that I have seen when installing  
packages over serial (my most frequent usage of NCX).  Both NCX and  
the Newton seem to still 'think' everything is fine, but the transfer  
just seems to stop.  Sometimes it will resume, but then again it  
often will not.  This is for maybe one package installation out of  
10. Again, this is using the PL2303 open source driver.  I haven't  
used the Prolific driver in a couple of years.


On Aug 24, 2010, at 7:17 AM, Matthias Melcher wrote:

>
> On 24.08.2010, at 11:07, Simon Bell wrote:
>
>>> I tried changing it to the PL2303 open source driver that I've been
>>> using
>>> with my generic USB-Serial adapter, and got a crash when I closed  
>>> the
>>> preference dialog.
>>
>> There does seem to be a problem with the PL2303 driver. I don’t know
>> why -- NCX uses only POSIX calls to the serial device. Not having the
>> requisite hardware I can’t reproduce this crash but I shall see  
>> what I
>> can do...
>
> The Newton hardware has issues when bursts of bytes come in at the  
> full baud rate. It drops bytes once in a while which makes the  
> connections unbearably slow or drops it alltogether. I believe the  
> problem is related to checksum calculation at the end of a block.
>
> On older PCs, "slowdown" can slow a PC sufficiently down to avoid  
> the problem.
>
> USB-to-serial adapters however don't necessarily transfer bytes  
> when they arrive, but may actually wait for a buffer to fill and  
> then send them in a burst. There are no POSIX calls that can keep  
> this from happening, except maybe flushing, but that depends on the  
> driver implementation.
>
> The only way I found to avoid this issue is to use carful timing  
> and send serial data in chunks, then not send any data until the  
> USB driver's flushing sets in (unfortunately, it does not tell us,  
> so we must guess).
>
> It would be possible to create some kind of statistics by sending  
> data via USB adapter and receiving them on the same machine via  
> built-in RS232 connector, then analyzing the delays. That of course  
> would require the adapter in question and some time consuming work.
>
>  - Matthias
>
> ====================================================================
> The NewtonTalk Mailing List - http://newtontalk.net/
> The Official Newton FAQ     - http://splorp.com/newton/faq/
> The Newton Glossary         - http://splorp.com/newton/glossary/
> WikiWikiNewt                - http://tools.unna.org/wikiwikinewt/
> ====================================================================

-- 
Don Zahniser







More information about the NewtonTalk mailing list