From: krw on
In article <48C23E59.BACAA685(a)hotmail.com>,
rabbitsfriendsandrelations(a)hotmail.com says...
>
>
> 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 ?

He didn't say he could maintain *your* lousy code. It does take
some talent to write maintainable code, in any language.

> ASM is for twits, the clueless, poor and morons mainly AFAICS.

No, twits shouldn't use it. Neither should dumb donkeys, evidently.

> I don't mind checking the asm output of PL/M to see how it's done it though. Never been
> unsatisfied.

There is nothing wrong with PL/M, other than there is hasn't been
support for it for a quarter century. There is nothing inherently
wrong with assembler, particularly for the 8051, either.

--
Keith
From: MooseFET on
On Sep 8, 9:45 am, Eeyore <rabbitsfriendsandrelati...(a)hotmail.com>
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.

>
> Graham

From: MooseFET on
On Sep 9, 6:22 am, krw <k...(a)att.bizzzzzzzzzz> wrote:
> In article <%LUwk.38434$Fr1.3...(a)newsfe03.iad>,
> jamie_ka1lpa_not_valid_after_ka1l...(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.

Even in the ones with more levels, it isn't rocket surgery. You just
keep a list of what is used by who.

>
> > 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.

I've worked on machines with stacks of less than 16 calls. Compared
to that, the 8051 stack is positively roomy.

>
> --
> Keith

From: Eeyore on


krw wrote:

> rabbitsfriendsandrelations(a)hotmail.com says...
> > 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.
>
> 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.

Did you ever try PL/M ?

Graham

From: Eeyore on


krw wrote:

> rabbitsfriendsandrelations(a)hotmail.com says...
> > Joerg wrote:
> > > Eeyore wrote:
> > > >
> > > > 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.

RAM The original was NMOS.

> The thing is tiny.

How old is your data book ?

Graham