I'm trying to give myself a bit of time each day to "play" with Forth, hoping at some point that I'll have that "Aha!" moment and I'll understand why those that love it so much do.
While working through a simple demo this morning I entered this:
2 3 . . <CR>
The expected output was
3 2 OK
but was actually
32 OK
Is this something that should be addressed? Sorry if this is a ridiculous request -- still WAY down the learning curve and am dependent on web-based tutorials.
That's really funny Jon, I never thought that by not including an automatic and not always desirable space in the number print function that it would produce puzzling results
Tachyon is Forth but I'm not trying to make it compatible to any standard although I'm not trying to make it incompatible either. It's just that I've had many times in programs where the space is fine say on the terminal screen but if I try to use it when it's redirected to an LCD for instance that I find the space messes things up. Excise the problem space I say and decide when it's needed or not.
Just be aware that there are many dialects of Forths just as there are many dialects of other languages but especially when it comes to embedded systems vs resource rich PCs. While trying to keep it compatible enough there is room for improvement or changes are necessary simply because it's a Propeller.
In the way of tutorials I'm quite happy to include specialized material in my Intro section if it's requested. I use Forth especially when I have a lot of mechatronics as I can interact with the devices and sometimes find I can do things that might not have been thought of or thought possible.
I like the explicit output without any extra padding. Adding the padding, CR and other formatting is easier than trying to remove it from generated output.
In "traditional" forth, the . is a diagnostic word that pops the top element off the stack and displays it on the output line. I think there's an ANSI description for the recommended implementation.
Another diagnostic word is .s which display the contents of the stack.
Propforth did the "traditional" . but not .s, instead opting for st? as Sal thought that did more of what he wanted. Just another design decision.
There's a lot of cases where we DON'T want the extra space after the number, but propforth decided leave that to the user.
We can implement either alternative in either flavor as an extension.
I'm slowly going through the Tachyon code to learn the words. Since I have a terrible memory and lots of debris from other languages in my head, I'm creating a Tachyon vocabulary cheat sheet out on Google Docs to help me learn the new words (and keep them straight). I'm far from done but I have enough to start sharing. Hopefully, the basic vocabulary is relatively stable at this point.
There are a bunch of very clever quick words in there when you start digging around!
If anyone wants to contribute by filling in the blanks, I'll be more than happy to grant you edit access (I can probably figure that out), just send me a PM with your Google details let me know.
Great idea, this list of words!
As it is now possible to use multible cogs, I think it is necessary to have hub vars for communication. Is this possible?
Christof
Another question: * is unsigned. Is this intended to remain unsigned?
Christof
Ah, probably not, but functionality comes first and so multiply just multiplies Seriously though there are some features that I need to go back over because you may notice that you can't even enter a signed number at present, it's a fairly minor thing but it will be addressed shortly. I was more concerned with the overall functionality and usability of Tachyon which is why I have been testing it a lot in real applications which BTW none have needed signed arithmetic.
I'm slowly going through the Tachyon code to learn the words. Since I have a terrible memory and lots of debris from other languages in my head, I'm creating a Tachyon vocabulary cheat sheet out on Google Docs to help me learn the new words (and keep them straight). I'm far from done but I have enough to start sharing. Hopefully, the basic vocabulary is relatively stable at this point.
There are a bunch of very clever quick words in there when you start digging around!
If anyone wants to contribute by filling in the blanks, I'll be more than happy to grant you edit access (I can probably figure that out), just send me a PM with your Google details let me know.
Hey Tony, just be aware that this can change from day to day (sorry) but that's the nature of development. Anyway coming up fairly soon the dictionary will support EEPROM dictionaries which includes stack comments and additional information. So that means that Tachyon itself hosts the glossary as you could type HELP BAUDRATE for instance and it will show the word, it's stack comments and any other information that has been entered. A bit like this:
HELP BAUDRATE
2046: 8A YCALL 08 : BAUDRATE ( baud -- ) '' sets the baudrate of the console which is locked into EEPROM, requires reboot)
If you type HELP without parameters it will list every word. I may include a search parameter to help narrow down words of interest.
What happens is when the source is compiled and a new word is created it will also take the stack comments and any other comments on that line and store this in the EEPROM dictionary information area. This area may simply be the top area of a 32K EEPROM which is normally an uninitialized data are such as display buffers or else if more than 32K is available it will use the top area of that device. Precompiled words and primary extensions will be searched as they are now in RAM and user words stored in EEPROM which frees up a lot of wasted RAM otherwise. The precompiled kernel words won't have any help information when it's freshly compiled but EXTEND.fth will include the additional information for these so that they can be compiled into EEPROM.
By all means you don't need to desist from maintaining a glossary however as I might even include the descriptions in the help comments.
How does that sound?
Hi Peter,
it is me "rough crowd" again. I have got the impression, that the basic functions are already there now. So tachyon could be useful for some guys like me. But such very basic things like * should be stable before. This leads me to the question, whether you might want to release a kernal, that is supposed to stay?
Christof
Ah, probably not, but functionality comes first and so multiply just multiplies Seriously though there are some features that I need to go back over because you may notice that you can't even enter a signed number at present, it's a fairly minor thing but it will be addressed shortly. I was more concerned with the overall functionality and usability of Tachyon which is why I have been testing it a lot in real applications which BTW none have needed signed arithmetic.
Save for entering a negative number which can be worked around it sure looks like it handles signed numbers.
Now that's not totally correct because you just gave me symbols and not actual pins so you do the substitution then. The code will float the MOSI pin after sending the command so you can use the same pin for data out and data in.
Now that's not totally correct because you just gave me symbols and not actual pins so you do the substitution then. The code will float the MOSI pin after sending the command so you can use the same pin for data out and data in.
I see this in the Spin Source
AdcDT=26
AdcCL=25
AdcCS=27
I just downloaded your latest Tachyon1v1-VGA.spin, tried to load it to RAM, I get "ERROR - Address is out of range". Not sure what is causing this to happen.
But which lines are you using? Are you saying that you have it hooked-up already to work with the Spin code? If so then it's simply:
#27 |< CONSTANT #mcp '' Select mcp3208 chip ( This is the chip select or AdcCS )
#25 |< CONSTANT #sck '' SCK mask ( This is the clock or AdcCL )
#26 |< CONSTANT #mosi '' MOSI
#26 |< CONSTANT #miso '' MISO data
I just downloaded your latest Tachyon1v1-VGA.spin, tried to load it to RAM, I get "ERROR - Address is out of range". Not sure what is causing this to happen.
Ray
I've just checked the Google doc version and it's fine in both BST and Spin tool. Just in case I have updated the Dropbox version as well. There was a small typo that I picked up earlier on which may have produced this error, in fact it was an XCALL,SETQ rather than the XCALL,xSETQ that was defined in the dictionary.
But which lines are you using? Are you saying that you have it hooked-up already to work with the Spin code? If so then it's simply:
#27 |< CONSTANT #mcp '' Select mcp3208 chip ( This is the chip select or AdcCS )
#25 |< CONSTANT #sck '' SCK mask ( This is the clock or AdcCL )
#26 |< CONSTANT #mosi '' MOSI
#26 |< CONSTANT #miso '' MISO data
In the MULTI-TASKING example, ' BLINKY >PFA 4 RUN, is the " ' " used for comment, or is it a word? When I tried to run the example as is, I get ??? on that line of code, and there is no LED that is blinking. My assumption with that example is the I could have an LED blinking while I would still be in the interactive mode.
If you are working with a fresh precompiled kernel that you have just F11d then you need to load in EXTEND.fth which has all the extras built on the kernel like RUN which is where the ??? came after in your attempt meaning it did not know what RUN is. You might need to set your line delay from the terminal to around 60ms or so as there is no handshaking while a large source code file is pasted in.
Not sure who Tony is, but that's ok! I'm cool with the development environment and changes. Hopefully, the core words won't change too dramatically.
Tachyon itself hosts the glossary as you could type HELP BAUDRATE for instance and it will show the word, it's stack comments and any other information that has been entered. A bit like this:
HELP BAUDRATE
2046: 8A YCALL 08 : BAUDRATE ( baud -- ) '' sets the baudrate of the console which is locked into EEPROM, requires reboot)
If you type HELP without parameters it will list every word. I may include a search parameter to help narrow down words of interest.
What happens is when the source is compiled and a new word is created it will also take the stack comments and any other comments on that line and store this in the EEPROM dictionary information area. This area may simply be the top area of a 32K EEPROM which is normally an uninitialized data are such as display buffers or else if more than 32K is available it will use the top area of that device. Precompiled words and primary extensions will be searched as they are now in RAM and user words stored in EEPROM which frees up a lot of wasted RAM otherwise. The precompiled kernel words won't have any help information when it's freshly compiled but EXTEND.fth will include the additional information for these so that they can be compiled into EEPROM.
By all means you don't need to desist from maintaining a glossary however as I might even include the descriptions in the help comments.
How does that sound?
The documenting dictionary sounds very impressive. So my choice soon will be to continue updating my spreadsheet from your source or just type in HELP <word> ?
Wow, that's going to be a tough choice!!
It's looking real good. Hopefully, I'll get a chance to play more this afternoon! :thumb:
Comments
I'm trying to give myself a bit of time each day to "play" with Forth, hoping at some point that I'll have that "Aha!" moment and I'll understand why those that love it so much do.
While working through a simple demo this morning I entered this:
2 3 . . <CR>
The expected output was
3 2 OK
but was actually
32 OK
Is this something that should be addressed? Sorry if this is a ridiculous request -- still WAY down the learning curve and am dependent on web-based tutorials.
3 2 . SPACE . <CR>
From PropForth:
From Tachyon:
Tachyon output is exactly as you specify it. PropForth output adds a CR here and a space there........
Which is more useful??? Hmmmmm.........
A Tale of Two Forths
"It was the best of times, it was the worst of times........"
Tachyon is Forth but I'm not trying to make it compatible to any standard although I'm not trying to make it incompatible either. It's just that I've had many times in programs where the space is fine say on the terminal screen but if I try to use it when it's redirected to an LCD for instance that I find the space messes things up. Excise the problem space I say and decide when it's needed or not.
Just be aware that there are many dialects of Forths just as there are many dialects of other languages but especially when it comes to embedded systems vs resource rich PCs. While trying to keep it compatible enough there is room for improvement or changes are necessary simply because it's a Propeller.
In the way of tutorials I'm quite happy to include specialized material in my Intro section if it's requested. I use Forth especially when I have a lot of mechatronics as I can interact with the devices and sometimes find I can do things that might not have been thought of or thought possible.
Another diagnostic word is .s which display the contents of the stack.
Propforth did the "traditional" . but not .s, instead opting for st? as Sal thought that did more of what he wanted. Just another design decision.
There's a lot of cases where we DON'T want the extra space after the number, but propforth decided leave that to the user.
We can implement either alternative in either flavor as an extension.
By the way, the Tachyon doc is really cool!
There are a bunch of very clever quick words in there when you start digging around!
If anyone wants to contribute by filling in the blanks, I'll be more than happy to grant you edit access (I can probably figure that out), just send me a PM with your Google details let me know.
As it is now possible to use multible cogs, I think it is necessary to have hub vars for communication. Is this possible?
Christof
Christof
Hey Tony, just be aware that this can change from day to day (sorry) but that's the nature of development. Anyway coming up fairly soon the dictionary will support EEPROM dictionaries which includes stack comments and additional information. So that means that Tachyon itself hosts the glossary as you could type HELP BAUDRATE for instance and it will show the word, it's stack comments and any other information that has been entered. A bit like this:
HELP BAUDRATE
2046: 8A YCALL 08 : BAUDRATE ( baud -- ) '' sets the baudrate of the console which is locked into EEPROM, requires reboot)
If you type HELP without parameters it will list every word. I may include a search parameter to help narrow down words of interest.
What happens is when the source is compiled and a new word is created it will also take the stack comments and any other comments on that line and store this in the EEPROM dictionary information area. This area may simply be the top area of a 32K EEPROM which is normally an uninitialized data are such as display buffers or else if more than 32K is available it will use the top area of that device. Precompiled words and primary extensions will be searched as they are now in RAM and user words stored in EEPROM which frees up a lot of wasted RAM otherwise. The precompiled kernel words won't have any help information when it's freshly compiled but EXTEND.fth will include the additional information for these so that they can be compiled into EEPROM.
By all means you don't need to desist from maintaining a glossary however as I might even include the descriptions in the help comments.
How does that sound?
it is me "rough crowd" again. I have got the impression, that the basic functions are already there now. So tachyon could be useful for some guys like me. But such very basic things like * should be stable before. This leads me to the question, whether you might want to release a kernal, that is supposed to stay?
Christof
Save for entering a negative number which can be worked around it sure looks like it handles signed numbers.
But what I want is a PWM signal of about 10kHz.
Do you have an example of that?
Thanks in advance.
I have these:
'' dpin = pin connected to both DIN and DOUT on MCP3208
'' cpin = pin connected to CLK on MCP3208
'' spin = pin connected to CS on MCP3208
How can we convert these pins into your program?
Cheers.
Jan
spin |< CONSTANT #mcp '' Select mcp3208 chip
cpin |< CONSTANT #sck '' SCK mask
dpin |< CONSTANT #mosi '' MOSI
dpin |< CONSTANT #miso '' MISO data
Now that's not totally correct because you just gave me symbols and not actual pins so you do the substitution then. The code will float the MOSI pin after sending the command so you can use the same pin for data out and data in.
when i understand you right is 8 bit enough. It wil used for a motor controller
I see this in the Spin Source
AdcDT=26
AdcCL=25
AdcCS=27
Ray
#27 |< CONSTANT #mcp '' Select mcp3208 chip ( This is the chip select or AdcCS )
#25 |< CONSTANT #sck '' SCK mask ( This is the clock or AdcCL )
#26 |< CONSTANT #mosi '' MOSI
#26 |< CONSTANT #miso '' MISO data
This pins work fine, thanks
Ray
Ray
The documenting dictionary sounds very impressive. So my choice soon will be to continue updating my spreadsheet from your source or just type in HELP <word> ?
Wow, that's going to be a tough choice!!
It's looking real good. Hopefully, I'll get a chance to play more this afternoon! :thumb:
Good work guys!