@"Christof Eb." said:
Hi,
perhaps this is again my not-knowing...
As far as I know, you can only use the streamer for data movement, if your code is executing from cog or lut memory. I don't think, that inline asm is loaded into cog memory?
Streamer and Fifo aren't entirely the same thing. The RDFAST instruction starts up the Fifo independent of the Streamer. It allows other Cog instructions like RFLONG access to the Fifo's FIFO.
Inline assembly is by default loaded into cogRAM just before it is executed. So not entirely inline as such. This is quite important when wanting to use the Fifo within the "inline" Pasm2 code. The Spin2 interpreter uses the Fifo itself. And Flexspin executes natively as hubexec which also requires the Fifo.
The "counter := @BHwindow" worked, @evanh , thank you. Attached is a test program to be run in debug mode for the scope displays - a blackman harris window is applied to a sine wave. The window is applied to a polar signal, as being easier to do when preloading the cordic engine. My attempt to do it on a cartesian signal didn't produce the correct result - I was not getting all the correct values out of the cordic, due to twice the number of multiplies, the 8 cycle pattern was broken. I may return to that - I expect it needs pacing to 16 cycles.
@"Christof Eb." , my inline assembly methods use the "org ... end" form which means the code will be loaded into cog ram before execution. Had I used " orgh ... end", then the code would execute from hub ram. (See "In-line PASM Code" section of the Spin2 manual) In the changes section it also states:-
PUB/PRI methods now support ORGH (hub) inline PASM code, in addition to ORG (cog) inline PASM code.
○ Like ORG, ORGH loads the first 16 local long variables from hub RAM into cog registers, executes
the inline code, and then updates the registers back to hub RAM.
○ Unlike ORG inline code, ORGH inline code does not load code into cog registers $000..$11F, but can
be up to $FFFF instructions long, since it stays and executes in hub RAM.
○ ORGH allows inline PASM code without interfering with the $000..$11F cog register space, So, those
cog registers can be used entirely for stay-resident code, like interrupt service routines or frequentlycalled fast PASM routines.
As you can see in the window demo here, both the "sine" and the "polwin" method in the dsp library use the FIFO successfully
Streamer and Fifo aren't entirely the same thing. The RDFAST instruction starts up the Fifo independent of the Streamer. It allows other Cog instructions like RFLONG access to the Fifo's FIFO.
Does this mean, that when DDS from LUT to DAC is used, the STREAMER is used but not the FIFO and therefore code can in parallel be executed from HUB?
Inline assembly is by default loaded into cogRAM just before it is executed. So not entirely inline as such. This is quite important when wanting to use the Fifo within the "inline" Pasm2 code. The Spin2 interpreter uses the Fifo itself. And Flexspin executes natively as hubexec which also requires the Fifo.
OK, sorry, I was not aware, that SPIN2 loads inline asm into cog ram.
@"Christof Eb." said:
Does this mean, that when DDS from LUT to DAC is used, the STREAMER is used but not the FIFO and therefore code can in parallel be executed from HUB?
I spotted the scope plot of the windowing method didn't look quite right. The whole idea is for the waveform to start at 0 and end at 0. The scope trace above doesn't look like it does that. However, it was only the two traces being set on AUTO scaling. When I defined the max and min plot scale, then the two traces did show zero ends:-
The production of the window in the DAT section was not laboriously typed in. It was a matter of:-
1. Producing the 1024 sample window in a spreadsheet
2. In another column, scaling up the window ( samples in the range 0-1) to the point where the first sample was just under 1. The window happened to peak at 16384
3. In another column, converting that scaled window to integers
4. In a column to the left of the integers, putting 'word' in every row (or 'long' or 'byte' or whatever you need )
5. These two columns can then be directly copied and pasted into the editor in Pnut or Spin Tools
Comments
Streamer and Fifo aren't entirely the same thing. The RDFAST instruction starts up the Fifo independent of the Streamer. It allows other Cog instructions like RFLONG access to the Fifo's FIFO.
Inline assembly is by default loaded into cogRAM just before it is executed. So not entirely inline as such. This is quite important when wanting to use the Fifo within the "inline" Pasm2 code. The Spin2 interpreter uses the Fifo itself. And Flexspin executes natively as hubexec which also requires the Fifo.
The "counter := @BHwindow" worked, @evanh , thank you. Attached is a test program to be run in debug mode for the scope displays - a blackman harris window is applied to a sine wave. The window is applied to a polar signal, as being easier to do when preloading the cordic engine. My attempt to do it on a cartesian signal didn't produce the correct result - I was not getting all the correct values out of the cordic, due to twice the number of multiplies, the 8 cycle pattern was broken. I may return to that - I expect it needs pacing to 16 cycles.
@"Christof Eb." , my inline assembly methods use the "org ... end" form which means the code will be loaded into cog ram before execution. Had I used " orgh ... end", then the code would execute from hub ram. (See "In-line PASM Code" section of the Spin2 manual) In the changes section it also states:-
PUB/PRI methods now support ORGH (hub) inline PASM code, in addition to ORG (cog) inline PASM code.
○ Like ORG, ORGH loads the first 16 local long variables from hub RAM into cog registers, executes
the inline code, and then updates the registers back to hub RAM.
○ Unlike ORG inline code, ORGH inline code does not load code into cog registers $000..$11F, but can
be up to $FFFF instructions long, since it stays and executes in hub RAM.
○ ORGH allows inline PASM code without interfering with the $000..$11F cog register space, So, those
cog registers can be used entirely for stay-resident code, like interrupt service routines or frequentlycalled fast PASM routines.
As you can see in the window demo here, both the "sine" and the "polwin" method in the dsp library use the FIFO successfully
LOL, I failed Spin's
:=syntax too. I get that wrong every time I start a new Spin project. First compile has me fixing them.Does this mean, that when DDS from LUT to DAC is used, the STREAMER is used but not the FIFO and therefore code can in parallel be executed from HUB?
OK, sorry, I was not aware, that SPIN2 loads inline asm into cog ram.
Yep.
I spotted the scope plot of the windowing method didn't look quite right. The whole idea is for the waveform to start at 0 and end at 0. The scope trace above doesn't look like it does that. However, it was only the two traces being set on AUTO scaling. When I defined the max and min plot scale, then the two traces did show zero ends:-
The production of the window in the DAT section was not laboriously typed in. It was a matter of:-
1. Producing the 1024 sample window in a spreadsheet
2. In another column, scaling up the window ( samples in the range 0-1) to the point where the first sample was just under 1. The window happened to peak at 16384
3. In another column, converting that scaled window to integers
4. In a column to the left of the integers, putting 'word' in every row (or 'long' or 'byte' or whatever you need )
5. These two columns can then be directly copied and pasted into the editor in Pnut or Spin Tools