Flexi Tone Generator TAS3204-EVM

Thomas,

I am not sure why that after couple of times of changing the frequency, it's stuck, maybe you need to wait for some time before change again? I've never used this generation myself, so not sure what happened.

But for the I2C message, I checked the code, you need to send the index, not the real frequency to DAP. say the first one on the list the index is 0, the frequency is 25 Hz for 48kHz sampling rate. the second one on the list the value you send would be 0x00000001 and that would be 32Hz for 48kHz sampling rate.

Hope this helps.

Susan

Thomas,

As you described in your email, what you need is a tone generator that would take a parameter at runtime to generate a tone at certain frequency.

To realize that and take into account the resource in TAS3x, I think it's doable, we need to do the following:

1) calculate the initial two samples based on the desired frequency(f0) and sampling rate (fs)and the target amplitude (A):

    y(0) = -1*A*sin(2*pi*f0/fs)

    y(1) = 0;

2) send these two numbers over the I2C, to realize this

     a) you could reuse most of the .asmx code in flextoneGen, I think the modification would be minor if there's any

     b) you need to modify the .xml file when publishing the component, you need to change the I2C interrupt handler from 97 to 2, 97 is the special handler for flextonegen, 2 is the general handler for 48 bit data transfer

Please let me know if there's any further info you need from me.

regards,

Susan

Second thought:  We could just calculate alpha and beta as described in the help file and send them through I2C, then we should be able to reuse the template file from flexToneGen.

Yes Susan, but how do we get an I2C address to write the alpha and beta values to?

Thanks for the effort you take.

Thomas

Thomas,

One I2C message is 20 bytes long, one data value is 6 bytes long, so we don't need another I2C sub address to do this, we can use the one that is used to transfer the index right now to transfer the alpha and beta into DAP.  Ok, I'll modify it and attach it here later today and you compare it with the origianl one and you would know what I am talking about.

Regards,

Susan

Seems I can only attach one at a time.  Here is the other one.

Thank you Susan,

I just can not find the reason for this eror during code generation because I am not familiar with the whole building process:

Error: dsp_init_cmds.objectx(17) : undefined property : 'ToneGeneratorFrequency'

Please see th picture attached as well.

Do you have any idea?

Thomas

Thomas,

It seems to me that you didn't publish the component properly.  Here is my suggestions:

1) read the document regarding how to use the component publisher, you could find it in GDE help content

2) copy everything from FlexToneGen from component cache folder to a separate folder and rename it something else (by renaming the .xml file)

3) copy the two .xml files I sent you and overwrite the existing ones (also remember to rename the .xml

4) open the component publisher and load the .xml with the component name and then resave it, then when you reload it, you should be able to see the .xml with the new name (the name you choose) appears in the file list.

5) Close GDE, publish the component and reopen GDE, see whether the problem still exists.

Regards,

Susan

Susan,

still the same error.

But I did search the files for ToneGeneratorFrequency and found it in the dsp_init_cmds.objectx:

 -- DSP initialization code for %%prop(InstanceId)
-- see 8051 file init.c for details
-- Priority
&H02
-- Handler Function
%%objecthex(%%prop(HandlerFunction1),0,2)
-- DSP Address
## Data address - must be offset by 0x0400
%%objecthex(%%prop(DSPDataBlockStart1),0x0400,2)
-- Delay - N/A
&H00
&H00
-- Length
&H04
-- Data
## The value of an enumerated property is the integer value, which is what is wanted here
%%objecthex(%%prop(ToneGeneratorFrequency),0,4)

Do we have to alter this?

Thanks for any help.

Thomas

Thomas,

I suggest that we get rid of the second line under "recipes" tab in the component publisher and publish the component again,  I think the purpose of .objectx is for the special I2C handler function that was used by the normal fexitongen which we don't use anymore, so you could delete that file from your component file list.

Let's try this first and see how it goes and also always remember to close and reopen GDE when republish the component.

Regards,

Susan

Well Susan, I do get a tone when I run the PF on the EVM. But it is 200 Hz even if it is set to 1kHz alpha = 1.98288... and beta = -0,13052... when I disable and reenable the tonegenerator I sometimes get nothing or a 200Hz square wave or a stange waveform with 12kHz.... Then I did reset the EVM and it goes back to 200Hz. Then I left it enabled and set alpha to 4kHz = 1.7320...and left beta untouched and I get a 4000kHz sinewave! I update beta to -0.5 and it stays fine even if I disable and enable again. Then I try to go back to 1kHz: disable, update alpha and beta, enable no output! disable enable does not change anything: no output. I reset . Back to 200Hz. I leave it enabled and set alpha to anything and then back to 1kHz and I do get a 1khz tone. I update alpha to 200Hz and get a 200Hz squarewave when I then update beta as well the output goes to 0.

It seem to be working somehow but either not stable or with an unpredictable output.

Do you have any idea how we can get this right?

Thanks for any thoughts.

Thomas

Thomas,

There are couple of things we could check:

1) whether the correct value is transferred to DSP via I2C, this we could check with tool->I2C memory tool, after you updated alpha and beta, first read back from the corresponding I2C subaddress to see whether the values are correct.  Then write the correct value using I2C memory tools to see whether the generator still behave the same

2) check whether we have correct value in DAP memory.  There is a .lst file under main_rate48 that you could find the address of the alpha and beta used which you could find in the .asmx file.

3) at the mean time, I'll check the 8051 code to see whether there's anything special about the I2C interrupt handler that was used before, whether there's any scaling involved, which I assumed there isn't.

