• AVR Freaks

AnsweredHot!Can someone explain this weird behaviour ?

Page: 12 > Showing page 1 of 2
Author
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
2019/05/25 05:22:13 (permalink)
0

Can someone explain this weird behaviour ?

Hi, i am busy with this chip : PIC16F1789 compiler version 1.43
 
I changed a 16 bit lookuptable to a 8 bit one, then the problems started.
after a day trying i found this out :
 
Everything works good with the following added code :
short iLFO;
long lTemp;
unsigned char iMod = 127,iFade = 255;
 
inline void UsePitchLFO()
{
lTemp = iLFO << 8;
lTemp *= iMod;
lTemp *= iFade;
lTemp >>= 15 + 8;

PITCHLFO = 128 + lTemp;
}

void HandlePitchLFO()
{
HandleDelay();
iPhase += iFreq;
iLFO = sinus[ ( iPhase >> 2 ) & MAXBIT_SINE ]; // 8 bit from -127 to 127
UsePitchLFO();
}

 
As you can see there is added shifts that should not be needed.
This part of the code should look like this :
lTemp = iLFO;
lTemp *= iMod;
lTemp *= iFade;
lTemp >>= 15;

 
This should be good, am i missing something ?
The problem looks like there is some unsigned value used only weirder.
Can someone explain ?, maybe it has to do with the bit that sets positive or negative.
post edited by Jan Audio - 2019/05/25 05:26:58
#1
du00000001
Just Some Member
  • Total Posts : 2679
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:00:36 (permalink)
+1 (1)
And why are you then shifting iLFO left by 8?
This exactly corresponds to the excess 8 Bits shift right you mock about!

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#2
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:05:12 (permalink)
0
I am shifting left by 8 because else it dont works.
Then later i shift back, else there is the error.
So its about not having to shift.
 
It should do the same thing without the two extra shifts.
post edited by Jan Audio - 2019/05/25 06:07:14
#3
du00000001
Just Some Member
  • Total Posts : 2679
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:13:51 (permalink)
+1 (1)
Ah.
What I missed in your code was some explicit type conversions:
the easiest way would be to declare iMod and iFade as signed shorts (instead of unsigned char).
My best guess is that iFade might not be converted in the sense you intend, resulting in an int value of 65535 instead of 255 - due to sign extension during automatic type conversion.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#4
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:16:04 (permalink)
0
Well thanks you i will try that, will report back.
#5
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:39:20 (permalink)
0
No, it does the same, i tryd setting iFade and iMod to short type.
Thats the whole point, i dont want iLFO also to be short, i need it char for this 8 bit chip.
 
The error looks like this :
When making iMod or iFade lower the error gets bigger.
It looks like when being close to the lowest value it suddely goes above the max value ( 127 ).
post edited by Jan Audio - 2019/05/25 06:41:20
#6
davekw7x
Entropy++
  • Total Posts : 1735
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 06:53:19 (permalink)
+3 (3)
Jan Audio
...i dont want iLFO also to be short, i need it char for this 8 bit chip...

Here is my suggestion:  Perform the calculations manually (pencil and ---gasp--- paper) for some specific values that give "weird" results in your program.
 
Show us the steps and the values from your manual calculations at each step.  Then, if the computer results still seem to be "weird,"  maybe we can see (and, maybe, help you understand) why your results don't meet your expectations.
 
Regards,
 
Dave
post edited by davekw7x - 2019/05/25 07:07:41

Sometimes I just can't help myself...
#7
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:15:33 (permalink)
0
Its all good with the extra shifting.
The values are all there, the lookuptable gives -127 to 127.
Then mutliplyd by max 255 and multiplyd again by max 127, all shifted right by 15 bits + extra 8 for fix.
Resulting in values higher then 127;
#8
NorthGuy
Super Member
  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:24:01 (permalink)
+1 (1)
if iLFO is 0xff then (iLFO << 8) is 0xff00. Since iFLO was signed, when this is assigned to lTemp it becomes 0xffffff00. After multiplications it's 0xff817f00, so the result after the shift is 0x1ff.
 
In your "normal" calculation, the first assignment to lTemp is 0x000000ff, the result after multiplication is 0x007e027f and after the shift it is 0xfc.
 
So, it's not surprising the results are different. As you don't tell what you want, it's hard to figure out which of these two results is good for you and why. Perhaps, using "signed char" (or better "int8_t") for iLFO would help, but it's only a guess.
#9
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:35:14 (permalink)
0
No the iLFO is a bipolar value from the sinus lookuptable from -127 to 127.
I am wondering how can the outcome be different ?
#10
davekw7x
Entropy++
  • Total Posts : 1735
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:37:53 (permalink)
+3 (3)
Jan Audio
Its all good with the extra shifting.

