'P.C. Timing ( was Re: PIC ICE recommendations? )'
If one is using the PicStart 16B or 16C1 is the P.C. timing as
critical as it might be with a programmer using the parallel port? I know
the UART in the com port clocks the data, but I don't know what other
RS-232 lines are used and how their timing effects the PicStarts.
I remember reading a message a long time ago about how TSR's might
disrupt the programming process and I couldn't remember whether this
applied to PicStarts or just to parallel programmers.
I do have a TSR I wrote that runs on the P.C. that will be used
with the PicStarts and I was planning to disable it during programming
because it does slow the system down slightly, but if this isn't a problem,
Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group
|Martin McCormick <DC.CIS.OKSTATE.EDU> wrote: martin
> If one is using the PicStart 16B or 16C1 is the P.C. timing as
> critical as it might be with a programmer using the parallel port? I know
> the UART in the com port clocks the data, but I don't know what other
> RS-232 lines are used and how their timing effects the PicStarts.
I spent some time reverse engineering the protocol used by the PicStart 16B
and 16C. I didn't completely finish, and I don't have my notes here, but
basically what they do is toggle one handshake line in each direction after
every one to four bytes. Moderate variations in timing can be acommodated.
I've never had any problems on 486, Pentium, or Pentium Pro machines.
People have reported varying degrees of success using the PicStart on non-Intel
machines that simulate the x86. Part of that may be due to speed, but the
big problem there is that many of the simulators don't handle the handshake
Note that the PicStart Plus uses an entirely different protocol. I haven't
looked at it on a protocol analyzer yet.
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...