@caskaz
Okay, I understand that your approach to creating arrays is the usual one.
But can you provide how to store and read the contents of each element?
wvariable array d10 allot
: test
d12 0 do 0 i array + C! loop
d12 0 do i array + C@ . loop cr
d12 0 do i i array + C! loop
d12 0 do i array + C@ . loop cr
6 0 do i i 2 u* array + W! loop
6 0 do i 2 u* array + W@ . loop cr
3 0 do i i 4 u* array + L! loop
3 0 do i 4 u* array + L@ . loop cr
;
I will upload sample-code for Loopy's printer project lator.
But I cannot check it because I don't have hardware(needing level-shift).
So, it might NOT work.
I wrote sample-code about your printer project.
I modified Sal's code about halfduplex.
I think TC74LCX245 can use as level-shifter.
But I don't test because I don't have hardware.
If you know much better way, you should use it.
My idea merely is sample.
If there are NO problem about code and curcuit, propforth reply d62 by executing word"test".
Thanks Caskaz,
I have been reading a lot of background material about Forth on microcontrollers, so I have not done work on the half-duplex, though I have what I believe are 3 possible solutions.
What you provided was a 4th choice for half-duplex. It is quite a bit of code for me to study, so I may be a bit slow to confirm it works.
Here are the alternatives.
1.A regular full duplex configuration with separate Rx and Tx pins that are wired together and a 3K ohm resistor going to the bi-directional half-duplex
2.A regular full duplex contiguration with separate Rx and Tx pins that are wired together and a 2N7000 Mosfet with 10k pull-ups on the 3.3v and the 5.0v sides going to the bi-directional half-duplex
3. A regular full duplex with separate Rx and Tx pins going to a 74ls175 Quad 3-state buffer that will require two additional Propeller pins to control direction. Between the Rx and the 74ls175 would be a 3K ohm resistor to protect the Propeller.
4. Your solution with special half-duplex Forth code.
~~~~
Solutions #1 and #2 would just use the existing serial and hope that the Rx buffer can be cleared before verifying a > prompt. Since there is a loopback, other characters might fill up the Rx beffor the > if the software is not right.
Solution #3 would add direction control, might require another Cog, and would protect the Rx buffer from being filled with bytes from a loop-back
Solution #4 is your solution.
I'll try to get started testing all of these ASAP.
to enable the test
2) load the code with no errors
3) launch the test word
4) see pin 16 LED light up
5) run test_stat repeatedly to see the valid characters sent
6) run test_test_error to see an error injected
7) run a jumper from pin 17 to pin 16 to inject error through hardware
Well, the situation is a big embarrassing. Full duplex ordinarily can interface with half-duplex and just wait for it. The problem is that bi-directional half-duplex on one wire.
So far, I have next to no availability for 3.3v logic that is 5v tolerant unless I order abroad. The local retail shops are backuped with older logic chips in DIP packages and don't want to take on more inventory.
So I went to a 74LS175 solution with a 3K resistor on the rx pin instead of trying to get everything into one pin on the Propeller. The use of the 74lvc245 is interesting as there are other applications - such as a parallel LCD display that might want to toggle direction and adapt from 5v to 3.3v i/o. But the truth is that I am beginning to have a dislike for bi-directional half-duplex RS232, especially when you need an outboard chip to toggle direction.
Can the 74LCX245 be eliminated and just have a 2n7000 operate as a bi-directional level shifter? I guess I'll have to investigate this alternative as a #5 ... but Sal's code looks like it requires the outboard directional control. I could use Sal's code with a 74LS175, but I'd also have to add a hex inverter to get the control signals right. That seems like I am building more and more.
@mjb
Thanks, that is interesting info from Phillips, but a bit involved. I provided the original thread in a link below.
Based on 500ua loading of a Propeller input pin, a 2.2k or larger resistor is supposed to protect an input from 5v
An output needs no protection.
But there is the bi-directional solution that may work with the 2n7000 and pullups of 2k to 10k.
Below is the original thread. Please forgive me, but I decided that I had more to learn about Forth and got away from the Chopstick printer and contest entries. Being involved in a contest deadline gets a bit demanding of my time, so I decided to catchup on other things.
Basically, the half-duplex has gotten into a few separate issues.
1. level shifting
2. doing half-duplex without directional control
3. doing half-duplex with directional control from the Propeller
Peter seems to think that Tachyon Forth will do this wiithout directional control via an outboard logic chip. And I am still thinking that may work.
Item #3 requires some sort of logic chip - eithr the 74xx175 or the 74xx245. Low voltage version with 5 volt tolerance are the LVC or the LCX that are surface mount. But I would be using the 5V 74ls175 or l4ls245 as they are all I can get locally for now.
If you use the 2.2K resistor you should be able to drive the input to the 5-volt device as long as it's input impedance is greater than about 10K. If the input impedance is in the 3K to 10K range you should be able to use a pull-up resistor to bias the signal from the Prop. You could also use a diode in parallel to the 2.2K resistor to provide a low-impedance high output voltage. It really depends on what the input looks like on the 5-volt device.
Note! This is essentially a text file that contains float5, a list of commands, and the test program.
It wasn't to hard to get it running. The primary problem was the differences in the original PropForth 2.5 it was written in.
I use EditPlus for both editing and copying/Pasting into TeraTerm to load the forth into my QuickStart.
Procedure:
1. Load "PropForthEEprom" current release.
2. Startup TeraTerm
3. Copy and Paste the "float" program.
4. "saveforth" to save it into the 512Kb eeprom.
5. It should run after a reset.
6. Copy and Paste the "test" program.
7. "test" to see if there is a problem.
The float functions work pretty well.
However, the trig and log functions are a bit lacking as they use the Props data tables. Yes this is fast but not particularly accurate.
I added a float version of my non-destructive stack displayer.
Please check this out in case I have done something wrong.
Is there forth code that does the inverse trig functions using the Prop tables?
Can it be done using a "Goal Seek" thing like in Excel?
I heard a rummer that PropForth 5.3 has float functions.
Does it?
I added a float version of my non-destructive stack displayer.
Please check this out in case I have done something wrong.
Is there forth code that does the inverse trig functions using the Prop tables?
Can it be done using a "Goal Seek" thing like in Excel?
I heard a rummer that PropForth 5.3 has float functions.
Does it?
Hi Duane
This has been added:
\V5.3\misc
08/03/2012 10:52 AM 6,890 4step.f
07/08/2012 06:06 AM 1,941 BluetoothHC05-06.f
08/03/2012 08:05 AM 4,715 bmp085.f
08/02/2012 09:44 AM 1,697,168 bmp085.xlsx
08/03/2012 09:06 AM 2,792 bmp085alt.f
07/30/2012 11:42 AM 11,876 DoubleMath.f
08/02/2012 07:32 PM 5,370 DS1302.f
07/24/2012 03:23 PM 21,649 float.f
08/03/2012 08:10 AM 585 SR04.f
07/30/2012 11:43 AM 12,906 time.f
11 File(s) 1,765,892 bytes
Basically, Sal did what you did, simply brought the old code up to v5.3. As you said, it was easy.
Your suggestions are good. Could you open an issue in the google code site asking for this as an enhancement? Sal is open to doing stuff a better way. If you put in specific detail, we could try implementing and testing a an enhanced float extension.
prof_braino, what are the licensing terms for PropForth code? I was thinking of porting some of the code to pfth.
"Use it for any purpose" is what Sal put.
I would append that with the obvious (for the benefit of lurkers) give Sal credit when you borrow from his work, give Braino money if you want to encourage this sort of behavior. That's about it.
In your gmail inbox. Remember, this is not released yet, we are still messing with how to structure that packaging for the distributable.
This that I sent is still configured to assume you already installed the Go-Language support, but Go-Language is not required. Just extract the v5.3 directory.
Today was Router day. When I last changed Internet providers, I messed up my routers, etc, to the extent I could not run the test automation. Routers and network configuration tends to be funky from brand to brand, so we attempted to work through the process so Sal and I could reach each other's test rigs. I'll try to put up a page to help others get their network configured to allow the test automation to work without compromising security, etc.
The PFV5.3RC2 has been sent to the team for testing and general abuse. Sal has added to the release package extensions from recent projects. These include the the half duplex serial from Caskaz and Loopy, recursion from Caskaz, additional float stuff Duane was asking about, and others.
We talked about the recursion. Recursion on the prop is only convenient in a few cases due to limited resources. In particular, the function can can itself, but should NOT keep pushing stuff onto the stack. It should act on the same stack item, as shown in the example, or will overflow after about 22 items.
We talked about heater's FFT. There's a bunch math support for this:
* Sal advises to get it working in forth, and later optimize the butterflies in assembler. Multiplies and divides are 64 bit, these are a tad slower. 64 bit is needed for counter scaling, which are the default since we do all the time.
* What is the dynamic range for FFT? Some folks use float so they don;t have to worry about dynamic range. But float is too expensive on the prop. If you DO use float, there is an extension for float, its NOT OPTIMIZED. Sal just used it when he's working out the tables that he'll need to implement for the scale integer, so it has not needed optimization as it is only used in design phase, not application. There's support for converting integers to float, etc.
* DOUBLE math - there is an extension supporting double math, 128 bit multiply and division. This is useful for universal time, micro seconds since 1970.
* SQUARE ROOT - the square root is 16 bit, so its a little faster.
As stated, Sal advises to "get it working in forth, then make it faster as needed". One step is to convert the slow float stuff into scaled integer. The recommendation is to only use the float stuff when precalculating the values for the tables, etc.
Duane, if any of the math stuff fits into your plans, please give it a look and let us know if you have any comments of changes.
Bluetooth support. The Bluetooth has found its way into most of Sal's projects. He has simply too many comports assigned to keep them all sorted out.
* build_boot.f extension has standard eeprom boot, and includes multiprop master and slave support; and routes for standard Blue Tooth
* QSboot.f extension, this boots the Quickstart using the regular serial on 30 &31, then switches to the bluetooth module on whatever pins you assign. With this, you can more easily connect to any project, wirelessly, with a meaningful name in the devices list. Sal connects to projects using a terminal program using a smart phone or netbook and found bluetooth to be the most convenient method.
SPINNERET HTTP support - the SPINNERET HTTP support is still included, but would take about 5 days to document properly. We are going to skip those docs for now, since its not getting much use.
I still have to get my network squared away, and run all the tests before we can finalize the release.
Little did I know that in the Forth world constants are actually variable:)
To put a finer point on it, constants and variables are memory locations that are associated with a value. As in any programming language.
CONSTANTS are typically a single value, not intended to change; VARIABLES can be multiple values and are expected to change. Also in any programming language.
Constants were optimized to return the associated value in the most efficient manner (from invoking the label);
Variables were optimized to the most efficient method to both fetch and store values to the memory locations.
As with assembler, we can change the value of the memory location of a constant thus changing the value returned by the constants. This is considered bad practice as were are given to rely that constants will not be changing; and its typically more efficient to use variable in that case.
Conversely, we also have the option to NOT change a value and use a variable like a constant, but it usually involves more effort as we have to write slightly more code to fetch the value from the memory location. But there are cases where this works out to be a better deal and so is not uncommon.
In a traditional (non interactive) compiler based language, a constant is converted to a value at compile time.
In an interpreted environment like forth or BASIC, a constant is recognized, but has to maintain the association between the label and the value, and does this using a memory location. In forth we can access and modify any memory location. Some folks like to show off and use constants like variable just because they can, but this is typically frowned upon.
It looks like you are starting to get the hang of it. At least you see one is the hammer and one is the screw driver
Some folks like to show off and use constants like variable just because they can, but this is typically frowned upon.
It looks like you are starting to get the hang of it. At least you see one is the hammer and one is the screw driver
Fortunately, ANS Forth provides variables defined by the VALUE word, which can be accessed like a constant, but can also be modified using the TO word. Why use a hammer or a screw driver when you can use power tools?
Fortunately, ANS Forth provides variables defined by the VALUE word, which can be accessed like a constant, but can also be modified using the TO word. Why use a hammer or a screw driver when you can use power tools?
Thats a good option, unfortunately we don't have VALUE and TO implemented in propforth. The take up dictionary space, are not used very much (in the kernel), and we can easily accomplish the same function with existing words.
If one wishes to implement these are extensions, we could add these to the list. Is someone wishes to have a custom kernel that contains these words, they would have to start as an unsupported private branch.
Comments
With respect to question 2, this is the approach I use to define arrays.
\ vector ( n -- ) <name> defines <name> as a one dimensional array of n+1 longs, where
\ 0 <name> is reserved for vector length.
: vector lockdict create $C_a_dovarl w, 0 l, 0 l, 4* allot forthentry freedict ;
For example:
128 vector (hx) \ executing (hx) leaves 0 address of vector on stack
: Hx 1+ 4* (hx) + L@ ; \ ( n -- value )
: >Hx 1+ 4* (hx) + L! ; \ ( value n -- )
NickL
I use variable/wvariable when using array.
This is NG?
array1 and array2 have 10bytes.
variable array1 6 allot
wvariable array2 8 allot
Okay, I understand that your approach to creating arrays is the usual one.
But can you provide how to store and read the contents of each element?
Result; Please dump inside memory.
array d12 dump
I bought Tester[P-10].
http://akizukidenshi.com/catalog/g/gM-00137/
This use FS9711_LP3.
This LSI has RS232-function.
But P-10 don't use this.
So, I tried to add curcuit and write codes.
Next step is display on LCD
More great work!
is hdserialRx what Loopy needs, to use with his printer project?
Would this be a general example driver for the FS9711_LP3?
Can I put this on the downloads page?
I will upload sample-code for Loopy's printer project lator.
But I cannot check it because I don't have hardware(needing level-shift).
So, it might NOT work.
I didn't find out FS9711_LP3's manual.
But it seem FS9721_LP ia almost same as FS9711_LP3.
Please check Page14-15 of FS9721_LP3-DS-20_EN.pdf.
http://www.ic-fortune.com/eng/new_product3_3.asp
I wrote sample-code about your printer project.
I modified Sal's code about halfduplex.
I think TC74LCX245 can use as level-shifter.
But I don't test because I don't have hardware.
If you know much better way, you should use it.
My idea merely is sample.
If there are NO problem about code and curcuit, propforth reply d62 by executing word"test".
I have been reading a lot of background material about Forth on microcontrollers, so I have not done work on the half-duplex, though I have what I believe are 3 possible solutions.
Yours may be a fourth... maybe the best.
I upload Sal's halfdup.
This might be modified a little when included in release 5.3.
What you provided was a 4th choice for half-duplex. It is quite a bit of code for me to study, so I may be a bit slow to confirm it works.
Here are the alternatives.
1.A regular full duplex configuration with separate Rx and Tx pins that are wired together and a 3K ohm resistor going to the bi-directional half-duplex
2.A regular full duplex contiguration with separate Rx and Tx pins that are wired together and a 2N7000 Mosfet with 10k pull-ups on the 3.3v and the 5.0v sides going to the bi-directional half-duplex
3. A regular full duplex with separate Rx and Tx pins going to a 74ls175 Quad 3-state buffer that will require two additional Propeller pins to control direction. Between the Rx and the 74ls175 would be a 3K ohm resistor to protect the Propeller.
4. Your solution with special half-duplex Forth code.
~~~~
Solutions #1 and #2 would just use the existing serial and hope that the Rx buffer can be cleared before verifying a > prompt. Since there is a loopback, other characters might fill up the Rx beffor the > if the software is not right.
Solution #3 would add direction control, might require another Cog, and would protect the Rx buffer from being filled with bytes from a loop-back
Solution #4 is your solution.
I'll try to get started testing all of these ASAP.
1) uncomment to enable the test
2) load the code with no errors
3) launch the test word
4) see pin 16 LED light up
5) run test_stat repeatedly to see the valid characters sent
6) run test_test_error to see an error injected
7) run a jumper from pin 17 to pin 16 to inject error through hardware
Looks like it works!
2) Loaded the code on a second quickstart
3) executed testRx on the second QS
4) ran a wire from pin 16 on QS1 to pin16 on QS2
5) see character on QS2's teraterm display. It looks like 1 to h_FF at 9600 baud.
6) ran a wire from pin 16 on QS1 to pin 17 on QS1.
7) Making the connection records errors on QS1, and causes gibberish on QS2
8) removing the connection resume the pattern from (5)
Looks like QS1 is transmitting at 9600, and QS2 is receiving at 9600 as hoped. So at least the code works.
http://code.google.com/p/propforth/wiki/HalfDuplexSerial
Hopefully this will help the next person that has a question on half duplex serial.
Thanks for your work on this guys!
Loopy, when you get to making the circuits for the other options, feel free to add to or update the page.
So far, I have next to no availability for 3.3v logic that is 5v tolerant unless I order abroad. The local retail shops are backuped with older logic chips in DIP packages and don't want to take on more inventory.
So I went to a 74LS175 solution with a 3K resistor on the rx pin instead of trying to get everything into one pin on the Propeller. The use of the 74lvc245 is interesting as there are other applications - such as a parallel LCD display that might want to toggle direction and adapt from 5v to 3.3v i/o. But the truth is that I am beginning to have a dislike for bi-directional half-duplex RS232, especially when you need an outboard chip to toggle direction.
Can the 74LCX245 be eliminated and just have a 2n7000 operate as a bi-directional level shifter? I guess I'll have to investigate this alternative as a #5 ... but Sal's code looks like it requires the outboard directional control. I could use Sal's code with a 74LS175, but I'd also have to add a hex inverter to get the control signals right. That seems like I am building more and more.
I don't know if you already have this 3 to 5 V BI-directional interfacing option.
FET based
Thanks, that is interesting info from Phillips, but a bit involved. I provided the original thread in a link below.
Based on 500ua loading of a Propeller input pin, a 2.2k or larger resistor is supposed to protect an input from 5v
An output needs no protection.
But there is the bi-directional solution that may work with the 2n7000 and pullups of 2k to 10k.
Below is the original thread. Please forgive me, but I decided that I had more to learn about Forth and got away from the Chopstick printer and contest entries. Being involved in a contest deadline gets a bit demanding of my time, so I decided to catchup on other things.
Basically, the half-duplex has gotten into a few separate issues.
1. level shifting
2. doing half-duplex without directional control
3. doing half-duplex with directional control from the Propeller
Peter seems to think that Tachyon Forth will do this wiithout directional control via an outboard logic chip. And I am still thinking that may work.
Item #3 requires some sort of logic chip - eithr the 74xx175 or the 74xx245. Low voltage version with 5 volt tolerance are the LVC or the LCX that are surface mount. But I would be using the 5V 74ls175 or l4ls245 as they are all I can get locally for now.
http://forums.parallax.com/showthread.php?127546-A-Cheap-easy-way-to-interface-Prop-with-5V-Peripherals
I just updated "float.f" so it works on PropForth 5.0. Note! This is essentially a text file that contains float5, a list of commands, and the test program.
It wasn't to hard to get it running. The primary problem was the differences in the original PropForth 2.5 it was written in.
I use EditPlus for both editing and copying/Pasting into TeraTerm to load the forth into my QuickStart.
Procedure:
1. Load "PropForthEEprom" current release.
2. Startup TeraTerm
3. Copy and Paste the "float" program.
4. "saveforth" to save it into the 512Kb eeprom.
5. It should run after a reset.
6. Copy and Paste the "test" program.
7. "test" to see if there is a problem.
The float functions work pretty well.
However, the trig and log functions are a bit lacking as they use the Props data tables. Yes this is fast but not particularly accurate.
I added a float version of my non-destructive stack displayer.
Please check this out in case I have done something wrong.
Is there forth code that does the inverse trig functions using the Prop tables?
Can it be done using a "Goal Seek" thing like in Excel?
I heard a rummer that PropForth 5.3 has float functions.
Does it?
Duane J
Hi Duane
This has been added:
\V5.3\misc 08/03/2012 10:52 AM 6,890 4step.f 07/08/2012 06:06 AM 1,941 BluetoothHC05-06.f 08/03/2012 08:05 AM 4,715 bmp085.f 08/02/2012 09:44 AM 1,697,168 bmp085.xlsx 08/03/2012 09:06 AM 2,792 bmp085alt.f 07/30/2012 11:42 AM 11,876 DoubleMath.f 08/02/2012 07:32 PM 5,370 DS1302.f 07/24/2012 03:23 PM 21,649 float.f 08/03/2012 08:10 AM 585 SR04.f 07/30/2012 11:43 AM 12,906 time.f 11 File(s) 1,765,892 bytesBasically, Sal did what you did, simply brought the old code up to v5.3. As you said, it was easy.
Your suggestions are good. Could you open an issue in the google code site asking for this as an enhancement? Sal is open to doing stuff a better way. If you put in specific detail, we could try implementing and testing a an enhanced float extension.
I'll try and test this later today.
"Use it for any purpose" is what Sal put.
I would append that with the obvious (for the benefit of lurkers) give Sal credit when you borrow from his work, give Braino money if you want to encourage this sort of behavior. That's about it.
In your gmail inbox. Remember, this is not released yet, we are still messing with how to structure that packaging for the distributable.
This that I sent is still configured to assume you already installed the Go-Language support, but Go-Language is not required. Just extract the v5.3 directory.
Somebody has to do receiving. I do all the non-engineering tasks, this is just another administration function.
Are you actually considering sending money? So far I have been struggling with where to invest the $0 we have received so far.
Today was Router day. When I last changed Internet providers, I messed up my routers, etc, to the extent I could not run the test automation. Routers and network configuration tends to be funky from brand to brand, so we attempted to work through the process so Sal and I could reach each other's test rigs. I'll try to put up a page to help others get their network configured to allow the test automation to work without compromising security, etc.
The PFV5.3RC2 has been sent to the team for testing and general abuse. Sal has added to the release package extensions from recent projects. These include the the half duplex serial from Caskaz and Loopy, recursion from Caskaz, additional float stuff Duane was asking about, and others.
We talked about the recursion. Recursion on the prop is only convenient in a few cases due to limited resources. In particular, the function can can itself, but should NOT keep pushing stuff onto the stack. It should act on the same stack item, as shown in the example, or will overflow after about 22 items.
We talked about heater's FFT. There's a bunch math support for this:
* Sal advises to get it working in forth, and later optimize the butterflies in assembler. Multiplies and divides are 64 bit, these are a tad slower. 64 bit is needed for counter scaling, which are the default since we do all the time.
* What is the dynamic range for FFT? Some folks use float so they don;t have to worry about dynamic range. But float is too expensive on the prop. If you DO use float, there is an extension for float, its NOT OPTIMIZED. Sal just used it when he's working out the tables that he'll need to implement for the scale integer, so it has not needed optimization as it is only used in design phase, not application. There's support for converting integers to float, etc.
* DOUBLE math - there is an extension supporting double math, 128 bit multiply and division. This is useful for universal time, micro seconds since 1970.
* SQUARE ROOT - the square root is 16 bit, so its a little faster.
As stated, Sal advises to "get it working in forth, then make it faster as needed". One step is to convert the slow float stuff into scaled integer. The recommendation is to only use the float stuff when precalculating the values for the tables, etc.
Duane, if any of the math stuff fits into your plans, please give it a look and let us know if you have any comments of changes.
Bluetooth support. The Bluetooth has found its way into most of Sal's projects. He has simply too many comports assigned to keep them all sorted out.
* build_boot.f extension has standard eeprom boot, and includes multiprop master and slave support; and routes for standard Blue Tooth
* QSboot.f extension, this boots the Quickstart using the regular serial on 30 &31, then switches to the bluetooth module on whatever pins you assign. With this, you can more easily connect to any project, wirelessly, with a meaningful name in the devices list. Sal connects to projects using a terminal program using a smart phone or netbook and found bluetooth to be the most convenient method.
SPINNERET HTTP support - the SPINNERET HTTP support is still included, but would take about 5 days to document properly. We are going to skip those docs for now, since its not getting much use.
I still have to get my network squared away, and run all the tests before we can finalize the release.
http://forums.parallax.com/showthread.php?144779-Lost-in-C&p=1153097&viewfull=1#post1153097
To put a finer point on it, constants and variables are memory locations that are associated with a value. As in any programming language.
CONSTANTS are typically a single value, not intended to change; VARIABLES can be multiple values and are expected to change. Also in any programming language.
Constants were optimized to return the associated value in the most efficient manner (from invoking the label);
Variables were optimized to the most efficient method to both fetch and store values to the memory locations.
As with assembler, we can change the value of the memory location of a constant thus changing the value returned by the constants. This is considered bad practice as were are given to rely that constants will not be changing; and its typically more efficient to use variable in that case.
Conversely, we also have the option to NOT change a value and use a variable like a constant, but it usually involves more effort as we have to write slightly more code to fetch the value from the memory location. But there are cases where this works out to be a better deal and so is not uncommon.
In a traditional (non interactive) compiler based language, a constant is converted to a value at compile time.
In an interpreted environment like forth or BASIC, a constant is recognized, but has to maintain the association between the label and the value, and does this using a memory location. In forth we can access and modify any memory location. Some folks like to show off and use constants like variable just because they can, but this is typically frowned upon.
It looks like you are starting to get the hang of it. At least you see one is the hammer and one is the screw driver
Thats a good option, unfortunately we don't have VALUE and TO implemented in propforth. The take up dictionary space, are not used very much (in the kernel), and we can easily accomplish the same function with existing words.
If one wishes to implement these are extensions, we could add these to the list. Is someone wishes to have a custom kernel that contains these words, they would have to start as an unsupported private branch.