regards,

Susan

Susan,

please see the screen shot attached:

the alpha value is right but the beta changes everytime I read the I2C address.

Thanks,

Thomas

Thomas,

I check the .asmx code, the memory location for beta is used to hold the temporary output, so it was overwritten for each sample, what you observed is correct.  But at least we got alpha right :)

I also checked 8051 code, there's no scaling for the beta and alpha passed into DAP, so we should be fine.

We could try couple of things:

1) try to debug using a smaller .pfw, just an input and output, see whether that makes any difference. 

2) can you take a look at your resource usuage, how many cycles you already used?  under view-> resources window

3) could you give me your component, so I could run it in the simulator to see how it's doing.  Of course, if you could do it yourself, it would be better, because it would take some time before I could do it.

Regards,

Susan

Susan,

1) a  pfw with only the sinegenerator and an output does the same.

2) My resource usage:

3) Please find the component attached.

Could you please find some time to spend on this. I now did spend already a lot of time and I get a little under pressure now.

Thank you very much.

Thomas

Thomas,

Please try the attached componet: I fixed couple of mistakes in the .asmx file, you could take a look to see the differences.  Also, I was wrong about the beta, it was scaled, so when you do the calculation, you need to put in the number *2^16.

And also, remember to disable and enable the tone generator when you switch between different frequencies.

Regards,

Susan

Does not change really, Susan.

I made sure that the component you send is used by removing the old from the directories componentcach, componentlibrary and usercomponentlibrary.

I can read the updated alpha and beta with the I2C memory tool but when the sinegenerator is enabled there is a strong increase in gain though the frequency is right and the beta changes every time I read the I2C address.

Thanks for further help....

Hoping...

Thomas

OOPS got the scaling of beta wrong, sorry...

I be be back after correcting...

Thomas

All right, it is working now, Susan.

There is one more thing.

I acctually would have to do a so called warble sweep with the sine wave. This is sweeping the sine wave from 20 to 20000 Hz while swinging round the center sweep frequency with 1/3 octave.

That means that I have to diable - update alpha beta - eable like ten times a second wich makes a horrible noise.

Now, is there any chance to work with two alphabeta registers and a third register to tell wich alphabeta register to work from?

This way I could update the alphabeta register A while the sinegenerator is working from the alphabeta register B

then switch to A and update B.

That would be realy a great thing.

Any thoughts on this?

Thanks,

Thomas

Thomas,

I think it's doable.  But it would require more changes than the previous change when converting from the existing FlexiTonGen.

You would need to:

1) change the two .xml files to add in the new alpha, beta and the selection

2) change the .asmx file to add in the source code to swap between the two sets of alpha/beta based on the selection

regards,

Susan

Thank you Susan.

But do you think that it is possible to change alpha and beta on the fly or do we have to disable - select - enable?

Thomas

Thomas,

without disable/enable, that would be difficult.  Because we need that to restore the initial state.  I am trying to think of another way to do it, but no luck yet.

Susan

Susan, I found a algorithm to calculate a sine wave but it is in C:

// Input angle from -pi/4 to pi/4
dsp16_t dsp16_op_kernel_sinfix(dsp16_t angle)
{
  // Coefficients of the 5th order Tchebychev polynom to calculate a sine.
  const dsp16_t s1 = DSP16_Q(0.785369873046875);
  const dsp16_t s3 = DSP16_Q(0.322784423828125);
  const dsp16_t s5 = DSP16_Q(0.03875732421875);
  S32 z, suma;

  // Computation of the polynom
  z = (angle*angle) >> (DSP16_QB - 3);
  suma = s3 - ((z*s5) >> (DSP16_QB + 1));
  suma = s1 - ((z*suma) >> (DSP16_QB + 1));

  return (angle*suma) >> (DSP16_QB - 2);
}

Could this be translated int assembler for the TAS?

Thanks,

Thomas

Thomas,

Have you tried to use this code to generate sine wave?  I am not 100% positive about it since usually polynomial approach is fine to calculate a sin(x) value based on the angle x, but when using it to generate sine wave, there might be discontinouity in the wave.

If you've confirmed the wave form is ok, then this algorithm can be implemented in TAS3x.

regards,

Susan

This is right Susan.
If we want to generate a sinsweep with a continous waveform we would have to be able to alter the frequency with the right phase. The code that I found is only the sin function. But it is a start. So we would need something like sin(2*pi*f/fs*t + phase).

Wouldn´t we?

Thanks for any further idea.

Thomas

Thomas,

That's right.  The problem with the polynomial approach is the possibility of discontinounity due to limited precision.  The most commonly used method on fixed-point DSP is lookup table, but indexing in TAX3x is very expensive, it's possible though.  So far, the IIR implementation in TAX3x is still the most efficient and simple method.

But your requirment is beyond just generating a sine wave, so that's difficult to realize in TAS3x.

Regards,

Susan

Susan, it´s me again.
Is there any possibility to try the polynomial approach and find out if it is enough precise?
If I can not solve this our customers would have to run long audio cables to the amp every time.

Thanks for any thoughts on that.

Thomas

Thomas,

There are many polynomial approches and all have limitations: the one you posted, for example, has to be within [-pi/4, pi/4], which can only be used to estimate small angles, not suitable for sine generator.   And since TAS3x is fixed point, that definitely added more constrains.

The only way I could think of is how to make the one we have work by sending the disable/enable and change frequency fast enough to generate the sweep signal, other than that, I run out of ideas.

Regards,

Susan