89C51ED2
in [Design]
|
From: Eeyore on 9 Sep 2008 08:39 Spehro Pefhany wrote: > krw wrote: > >rabbitsfriendsandrelations(a)hotmail.com says... > >> Joerg wrote: > >> > Eeyore wrote: > >> > > Joerg wrote: > >> > >> Rich Grise wrote: > >> > >>> TT_Man wrote: > >> > >>>> ">> > >> > >>>>>>>> I think he said it was all written in asssembler <yuk>. > >> > >>>>>>> On an 8051, asm is really the way to go. The OP was making comments > >> > >>>>>>> about DPTR so I suspected asm but vagueness of his descriptions > >> > >>>>>>> sounded like a C programmer who doesn't really know what is going on > >> > >>>>>>> under the hood. Many C compilers overlay variables on the 8051 if he > >> > >>>>>>> is doing interrupts in C code he may be running a routine in the > >> > >>>>>>> interrupt code that overlays one of his variables. > >> > >>>>>> Not a prayer in hell 100% assembler. :) > >> > >>>>> Are you using interrupts? > >> > >>>> Everything is interrupt driven. Processor spends 99% in sleep mode.Int > >> > >>>> routines set flags and the background processes flags, then goes back to > >> > >>>> sleep. Dual 3 of 5 uarts are processed with 125uS RTC. > >> > >>> This raises a BIG red flag for me - how long does the uP take to come out > >> > >>> of sleep mode? How's the interrupt latency? Did it used to block other > >> > >>> interrupts, or could they be stepping on each other? > >> > >> This is done all the time. First time I used the PCON features on a > >> > >> 88C51 was in the early 90's. You have to make sure it does a controlled > >> > >> wake up (socks, shoes, brush teeth, etc.) and know the time it takes. > >> > >> When you build analog/RF stuff where there needs to be radio silence > >> > >> you've got no other choice. > >> > > > >> > > And IIRC, the recent iterations of 8051 variants have improved the sleep etc > >> > > function. It used to be almost useless. > >> > > >> > It was not useless. I sucessfully used it in the early 90's and that one > >> > is still in production. Same code as the old code. > >> > >> Yeah, but back then is was DRAM, now it's static. You can rely on variables still > >> being there. Plus I think they introduced a 'snooze' mode. > > > >Nonsense. I never met an 8051 that used dynamic logic. The thing > >is tiny. > > Bleah, you're both wrong. ;-) > > The original Intel 8031/8051s (mid-1980s) had a minimum clock > frequency of 3.5MHz. The (later) CMOS ones (80C31/51/87C51/89C51 etc.) > have always been static, at least as far as I've ever seen. The > earlier MCS-48 products worked down to 1MHz (0.0833 MIPS). > > OTOH, they have never used DRAM. The RAM has always been static, even > on the earlier MCS-48 series: > > "It should be noted that the 80C51BH CPU is not static. > That means if the clock frequency is too low, the CPU > might forget what it was doing. This is because the > circuitry uses a number of dynamic nodes. A dynamic > node is one that uses the note-to-ground capacitance to > form a temporary storage cell. Dynamic nodes are used > to reduce the transistor count, and hence the chip area, > thus to produce a more economical device. > > This is not to say that the on-chip RAM in CHMOS > microcontrollers is dynamic. It's not. It's the CPU that > is dynamic, and that is what imposes the minimum > clock frequency specification." > > (from Intel AP-252) OK - I admit it was a flyer that the actual RAM was dynamic but I knew the early chips had to have a minimum clock freq. That applied to the very early NMOS ? versions as well as the CHMOS (came out about 1985 - I had some of the first samples at Xerox). Only the true CMOS parts are fully static. So there's quite a bit to it ! Graham
From: MooseFET on 9 Sep 2008 09:10 On Sep 9, 12:03 pm, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > MooseFET wrote: > > Eeyore wrote: > > > MooseFET wrote: > > > > This is all in ASM so the overhead is just the LCALL and RET. > > > > Cor Blimey ! If you chose a certain optimise level in PL/M it'll use CALLs instead > > > of LCALLs if it can to save a few us. > > > How do you propose to save any time that way? Thy both take 24 clocks > > to do. > > LCALLS are longer. I'm sure of it. 3 vs 2 cycles IIRC. Unless that's been changed too. You are sure wrong. Intel Embededded Controller Handbook 1987 7-47 The LCALL is 2 machine cycles. IIRC in the eariest part it was 2 machine cycles. > > Graham
From: Eeyore on 9 Sep 2008 10:19 MooseFET wrote: > Eeyore wrote: > > MooseFET wrote: > > > Eeyore wrote: > > > > MooseFET wrote: > > > > > This is all in ASM so the overhead is just the LCALL and RET. > > > > > > Cor Blimey ! If you chose a certain optimise level in PL/M it'll use CALLs instead > > > > of LCALLs if it can to save a few us. > > > > > How do you propose to save any time that way? Thy both take 24 clocks > > > to do. > > > > LCALLS are longer. I'm sure of it. 3 vs 2 cycles IIRC. Unless that's been changed too. > > You are sure wrong. > > Intel Embededded Controller Handbook 1987 > 7-47 The LCALL is 2 machine cycles. IIRC in the eariest part it was > 2 machine cycles. My equivalent book is with a client now. It's an older version. 1985 ? I would have sworn LCALLs used to be 3 cycles. Graham
From: Spehro Pefhany on 9 Sep 2008 11:00 On Tue, 09 Sep 2008 15:19:13 +0100, Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote: > > >MooseFET wrote: > >> Eeyore wrote: >> > MooseFET wrote: >> > > Eeyore wrote: >> > > > MooseFET wrote: >> > > > > This is all in ASM so the overhead is just the LCALL and RET. >> > >> > > > Cor Blimey ! If you chose a certain optimise level in PL/M it'll use CALLs instead >> > > > of LCALLs if it can to save a few us. >> > >> > > How do you propose to save any time that way? Thy both take 24 clocks >> > > to do. >> > >> > LCALLS are longer. I'm sure of it. 3 vs 2 cycles IIRC. Unless that's been changed too. >> >> You are sure wrong. >> >> Intel Embededded Controller Handbook 1987 >> 7-47 The LCALL is 2 machine cycles. IIRC in the eariest part it was >> 2 machine cycles. > >My equivalent book is with a client now. It's an older version. 1985 ? I would have sworn >LCALLs used to be 3 cycles. > >Graham Nope, it's always been 2 cycles, 3 bytes! Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Eeyore on 9 Sep 2008 20:57
Spehro Pefhany wrote: > Eeyore wrote: > >MooseFET wrote: > >> Eeyore wrote: > >> > MooseFET wrote: > >> > > Eeyore wrote: > >> > > > MooseFET wrote: > >> > > > > This is all in ASM so the overhead is just the LCALL and RET. > >> > > >> > > > Cor Blimey ! If you chose a certain optimise level in PL/M it'll use CALLs >> > > > > instead of LCALLs if it can to save a few us. > >> > > >> > > How do you propose to save any time that way? Thy both take 24 clocks > >> > > to do. > >> > > >> > LCALLS are longer. I'm sure of it. 3 vs 2 cycles IIRC. Unless that's been changed >> > > too. > >> > >> You are sure wrong. > >> > >> Intel Embededded Controller Handbook 1987 > >> 7-47 The LCALL is 2 machine cycles. IIRC in the eariest part it was > >> 2 machine cycles. > > > >My equivalent book is with a client now. It's an older version. 1985 ? I would have >sworn > LCALLs used to be 3 cycles. > > Nope, it's always been 2 cycles, 3 bytes! Ah, it's the bytes not the cycles. I knew there was some reason for that optimise level in PL/M. Thanks for that. Graham |