When I use the ? symbol as a suffix I hope by convention to mostly imply that this returns with a yes/no true/false flag. So LOW? will test a pin and return with a true if high or false if low.
Shouldn't LOW? return a true if low, and a false if high? Apologies, if that's what you meant
When I use the ? symbol as a suffix I hope by convention to mostly imply that this returns with a yes/no true/false flag. So LOW? will test a pin and return with a true if high or false if low.
Shouldn't LOW? return a true if low, and a false if high? Apologies, if that's what you meant
Hmmm.... I forgot that I have only just defined HIGH? and LOW? the other day as part of the counter modes.
I think the convention of a '?' suffix indicating a binary test is a good one. If the test is to return a number rather than simply true/false, maybe add a '#' e.g. HIGH#?
Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
Same goes for FREQ@ as well.
Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
Same goes for FREQ@ as well.
For my $0.02 worth, this wouldd be my preference. When do you think we will see these changes in Extend?
Jim
Typically I use a @ which normally returns the contents of a variable so maybe HIGH@ and LOW@ since it also conforms with a source parameter, in this case a pin.
Same goes for FREQ@ as well.
For my $0.02 worth, this wouldd be my preference. When do you think we will see these changes in Extend?
Jim
That's already been changed but there have been many times where I am testing out a new function and shortly thereafter I rename and/or redo it. For instance, the DETECT words I initially did a bit differently but decided to lock in a "prefix" to the DETECT sequence with POS and NEG and add in modifiers EDGE and FB since it reads so much better.
OK
I have to re-install Extend on my QS board as I have some how managed to trash it. The clock will load once and display the tine at the start up but no repeats and the color is missing from the post boot Display on the console.
Jim
Peter,
What are the specific words to load PHSA (PHSB) and FRQA(FRQB) to the counters. I want my rain guage counter for example to increment PHSA by a constant value that allows for reading the output in .01 inch increments of rain without the need for any complicated math, other than decimal place management. Probably will be able to do the same with the wind velocity once the anamometer is calibrated. Is it as simple as PHSA! FRQA! and PHSA@, PHSB@? I will probably be using the EDGE detection feature.
Jim
Peter,
What are the specific words to load PHSA (PHSB) and FRQA(FRQB) to the counters. I want my rain guage counter for example to increment PHSA by a constant value that allows for reading the output in .01 inch increments of rain without the need for any complicated math, other than decimal place management. Probably will be able to do the same with the wind velocity once the anamometer is calibrated. Is it as simple as PHSA! FRQA! and PHSA@, PHSB@? I will probably be using the EDGE detection feature.
Jim
Just use POS EDGE DETECT to set it up but change the FRQx value directly with FRQ. All the SFRs are named as constants such as PHSA PHSB etc so you just need to use COG@ or COG! instead of @ and ! so it addresses the COG memory.
Now you may have noticed that I said FRQ and not FRQA or FRQB and that is because there this word is part of the counter words that allow an A or a B counter to be selected and operated with a common set of words rather than duplicating code. So strictly speaking if you want to use both counters you need to select them with an A or a B word as in A POS EDGE DETECT. You can read PHSA and PHSB with this method too with COUNT@ which will read the PHSx counter that has been selected. Both A and B words are simply selectors and don't need to be reselected each time.
If you are using CTRB and also want to change the FRQx value to 12, just do it like this.
B POS EDGE DETECT 12 FRQ
BTW, scaled integer maths are easy to do in Forth.
I've knocked together some code to drive a 4-quadrant X/Y piezoelectric scanner. I've checked it with a 'scope and it works, but since I'm a Tachyon noob, I would be interested in comments on how I could make it tidier/more efficient.
Thanks in advance!
{
Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
DAC A = -X
DAC B = +X
DAC C = -Y
DAC D = +Y
Horizontal (X) waveforms are triangular
}
--- LTC2754 Commands
$00300000 := LTC2754_DAC_A
$00320000 := LTC2754_DAC_B
$00340000 := LTC2754_DAC_C
$00360000 := LTC2754_DAC_D
$00500000 := LTC2754_UPDATE
&13.14.12.11 SPIPINS
--- scan origin
word xorg
word yorg
--- number of scanline points
word xpts
word ypts
--- DAC increments between scanline points
word xinc
word yinc
--- -X,Y scan values: subtract from $FFFF for +X,Y
word xval
word yval
--- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
word xinctmp
--- delay in ms between scan points
word xypause
: XORG xorg W! ;
: YORG yorg W! ;
: XPTS xpts W! ;
: YPTS ypts W! ;
: XINC xinc W! ;
: YINC yinc W! ;
: XYPAUSE xypause W! ;
--- set scan origin and copy xinc
: SCANINIT xorg W@ xval W! yorg W@ yval W! xinc W@ xinctmp W! ;
--- Writing to LTC2754 in 24-bit mode, MSB first
: LTC2754! ( cmd -- ) SPIWR32 DROP 13 HIGH ;
--- calc -X,Y from +X,Y and write all 4 values to the LTC2754
: XYOUT
xval W@ $FFFF xval W@ - yval W@ $FFFF yval W@ -
LTC2754_DAC_A + LTC2754!
LTC2754_DAC_B + LTC2754!
LTC2754_DAC_C + LTC2754!
LTC2754_DAC_D + LTC2754!
LTC2754_UPDATE LTC2754! ;
--- do a single complete scan
: SCAN
SCANINIT
ypts W@
FOR
xpts W@
--- output X scanline
FOR XYOUT xinctmp W@ xval W+! xypause W@ ms NEXT
--- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
xval W@ xinctmp W@ - xval W!
--- negate xinctmp for next X scanline
xinctmp W@ -1 * xinctmp W!
--- increment Y
yinc W@ yval W+!
NEXT ;
--- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points
$8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1 XYPAUSE SCAN
I've knocked together some code to drive a 4-quadrant X/Y piezoelectric scanner. I've checked it with a 'scope and it works, but since I'm a Tachyon noob, I would be interested in comments on how I could make it tidier/more efficient.
Thanks in advance!
Looks good, not much to improve upon but here's my take on it nonetheless and also by using longs we can store and handle signed values more easily. I noticed that you were subtracting values from $FFFF but that would not be the same as negating the value as it would be off by one unless that was your intention.
TACHYON
{
Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
DAC A = -X
DAC B = +X
DAC C = -Y
DAC D = +Y
Horizontal (X) waveforms are triangular
}
( use longs for signed values )
--- scan origin
long xorg
long yorg
--- DAC increments between scanline points
long xinc
long yinc
--- -X,Y scan values: subtract from $FFFF for +X,Y
long xval
long yval
--- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
long xinctmp
--- number of scanline points
long xpts
long ypts
--- delay in ms between scan points
long xypause
: XORG xorg ! ;
: YORG yorg ! ;
: XPTS xpts ! ;
: YPTS ypts ! ;
: XINC xinc ! ;
: YINC yinc ! ;
: XYPAUSE xypause ! ;
--- LTC2754 DAC Bipolar –10V to 10V
: DAC! ( val chan -- ) $18 OR 17 << SWAP $FFFF AND +
--- Writing to LTC2754 in 24-bit mode, MSB first with dummy byte for 32-bits
: LTC2754! ( cmd -- ) SPIWR32 DROP SPICE ;
: VAL! ( val chan -- ) OVER NEGATE OVER DAC! 1+ DAC! ;
--- calc -X,Y from +X,Y and write all 4 values to the LTC2754
: XYOUT yval @ VAL! xval @ 2 VAL! $00500000 LTC2754! ;
--- do a single complete scan
: SCAN
&13.14.12.11 SPIPINS --- init SPI pins (works if rebooted)
xorg xval 12 CMOVE --- SCANINIT
ypts @
FOR
xpts @
--- output X scanline
FOR XYOUT xinctmp @ xval +! xypause @ us NEXT
--- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
xinctmp @ NEGATE xval +!
--- negate xinctmp for next X scanline
xinctmp @ NEGATE xinctmp !
--- increment Y
yinc @ yval +!
NEXT ;
( SHORTCUTS )
: CENTER -32768[s][/s]
: XYORG DUP XORG YORG ;
: XYINC DUP XINC YINC ;
: FINE 20
: XYPTS DUP XPTS YPTS ;
: FAST 1,0000 XYPAUSE ;
: SLOW 5,0000 XYPAUSE ;
END
?BACKUP
--- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points
\ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN
CENTER FINE 1000 XYINC FAST SCAN
EDIT: I was really tired last night and made some mistakes so I've fixed them up now.
So now after breakfast I wrote a specialized LTC2754 module that simplifies the code so that XYOUT now takes 53.6us. It also auto-updates after you write to the last channel.
Thanks very much for that Peter, that's a lot more readable. Calculating the DAC words cleans the code up nicely, and the block copy to initialise variables for SCANINIT is a good idea too.
Thanks very much for that Peter, that's a lot more readable. Calculating the DAC words cleans the code up nicely, and the block copy to initialise variables for SCANINIT is a good idea too.
Thanks, this is the other one where I have updated the kernel with an LTC2754 module that is twice as fast. Untested and certainly some bugs but basically ok.
TACHYON
{
Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner
Waveform outputs are via an LTC2754-16 SPI 4-channel DAC:
DAC A = -X
DAC B = +X
DAC C = -Y
DAC D = +Y
Horizontal (X) waveforms are triangular
-2 version uses LTC2754 runmod and executes XYOUT in 53.6us
}
( use longs for signed values )
--- scan origin
long xorg
long yorg
--- DAC increments between scanline points
long xinc
long yinc
--- -X,Y scan values: subtract from $FFFF for +X,Y
long xval
long yval
--- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan
long xinctmp
--- number of scanline points
long xpts
long ypts
--- delay in ms between scan points
long xypause
: XORG xorg ! ;
: YORG yorg ! ;
: XPTS xpts ! ;
: YPTS ypts ! ;
: XINC xinc ! ;
: YINC yinc ! ;
: XYPAUSE xypause ! ;
: VAL! ( val chan -- ) OVER NEGATE OVER RUNMOD 1+ RUNMOD ;
--- calc -X,Y from +X,Y and write all 4 values to the LTC2754 - 53.6us
: XYOUT yval @ 0 VAL! xval @ 2 VAL! ;
--- do a single complete scan
: SCAN
&13.14.12.11 MODPINS [LTC2754] --- init LTC2754 MODULE
xorg xval 12 CMOVE --- SCANINIT
ypts @
FOR
xpts @
--- output X scanline
FOR XYOUT xinctmp @ xval +! xypause @ us NEXT
--- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one
xinctmp @ NEGATE xval +!
--- negate xinctmp for next X scanline
xinctmp @ NEGATE xinctmp !
--- increment Y
yinc @ yval +!
NEXT ;
( SHORTCUTS )
: CENTER -32768
: XYORG DUP XORG YORG ;
: XYINC DUP XINC YINC ;
: FINE 20
: XYPTS DUP XPTS YPTS ;
: FAST 1,0000 XYPAUSE ;
: SLOW 5,0000 XYPAUSE ;
END
?BACKUP
--- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points
\ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN
CENTER FINE 1000 XYINC FAST SCAN
I have got the first version going (LAP XYOUT LAP .LAP = 90.4 us at 100 MHz)
I'm having problems with the 2nd version that uses the new module - beyond the CE line going high, I can't see any further SPI bus activity on the scope.
If I put XYOUT into an infinite loop (BEGIN XYOUT 1 ms AGAIN) and probe the SPI lines, there's nothing going on. XYOUT with RUNMOD is taking 42.88 us at 100 MHz.
I'm a pasm noob too, but I've written assembler on other architectures and I can follow the source of the module, makes sense so far. Even if it has bugs though, I would have expected to see, for example, the CE line going up and down.
Great that you tried it. I see the problem with the runmod, it is referring to the standard SPI masks, not the runmod masks. Easy way around it is to use SPIPINS but I will fix it up in the meantime and test it out.
Well, it would have been rude not to try it after you went to the trouble of writing it And it's a >50% performance improvement, which is a big win.
SPIPINS did the trick. Could you explain SPIPINS vs MODPINS?
from EXTEND.fth
1 == @SCK
@SCK 1 + == @MOSI
@SCK 2 + == @MISO
@SCK 3 + == @CE
@SCK 4 + == @CNT
15 == @SCL
10 == @SPISCK
\ pri MASK? ( n -- mask ) >B DUP 32 U< IF MASK ELSE DROP 0 THEN ;
\ pri MASK? ( n -- mask ) >B DUP 5 >> IF DROP 0 ELSE MASK THEN ;
--- Set the SPI pins using a long as 4 octets = &ce.miso.mosi.clk as this allows passing a single long
pub SPIPINS ( &ce.miso.mosi.clk --- ) ( 20us )
@SPISCK
pub SETPINS ( &pins dst -- ) ( ~190us)
1!
DUP MASK L 1@ COG! 8>> 1++
DUP MASK L 1@ COG! 8>> 1++
DUP MASK F 1@ COG! 8>> 1++
MASK H 1@ COG!
;
pub MODPINS @SCK SETPINS ;
there are two sets of SPI pin descriptions one for the internal SPI functions and a separate one for the runm@sckam Internal is at COG address 1 = @SCK other is at COG address 10 = @SPISCK
So
SPIPINS is really @SPISCK SETPINS
MODPINS @SCK SETPINS
SPIPINS & MODPINS both call SETPINS but with different destination mask addresses. So MODPINS is for the RUNMODs and SPIPINS for the SPI instructions. I have code that uses both at the same time. What I'd like to do is find an easy way to add modules, even if we do compile with the Prop tool, much like I create the ROMs too. Ideally I'd have an inline assembler in Tachyon and although I have tackled this method before it doesn't seem practical to tie up all that memory just for an assembler as it needs even more dictionary and symbol memory than code memory just to support the assembler itself. The whole reason for Tachyon is to provide the on-chip support infrastructure and resources for applications, so it's usually a good idea to have some memory left over
EDIT: I see that there is a command 9 that writes DACn and updates all so that could be used in place of a separate command to update. I've updated the kernel accordingly, I will check the timing now.
BTW, I would have written it anyway just for the exercise but I'm not used to anyone actually trying it!
OK - Just tested it. Looks good with using a cmd 9 for channel 3 to update all at the same time. Saves one more write operation.
Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.
Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.
Looks like that may have been deprecated in 4.7 even but seems this is the section?
PRIVATE
16 longs locals
locals 4 + == @x2
locals 8 + == @x3
locals 12 + == @x4
pri @X 4* locals + ;
pub X1 locals @ ;
pub X2 @x2 @ ;
pub X3 @x3 @ ;
pub X4 @x4 @ ;
--- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
pub LOCAL ( <data> n -- )
DUP 4* ( <data> n bytes )
locals 2DUP + ROT <CMOVE
FOR I @X ! NEXT
;
--- pop and release emove n elements from locals, of no longer used )
pub RELEASE ( n -- ) DUP @X locals ROT 4* $40 SWAP - CMOVE ;
You could just paste it in with the slight change of == to := but I never really used locals like this so I think you shouldn't really need it.
Hello Peter, moving from V4 to V5 we ran into problems using the UART. The word .UART prints the uart settings to console and uses the word X1. This word was defined in EXTEND of V4 and is no longer available in EXTEND of V5.
Hi Werner
this ode I find in EXTEND (as comment)
It implements a stack of local variables which sometimes come convenient, but not really necessary.
If you need it, just cut & paste it.
btw. I could not find .UART
From which file did you load it?
Probably you can just modify .UART to do without the X1.. local variables
{
PRIVATE
16 longs locals
locals 4 + == @x2
locals 8 + == @x3
locals 12 + == @x4
pri @X 4* locals + ;
pub X1 locals @ ;
pub X2 @x2 @ ;
pub X3 @x3 @ ;
pub X4 @x4 @ ;
--- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
pub LOCAL ( <data> n -- )
DUP 4* ( <data> n bytes )
locals 2DUP + ROT <CMOVE
FOR I @X ! NEXT
;
--- pop and release emove n elements from locals, of no longer used )
pub RELEASE ( n -- ) DUP @X locals ROT 4* $40 SWAP - CMOVE ;
\ locals $40 ERASE \ Clean out the locals (easier for debugging)
}
the problem morphed a little. We wanted to have .UART1 to see the pointers of the communication buffer between Tachyon and the assembler UART-COG. Since 4.5 ROMS has changed as the code was in the kernel, now there is a separate SPIN-ASM file, which is compiled and the binary is converted to INTEL HEX with help of "bin2hex.py", (for convenience renamed to bh.py by pj) We use the SAVEROM word to place the hex into memory (Start Address $C01C, 468 Bytes). Next we start a COG:
uart1 6 " UART " LOADCOG
We can not check, if this was successful. A communication is not possible, when we output to the UART: UART> ." 8charact" the sendbufferpointer show 7, but the uart pointer stays at 0, so obviosly the uart doesn't work properly.
Is there an easy way to dump eeprom to check, if the ROM code is stores properly?
Symptoms: we remember, that LOADCOG answered with address values. Now we only get an "ok". Making some experiments with misspelled roms names also resulted in LOADCOG ok, and no other output.
It looks as if the ROM is not found by FINDROM as in the LOADCOGS word OVER .W DUP .W should print addresses!
LOADROM is insensitive to line endings etc, it just looks for the : that marks a hex line and continues until it reaches the last line which has the hex end of load command and count of zero (iirc). In that case it reports the size of the load. You still need some kind of line delay and the line delay depends upon whether it sees an end of line, usually a CR so make sure that is happening. I will see under what conditions i can make it fail.
Btw, EE modifies the dump word temporarily to use eeprom after which it reverts back to hub ram. But all the dump words such as DUMPW DUMPL DUMPA DUMPAW DUMPC etc use the selected memory method. Other dump memory modifiers are RTC, SD, FS, SF, WIZ etc
Using the correct stack values to start a cog, the LOADCOG seems to work, as the FINDROM dumps address values.
We start the cog with the UART.
" UART " 4 uart1 LOADCOG
We get the right start address and length reported.
If we change the write pointer value, the expectation is that the UART follows with the read pointer, what doesn't happen.
So our impression is that the parameters are not transfered to the UART correctly, so the UART doesn't see the write pointer.
In a next step we made a simple pin toggle program as ROM without parameters. This program, when loaded with a spin frame stand alone was functional. But the ASM part as ROM loaded by LOADCOG didn't work. LOADCOG showed name and addresses correctly (plausible) and even the cog# as an response on cognew was correct.
If I only had time... as Tachyon is so powerfull and I only have a little glue, going down from a LOADCOG needed to extent to kernel I end up to see LMM which I should have analyzed for years.... It definitely is a pity, that FORTH is not the first choice when learning to program. The world would become more simple and even a low grader could gain success. ;-(
There is one sympton: at reboot EASYNET is started and running. The STACK ends up in Level 2: .S Data Stack (2) $0000.51DA - 20954 $0000.51CE - 20942 ok.
I had expected the stack to be empty.
@ErNa - I will have a look today to see what's happening but it would be a lot easier if you could at least send me a copy of your code and at the very least I should be able to get it going and perhaps offer a pointers. Most of the problems in learning something "different", is well, because it is different and thinking in one while trying to do in the other does not work as well.
Forth is very "unstructured" but flexible and extensible and it is up to the user to define the structure they need for that application. The trouble is that many try to "program" without thinking about and creating a structure to build on, and it looks a mess and can easily crumble into one big mess. Once the structure is in place such as thinking about the "division of labor" and how they work in together then each section can be clearly seen, coded, and tested. So even though we might code bottom up we still do so with a top down view in mind.
Thanks Peter, we will drill down a little more, I will check this stack level behavior, as I think, after booting the system the stack level should be 0. Maybe the problem finds the roots there. In V4 we had this running but as some forumistas now engage in V5 and as P2 is near, I believe V5 will be final, become stable and still it is the cheapest way to start with learning forth and so documentation will be made. That allows for a less steep learning curve.
Comments
Shouldn't LOW? return a true if low, and a false if high? Apologies, if that's what you meant
Hmmm.... I forgot that I have only just defined HIGH? and LOW? the other day as part of the counter modes. Perhaps I should choose better names for these functions but in this case the ? signifies a measurement of some kind.
Same goes for FREQ@ as well.
Jim
That's already been changed but there have been many times where I am testing out a new function and shortly thereafter I rename and/or redo it. For instance, the DETECT words I initially did a bit differently but decided to lock in a "prefix" to the DETECT sequence with POS and NEG and add in modifiers EDGE and FB since it reads so much better.
I have to re-install Extend on my QS board as I have some how managed to trash it. The clock will load once and display the tine at the start up but no repeats and the color is missing from the post boot Display on the console.
Jim
What are the specific words to load PHSA (PHSB) and FRQA(FRQB) to the counters. I want my rain guage counter for example to increment PHSA by a constant value that allows for reading the output in .01 inch increments of rain without the need for any complicated math, other than decimal place management. Probably will be able to do the same with the wind velocity once the anamometer is calibrated. Is it as simple as PHSA! FRQA! and PHSA@, PHSB@? I will probably be using the EDGE detection feature.
Jim
Just use POS EDGE DETECT to set it up but change the FRQx value directly with FRQ. All the SFRs are named as constants such as PHSA PHSB etc so you just need to use COG@ or COG! instead of @ and ! so it addresses the COG memory.
Now you may have noticed that I said FRQ and not FRQA or FRQB and that is because there this word is part of the counter words that allow an A or a B counter to be selected and operated with a common set of words rather than duplicating code. So strictly speaking if you want to use both counters you need to select them with an A or a B word as in A POS EDGE DETECT. You can read PHSA and PHSB with this method too with COUNT@ which will read the PHSx counter that has been selected. Both A and B words are simply selectors and don't need to be reselected each time.
If you are using CTRB and also want to change the FRQx value to 12, just do it like this.
BTW, scaled integer maths are easy to do in Forth.
I've knocked together some code to drive a 4-quadrant X/Y piezoelectric scanner. I've checked it with a 'scope and it works, but since I'm a Tachyon noob, I would be interested in comments on how I could make it tidier/more efficient.
Thanks in advance!
{ Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner Waveform outputs are via an LTC2754-16 SPI 4-channel DAC: DAC A = -X DAC B = +X DAC C = -Y DAC D = +Y Horizontal (X) waveforms are triangular } --- LTC2754 Commands $00300000 := LTC2754_DAC_A $00320000 := LTC2754_DAC_B $00340000 := LTC2754_DAC_C $00360000 := LTC2754_DAC_D $00500000 := LTC2754_UPDATE &13.14.12.11 SPIPINS --- scan origin word xorg word yorg --- number of scanline points word xpts word ypts --- DAC increments between scanline points word xinc word yinc --- -X,Y scan values: subtract from $FFFF for +X,Y word xval word yval --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan word xinctmp --- delay in ms between scan points word xypause : XORG xorg W! ; : YORG yorg W! ; : XPTS xpts W! ; : YPTS ypts W! ; : XINC xinc W! ; : YINC yinc W! ; : XYPAUSE xypause W! ; --- set scan origin and copy xinc : SCANINIT xorg W@ xval W! yorg W@ yval W! xinc W@ xinctmp W! ; --- Writing to LTC2754 in 24-bit mode, MSB first : LTC2754! ( cmd -- ) SPIWR32 DROP 13 HIGH ; --- calc -X,Y from +X,Y and write all 4 values to the LTC2754 : XYOUT xval W@ $FFFF xval W@ - yval W@ $FFFF yval W@ - LTC2754_DAC_A + LTC2754! LTC2754_DAC_B + LTC2754! LTC2754_DAC_C + LTC2754! LTC2754_DAC_D + LTC2754! LTC2754_UPDATE LTC2754! ; --- do a single complete scan : SCAN SCANINIT ypts W@ FOR xpts W@ --- output X scanline FOR XYOUT xinctmp W@ xval W+! xypause W@ ms NEXT --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one xval W@ xinctmp W@ - xval W! --- negate xinctmp for next X scanline xinctmp W@ -1 * xinctmp W! --- increment Y yinc W@ yval W+! NEXT ; --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1 XYPAUSE SCANLooks good, not much to improve upon but here's my take on it nonetheless and also by using longs we can store and handle signed values more easily. I noticed that you were subtracting values from $FFFF but that would not be the same as negating the value as it would be off by one unless that was your intention.
TACHYON { Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner Waveform outputs are via an LTC2754-16 SPI 4-channel DAC: DAC A = -X DAC B = +X DAC C = -Y DAC D = +Y Horizontal (X) waveforms are triangular } ( use longs for signed values ) --- scan origin long xorg long yorg --- DAC increments between scanline points long xinc long yinc --- -X,Y scan values: subtract from $FFFF for +X,Y long xval long yval --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan long xinctmp --- number of scanline points long xpts long ypts --- delay in ms between scan points long xypause : XORG xorg ! ; : YORG yorg ! ; : XPTS xpts ! ; : YPTS ypts ! ; : XINC xinc ! ; : YINC yinc ! ; : XYPAUSE xypause ! ; --- LTC2754 DAC Bipolar –10V to 10V : DAC! ( val chan -- ) $18 OR 17 << SWAP $FFFF AND + --- Writing to LTC2754 in 24-bit mode, MSB first with dummy byte for 32-bits : LTC2754! ( cmd -- ) SPIWR32 DROP SPICE ; : VAL! ( val chan -- ) OVER NEGATE OVER DAC! 1+ DAC! ; --- calc -X,Y from +X,Y and write all 4 values to the LTC2754 : XYOUT yval @ VAL! xval @ 2 VAL! $00500000 LTC2754! ; --- do a single complete scan : SCAN &13.14.12.11 SPIPINS --- init SPI pins (works if rebooted) xorg xval 12 CMOVE --- SCANINIT ypts @ FOR xpts @ --- output X scanline FOR XYOUT xinctmp @ xval +! xypause @ us NEXT --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one xinctmp @ NEGATE xval +! --- negate xinctmp for next X scanline xinctmp @ NEGATE xinctmp ! --- increment Y yinc @ yval +! NEXT ; ( SHORTCUTS ) : CENTER -32768[s][/s] : XYORG DUP XORG YORG ; : XYINC DUP XINC YINC ; : FINE 20 : XYPTS DUP XPTS YPTS ; : FAST 1,0000 XYPAUSE ; : SLOW 5,0000 XYPAUSE ; END ?BACKUP --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points \ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN CENTER FINE 1000 XYINC FAST SCANEDIT: I was really tired last night and made some mistakes so I've fixed them up now.So now after breakfast I wrote a specialized LTC2754 module that simplifies the code so that XYOUT now takes 53.6us. It also auto-updates after you write to the last channel.
Thanks, this is the other one where I have updated the kernel with an LTC2754 module that is twice as fast. Untested and certainly some bugs but basically ok.
TACHYON { Generate bipolar raster scan waveforms for a 4-quadrant piezodisk scanner Waveform outputs are via an LTC2754-16 SPI 4-channel DAC: DAC A = -X DAC B = +X DAC C = -Y DAC D = +Y Horizontal (X) waveforms are triangular -2 version uses LTC2754 runmod and executes XYOUT in 53.6us } ( use longs for signed values ) --- scan origin long xorg long yorg --- DAC increments between scanline points long xinc long yinc --- -X,Y scan values: subtract from $FFFF for +X,Y long xval long yval --- xinc gets inverted for reverse slope of triangle, so temp copy is used for scan long xinctmp --- number of scanline points long xpts long ypts --- delay in ms between scan points long xypause : XORG xorg ! ; : YORG yorg ! ; : XPTS xpts ! ; : YPTS ypts ! ; : XINC xinc ! ; : YINC yinc ! ; : XYPAUSE xypause ! ; : VAL! ( val chan -- ) OVER NEGATE OVER RUNMOD 1+ RUNMOD ; --- calc -X,Y from +X,Y and write all 4 values to the LTC2754 - 53.6us : XYOUT yval @ 0 VAL! xval @ 2 VAL! ; --- do a single complete scan : SCAN &13.14.12.11 MODPINS [LTC2754] --- init LTC2754 MODULE xorg xval 12 CMOVE --- SCANINIT ypts @ FOR xpts @ --- output X scanline FOR XYOUT xinctmp @ xval +! xypause @ us NEXT --- subtract xinc to get us back to the X val of the end of the scanline, which is the X val for the start of the next one xinctmp @ NEGATE xval +! --- negate xinctmp for next X scanline xinctmp @ NEGATE xinctmp ! --- increment Y yinc @ yval +! NEXT ; ( SHORTCUTS ) : CENTER -32768 : XYORG DUP XORG YORG ; : XYINC DUP XINC YINC ; : FINE 20 : XYPTS DUP XPTS YPTS ; : FAST 1,0000 XYPAUSE ; : SLOW 5,0000 XYPAUSE ; END ?BACKUP --- example usage: start at $8000,$8000 (centre of range), 20 points in X and Y (so 400 points total), DAC increments of 1000 counts per point, 1 ms between points \ $8000 XORG $8000 YORG 20 XPTS 20 YPTS 1000 XINC 1000 YINC 1,000 XYPAUSE SCAN CENTER FINE 1000 XYINC FAST SCANI have got the first version going (LAP XYOUT LAP .LAP = 90.4 us at 100 MHz)
I'm having problems with the 2nd version that uses the new module - beyond the CE line going high, I can't see any further SPI bus activity on the scope.
If I put XYOUT into an infinite loop (BEGIN XYOUT 1 ms AGAIN) and probe the SPI lines, there's nothing going on. XYOUT with RUNMOD is taking 42.88 us at 100 MHz.
I'm a pasm noob too, but I've written assembler on other architectures and I can follow the source of the module, makes sense so far. Even if it has bugs though, I would have expected to see, for example, the CE line going up and down.
Any ideas?
SPIPINS did the trick. Could you explain SPIPINS vs MODPINS?
from EXTEND.fth there are two sets of SPI pin descriptions one for the internal SPI functions and a separate one for the runm@sckam Internal is at COG address 1 = @SCK other is at COG address 10 = @SPISCK
So
SPIPINS is really @SPISCK SETPINS
MODPINS @SCK SETPINS
EDIT: I see that there is a command 9 that writes DACn and updates all so that could be used in place of a separate command to update. I've updated the kernel accordingly, I will check the timing now.
BTW, I would have written it anyway just for the exercise but I'm not used to anyone actually trying it!
OK - Just tested it. Looks good with using a cmd 9 for channel 3 to update all at the same time. Saves one more write operation.
Well, Tachyon isn't just an intellectual curiosity for me - it's an integral part of my project (a homebrew scanning tunnelling microscope).
Tachyon will extend the useful life of the Prop 1 for many years, I think.
Looks like that may have been deprecated in 4.7 even but seems this is the section?
You could just paste it in with the slight change of == to := but I never really used locals like this so I think you shouldn't really need it.
Hi Werner
this ode I find in EXTEND (as comment)
It implements a stack of local variables which sometimes come convenient, but not really necessary.
If you need it, just cut & paste it.
btw. I could not find .UART
From which file did you load it?
Probably you can just modify .UART to do without the X1.. local variables
{ PRIVATE 16 longs locals locals 4 + == @x2 locals 8 + == @x3 locals 12 + == @x4 pri @X 4* locals + ; pub X1 locals @ ; pub X2 @x2 @ ; pub X3 @x3 @ ; pub X4 @x4 @ ; --- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 .. pub LOCAL ( <data> n -- ) DUP 4* ( <data> n bytes ) locals 2DUP + ROT <CMOVE FOR I @X ! NEXT ; --- pop and release emove n elements from locals, of no longer used ) pub RELEASE ( n -- ) DUP @X locals ROT 4* $40 SWAP - CMOVE ; \ locals $40 ERASE \ Clean out the locals (easier for debugging) }uart1 6 " UART " LOADCOG
We can not check, if this was successful. A communication is not possible, when we output to the UART: UART> ." 8charact" the sendbufferpointer show 7, but the uart pointer stays at 0, so obviosly the uart doesn't work properly.
Is there an easy way to dump eeprom to check, if the ROM code is stores properly?
Symptoms: we remember, that LOADCOG answered with address values. Now we only get an "ok". Making some experiments with misspelled roms names also resulted in LOADCOG ok, and no other output.
It looks as if the ROM is not found by FINDROM as in the LOADCOGS word OVER .W DUP .W should print addresses!
sure
Btw, EE modifies the dump word temporarily to use eeprom after which it reverts back to hub ram. But all the dump words such as DUMPW DUMPL DUMPA DUMPAW DUMPC etc use the selected memory method. Other dump memory modifiers are RTC, SD, FS, SF, WIZ etc
LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)
We start the cog with the UART. We get the right start address and length reported.
If we change the write pointer value, the expectation is that the UART follows with the read pointer, what doesn't happen.
So our impression is that the parameters are not transfered to the UART correctly, so the UART doesn't see the write pointer.
In a next step we made a simple pin toggle program as ROM without parameters. This program, when loaded with a spin frame stand alone was functional. But the ASM part as ROM loaded by LOADCOG didn't work. LOADCOG showed name and addresses correctly (plausible) and even the cog# as an response on cognew was correct.
If I only had time... as Tachyon is so powerfull and I only have a little glue, going down from a LOADCOG needed to extent to kernel I end up to see LMM which I should have analyzed for years.... It definitely is a pity, that FORTH is not the first choice when learning to program. The world would become more simple and even a low grader could gain success. ;-(
There is one sympton: at reboot EASYNET is started and running. The STACK ends up in Level 2: .S Data Stack (2) $0000.51DA - 20954 $0000.51CE - 20942 ok.
I had expected the stack to be empty.
Forth is very "unstructured" but flexible and extensible and it is up to the user to define the structure they need for that application. The trouble is that many try to "program" without thinking about and creating a structure to build on, and it looks a mess and can easily crumble into one big mess. Once the structure is in place such as thinking about the "division of labor" and how they work in together then each section can be clearly seen, coded, and tested. So even though we might code bottom up we still do so with a top down view in mind.