Spin Semiconductor

Ground is tied together in the chip so it doesn't matter. What is important is to have a good, solid ground plane.

Similar but not the same. You will have to review the languages to see how difficult it will be for your programs.

Let me ask you one more question, unrelated to the topic. Is there any way to prevent the eeprom contents from being decompiled? You know, I'm afraid now I can buy any FV-1 based product, make the memory dump and decompile bin with shift-line's docompiler. Is there any way to "crypt" it? ...

Just set COS and SIN to the proper starting points. As long as COS leads SIN by 90 degrees it should work. So any of the following should work (values in degrees not actual SIN and COS values):

S=0, C=90
S=0, C=-90
S=C=45

Probably a bit width issue, MULX is a 16-bit coefficient so losing the lower 8-bits of the value used for the coefficient.

That was a reply intended for another person who is using the h/w LFOs. To answer you, don't use SOF. SOF only takes a S1.14 format 16-bit value and you are trying to put in too small a number. So your choices are to use a larger value and shift the result down like you are with the SOF 0.1, 0 instr...

You will have to do the LFO in code, there are examples in the forum.

gary00k wrote: ↑Sun Oct 03, 2021 10:46 am Result should be the same

Nope, they should not. You are not considering bit width, as I said the coefficient in SOF is 16-bits.

Then you will probably need to code it by hand to get the desired range and resolution and not use the built in LFOs.

SOF takes a 16-bit C value, 0.00028095 is 1,000 times smaller (about 11 bits) than 0.28095 so you lose 11-bits of resolution.

Just look at the assembled code:
0000 0004000D :sof 0.00028095, 0
0001 11FB000D :sof 0.28095, 0

It is a limited range LFO designed for things like chorus, etc. If you want a really wide ranging sin generator with lots of resolution you will have to code it up by hand and maybe use 2 POTs for a coarse and fine adjustment. In most effects the absolute frequency is unimportant, it is what sounds ...

Maybe different sample rates?

See this thread, the code in it show how the SIN algo works: http://www.spinsemi.com/forum/viewtopic.php?t=28

Have you looked at the equations and mapping of bits for sinX_rate in AN-0001?

Couple of different ways google it to show you some of them. Basically delays and filtering.