89C51ED2
in [Design]
|
From: Eeyore on 8 Sep 2008 04:15 "Gordon S. Hlavenka" wrote: > Eeyore wrote: > > Now that is one thing that does bug me about the 8051. I don't recall seeing anywhere > that port pins > power-up in a defined state. I had reason to be cautious on a recent project. Just how fast do they initialise to 0FFH ? > From the 1990 edition Intel "8-bit Embedded Controllers" databook (on > paper!) Page 6-7: > "What do the [MCS-51] SFRs contain just after power-on or a reset?" > (...) > "P0 11111111" > "P1 11111111" > "P2 11111111" > "P3 11111111" > > I generally preload everything explicitly anyway. Totally agree. > However you do need to condition the pins if external circuitry is > sensitive to glitches, as the IO pins do hiccup to varying degrees at > power-on. That's exactly what I was concerned about. Graham
From: krw on 8 Sep 2008 18:22 In article <48C20A2E.774FA7F5(a)hotmail.com>, rabbitsfriendsandrelations(a)hotmail.com says... > > > Joerg wrote: > > > Rich Grise wrote: > > > On Fri, 05 Sep 2008 17:53:59 +0100, 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. I used the sleep function on the 87FC51 in the late '80s without too much trouble (after finding that the databook was wrong). I only used it under battery power where my interrupt latency wasn't a problem (it only had to do intrusion alarm and housekeeping stuff). I rather liked the 8051, though assembler was the only way to fly on such a weird architecture. -- Keith
From: krw on 8 Sep 2008 18:22 In article <48C2B39A.8F38BE1B(a)hotmail.com>, 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. -- Keith
From: krw on 8 Sep 2008 18:22 In article <WHswk.636281$7f3.53619(a)newsfe23.ams2>, Someone(a)ntlworld.com says... > >>>> 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? > > > > But I've never trusted "sleep mode" - probably because it takes me about > > 3 hours after getting up, before I'm fully awake. ;-) > > > > Do you have a little "morning eye-opener" circuit? ;-D > > > > Good Luck! > > Rich > > > Latency is 1 instruction cycle. ....after the oscillator starts. -- Keith
From: krw on 8 Sep 2008 18:22
In article <%LUwk.38434$Fr1.3855(a)newsfe03.iad>, jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net says... > TT_Man wrote: > > >>>>Hmmm that's not how to code 8051 inrterrupts. > >>> > >>>Huh?????? > >>> > >>>Do you mean that you don't save the interrupted context???? !!!!! > >> > >>I can't remember my reason for saying that now. Flags perhaps ? > >> > >>Anyway PL/M handles all that for one. Declare procedure interrupt ! > >> > >>Graham > >> > > > > Coding in assembler opens all sorts of clever trick possibilities that HLL > > guys would never have dreamed of. That only comes with years of developing > > RT asm code. Why push a couple of status bytes when they can be saved in > > half the time by moving them to registers in the current bank.......... > > Doesn't work for everyone though...... > > > > > I guess that would be fine if you didn't have any higher priority INT's There are only two (levels). It doesn't take too much imagination to figure out how to keep them from stepping on one another. > doing the same thing or calling functions with in that block that are > also doing the same thing. > Remember, the 8051's stack is also quite limited. -- Keith |