Pass 6 digit ascII from spin obj to asm ?
tonyp12
Posts: 1,951
I have never wrote any code in spin yet, I'm pretty good at pasm.
I understand when you start a new cog, you can pass one value that is an single address in hub ram.
PUB LedDisplay (text)
cognew(@asm_entry, text) 'launch assembly program in a COG
And to access it you would use something like rdlong mytext,par
You could only squeeze in four bytes (letters) in an long.
So the par would instead need to point to the first hub address of a 6 bytes/longs table?
And how do you use LedDisplay("HELLO9") to be broken up in 6 bytes/longs in spin?
not using "H","E"... as it need to support to.string(value) for temprature etc
Later it should also support a dot and then have 7 letters as a dot does not use up a digit.
I understand when you start a new cog, you can pass one value that is an single address in hub ram.
PUB LedDisplay (text)
cognew(@asm_entry, text) 'launch assembly program in a COG
And to access it you would use something like rdlong mytext,par
You could only squeeze in four bytes (letters) in an long.
So the par would instead need to point to the first hub address of a 6 bytes/longs table?
And how do you use LedDisplay("HELLO9") to be broken up in 6 bytes/longs in spin?
not using "H","E"... as it need to support to.string(value) for temprature etc
Later it should also support a dot and then have 7 letters as a dot does not use up a digit.
spin
6K
Comments
Lately I've been spending a lot of time with Tim Moore's four port serial driver. I've modified it to increase the buffers size, to set end of message flags and detect wireless tx acknowledgments.
I'm hoping of using the same starting point (Tim's driver) but make one the serial ports drive the LED display. The display wouldn't need to run faster than 80 bps and wouldn't require checking for any rx signal. It would probably end up slowing the serial driver but most of my serial devices aren't very fast.
I'm not sure if this is possible (especially for me) but it would be nice if the LED driver didn't take up a whole cog. I think it would be great if the cog could also drive a few serial lines.
The led driver needs to move on the next digit on a regulary time interval and do so at least 200 times/sec.
But if you look at driver v0.6 you see a 4000 cycle delay (will use waitcnt later)
so you could squeeze in your program there and not waste a cog.
as long you don't use waitpne etc that wait for long periods.
And I may even write a driver made in spin,
so you could squeeze in your spin code and not waste a cog.
But now back the original question.
PUB Display (text)
cognew(@asm_entry, @text) 'launch assembly program in a COG
added these lines of code
mov buffer,par
rdlong mytext,buffer
created a new spin program
OBJ
LED : "LED17"
PUB DisplayText
LED.Display("W")
And it will change the first letter H to W.
But how do I change the spin program so it will accept 6 numbers inside LED.Display(1,2,3,4,5,6)?
LED.Display("W")
I think you'll want
I think you'd be better off using bytes instead of longs. You could read one byte in at a time and place it in the appropriate place inside the cog.
I'd add an incrementing pointers "t1" and "t2".
EDIT: I think I did this wrong. I'm fixing it now. Fixed, I think. I needed the movd instructions. It's harder to use pointers in PASM.
I think that would get the six characters into the cog.
I think it would work if you left mytext as longs. I'm not sure how to deal with bytes vs longs within the cog.
In hub RAM you increment by one for each byte and by four for each long. Inside a cog you increment longs by one. I'm not sure how one increments by bytes inside the cog.
Edit: I think I've fixed it.
I tried this flashing text, but it's gets garbled when it tries to update to LUCKY7
Repeat
LED.Display("W","O","R","K","I","T")
waitcnt(15000000+cnt)
LED.Display("L","U","C","K","Y","7")
waitcnt(15000000+cnt)
add sinkpnt,#1 'next digit
I'm guessing it's the same as incrementing the source by one. Interesting.
I suppose one could add an appropriate number to increment the destination field as well. This self modifying code stuff is a trip.
if you add %1000000000 to it and that would be the same as +1 without effecting the sourcefield.
lable mov 0-0,#255
add lable,destfield
destfield long %1<<9 'declaring needed as highest number inline is 511
I think the driver should read the characters in from the hub in a similar way to many of the serial drivers.
So every time I use LED.Display in the spin cog it starts a new cog.
This works:
But how do I create a spin method of updating the text on the fly?
I guess I need to create seperate LED.Start and LED.Display
In the PASM COG you simply loop checking a memory address, and if it changes you jump to a dedicated code.
Moreover, consider a string as an array. You pass the address of the first char. If you had an array (say array[10]) you would pass to the COG the address of the array as @array[0]. Then you iteratively add 1, 2 or 4 (byte, word, long) to have the address of the next one.
With a string you pass the string address, so part of the job is done.
With a formatted string the last byte is 0, so you can check for it for ending the routine.
Massimo
Supports zero terminated text of any lenght and also space char.