89C51ED2
in [Design]
|
From: MooseFET on 6 Sep 2008 13:56 On Sep 6, 4:22 pm, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > MooseFET wrote: > > On Sep 6, 5:30 am, Rich Grise <r...(a)example.net> 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? > > > 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. > > Graham
From: MooseFET on 6 Sep 2008 13:58 On Sep 6, 4:20 pm, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > MooseFET wrote: > > "TT_Man" <Some...(a)ntlworld.com> 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. > > > > >> >> Graham > > > > >> 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. > > > I think you need to look very carefully at the interrupt code to make > > sure that it doesn't forget to save part of the context. This sounds > > like it is either timing related or an uninitialized flag. > > Hmmm that's not how to code 8051 inrterrupts. Huh?????? Do you mean that you don't save the interrupted context???? !!!!! > > Graham
From: MooseFET on 6 Sep 2008 14:01 On Sep 6, 6:15 pm, "TT_Man" <Some...(a)ntlworld.com> wrote: > >> >> 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. > > > I think you need to look very carefully at the interrupt code to make > > sure that it doesn't forget to save part of the context. This sounds > > like it is either timing related or an uninitialized flag. > > No. The code runs perfectly in old date code devices and has been in > production world wide for 15 odd years in one form or another. As I pointed out elsewhere, the memory locations in a given chip tend to go to one value on power up. On a different chip they will go to a different value. If you forgot to initialize something, this will make some devices work and others fail. 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.
From: MooseFET on 6 Sep 2008 14:03 On Sep 6, 4:24 pm, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > MooseFET wrote: > > Eeyore wrote: > > > MooseFET wrote: > > > > Eeyore wrote: > > > > > MooseFET wrote: > > > > > > > Is it written in ASM or C? > > > > > > 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. > > > > I still use PL/M 51. So easy to use. You can treat it as highish level language and > > > set a register directly in the next line. > > > > I can't even begin to imagine coding some of the fairly complex (for microcontrollers) > > > stuff that we did with 8051s in asm. The mind boggles. Never mind code maintenance. > > > I do it all the time. It takes less time to write the code than to > > design it. Any competent engineer can maintain it. > > I'll send you some code shall I ? Only if this code was written by a competent engineer and you also send money. I don't work for free. > ASM is for twits, the clueless, poor and morons mainly AFAICS. I guess this is where we will part company on this subject.
From: MooseFET on 6 Sep 2008 14:08
On Sep 7, 12:06 am, legg <l...(a)nospam.magma.ca> wrote: > On Thu, 04 Sep 2008 14:29:05 +0100, Eeyore > > <rabbitsfriendsandrelati...(a)hotmail.com> wrote: > > >MooseFET wrote: > > >> Is it written in ASM or C? > > >I think he said it was all written in asssembler <yuk>. > > Can't think of a more apt instance where assembler shows it's > advantages over more bloated forms - in troubleshooting IC abnormal > behavior at a specific stage of operation. Not all compilers are all that bloated. PL/M doesn't do all that bad of a job of making ASM out of a highish level source code. It makes code that is better than most beginner level asm writers will produce. |