Arrays, Spin, PASM??? Something funny going on

Harley

I have a problem I've been chasing for too long.

VAR 'value' is an array used to hold 128 A/D samples, and two longs up front at value[noparse][[/noparse] 0 ] and value[noparse][[/noparse] 1 ]. Problem is Spin can initialize value[noparse][[/noparse] 1 ], but PASM A2D only sees ZEROs there via PASD.

If I load a constant in Nsamp, write it to PAR+4 that writes OK and via TV_text displays correctly. Initially at 80 changes to 26. I need to adjust this value (via a keypad) in use. I've used the constant initially to bring up A2D. Now am surprised I cannot make this work as planned with a variable .

The A2D array values are properly being scaled and displayed on a graphic LCD via ST7920. Photo of the simulated pulse from D2A.

What all might be wrong with this? Stumping me to death.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Mike Green

Step 1 is to rewrite your explanation so even I can understand it.

I get 128 A/D samples, but I don't understand the bit about value[noparse][[/noparse] 0 ] and value[noparse][[/noparse] 1 ].

I don't get the Nsamp thing or about adjusting with a keypad. Are you wanting to set the number of samples via a keypad?

What works and what doesn't work?

MagIO2

      TVy := 12 - ((LONG[noparse][[/noparse][color=red]value[/color]][noparse][[/noparse]TVx])/150000000 )'/87382 

don't forget the @

  Bpm := 60 * 80_000_000/(LONG[noparse][[/noparse]value][noparse][[/noparse]0])              ' form 'beats per minute' value

again @ AND ... 60*80_000_000 will exceed 32 bit, so you don't get what you expect.

Post Edited (MagIO2) : 2/15/2010 10:13:42 PM GMT

Harley

@ Mike Green, apologies, it wasn't written better. Like from the reader's needs. First off, I should have better explained VAR 'value' which holds 128 values from the A/D following the first two locations; value[noparse][[/noparse]0] holds a measured Period value from A2D, and value holds a value from Spin/keypad, the variable in A2D named 'Nsamp'. The A2D values are located from value[noparse][[/noparse] 2 ]..value[noparse][[/noparse] 129 ].

Funny thing, a constant loaded into Nsamp works, but trying to 'rdlong Nsamp,_ptr' at the PAR+4 location only loads all zeros. In PASD the PAR+4 value doesn't get updated when the keypad increments/decrements the value; in fact doesn't even get initialized from a Spin 'value := 80'. This is the part that doesn't work. The value at 'value[noparse][[/noparse] 1 ] doesn't get initialized from Spin as viewed in PASD debugger. Shouldn't a PASM array get initialized via Spin? At least I see it using TV_text and on a DVD monitor, the output can be incremented/decremented via the keypad. So why wouldn't the value at value which should also be PAR+4 location be seen by this A2D set of instructions?

@ MagIO2, I will attend to the '@' and 60 ° 80_000_000 details later. Thank you for the 'good detective' eyes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Graham Stabler

try putting the value := 80 before starting the assembly cog

Harley

Graham said...

try putting the value := 80 before starting the assembly cog

It works, but don't understand WHY. Any explanation why initializing a PASM variable before or after a cognew makes a difference?

Anyway, it worked beautifully. Now can expand or contract the image to effectively view several pulses or the magnifie first detected pulse. Presently I'm setting a threshold about 1/2 maximum pulse displayable. And when triggered, move that left a number of samples back to place the pulse at the left of the screen. Sort of making it 'synchronize' to the first event over the threshold.

Now I can move on to other details in this area. Maybe even add a SD card. Ah, the snowballing begins to take effect...

Thanks Graham.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

kuroneko

Harley said...
It works, but don't understand WHY. Any explanation why initializing a PASM variable before or after a cognew makes a difference?

cognew/coginit will only kick off cog initialisation. The cog itself is loaded/initialised in the background (takes about 8K cycles). So basically the cog is still being initialised when you execute the next SPIN instruction(s). In your case the PASM code for fetching value[noparse][[/noparse] 1] happens before you initialise its value from SPIN.

Edit: sort out before/after

Post Edited (kuroneko) : 2/16/2010 1:04:31 AM GMT

Graham Stabler

I think his problem only makes sense if the assembly code had checked the state of value before the spin code got a chance to initialise it (because it was read as 0 not 80). He does quite a bit of stuff between the coginit and the value:= 80, that delay might be enough for the cog to initialise?

So if I am right, you set the cog initialising then set some other cogs initialising and did some other set up stuff, in the mean time the asm cog started running and read value as 0. Only later would it then get updated to 80 by the spin.

Graham

Harley

Thanks for the suggestions and info, everyone.

I seem to recall some thread on boot-up timings, maybe a year ago or so. Anyone recall that thread? I'm curious as to WHEN initialization of variables can occur?

The reason I ask is I ran into the above 'strange' situation with Spin initializing a variable, value := 80, in an array written by both Spin and and read by PASM code. But after the cogs are running, this cog's array only had all zeros in Hub RAM. The suggestion, from Graham Stabler, was to initialize prior to that cog's cognew, which worked. Probably that writes to Hub RAM, which later is read once the cog begins to run.

I suppose that value of zero, used by a djnz counter, then had to do 2^32 loops x 128 times before it could return and read value for the next major loop. I calculate a time of over 2 hours! So I didn't wait long enough to see it working. Sure consumed lots of wasted time trying to figure out where the problem was.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Mike Green

As other have said, COGNEW/COGINIT only initiates the initialization of a cog which involves the copying of 512 longs of data from hub memory to a cog memory.· This copies one long every 16 clock cycles which takes roughly 100us with an 80MHz system clock.· There's a little more time needed for other initialization, but this copying takes most of the time.· The COGINIT instruction itself only takes a couple of hundred ns to execute.

If you initialize some of the memory to be copied prior to the COGINIT, all will be well.· If you wait until after the COGINIT, the hub controller may have copied the long already.· The other choice is to wait until after the cog has started running.· In that case, you'll need initialization·code in the cog to copy the information from a shared area into the appropriate variables in the cog's memory.· There's no way for one cog to copy information to another cog's memory.

Harley

Mike Green said...

As other have said, COGNEW/COGINIT only initiates the initialization of a cog which involves the copying of 512 longs of data from hub memory to a cog memory. This copies one long every 16 clock cycles which takes roughly 100us with an 80MHz system clock. There's a little more time needed for other initialization, but this copying takes most of the time. The COGINIT instruction itself only takes a couple of hundred ns to execute.

If you initialize some of the memory to be copied prior to the COGINIT, all will be well. If you wait until after the COGINIT, the hub controller may have copied the long already. The other choice is to wait until after the cog has started running. In that case, you'll need initialization code in the cog to copy the information from a shared area into the appropriate variables in the cog's memory. There's no way for one cog to copy information to another cog's memory.

Thanks, Mike, for the clarification on the initialization timing. Does Spin move on to next instruction following a COGNEW before the 512 longs are finished moved to cog memory, running in parallel?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

MagIO2

Yes, that's what Mike tries to tell you.