Bruce Evans wrote:
> Date: Wed, 5 Jan 2000 02:54:50 +1100 (EST)
> > consider applying the included patch to re-enable them?
>
> > +static int
> > +nap ( int microsec )
> > +{
> > + int rc;
> > +
> > + rc = usleep ( microsec );
> > + if (rc != 0) {
> > + fprintf ( stderr,
> > + "warning: ldelay or cdelay interrupted, "
> > + "delay time cut short: %s\n",
> > + strerror(errno) );
> > + }
> > +
> > + return 0;
> > +}
>
> usleep() has a resolution of 2/HZ seconds (normally 20msec), so the above
> gives very slow output (50-100 cps). Using a low baud rate (500-1000 bps)
> give the same result. If you want a shorter delay/faster output, then
> there is nothing better than a busy-wait loop for implementing nap().
> Using a not so low baud rate (1200+ bps) may work better. Perhaps nap()
> was dropped because it can't be implemented reasonably.
This explains why setting cdelay below a certain value seemed to have
no additional affect in my tests. I was suspicious of the microsecond
resolution, though I had not verified it by code examination. I did
implement nap() with nanosleep() and saw no difference in resolution
so it must be based on the same underlying facilities as usleep().
For my microcontroller (9600 baud), setting cdelay=0 and ldelay=70ms
while using 80 character per line S-Record files does the trick. Any
lower and it overflows my device and I don't get reliable data
transfer. However, I must use 'cdelay' for my EEPROM burner (fixed at
1200 baud) set set ldelay=0; I can only surmize that it does not
buffer much if at all while writing the data to the chip (50 ms burn
time per byte for the EEPROM chip I worked with last). Thus, for my
slow EEPROM burner, enforcing a 50ms delay per character vs no other
flow control means the difference between being able to use FreeBSD
and tip for burning my EEPROMs (which is very convenient) or having to
come up with some other alternative.
Perhaps re-enabling 'cdelay' and 'ldelay' but changing 'nap()' to accept
its argument in milliseconds so that it does not misrepresent itself
to badly would be more reasonable? For me this change makes the
difference between working acceptably well and not working at all.
Would you consider committing a patch to that effect? It would save
me from having to maintain local mods to my source tree, and it would
probably be useful to others as well. If not, please let me know what
changes you would consider taking and I'll do my best to get you
patches.
Here a modified patch which:
1) closes PR bin/15847
2) enables 'cdelay' and 'ldelay'
3) makes 'nap()' take milliseconds instead of microseconds
so that it does not misrepresent it's resolution too
badly
Thanks,
-Brian
--
Brian Dean [EMAIL PROTECTED]
Index: cmds.c
===================================================================
RCS file: /usr00/mirror/ncvs/src/usr.bin/tip/tip/cmds.c,v
retrieving revision 1.10
diff -r1.10 cmds.c
516c516
< for (pc = eofchars; *pc; pc++)
---
> for (pc = eofchars; pc && *pc; pc++)
562a563,579
> static int
> nap(msec)
> int msec; /* msec is milliseconds */
> {
> int rc;
>
> rc = usleep ( msec*1000 );
> if (rc != 0) {
> fprintf ( stderr,
> "warning: ldelay or cdelay interrupted, "
> "delay time cut short: %s\n",
> strerror(errno) );
> }
>
> return 0;
> }
>
576d592
< #ifdef notdef
579d594
< #endif
581d595
< #ifdef notdef
584d597
< #endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
