Do you have a piece of code on how to do this?
But it should not be bound to the pure sine.
After all, up to 32 oscillators with different frequencies and amplitudes can work here.
Have a good read of source for Chip's Spiral Demo.
Here's a video of an early version of the spiral demo. It's updating the whole display area at that rate. And that was before Chip unrolled the Cordic calculations. We are running it at much higher resolutions now and it still runs quite smoothly.
If I were to do multiple calculations to improve the signal quality, I would have to synchronise the oscillators. From 2..30, the variation would be a maximum of 10 groups of 3 oscillators each. (e.g. piano 10 fingers with 3 sides per note).
Which brings new problems and consumes recourses.
As it stands, I can increase from 250k to 500k.
I think for 20kHz the signal is good enough.
In the object are 32 oscillators at one output.
Each can be adjusted independently in frequency and level.
The propeller works with 348Mhz, but other frequencies are possible.
When I have time I will clean the project and put it on #001.
@pic18f2550 said:
COG and DAC work but the Cordic only delivers 0h.
Good to know. Others had said they'd found things went badly before the clock slowed down on high temperature. So Cordic will be one of the areas that isn't protected by the self-limiting of the PLL that was added with revB silicon.
Well, refrigeration could be applied to the exposed pad. I'd probably go with leaving the PCB in place for good grounding and just use lots of vias for thermal transfer between the exposed pad and the chilled plate. Metallic transfer paste would be excellent interface choice for the chilled plate.
I found when testing the SD that catastrophic failure occurred just above 380MHz. All instructions started failing without using SD. COoling the P2 will increase the max freq. This max may also vary with P2 chips.
Oh, waitatn was already available for the P1?
I hadn't noticed. Probably because I've never had this situation before. I'll take a closer look.
I want to use the computing power of the Cordic more.
I want to feed the Cordic with one COG and read out the results with another. Is that possible at all?
The load would then be approx. 90% of the cycle time.😊
I am in favour of each COG getting its own cordic.👍
@pic18f2550 said:
Is it only difficult or not possible?
No, not possible with the Prop2. The reason is why it wasn't even considered a good idea to have.
Also, if allowing that, it mixes things up too much. There is a level of separation between cogs that allows a modular approach to "objects", making able to take a whole cog for itself and not be too concerned with a mix of objects by different authors.
The philosophy was a natural fit with the Prop1. Prop2 might be a tad more effort to make it work. Just the flexibility of setting the clock frequency alone will be an unwanted spanner when mixing some objects.
@pic18f2550 said:
The goal is to do 220 cordic calculations in 450 clocks.
That would require all the cogs doing a part each to have a chance. Peak calculation throughput is one per clock but as you've already seen, it's not simple to get close to one cog's potential let alone them all.
@pic18f2550 said:
I think the question can only be answered by someone who is familiar with the internal function of the P2.
A particular cog's Cordic operations are strictly tracked along the pipeline. Those results appear only to said cog. It's part of the fixed slot numbering in hub rotation mechanism.
I have to say, you're the first person to even question it! afaik
EDIT: Possibly more accurately, the Cordic doesn't have to track cog numbers through the stages but rather the cog number is inherently known by which slot number that the result pops out the end of the pipeline at.
EDIT2: So what will need tracked is what, if any, operation is required of each stage. The "if any" will be important for whether or not to overwrite the QX/QY result registers for each cog. And also for generating events.
In the optimised listing I posted above I've listed the precise number of sysclock ticks at each cordic instruction from the first QROTATE all the way to the final GETQY.
Comments
without interpolation
with interpolation
I polish the rest away with an RC combination.
Nice. Though adding more modelled data points instead would be better still.
Do you have a piece of code on how to do this?
But it should not be bound to the pure sine.
After all, up to 32 oscillators with different frequencies and amplitudes can work here.
Not me. I thought the discussion on staggered Cordic use was leading that way.
Have a good read of source for Chip's Spiral Demo.
Here's a video of an early version of the spiral demo. It's updating the whole display area at that rate. And that was before Chip unrolled the Cordic calculations. We are running it at much higher resolutions now and it still runs quite smoothly.
https://forums.parallax.com/uploads/FileUpload/83/e4983d5634ca3c0a7ab28fabdfc284.mp4
If I were to do multiple calculations to improve the signal quality, I would have to synchronise the oscillators. From 2..30, the variation would be a maximum of 10 groups of 3 oscillators each. (e.g. piano 10 fingers with 3 sides per note).
Which brings new problems and consumes recourses.
As it stands, I can increase from 250k to 500k.
I think for 20kHz the signal is good enough.
In the object are 32 oscillators at one output.
Each can be adjusted independently in frequency and level.
The propeller works with 348Mhz, but other frequencies are possible.
When I have time I will clean the project and put it on #001.
The Cordic only wants to work up to 400Mhz.
Put an ice pack on top. :P
Actually, what did happen at 400 MHz? Data corruption in GETQX/GETQY?
The propeller hardly gets warm.
The spiral demo gets warmer.
COG and DAC work but the Cordic only delivers 0h.
But this is no problem because even at 256Mhz a usable signal with 20Khz comes out.
I encountered this problem when trying to use BLDCs.
I can assure you the ice pack works alright. It wasn't just an impractical joke.
Good to know. Others had said they'd found things went badly before the clock slowed down on high temperature. So Cordic will be one of the areas that isn't protected by the self-limiting of the PLL that was added with revB silicon.
If the propeller had a better housing, it would now be water-cooled.
But in this case, it doesn't do much good.
Well, refrigeration could be applied to the exposed pad. I'd probably go with leaving the PCB in place for good grounding and just use lots of vias for thermal transfer between the exposed pad and the chilled plate. Metallic transfer paste would be excellent interface choice for the chilled plate.
I found when testing the SD that catastrophic failure occurred just above 380MHz. All instructions started failing without using SD. COoling the P2 will increase the max freq. This max may also vary with P2 chips.
Here's an earlier topic - https://forums.parallax.com/discussion/172903/maximum-stable-p2-clock-did-someone-try-this/p1
Does anyone know why this does not translate?
If I leave out the "return" everything is OK.
But I need the COGID.
It bumps into the coginit. for whatever reason.
PUB ini(psync, pstatus, sstatus, parray, sarray1, pchan1, pchan2) sync := psync stat1 := pstatus stat2 := sstatus indat := parray outdat := sarray1 chan1 := pchan1-1 chan2 := pchan2-1 return coginit(COGEXEC_NEW, @pha0, 0) + 1 {{ Phasenberechnung starten}}You need to specify that a return value is being used. eg
PUB xyz(a,b,c) : retn
...
Retn := coginit(....
OK then there is probably a change here to the P1.
var { object globals } long cog ''cog (+1) running uart code pub start(rxp, txp, mode, baud) '' Start serial driver (uses a cog, returns 1 to 8 if successful) stop '' stop if running longfill(@rxhead, 0, 4) '' clear buffer indexes longmove(@rxpin, @rxp, 3) '' copy pins and mode bitticks := clkfreq / baud '' system ticks per bit bufpntr := @rxbuffer '' hub address of rxbuffer cog := cognew(@fdsuart, @rxhead) + 1 '' start the fds uart cog return cog '' return 1..8 if started, 0 if notpub start(rxp, txp, mode, baud):xyz <---- ?
Why that does not bring an error when expanding, I do not know?
OK what learned. --> : do not forget.
File "SINE_2021_04_08.spin2" inserted in 001.
This is a simple model, which shows how to generate 32 tones with enough computing time.
Oh, waitatn was already available for the P1?
I hadn't noticed. Probably because I've never had this situation before. I'll take a closer look.
I want to use the computing power of the Cordic more.
I want to feed the Cordic with one COG and read out the results with another. Is that possible at all?
The load would then be approx. 90% of the cycle time.😊
I am in favour of each COG getting its own cordic.👍
No. There was no waitatn for P1.
Here's a better optimised version of one of your already unrolled sections:
{{ ==== 1. Sampelausschnitt und Sinus berechnen }} add ph1, fr1 ' 2 qrotate am1, ph1 ' 0 (2..9) add ph2, fr2 ' qrotate am2, ph2 ' 8 add ph3, fr3 ' qrotate am3, ph3 ' 16 add ph4, fr4 ' qrotate am4, ph4 ' 24 add ph5, fr5 ' qrotate am5, ph5 ' 32 add ph6, fr6 ' qrotate am6, ph6 ' 40 add ph7, fr7 ' qrotate am7, ph7 ' 48 add ph8, fr8 ' qrotate am8, ph8 ' 56 getqy outws ' #1 add outwn, outws ' add ph9, fr9 ' qrotate am9, ph9 ' 64 getqy outws ' #2 add outwn, outws ' add ph10, fr10 ' qrotate am10, ph10 ' 72 getqy outws ' #3 add outwn, outws ' add ph11, fr11 ' qrotate am11, ph11 ' 80 getqy outws ' #4 add outwn, outws ' add ph12, fr12 ' qrotate am12, ph12 ' 88 getqy outws ' #5 add outwn, outws ' add ph13, fr13 ' qrotate am13, ph13 ' 96 getqy outws ' #6 add outwn, outws ' add ph14, fr14 ' qrotate am14, ph14 ' 104 getqy outws ' #7 add outwn, outws ' add ph15, fr15 ' qrotate am15, ph15 ' 112 getqy outws ' #8 add outwn, outws ' add ph16, fr16 ' qrotate am16, ph16 ' 120 getqy outws ' 122 #9 add outwn, outws ' getqy outws ' 130 #10 add outwn, outws ' getqy outws ' 138 #11 add outwn, outws ' getqy outws ' 146 #12 add outwn, outws ' getqy outws ' 154 #13 add outwn, outws ' getqy outws ' 162 #14 add outwn, outws ' getqy outws ' 170 #15 add outwn, outws ' getqy outws ' 178 #16 add outwn, outws ' waitct1 'No. That would be very hard to keep the data through the cordic and the cogs in order. It's hard enough already.
Is it only difficult or not possible?
Difficult is not an argument for giving up, but rather for a PidBull.
I think the question can only be answered by someone who is familiar with the internal function of the P2.
The goal is to do 220 cordic calculations in 450 clocks.
No, not possible with the Prop2. The reason is why it wasn't even considered a good idea to have.
Also, if allowing that, it mixes things up too much. There is a level of separation between cogs that allows a modular approach to "objects", making able to take a whole cog for itself and not be too concerned with a mix of objects by different authors.
The philosophy was a natural fit with the Prop1. Prop2 might be a tad more effort to make it work. Just the flexibility of setting the clock frequency alone will be an unwanted spanner when mixing some objects.
That would require all the cogs doing a part each to have a chance. Peak calculation throughput is one per clock but as you've already seen, it's not simple to get close to one cog's potential let alone them all.
A particular cog's Cordic operations are strictly tracked along the pipeline. Those results appear only to said cog. It's part of the fixed slot numbering in hub rotation mechanism.
I have to say, you're the first person to even question it! afaik
EDIT: Possibly more accurately, the Cordic doesn't have to track cog numbers through the stages but rather the cog number is inherently known by which slot number that the result pops out the end of the pipeline at.
EDIT2: So what will need tracked is what, if any, operation is required of each stage. The "if any" will be important for whether or not to overwrite the QX/QY result registers for each cog. And also for generating events.
Ok, I thought that this would not be easy.
The Cordic is certainly fed via an 8 to 1 multiplexer.
Once every 8 COGs is 8 steps plus one if the slot is missed. Since the COG has to wait here, we would have a synchronisation of COG and Cordic.
Now it would be nice to know how many internal clocks the Cordic needs for the operation.
Using this data, one could determine how to read the result of the Cordic with 2 clocks for getqy.
The clocks between qrotate and getqy give information whether I can feed the Cordic from the same COG.
Translated with www.DeepL.com/Translator (free version)
In the optimised listing I posted above I've listed the precise number of sysclock ticks at each cordic instruction from the first QROTATE all the way to the final GETQY.
It takes 58 clocks for each result.
If a slot is missed, it's another 8 clocks to the next.