C and MATH confusion

[neochrome32]

in an example code, im trying to convert code,


from the original code

[stinky]

[neochrome32]

Thank you!

it was producing rubbish, so as long as i know this is working the way it should...

this helps

[temtronic]

hmm..did this test...
from a PIC18F46k22 listing...

z located at 1e
y located at 1d
x located at 1c...

76: x=y=z;
033A C01E MOVFF 0x1e, 0x1d
033E C01D MOVFF 0x1d, 0x1c
77: x=z;
0342 C01E MOVFF 0x1e, 0x1c
78: y=z;
0346 C01E MOVFF 0x1e, 0x1d

so both x and y become whatever z is.
to avoid confusion you can code as 2 lines since it's the same amount of memory and time.

hth
jay

[neochrome32]

OH dear!!! i could have fallen in to that trap! slows this down a bit, but if CCS C seems to make mistakes like that..

i did a test too and it seemed to work, I'm about to test

unsigned int16 a;
signed int16 b;

a = b = 5;

see what happens...


I'm still getting bizarre answers.


Thanks Jay (also sorry for the late reply)

[Jerson]

a = b = c;

Has nothing to do with any specific compiler. It is a familiar C construct that is used by C-coders.

What it means is simply - reading from right to left (that's the way C parses expressions)
c 'is assigned to' b 'is assigned to' a
So,
if c contains the value 3,
b will be made 3
a will be made 3 because b now holds 3.


Hope it helps

[neochrome32]

i've only been coding C for about 2 years really, and the a=b=c has always worked before! lol

ok i've got some sort of really poor voice synth using the polyphonic system 3 oscillation thing and its harder and requires a TON of cycles :(

though again thank you!

i am still trying to figure out the code.

[Ttelmah]

Key problem I can see here, is the use of pgm_read_byte, and the wrong syntax for accessing the address of arrays.

As written, this won't read the byte from the array as required.

First, use rom, not const for the arrays.

Then declare the pointer as:

unin8_t rom *framepos = frameList;

Remember in C, the name of an array, is it's address. You are using &frameList, which says take the address of the array's address... Not correct.

rom does exactly the same as const, except it builds the extra structures to allow a ROM address to be constructed (remember that in the PIC, the ROM data space is a separate memory area to RAM), and declaring a pointer as 'rom', says that this is a pointer to ROM.

Then don't bother with pgm_read_byte, just use *frameList.

If a pointer is declared as to rom (not const), CCS knows to use the program memory read function to access it.

Same applies with formatTable etc..

Now in the original construction, if you did use 'frameList', to access a const array, this does not return the address in ROM. It returns the address of the program to access the array. To get the address of the actual table (if you wanted to use the original approach), you need to use the 'label_address' function. However much more complex than just accessing the table directly.

To show how this works, I took your sin table, and constructed a simple loop to access this:

[neochrome32]

i posted the original code , not the converted code, i will post the converted and i do indeed use ROM, (it works well with just const too)

i'll paste later