I am finding the Forth language, very, very different, and very intriguing. So, my next question is, as it pertains to the Propeller, how close to asm can you get? Does it have some key words that are already there to reach the innards of the Propeller?
I don't have an assembler yet although Sal's PropForth does. Tachyon has some minimal support so it is possible for me to push PASM instructions onto a stack and execute them although I have never even tried using this yet. Of course Forth allows you to get interactive with all the hardware, to examine it, change it manually or under program control or even a "command line script" or one-liner as I refer to them. Have you got a particular example you are thinking of?
It looks like Mike answered my questions. So GNU Forth does support floating point. Standard objects and structs are still under devepment. It seems like what Forth needs to become a widely accepted language is a standardized dictionary that has the same level of support as the standard libraries used with other more popular HLLs.
I have some code here just to give you a tiny idea how different and similar Forth is to in this instance Spin which everyone here on the forum understands. I was testing out a product of mine that already has code written in Spin. I am looking at converting it to Forth and so I grabbed part of an LCD driver I had written in Spin and I have interspersed these code fragments next to the equivalent Forth words. BTW, it worked first time without a hitch.
TACHYON
\ ****************** P1144 MultiLCD **********************
{
The P1144 combines a 20x4 character LCD or 128x64 graphics LCD plus
Piezo, SD card, keypad, PS/2 or USB, and output outputs as well as
RS485 and other I/O connnections.
Using this as a platform for some further Tachyon testing
}
: ... ; \ just a handy separator
\ just redefine OUT to accept a mask and also set output dir.
: OUT ( state pinmask -- ) DUP OUTPUTS ... SWAP SHROUT ... 2DROP ;
$FF CONSTANT dbus \ LCD data bus
#12 MASK CONSTANT .BSY
#13 MASK CONSTANT .RDY
#14 MASK CONSTANT .CONT
#15 MASK CONSTANT .RS
#16 MASK CONSTANT .RW
#17 MASK CONSTANT .LCD
#18 MASK CONSTANT .LITE
#19 MASK CONSTANT .BUZZ
#23 MASK CONSTANT .CARD
#25 MASK CONSTANT .SDCK
#26 MASK CONSTANT .MOSI \ SD DATA IN
#27 MASK CONSTANT .MISO \ SD DATA OUT
: TONE ( tone dur -- )
FOR .BUZZ OUTSET DUP us .BUZZ OUTCLR DUP us NEXT DROP
;
: BEEP #180 #250 TONE ;
: PIP #180 #80 TONE ;
: WARBLE 3 FOR #180 #100 TONE ... #200 #100 TONE NEXT ;
: RING WARBLE #200 ms WARBLE ;
: RINGS FOR RING #1000 ms NEXT ;
: SHRILL 3 FOR #120 #100 TONE ... #100 #100 TONE NEXT ;
: LITE ( on/off -- ) .LITE OUT ;
: WriteLcd ( data rs -- )
.RS OUT \ write register select
dbus OUTCLR \ Prep data bus as outputs (all low)
OUTSET \ and write data (set over clear)
.LCD DUP OUTSET OUTCLR \ pulse chip enable
5 us \ small delay
dbus INPUTS \ float the data lines (used by keypad)
;
{
pri WriteLcd(data,adr)
dira[dbus+7..dbus]~~
outa[RS] := adr
outa[dbus+7..dbus] := data
outa[EN]~~
outa[EN]~
outa[EN]~ 'dummy operation for delay
dira[dbus+7..dbus]~ ' release data lines
}
: LcdDat ( ch -- ) 1 WriteLcd ;
{
pri LcdDat(data)
WriteLcd(data,1)
}
: LcdCtl ( cmd -- ) 0 WriteLcd ;
{
pri LcdCtl(data)
WriteLcd(data,0)
}
CVARIABLE xpos
CVARIABLE ypos
CVARIABLE dpy
CVARIABLE size
: LCDHOME 0 ypos C! ... 0 xpos C! ... 2 LcdCtl ... 1 ms ;
{
pri LCDHOME
ypos~
xpos~
LcdCtl(2)
ms(1)
}
: LCDCLS 1 LcdCtl ... 1 ms ... 0 size C! ... LCDHOME ;
{
pri LCDCLS
LcdCtl(1)
ms(1)
size~
LCDHOME
}
: str BEGIN C@++ ?DUP WHILE LcdDat REPEAT DROP ;
: SPLASH " MultiLCD V1.0 " ;
: InitLcd
\ shift~
$0F dpy C!
0 xpos C! 0 ypos C!
.RW OUTCLR \ Force R/W low (not needed for standard LCDs)
.RS OUTCLR
.LCD OUTCLR
.CONT OUTCLR
$28 LITE
2 ms ... $38 LcdCtl ... 2 ms ... $38 LcdCtl ... 1 ms
$40 LcdCtl ... $0C LcdCtl ... $06 LcdCtl ... $01 LcdCtl
1 ms ... $02 LcdCtl ... 2 ms
LCDCLS ... BEEP ... SPLASH str
;
{
pri InitLcd
shift~
dpy := $0F
xpos~~
ypos~~
if RW+1 ' Set RW low unless it's specified as -1
dira[RW]~~
outa[RW]~
dira[RS]~~
outa[RS]~
dira[EN]~~
outa[EN]~
dira[piezo]~~
outa[piezo]~
dira[lite]~~
outa[lite]~
' dira[dbus+7..dbus]~~
contrast(0)
backlite($28)
ms(2)
LcdCtl($38)
ms(2)
LcdCtl($38)
ms(1)
LcdCtl($40)
LcdCtl($0C)
LcdCtl($06)
LcdCtl($01)
ms(1)
LcdCtl($02)
ms(2)
LCDCLS
Bell
str(@SPLASH)
}
END
Dave, you mentioned floating point and immediately I turned off, the screen went blank. Floating point has been done to death in computer languages yet I have never needed floating point. How's that? I know the scales involved both on the input and the output so simple scaling of integers is all I have ever needed. No accumulation of floating point errors a la Patriot missile bug for me thank you. If I have a 12-bit ADC and it has to be scaled to an odd figure then this is easily handled with a multiply and a divide.
Peter, I don't doubt that you are the master of this type of conversion, to handle floating point arithmetic within languages that are integer based. If you can recommend a good instructional source, please post the links and references as it would be very helpful. Thanks!
PropForth has an assembler but it really needs better documentation and examples a it is hard to use right now. It does let you generate PASM and create forth words that are chunks of PASM code.
PropForth has a wealth of words to manipulate much of the environment check here for a list of the current PropForth vocabulary. It details what the words are and what modules they are defined in (many are kernel words - PF has a BIG kernel compared to Tachyon).
The Forth environment is interesting in that it has an interpreter running as the user prompt, a compiler available for new words to extend it ( the ": newword blah blah blah;" sequence) the colon actually tells the interpreter to compile what follows until it hits a semi-colon as well as an assembler.
No, it's now a GIGANTIC Forth image and wouldn't fit well. It is written in C, so it could be ported to the propeller but with PropForth and now Tachyon, I really can't see why you would want GNUForth.
Nice example with the Multi-LCD. It's neat to see SPIN and Forth side by side.
@Dave Hein, there is an ANSI Forth standard that defines many of the words that shoudl be in the kernel. The good/bad thing about Forth is that you can make the kernel as small as it should be for the target machine and you don't carry around the stuff you don't need. To your point though, there should be stanrd extensions that build on the kernel using standard words with standard stack effects until you get to the point where you become applicaiton or machine dependent on further words.
So, to get a better feel for "Why Forth?", in the Propeller manual there is an example for turning on/off p16, in PASM, which is an LED on the DEMO board. What would the code look like if you tried to do the same thing in Forth? And maybe what would it look like in Spin, although I think there already examples for that. Probably the next question that would be asked is timing, does it run like turtle slow in Forth?
PropForth and Tachyon Forth are integer based. GNUForth is floating point. The objective is to gain seamless float.
I would think the solution would be to write a floating point vocabulary for the existing Forths rather than bring GForth to the Propeller. When folks wanted FP support in Spin (OH MY!!! It doesn't have FP support EITHER!!!), they wrote FP objects rather than port FORTRAN to the Prop. In bringing GForth to the Prop for FP support, you would lose so much more Propellerish things than you would gain.
As Peter said above, do you REALLY need FP support??
So, to get a better feel for "Why Forth?", in the Propeller manual there is an example for turning on/off p16, in PASM, which is an LED on the DEMO board. What would the code look like if you tried to do the same thing in Forth? And maybe what would it look like in Spin, although I think there already examples for that. Probably the next question that would be asked is timing, does it run like turtle slow in Forth?
Ray
This is all for PropForth. From the forth prompt:
16 pinout
16 pinhi
16 pinlo
The LED on pin 16 just blinked as fast as you could type those command in.
Want a 1/2 second delay? Ok, first let's define a word for waiting 500ms
: wait500ms 500 delms ;
Now, let's define a word blink so it blinks the LED on pin 16 so it's on for 500ms and then off for 500ms:
: blink 16 pinout 16 pinhi wait500ms 16 pinlo ;
OK, now if I type in blink, the LED blinks once with a 500ms duty cycle
For out last trick, we want to be able to blink the LED on pin 16 as many times as we want. For this let's define a word called blinks
: blinks 0 do blink loop ;
to test it with 10 blinks, try this at the prompt:
having started programming with BASIC and then spent many years with LISP for me it is hard reading forth
because there is no syntactic indication as to how many parameters a function/word takes.
So it seems to me I need to know all the forth words - and what args they take - to make sense of other peoples code.
Conventional HLL usually indicate it clearly like:
proc(par1, par2, par3)
or LISP (proc par1 par2 par3)
or even better proc(par1= 12, par2= ..., par3=....) with explicitly named parameters
any advise to help me here - other than memorizing all possible words and the parameters they take?
btw - I like LISP very much, because it is an interactive interpreter - and I can define new functions/word on the fly at the prompt
so some similarity to FORTH here.
Taking one of the Spin exercises from the manual I have presented the two source codes, an optimized version, their listings, and then also taken out the delay in each loop and measured the raw maximum toggle frequency. Decide for yourselves. Hint, have a look at the bottom of the code and figure out which is smaller and faster and by how much.
*********************** Spin source ************************
{{Output.spin
Toggles Pin with Delay clock cycles of high/low time.}}
CON
Pin = 16 { I/O pin to toggle on/off }
Delay = 3_000_000 { On/Off Delay, in clock cycles}
PUB Toggle
''Toggle Pin forever
{Toggles I/O pin given by Pin and waits Delay system clock cycles
in between each toggle.}
dira[Pin]~~ 'Set I/O pin to output direction
repeat 'Repeat following endlessly
!outa[Pin] ' Toggle I/O Pin
waitcnt(Delay + cnt) ' Wait for Delay cycles
******************** Compiled Spin Listing *********************
Constant Pin = 00000010 (16)
Constant Delay = 002DC6C0 (3000000)
|===========================================================================|
|===========================================================================|
Spin Block Toggle with 0 Parameters and 0 Extra Stack Longs. Method 1
PUB Toggle
Local Parameter DBASE:0000 - Result
|===========================================================================|
14 dira[Pin]~~ 'Set I/O pin to output direction
Addr : 0018: 38 10 : Constant 1 Bytes - 10 - $00000010 16
Addr : 001A: 3D D6 1C : Register [Bit] op DIRA VAR~~ Post-set
Addr : 001D: Label0002
16 !outa[Pin] ' Toggle I/O Pin
Addr : 001D: 38 10 : Constant 1 Bytes - 10 - $00000010 16
Addr : 001F: 3D D4 47 : Register [Bit] op OUTA LongMathop !
17 waitcnt(Delay + cnt) ' Wait for Delay cycles
Addr : 0022: 3A 2D C6 C0 : Constant 3 Bytes - 2D C6 C0 - $002DC6C0 3000000
Addr : 0026: 3F 91 : Register op CNT Read
Addr : 0028: EC : Math Op +
Addr : 0029: 23 : WaitCnt(count)
Addr : 002A: Label0003
Addr : 002A: JMP Label0002
Addr : 002A: 04 71 : Jmp 001D -15
Addr : 002C: Label0004
Addr : 002C: 32 : Return
******************** TACHYON Forth ***********************
DECIMAL
16 MASK CONSTANT Pin { I/O pin to toggle on/off }
3_000_000 CONSTANT Delay { On/Off Delay, in clock cycles}
: Toggle
\ Toggle Pin forever - except with synchronized delay without jitter
{ Toggles I/O pin given by Pin and waits Delay system clock cycles
in between each toggle.}
Delay DELTA \ Setup initial target and delta for WAITCNT
BEGIN
Pin OUTSET \ Set pin high (also sets DIR)
WAITCNT \ Synchronized delay
Pin OUTCLR \ Set pin low
WAITCNT
AGAIN
;
********************* TACHYON Pseudo listing *****************
Toggle byte XCALL,xDelay
byte XCALL,xPin,OUTSET
byte WAITCNT
byte XCALL,xPin,OUTCLR
byte WAITCNT
byte JUMP,10
''' 12 bytes total
byte EXIT ' could be omitted
********************* TACHYON (optimized) ****************
: Toggle
\ Toggle Pin forever - except with synchronized delay without jitter
{ Toggles I/O pin given by Pin and waits Delay system clock cycles
in between each toggle.}
Delay DELTA \ Setup initial target and delta for WAITCNT
Pin \ Leave the I/O mask on the stack
BEGIN
DUP OUTSET \ Set pin high (also sets DIR)
WAITCNT \ Synchronized delay
DUP OUTCLR \ Set pin low
WAITCNT
AGAIN
;
********************* TACHYON (optimized) Pseudo listing *****************
Toggle byte XCALL,xDelay
byte XCALL,xPin
byte DUP,OUTSET
byte WAITCNT
byte DUP,OUTCLR
byte WAITCNT
byte JUMP,8
''' 12 bytes total
byte EXIT ' could be omitted
********************** TACHYON toggle loop (interactive mode) maximum frequency ***************
\ This loop toggles at a maximum frequency of 178.6kHz
16d MASK BEGIN DUP OUTSET DUP OUTCLR AGAIN
*********************** Spin toggle loop snippet maximum frequency *******************
dira[Pin]~~ 'Set I/O pin to output direction
' This loop toggles at a maximum frequency of 44.64kHz
repeat 'Repeat following endlessly
!outa[Pin] ' Toggle I/O Pin
any advise to help me here - other than memorizing all possible words and the parameters they take?
This may sound weird, but I don't particularly think about how many parameters each word takes. They all take one and leave two, or take two and leave one, or take one and leave zero. I only have to worry about the exceptions, like DUMP, which take two or three (depending on the implementation). Even then, I only think about setting out the stack once, then I just use the words like a sentence.
I guess we just get accustomed to accepting the stack in this way..
It seems when folks really complain about forth and the stack, it is in a strange context like having words that consume or deposit varying numbers of items on the stack. I saw some really slick tricky guys do this in production code, I have hated that technique ever since. It's impossible for me to get that stuff to work right. The the tricky guys didn't get it right either, which was why I had to sort it out.
In general, when writing code, I tend to make all the words consume exactly zero, one or two elements, and deposit exactly zero, one or two elements. Any more than than means I'm probably doing it the hard way, and should re-factor the code. When the code is working and its time to optimize, I relax this restriction and do what ever I want, since its easy to tell if the code still works after ever change.
PropForth and Tachyon Forth are integer based. GNUForth is floating point. The objective is to gain seamless float.
To do float, you can do it in software (very slow, very expensive) or do it with a coprocessor float chip like nglordi does (see propforth wiki). But that turns out to be fairly slow and cumbersome too. I've never had reason to use float on a forth app. Well, once I wanted to implement a desktop calculator on the Jupiter ACE, but got over it.
In reality, the secret is SCALED INTEGER math. This stuff is great. It cam be made more accurate than float if done right, and is pretty much as fast as integer math, we just have to set some stuff up (the scaling) before and after we do the calculations.
The thing is, we are doing something very specific, being a micro controller, so we can define our problem domain such that we can apply the integer math. If the app REALLY needs fast float, its likely that it just plain needs a processor that supports hardware float. But we can tease a LOT of functionality out using scaled integer. THAT is where the fun is.
The thing is, we are doing something very specific, being a micro controller, so we can define our problem domain such that we can apply the integer math. If the app REALLY needs fast float, its likely that it just plain needs a processor that supports hardware float. But we can tease a LOT of functionality out using scaled integer. THAT is where the fun is.
That's a great argument, and I totally agree. Unfortunately to most people computer = calculator almost without exceptions. So sad.
That's a great argument, and I totally agree. Unfortunately to most people computer = calculator almost without exceptions. So sad.
But the funny thing is that "most people" aren't using or know about the Propeller. So the people here are ones that are not most people yet even most of them are set in their ways with their way of thinking that this is the way it should be when it comes to programming or perhaps that anything else is too much bother.
Of course they all had to spend more than an hour or two to get their heads around Spin as that was the only thing available for the Prop once. Anyway, back to my motto "No effort, no joy"
Hey JohnnyMac, did you ever find the forth books and give it a try?
Prohfessor: I spent several days doing Propeller programming (Spin and PASM) for FX wizard, Steve Wang, (will post pics when I'm allowed to) and then went right on to a video shoot (see: http://t.co/Pfl9J7HV). That is to say that I've been busy. When things settle down in a week or two I will begin to play.
Prohfessor: I spent several days doing Propeller programming (Spin and PASM) for FX wizard, Steve Wang, (will post pics when I'm allowed to) and then went right on to a video shoot (see: http://t.co/Pfl9J7HV). That is to say that I've been busy. When things settle down in a week or two I will begin to play.
I can't wait until September to see how you handle the ladies!
I'm glad someone asked the question... a lot of us were wondering:)
I don't know C... chances are I'll never learn Forth either. But Heater said "this and that" and then he said that you could never compute a Fourier transform in Forth.
So... I looked and of course I found it:
So, the question is... given a Forth library.... say, dfourier.seq from the above link... is the library useable by itself or do I have to modify Forth to accept it?
Out of curiosity is there a Fast Fourier Transform in Forth we can look at. Just want to see what it looks like.
The answer, of course, is yes, you can compute an FFT in Forth. The more pertinent question is whether you can do it it real time. But that will be implementation-dependent and not a function of the language itself.
I have ARM chips and DSPs that I am happy to compute an FFT on, but the Propeller is not a chip I would ever use for this purpose. There are faster, cheaper, and easier alternatives for this. Now Forth has been mentioned in relation TO the Propeller since this is the Propeller forum and being a microcontroller there are many advantages for running Forth on a chip vs PC compile and download etc. When I order an ice-cream I don't complain that it's not salty enough and I would never want it to be.
Comments
Ray
TACHYON \ ****************** P1144 MultiLCD ********************** { The P1144 combines a 20x4 character LCD or 128x64 graphics LCD plus Piezo, SD card, keypad, PS/2 or USB, and output outputs as well as RS485 and other I/O connnections. Using this as a platform for some further Tachyon testing } : ... ; \ just a handy separator \ just redefine OUT to accept a mask and also set output dir. : OUT ( state pinmask -- ) DUP OUTPUTS ... SWAP SHROUT ... 2DROP ; $FF CONSTANT dbus \ LCD data bus #12 MASK CONSTANT .BSY #13 MASK CONSTANT .RDY #14 MASK CONSTANT .CONT #15 MASK CONSTANT .RS #16 MASK CONSTANT .RW #17 MASK CONSTANT .LCD #18 MASK CONSTANT .LITE #19 MASK CONSTANT .BUZZ #23 MASK CONSTANT .CARD #25 MASK CONSTANT .SDCK #26 MASK CONSTANT .MOSI \ SD DATA IN #27 MASK CONSTANT .MISO \ SD DATA OUT : TONE ( tone dur -- ) FOR .BUZZ OUTSET DUP us .BUZZ OUTCLR DUP us NEXT DROP ; : BEEP #180 #250 TONE ; : PIP #180 #80 TONE ; : WARBLE 3 FOR #180 #100 TONE ... #200 #100 TONE NEXT ; : RING WARBLE #200 ms WARBLE ; : RINGS FOR RING #1000 ms NEXT ; : SHRILL 3 FOR #120 #100 TONE ... #100 #100 TONE NEXT ; : LITE ( on/off -- ) .LITE OUT ; : WriteLcd ( data rs -- ) .RS OUT \ write register select dbus OUTCLR \ Prep data bus as outputs (all low) OUTSET \ and write data (set over clear) .LCD DUP OUTSET OUTCLR \ pulse chip enable 5 us \ small delay dbus INPUTS \ float the data lines (used by keypad) ; { pri WriteLcd(data,adr) dira[dbus+7..dbus]~~ outa[RS] := adr outa[dbus+7..dbus] := data outa[EN]~~ outa[EN]~ outa[EN]~ 'dummy operation for delay dira[dbus+7..dbus]~ ' release data lines } : LcdDat ( ch -- ) 1 WriteLcd ; { pri LcdDat(data) WriteLcd(data,1) } : LcdCtl ( cmd -- ) 0 WriteLcd ; { pri LcdCtl(data) WriteLcd(data,0) } CVARIABLE xpos CVARIABLE ypos CVARIABLE dpy CVARIABLE size : LCDHOME 0 ypos C! ... 0 xpos C! ... 2 LcdCtl ... 1 ms ; { pri LCDHOME ypos~ xpos~ LcdCtl(2) ms(1) } : LCDCLS 1 LcdCtl ... 1 ms ... 0 size C! ... LCDHOME ; { pri LCDCLS LcdCtl(1) ms(1) size~ LCDHOME } : str BEGIN C@++ ?DUP WHILE LcdDat REPEAT DROP ; : SPLASH " MultiLCD V1.0 " ; : InitLcd \ shift~ $0F dpy C! 0 xpos C! 0 ypos C! .RW OUTCLR \ Force R/W low (not needed for standard LCDs) .RS OUTCLR .LCD OUTCLR .CONT OUTCLR $28 LITE 2 ms ... $38 LcdCtl ... 2 ms ... $38 LcdCtl ... 1 ms $40 LcdCtl ... $0C LcdCtl ... $06 LcdCtl ... $01 LcdCtl 1 ms ... $02 LcdCtl ... 2 ms LCDCLS ... BEEP ... SPLASH str ; { pri InitLcd shift~ dpy := $0F xpos~~ ypos~~ if RW+1 ' Set RW low unless it's specified as -1 dira[RW]~~ outa[RW]~ dira[RS]~~ outa[RS]~ dira[EN]~~ outa[EN]~ dira[piezo]~~ outa[piezo]~ dira[lite]~~ outa[lite]~ ' dira[dbus+7..dbus]~~ contrast(0) backlite($28) ms(2) LcdCtl($38) ms(2) LcdCtl($38) ms(1) LcdCtl($40) LcdCtl($0C) LcdCtl($06) LcdCtl($01) ms(1) LcdCtl($02) ms(2) LCDCLS Bell str(@SPLASH) } ENDPeter, I don't doubt that you are the master of this type of conversion, to handle floating point arithmetic within languages that are integer based. If you can recommend a good instructional source, please post the links and references as it would be very helpful. Thanks!
PropForth has an assembler but it really needs better documentation and examples a it is hard to use right now. It does let you generate PASM and create forth words that are chunks of PASM code.
PropForth has a wealth of words to manipulate much of the environment check here for a list of the current PropForth vocabulary. It details what the words are and what modules they are defined in (many are kernel words - PF has a BIG kernel compared to Tachyon).
The Forth environment is interesting in that it has an interpreter running as the user prompt, a compiler available for new words to extend it ( the ": newword blah blah blah;" sequence) the colon actually tells the interpreter to compile what follows until it hits a semi-colon as well as an assembler.
No, it's now a GIGANTIC Forth image and wouldn't fit well. It is written in C, so it could be ported to the propeller but with PropForth and now Tachyon, I really can't see why you would want GNUForth.
Nice example with the Multi-LCD. It's neat to see SPIN and Forth side by side.
@Dave Hein, there is an ANSI Forth standard that defines many of the words that shoudl be in the kernel. The good/bad thing about Forth is that you can make the kernel as small as it should be for the target machine and you don't carry around the stuff you don't need. To your point though, there should be stanrd extensions that build on the kernel using standard words with standard stack effects until you get to the point where you become applicaiton or machine dependent on further words.
Ray
I would think the solution would be to write a floating point vocabulary for the existing Forths rather than bring GForth to the Propeller. When folks wanted FP support in Spin (OH MY!!! It doesn't have FP support EITHER!!!), they wrote FP objects rather than port FORTRAN to the Prop. In bringing GForth to the Prop for FP support, you would lose so much more Propellerish things than you would gain.
As Peter said above, do you REALLY need FP support??
This is all for PropForth. From the forth prompt:
16 pinout
16 pinhi
16 pinlo
The LED on pin 16 just blinked as fast as you could type those command in.
Want a 1/2 second delay? Ok, first let's define a word for waiting 500ms
: wait500ms 500 delms ;
Now, let's define a word blink so it blinks the LED on pin 16 so it's on for 500ms and then off for 500ms:
: blink 16 pinout 16 pinhi wait500ms 16 pinlo ;
OK, now if I type in blink, the LED blinks once with a 500ms duty cycle
For out last trick, we want to be able to blink the LED on pin 16 as many times as we want. For this let's define a word called blinks
: blinks 0 do blink loop ;
to test it with 10 blinks, try this at the prompt:
10 blinks
your LED should have blinked 10 times.
so in summary, here's your application
Want this to be able to blink any pin?
It must be time for a user exercise!
I want to be able to do:
n blink
where n is any pin number!
Happy Forthing!!!
As for "Turtle slow"? Not a chance... some place in the forum are some benchmarks for unwinding empty loops with Spin, Forth, C and others.........
Rick, you forgot the second pause ... one pause for ON, one pause for OFF ... without it your code is steady ON
Once more I find myself temped to the dark side of the "forth"... Perhaps after the month's activities die down..
Jeff
because there is no syntactic indication as to how many parameters a function/word takes.
So it seems to me I need to know all the forth words - and what args they take - to make sense of other peoples code.
Conventional HLL usually indicate it clearly like:
proc(par1, par2, par3)
or LISP (proc par1 par2 par3)
or even better proc(par1= 12, par2= ..., par3=....) with explicitly named parameters
any advise to help me here - other than memorizing all possible words and the parameters they take?
btw - I like LISP very much, because it is an interactive interpreter - and I can define new functions/word on the fly at the prompt
so some similarity to FORTH here.
That must be why we "forget"
*********************** Spin source ************************ {{Output.spin Toggles Pin with Delay clock cycles of high/low time.}} CON Pin = 16 { I/O pin to toggle on/off } Delay = 3_000_000 { On/Off Delay, in clock cycles} PUB Toggle ''Toggle Pin forever {Toggles I/O pin given by Pin and waits Delay system clock cycles in between each toggle.} dira[Pin]~~ 'Set I/O pin to output direction repeat 'Repeat following endlessly !outa[Pin] ' Toggle I/O Pin waitcnt(Delay + cnt) ' Wait for Delay cycles ******************** Compiled Spin Listing ********************* Constant Pin = 00000010 (16) Constant Delay = 002DC6C0 (3000000) |===========================================================================| |===========================================================================| Spin Block Toggle with 0 Parameters and 0 Extra Stack Longs. Method 1 PUB Toggle Local Parameter DBASE:0000 - Result |===========================================================================| 14 dira[Pin]~~ 'Set I/O pin to output direction Addr : 0018: 38 10 : Constant 1 Bytes - 10 - $00000010 16 Addr : 001A: 3D D6 1C : Register [Bit] op DIRA VAR~~ Post-set Addr : 001D: Label0002 16 !outa[Pin] ' Toggle I/O Pin Addr : 001D: 38 10 : Constant 1 Bytes - 10 - $00000010 16 Addr : 001F: 3D D4 47 : Register [Bit] op OUTA LongMathop ! 17 waitcnt(Delay + cnt) ' Wait for Delay cycles Addr : 0022: 3A 2D C6 C0 : Constant 3 Bytes - 2D C6 C0 - $002DC6C0 3000000 Addr : 0026: 3F 91 : Register op CNT Read Addr : 0028: EC : Math Op + Addr : 0029: 23 : WaitCnt(count) Addr : 002A: Label0003 Addr : 002A: JMP Label0002 Addr : 002A: 04 71 : Jmp 001D -15 Addr : 002C: Label0004 Addr : 002C: 32 : Return ******************** TACHYON Forth *********************** DECIMAL 16 MASK CONSTANT Pin { I/O pin to toggle on/off } 3_000_000 CONSTANT Delay { On/Off Delay, in clock cycles} : Toggle \ Toggle Pin forever - except with synchronized delay without jitter { Toggles I/O pin given by Pin and waits Delay system clock cycles in between each toggle.} Delay DELTA \ Setup initial target and delta for WAITCNT BEGIN Pin OUTSET \ Set pin high (also sets DIR) WAITCNT \ Synchronized delay Pin OUTCLR \ Set pin low WAITCNT AGAIN ; ********************* TACHYON Pseudo listing ***************** Toggle byte XCALL,xDelay byte XCALL,xPin,OUTSET byte WAITCNT byte XCALL,xPin,OUTCLR byte WAITCNT byte JUMP,10 ''' 12 bytes total byte EXIT ' could be omitted ********************* TACHYON (optimized) **************** : Toggle \ Toggle Pin forever - except with synchronized delay without jitter { Toggles I/O pin given by Pin and waits Delay system clock cycles in between each toggle.} Delay DELTA \ Setup initial target and delta for WAITCNT Pin \ Leave the I/O mask on the stack BEGIN DUP OUTSET \ Set pin high (also sets DIR) WAITCNT \ Synchronized delay DUP OUTCLR \ Set pin low WAITCNT AGAIN ; ********************* TACHYON (optimized) Pseudo listing ***************** Toggle byte XCALL,xDelay byte XCALL,xPin byte DUP,OUTSET byte WAITCNT byte DUP,OUTCLR byte WAITCNT byte JUMP,8 ''' 12 bytes total byte EXIT ' could be omitted ********************** TACHYON toggle loop (interactive mode) maximum frequency *************** \ This loop toggles at a maximum frequency of 178.6kHz 16d MASK BEGIN DUP OUTSET DUP OUTCLR AGAIN *********************** Spin toggle loop snippet maximum frequency ******************* dira[Pin]~~ 'Set I/O pin to output direction ' This loop toggles at a maximum frequency of 44.64kHz repeat 'Repeat following endlessly !outa[Pin] ' Toggle I/O PinThis may sound weird, but I don't particularly think about how many parameters each word takes. They all take one and leave two, or take two and leave one, or take one and leave zero. I only have to worry about the exceptions, like DUMP, which take two or three (depending on the implementation). Even then, I only think about setting out the stack once, then I just use the words like a sentence.
I guess we just get accustomed to accepting the stack in this way..
It seems when folks really complain about forth and the stack, it is in a strange context like having words that consume or deposit varying numbers of items on the stack. I saw some really slick tricky guys do this in production code, I have hated that technique ever since. It's impossible for me to get that stuff to work right. The the tricky guys didn't get it right either, which was why I had to sort it out.
In general, when writing code, I tend to make all the words consume exactly zero, one or two elements, and deposit exactly zero, one or two elements. Any more than than means I'm probably doing it the hard way, and should re-factor the code. When the code is working and its time to optimize, I relax this restriction and do what ever I want, since its easy to tell if the code still works after ever change.
Hey JohnnyMac, did you ever find the forth books and give it a try?
To do float, you can do it in software (very slow, very expensive) or do it with a coprocessor float chip like nglordi does (see propforth wiki). But that turns out to be fairly slow and cumbersome too. I've never had reason to use float on a forth app. Well, once I wanted to implement a desktop calculator on the Jupiter ACE, but got over it.
In reality, the secret is SCALED INTEGER math. This stuff is great. It cam be made more accurate than float if done right, and is pretty much as fast as integer math, we just have to set some stuff up (the scaling) before and after we do the calculations.
The thing is, we are doing something very specific, being a micro controller, so we can define our problem domain such that we can apply the integer math. If the app REALLY needs fast float, its likely that it just plain needs a processor that supports hardware float. But we can tease a LOT of functionality out using scaled integer. THAT is where the fun is.
That's a great argument, and I totally agree. Unfortunately to most people computer = calculator almost without exceptions. So sad.
Of course they all had to spend more than an hour or two to get their heads around Spin as that was the only thing available for the Prop once. Anyway, back to my motto "No effort, no joy"
Prohfessor: I spent several days doing Propeller programming (Spin and PASM) for FX wizard, Steve Wang, (will post pics when I'm allowed to) and then went right on to a video shoot (see: http://t.co/Pfl9J7HV). That is to say that I've been busy. When things settle down in a week or two I will begin to play.
I can't wait until September to see how you handle the ladies!
I don't know C... chances are I'll never learn Forth either. But Heater said "this and that" and then he said that you could never compute a Fourier transform in Forth.
So... I looked and of course I found it:
http://www.forth.org/taygeta.html
So, the question is... given a Forth library.... say, dfourier.seq from the above link... is the library useable by itself or do I have to modify Forth to accept it?
Rich
The answer, of course, is yes, you can compute an FFT in Forth. The more pertinent question is whether you can do it it real time. But that will be implementation-dependent and not a function of the language itself.
-Phil