TI-H: Re: TI Link Port Data Rate
[Prev][Next][Index][Thread]
TI-H: Re: TI Link Port Data Rate
eplese@lnd.com wrote:
> I just was looking at your web page and I noticed that at one point
> you stated that you expected your PIC to be able to recieve data at
> 5K/s, or this was your goal at least. A while back I was
> experimenting with this and I think that the absolute maximum is 4-5K
> and this with a very optimized digital circuit that is completely
> hardware based that I made using 74xx chips. 6 of them to be exact.
> I don't think that a PIC will be able to match this speed. Instead of
> 5K, try to shoot for around 3K or maybe 4K. Of course I may wrong,
> but I was just letting you know my findings.
No, you are very much correct. I don't know which calculator you
experimented with, but on the TI-92 the calculator will accept at
least 108 bytes at very impressive speeds - However, if these bytes
are not emptied as fast as they come in, the buffer will overflow, at
which point the entire thing will come crashing down and no more
data can be received.
I have found that with the currently unoptimized link port receive
routines I am using in the nearly completed Extender uP driver, I need
a ~60uS delay between bytes to keep the buffer from overflowing and
blocking further incoming data.
Practically I am getting a data rate of about 0.7k/sec... Much less
than I expected, but still not that much below the calc-calc or calc-PC
rate.
Basically, that 5k/sec was a HOPE - A rough guess. I should have worded
it more carefully. 0.7k/sec is about all I'm seeing, and that is because
the TI-92 cannot empty its own buffer fast enough. If I optimized the
link port routines I could probably bump that up to 1.5k/sec - But
again,
that's a rough guess and I don't think I'm ever going to get about
2k/sec,
especially since the PIC must send out at the lowest common demoniator -
I.E. the rate the TI-82 (the slowest calc the EuP will support) can
accept data.
Sorry about the confusion,
(BTW I have echoed this to TI-H for those interested in our findings)
Bryan Rittmeyer
bryanr@flash.net
References: