Post by thread:Wanted: 4digit number to string routine with consi

I am looking for a number to string routine that has consistent loop timing. I have an application that writes to an LCD with the current count. This is within a fairly critical loop and I'd like to keep the timing consistent. The problem is as the count decreases, the conversion function doesn't take as long. Any thoughts? Craig Lee

> I have an application that writes to an LCD > with the current count. This is within a > fairly critical loop and I'd like to keep > the timing consistent. > > The problem is as the count decreases, the > conversion function doesn't take as long. > > Any thoughts? Seriously: Don't put code like this inside timing loops. Avoid timing loops wherever possible. Pad with NOPs in the appropriate cases. :-P

Dave VanHorn wrote: > Seriously: > Don't put code like this inside timing loops. > Avoid timing loops wherever possible. > Pad with NOPs in the appropriate cases. :-P This approach my friend, is M$ territory! I put my W95RevB drive from the 6x86 work machine which had failed (persistent BSOD) into a brand-new K6/2-450 box on the weekend. So doing, entered the world of the "IOS Windows Protection Error". Having learnt the rules of the M$ service search engine (if you get 200 answers, then *none* are relevant, you've obviously asked the wrong question) I got the right answer out of 8, even specified the processor. http://support.microsoft.com/support/kb/articles/Q192/8/41.ASP for anyone curious. But do they ever let the cat out of the bag! Unbelievable. IOS.VXD and other actually contain - get this - *software timing loops*. And this is in a supposed *operating system*. Oh yes, it "has been fixed in W98", as well as the patch they give (and it does work), but you're only supposed to use it for this particular problem. Well, Duhhh! But I ask you, how do you suppose they "fixed" it eh? -- Cheers, Paul B.

> > Seriously: > > Don't put code like this inside timing loops. > > Avoid timing loops wherever possible. > > Pad with NOPs in the appropriate cases. :-P > > This approach my friend, is M$ territory! I DID put them in order of preference... I've had to do it too. When you need a 2uS delay, what else can you practically do? My RTOS uses 1mS ticks, so that's WAY too slow, and any other mechanism I could come up with took longer than I needed to get in and out of it. (16 instructions total)

Dave VanHorn wrote: > I've had to do it too. When you need a 2uS delay, what else can you > practically do? Focussing on the PC. This *really* frustrates me. One major reason why the PC was better than the (of comparable technical capability) Tandy CoCo was the presence of a hardware timer counting at a *standard* if rather odd rate. Common sense at least as I understand it, is that if you want small delays, you use this timer for them and *no* future alteration in clock speed will ever affect it. There were programs designed to depend on the 4.7 MHz clock of the XT, but it must have become evident the moment an 8 MHz machine appeared that relying on the processor speed for timing was never viable. The implication that this vital component may have been "designed out" of the PC is staggering! -- Cheers, Paul B.

> Common sense at least as I understand it, is that if you want small > delays, you use this timer for them and *no* future alteration in clock > speed will ever affect it. There were programs designed to depend on > the 4.7 MHz clock of the XT, but it must have become evident the moment > an 8 MHz machine appeared that relying on the processor speed for timing > was never viable. It depends on what speed the timer is running (of course one COULD add more timers..) With a single timer, you're stuck to a minimum of 1-2 time intervals, because you have no way to assure that a count of 1 will output a time of "1". You might hit the timer just before it "ticks", or just after. With my situation, my 1mS timer is way too slow, so if I need a 2uS delay, the only practical method is 2us worth of NOPs. I've done shorter (and variable) delays using the other timer, for RC servos, where I use timer 2 as an "alarm clock" to turn off the servo pulse after the appropriate time has passed. With all the devices the PC has to work with, it seems unlikely that they could just keep adding timers. A better approach might be to add a local processor, and let that deal with the delays, freeing up the main system to do the "thinking". I designed a system like this way back in 89 with a 10 MHz Z80 as the peripheral controller, and a Z-280 as the main processor, but problems in the 280 caused us to die on the vine. I've still got the PCBs around somewhere, designed to fit an XT case, and use PC peripheral cards. Long delays are no problem, but short ones suck!

> Common sense at least as I understand it, is that if you want small > delays, you use [the standard PC] timer for them and *no* future > alteration in clock speed will ever affect it. This only works for reasonable length times (the 2uS that someone mentioned is WAY too short.) It's also not particularly usable in a multitasking environment. Our (big) IOS has a nice tree-structured timer mechanism. You can build little timer trees that are carefully sorted when you activate a timer, so that the tree that is its parent only has to look at the "top" to see if any timer in the tree has expired. Eventually, the scheduler looks at some small number of timers and compares them with a clock driven off the NMI. Cute, and efficient from a scheduler perspective, depending on how often you start new timers (which may cause a re-sort of that portion of the tree.) The NMI is some few milliseconds, though. For accuracy to less than 100ms or so, you need something else. For times less than a clock tick, you need something else whether you need accuracy or not. BillW