89C51ED2
in [Design]
|
From: TT_Man on 7 Sep 2008 15:39 "MooseFET" <kensmith(a)rahul.net> wrote in message news:389ef885-8dc7-465b-87ef-b9f2aec746f0(a)a8g2000prf.googlegroups.com... > 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. Get real, contact bounce is handled in a 25mS background routine.........
From: MooseFET on 7 Sep 2008 19:43 On Sep 7, 12:38 pm, "TT_Man" <Some...(a)ntlworld.com> wrote: > "Jamie" <jamie_ka1lpa_not_valid_after_ka1l...(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... I do "functions" quite often with an interrupt routine. I have RS-232 interrupt routines that need to do a fair bit of logic and then perhaps send the next character. It makes it a lot easier to read if you make a few routines out of it. This is all in ASM so the overhead is just the LCALL and RET.
From: Eeyore on 7 Sep 2008 21:34 TT_Man wrote: > "Jamie" wrote > > TT_Man wrote: > >> > >> 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... Hmmm flags ... useful things they are. Can we talk about finite state machines next ? Graham
From: Eeyore on 7 Sep 2008 21:45 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. Graham
From: Gordon S. Hlavenka on 8 Sep 2008 01:33
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. 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. 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. -- Gordon S. Hlavenka Join the Revolution at http://www.ronpaul.com |