Hi all! I have a very strange effect when trying to backup the l5 register in an ISR. I do this at the start of the ISR: dm(save_i5) = i5; ! save DAG 5 dm(save_m5) = m5; dm(save_l5) = l5; and this at the end: i5 = dm(save_i5); m5 = dm(save_m5); l5 = dm(save_l5); rti; However, for i5 and i5 this works, while l5 is always reset to zero when observed from the main program. Is this a processor bug? If I use DAG 4 , the same code seems to run. Any idea? Best regards, Andre (please replace no_spam by a.lodwig to reply!)
Strange things happen with ADSP2185 and l5 register. HELP!!!
Started by ●March 23, 2004
Reply by ●March 23, 20042004-03-23
Andre <no_spam@fischer-zoth.de> wrote in news:c3plpg$rts$00$1@news.t- online.com:> Hi all! > > I have a very strange effect when trying to backup the l5 register inan> ISR. I do this at the start of the ISR: > > dm(save_i5) = i5; ! save DAG 5 > dm(save_m5) = m5; > dm(save_l5) = l5; > > and this at the end: > > i5 = dm(save_i5); > m5 = dm(save_m5); > l5 = dm(save_l5); > rti; > > However, for i5 and i5 this works, while l5 is always reset to zero > when observed from the main program. > Is this a processor bug? If I use DAG 4 , the same code seems to run. > > Any idea? > > Best regards, > > Andre > > > (please replace no_spam by a.lodwig to reply!) >Any chance that i5 is being used by a SPORT for autobuffering? -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?
Reply by ●March 24, 20042004-03-24
No, I am using DAGs 6 and 7, both using the m7 modifier. Funny enough, saveing and restoring the l4 register seems to work. Very strange. I think I will live with l5=0 and re-organize my code a bit... Al Clark wrote: > > > Any chance that i5 is being used by a SPORT for autobuffering? >> Andre <no_spam@fischer-zoth.de> wrote in news:c3plpg$rts$00$1@news.t- > online.com: > > >>Hi all! >> >>I have a very strange effect when trying to backup the l5 register in > > an > >>ISR. I do this at the start of the ISR: >> >> dm(save_i5) = i5; ! save DAG 5 >> dm(save_m5) = m5; >> dm(save_l5) = l5; >> >>and this at the end: >> >> i5 = dm(save_i5); >> m5 = dm(save_m5); >> l5 = dm(save_l5); >> rti; >> >>However, for i5 and i5 this works, while l5 is always reset to zero >>when observed from the main program. >>Is this a processor bug? If I use DAG 4 , the same code seems to run. >> >>Any idea? >> >>Best regards, >> >>Andre >> >> >>(please replace no_spam by a.lodwig to reply!) >>
Reply by ●March 24, 20042004-03-24
Sorry to all, forget my posting. I had some code in the Interrupt vector table itself, and I was resetting l5 to zero here.... Andre wrote:> > No, I am using DAGs 6 and 7, both using the m7 modifier. > Funny enough, saveing and restoring the l4 register seems to work. > > Very strange. I think I will live with l5=0 and re-organize my code a > bit... > > Al Clark wrote: > > > > > > > Any chance that i5 is being used by a SPORT for autobuffering? > > > >> Andre <no_spam@fischer-zoth.de> wrote in news:c3plpg$rts$00$1@news.t- >> online.com: >> >> >>> Hi all! >>> >>> I have a very strange effect when trying to backup the l5 register in >> >> >> an >> >>> ISR. I do this at the start of the ISR: >>> >>> dm(save_i5) = i5; ! save DAG 5 >>> dm(save_m5) = m5; >>> dm(save_l5) = l5; >>> >>> and this at the end: >>> >>> i5 = dm(save_i5); >>> m5 = dm(save_m5); >>> l5 = dm(save_l5); >>> rti; >>> >>> However, for i5 and i5 this works, while l5 is always reset to zero >>> when observed from the main program. >>> Is this a processor bug? If I use DAG 4 , the same code seems to run. >>> >>> Any idea? >>> >>> Best regards, >>> >>> Andre >>> >>> >>> (please replace no_spam by a.lodwig to reply!) >>>
Reply by ●March 24, 20042004-03-24
Andre <no_spam@fischer-zoth.de> wrote in news:c3rgb9$jpr$01$1@news.t-online.com:> > No, I am using DAGs 6 and 7, both using the m7 modifier. > Funny enough, saveing and restoring the l4 register seems to work. > > Very strange. I think I will live with l5=0 and re-organize my code a > bit...Very strange, indeed, I have written as much 218x code as probably anyone on the planet, and I have never seen this problem, HOWEVER, I always use i1 & i5 with a SPORT and therefore I never use them in my other routines. Have you checked the errata? -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?> > Al Clark wrote: > > > > > > > Any chance that i5 is being used by a SPORT for autobuffering? > > > >> Andre <no_spam@fischer-zoth.de> wrote in news:c3plpg$rts$00$1@news.t- >> online.com: >> >> >>>Hi all! >>> >>>I have a very strange effect when trying to backup the l5 register in >> >> an >> >>>ISR. I do this at the start of the ISR: >>> >>> dm(save_i5) = i5; ! save DAG 5 >>> dm(save_m5) = m5; >>> dm(save_l5) = l5; >>> >>>and this at the end: >>> >>> i5 = dm(save_i5); >>> m5 = dm(save_m5); >>> l5 = dm(save_l5); >>> rti; >>> >>>However, for i5 and i5 this works, while l5 is always reset to zero >>>when observed from the main program. >>>Is this a processor bug? If I use DAG 4 , the same code seems to run. >>> >>>Any idea? >>> >>>Best regards, >>> >>>Andre >>> >>> >>>(please replace no_spam by a.lodwig to reply!) >>>
Reply by ●March 25, 20042004-03-25
Sorry again, it was my fault! To save code space, I had put l5=0 into the vector table and just had forgotten this fact... Thanks again, Andre Al Clark wrote:> Andre <no_spam@fischer-zoth.de> wrote in > news:c3rgb9$jpr$01$1@news.t-online.com: > > >>No, I am using DAGs 6 and 7, both using the m7 modifier. >>Funny enough, saveing and restoring the l4 register seems to work. >> >>Very strange. I think I will live with l5=0 and re-organize my code a >>bit... > > > Very strange, indeed, > > I have written as much 218x code as probably anyone on the planet, and I > have never seen this problem, HOWEVER, > > I always use i1 & i5 with a SPORT and therefore I never use them in my > other routines. > > Have you checked the errata? >
Reply by ●March 25, 20042004-03-25
Andre <no_spam@fischer-zoth.de> wrote in news:c3ubvb$3f6$02$1@news.t-online.com:> Sorry again, it was my fault! > > To save code space, I had put l5=0 into the vector table and just had > forgotten this fact... > > Thanks again, > > Andre > > >Once again, someone has proven Clark's Law of Ten: All bugs take 10 seconds, 10 minutes, 10 hours, 10 days,...... to solve and they're are dumb shits (when you find them). Clark's Corollary: Most problems can be solved two blocks from the office on the way home. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- comp.dsp conference July 28 - Aug 1, 2004 details at http://www.danvillesignal.com/index.php?id=compdsp email: compdsp@danvillesignal.com Who says you can't teach an old dog a new DSP trick?
Reply by ●March 25, 20042004-03-25
> > Once again, someone has proven Clark's Law of Ten: > > All bugs take 10 seconds, 10 minutes, 10 hours, 10 days,...... to solve > and they're are dumb shits (when you find them). > > Clark's Corollary: > > Most problems can be solved two blocks from the office on the way home.Or when going to bed... or when taking a shower... It's strange for me: sometimes I find the solution to a problem I've been struggling with the whole day before, and I get it solved when taking the morning shower... But, often times, when I get back to work, I forget the solution I had in my mind when taking the shower.. and the struggling begins again! And yes, many, many times the "problem" was just a little mistake. Little since you find it. Huge before that. JaaC> > > > -- > Al Clark > Danville Signal Processing, Inc. > -------------------------------------------------------------------- > comp.dsp conference July 28 - Aug 1, 2004 > > details at http://www.danvillesignal.com/index.php?id=compdsp > email: compdsp@danvillesignal.com > > Who says you can't teach an old dog a new DSP trick?
Reply by ●March 25, 20042004-03-25
Jaime Andres Aranguren Cardona wrote:>>Once again, someone has proven Clark's Law of Ten: >> >>All bugs take 10 seconds, 10 minutes, 10 hours, 10 days,...... to solve >>and they're are dumb shits (when you find them). >> >>Clark's Corollary: >> >>Most problems can be solved two blocks from the office on the way home. > > > Or when going to bed... or when taking a shower... It's strange for > me: sometimes I find the solution to a problem I've been struggling > with the whole day before, and I get it solved when taking the morning > shower... But, often times, when I get back to work, I forget the > solution I had in my mind when taking the shower.. and the struggling > begins again! > > And yes, many, many times the "problem" was just a little mistake. > Little since you find it. Huge before that. > > JaaCI used to keep pad and pencil in my night stand. Sometimes what I saw on it in the morning was nonsense, sometimes it was good, but the most frustrating were the true insights that might as well have been written by a stranger. When I was a sophomore in high school, a friend a year older posed me this puzzle, where each letter stands for a digit, and the addition is correct: SEND + MORE ������� MONEY I struggled with it on and off through day without cracking it, and though the answer was on my nightstand pad the next morning, I still had no coherent method for solving it. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●March 25, 20042004-03-25
On Thu, 25 Mar 2004 16:25:29 -0500, Jerry Avins <jya@ieee.org> wrote:> Jaime Andres Aranguren Cardona wrote: > > When I was a sophomore in high school, a friend a year older posed me > this puzzle, where each letter stands for a digit, and the addition is > correct: > > SEND > + MORE > ������� > MONEY > > I struggled with it on and off through day without cracking it, and > though the answer was on my nightstand pad the next morning, I still had > no coherent method for solving it. > > JerryJerry, The first clue is the carry. The largest any column addition can be is 9 + 9 + 1 (carry) or 19. Therefore M = 1. That gives you a limited number of possibilities for S, and so on. We had to develop programs to solve these sorts of puzzles in Algorithms as an excercise in backtracking. Charles