So you fiddle-farted around with your code so that you got the answer you expected for some particular values.  (See Footnote)
Looking back over your posts, I see:
Jan AudioCan someone explain ?

 
and
Jan AudioIt should do the same thing without the two extra shifts.

 
and
Jan AudioIt looks like when being close to the lowest value it suddely goes above the max value

 
and
Jan AudioIts all good with the extra shifting

 
Bottom line for me: How the heck can you have confidence in a program that required some non-understandable tweaks to give expected results for some particular tests?   I mean, you should test and test and test some more to try to uncover bugs, but, in general, you can not prove a program is correct just by testing.
 
I hate to repeat myself: But if you will write out the steps of your calculations for some particular values that give non-understandable results and show us the manually calculated results at each step, maybe we can get to the bottom of things.
 
 
Regards,

Dave
 
Footnote.
The very first thing I learned in my very first EE lab course about a hundred years ago (or so it seems) is:
"If you know the right answer, you can get the right answer."
On the other hand...
Dry-labbing results to give the "right" answer can not increase your understanding of the underlying process or of proper lab procedures.
post edited by davekw7x - 2019/05/25 07:42:01

Sometimes I just can't help myself...
#11
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:44:13 (permalink)
0
Ok, thanks for the reply, if it works i can forget it.
Dont want to be rude to blaim the compiler in advance so just asking if its me ?
I just get these bugs many times while its proven not me, i dont give up and still trying to blaim myself.
#12
davekw7x
Entropy++
  • Total Posts : 1735
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:52:27 (permalink)
+1 (1)
Jan Audio
Ok, thanks for the reply, if it works i can forget it.

That's exactly the opposite of what I thought I was saying.  (See Footnote.)
 
Jan Audio
... i dont give up...

Ahhh---that's the spirit!  I hate to repeat myself again (for one last time) but can you show us some manually calculated step-by-step results that differ from the results of your program (with and without the non-understadable modifications)?
 
Regards,

Dave
 
Footnote:
"The purpose of computing is insight, not numbers."
---Richard W. Hamming
 
"Well, the numbers are important, too, but numbers without insight are dangerous."
---davekw7x
post edited by davekw7x - 2019/05/25 08:06:37

Sometimes I just can't help myself...
#13
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 07:58:12 (permalink)
0
I can make a movie from the oscilloscope if i get a camera charged.
#14
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 08:00:37 (permalink)
0
The funny thing is when multiplyd by value 256 and 128 there is no error.
 
#15
LdB_ECM
Junior Member
  • Total Posts : 56
  • Reward points : 0
  • Joined: 2019/04/16 22:01:25
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 08:15:13 (permalink)
0
There is nothing wrong your code is crazy because it lacks understanding
The sign bit (+ve or negative) is bit 31 on your long which is SIGNED.
 
Short is itself signed with bit15 carry the bit and you first butcher it by left shifting it 8 bits so it becomes randomly unsigned.
 
Then you roll a signed int back 15 bits so the sign bit is sitting in limbo at bit 16
[code]lTemp >>= 15;[code]
 
So your code is nonsense, you can't start rolling signed things and then multiplying them by unsigned things.
#16
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 08:31:00 (permalink)
0
Ok, so the signed char sinus value is loaded into a short,
is the sign bit then in the short bit 15 or copyd bit 7 from the char ?
Then the short is placed into long, is the sign bit now bit 31 ?
#17
1and0
Access is Denied
  • Total Posts : 9200
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 09:35:11 (permalink)
+1 (1)
Post the definition of your sinus[] lookup table.
#18
Jan Audio
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2018/09/24 08:12:24
  • Location: 0
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 09:38:45 (permalink)
0
const char sinus[ 1024 ];
#19
1and0
Access is Denied
  • Total Posts : 9200
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Can someone explain this weird behaviour ? 2019/05/25 13:31:03 (permalink) ☼ Best Answerby Jan Audio 2019/05/26 06:18:53
+4 (4)
Jan Audio
const char sinus[ 1024 ];

That is your problem (as usual it is nowhere what you posted ;) the sign of plain char type is compiler dependent and it's unsigned for XC8.  So replace it with
const signed char sinus[ 1024 ];

as your wanted signed values of -127 to 127. ;)

Better yet, use
const int8_t sinus[ 1024 ];

#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2019 APG vNext Commercial Version 4.5