89C51ED2
in [Design]
|
From: MooseFET on 7 Sep 2008 12:21 On Sep 7, 11:49 am, mpm <mpmill...(a)aol.com> wrote: > On Sep 6, 10:56 pm, Spehro Pefhany <speffS...(a)interlogDOTyou.knowwhat> > wrote: > > > > > On Fri, 05 Sep 2008 18:23:00 +0100, the renowned Eeyore > > > <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > > > >Spehro Pefhany wrote: > > > >> Eeyore wrote: > > >> >Rich Grise wrote: > > > >> >> If I could get an 8051 equivalent but with Motorola's timer system (see > > >> >> 68HC11, e.g.), I'd be in hog heaven. ;-) > > > >> >What's so great about Motorola's timers ? > > > >> Much better designed. > > > >In any specific way ? The only thing I might like in 8051 family timers is more > > >than 16 bits. > > > >Graham > > > For example, they added a little clump of hardware that latches the > > low order byte of a timer in a hidden register when you read the high > > order byte... which effectively makes a 16-bit timer read an atomic > > operation on an 8-bit processor, without ugly tests and fixes. > > > Best regards, > > Spehro Pefhany > > -- > > "it's the network..." "The Journey is the reward" > > sp...(a)interlog.com Info for manufacturers:http://www.trexon.com > > Embedded software/hardware/analog Info for designers:http://www.speff.com-Hide quoted text - > > > - Show quoted text - > > Like they say, > "A little bit goes a long way." > > Sorry, I could not help myself. ;-) > I agree that using assembler to generate long delays at reasonably > fast clock rates is a bit of a hassle. A wider clock register on > 8051's would be nice, but is of course, not essential. Take a look at the Silabs (formerly Cygnal) processors. You get a lot more timer options. > > -mpm
From: MooseFET on 7 Sep 2008 12:31 On Sep 7, 1:32 pm, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > MooseFET wrote: > > Eeyore wrote: > > > MooseFET wrote: > > > > Rich Grise <r...(a)example.net> 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? > > > > > 8051s have a built in interrupt lock out and priority system. I doubt > > > > that he is getting into multiple levels of interrupts. > > > > LOL ! > > > > All too easy by half and don't forget you have only 4 register banks to play > > > with, meaning only only 3 simultaneous interrupts. of various priorities. > > > Since the basic 8051 only has two levels, even if you use the faked up > > 3rd level trick, you only have 3 interrupts to spread among the 3 > > banks. It isn't really a problem. > > > The faked up extra level involves calling a return from interrupt > > instruction from within the interrupt code. This makes the following > > code run in non-interrupt mode and thus allows another interrupt. > > > If you try to do this more than one deep, you find your self in deep > > trouble. > > Some of the more recent ones including I suspect the ED2 have more IP bits. Yes, the RD and ED chips do a 4 level priority on interrupts. This means that the fake extra level moves it from 4 to 5. > Intel were smart to leave open those possibilities. I wonder if it was smart or lucky. They elected to make the SFRs be addressed the same way as RAM so they ended up with 128 of them. Even at that the Silabs processor pages its SFRs to allow even more. > > Graham
From: MooseFET on 7 Sep 2008 12:40 On Sep 8, 12:05 am, "TT_Man" <Some...(a)ntlworld.com> wrote: > "MooseFET" <kensm...(a)rahul.net> wrote in message > > news:80fdab35-9c4f-4537-9237-d23ef03b79e1(a)v39g2000pro.googlegroups.com... > > > On Sep 7, 6:29 am, "TT_Man" <Some...(a)ntlworld.com> wrote: > >> "MooseFET" <kensm...(a)rahul.net> wrote in message > > > [....] > > >> > The timing related problem will only show if you have external inputs > >> > other than the clock and reset pins. The true false boundary varies > >> > from chip to chip and run to run. > > >> All inputs are flagged and re checked 25 ms later, If true , a flag > >> change > >> is set.... > > > It could be a narrow window of timing that is causing the problem. > > Try changing the clock speed just a a little and see if the problem > > goes away. > > Why should I? The problem lies in the manufacture of the chip, not my code. > In any case, if it's missed by 1 nanosecond, it will catch it next time > round, unless you can pull and release a trigger within 100 microseconds... I'm thinking that there really may be a problem in your code when you have something like contact bounce.
From: Jamie on 7 Sep 2008 14:22 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 doing the same thing or calling functions with in that block that are also doing the same thing. http://webpages.charter.net/jamie_5"
From: TT_Man on 7 Sep 2008 15:38
"Jamie" <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote in message news:%LUwk.38434$Fr1.3855(a)newsfe03.iad... > 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 > doing the same thing or calling functions with in that block that are also > doing the same thing. > > > http://webpages.charter.net/jamie_5" Functions and things should be kept out of int service routines..... set a flag, and handle it in a background scheduler... > |