Why can't I create a variable like "CREATE DUMMY 99 ,"?
But when I use "CREATE DUMMY 99 C," seems to work, but when I recall DUMMY I het a data stack dump
What I wont is to create an lookup table like
CREATE DISPLAY $3F C, $06 C, $6D C, ............
Not all Forths operate the same way when you start delving under the hood such as creating new structures. I don't really want to make it work exactly the same as there are far better ways of doing it. However I have modified CREATE to compile the bytecode for a variable by default without assigning any memory and without aligning to longs although I could make that optional. I also needed to modify C, because due to the nature of Tachyon when it compiles on the fly this means that the literals you enter before a C, are already compiled as literals. What was needed was to execute any interactive code up to that point so that C, could use the result.
I have also added CVARIABLE, WVARIABLE, and VARIABLE which not only allocate memory but also align the storage area to their respective boundaries. Now I might add CONSTANTs as well even though I have been getting around it simply with a normal colon definition but certainly a long constant would execute a little faster.
There's probably other stuff I've done but I forget now.... so I'll mention it later if I remember and it's pertinent.
Do you have time to look at this question?
Thanks allot
Jan
Hi Jan, that's vey straightforward and this code here should work fine. I have just modified EXTEND.fth a tiny bit so you will need to use the new version. In the old version IC2! returned with an ack flag but most of the time we don't need it so I just made I2C! the ack flag but if I do need to find out I have I2C!? which is actually the old version.
Now as I mentioned earlier in another post that I2C addresses are sometimes referred to in 7-bit right justified format so if your $70 is in that format then make sure you type it in the 8-bit format as $E0. Which device is it by the way?
\ Init the I2C
\ BeginTransmission($70) \ assuming the 7-bit address is in normal byte format not right justified
BEGIN I2CST $70 I2C!? 0= UNTIL \ Wait for an ack from device (otherwise just use I2CST $70 I2C!)
\ Send_I2C($00)
\ Send_I2C($47)
$00 I2C! $47 I2C!
\ EndTransmission
I2CSP
\ BeginTransmission($70)
I2CST $70 I2C! \ this time we are going in blind
\ Send_I2C($01)
\ Send_I2C($3B)
$01 I2C! $3B I2C!
\ EndTransmission
I2CSP
Be aware that as I develop Tachyon that I may change some names and the way they operate as I see ways to improve the operation and readability of the code. So I2CST may just be called I2CSTART and I2CSP will be called I2CSTOP although I will still keep the old names too.
Thanks again for the help.
As answer on your question, this I2C device is a 7-Segment display on the Gravitech shield for the Arduino.
When I use the command I2CBUS then I see the address of $70,$92 and $A0
So I will use these addresses!
There is also a Thermometer, and a EEP on the the board.
Nice board to do some experiments with the I2C bus!!
Last question about the I2C.
Is it also posible to read more bytes in on go?
Supose I wont to read the registers of the DS1307 in one go?
Hi Jan, that's vey straightforward and this code here should work fine. I have just modified EXTEND.fth a tiny bit so you will need to use the new version. In the old version IC2! returned with an ack flag but most of the time we don't need it so I just made I2C! the ack flag but if I do need to find out I have I2C!? which is actually the old version.
Now as I mentioned earlier in another post that I2C addresses are sometimes referred to in 7-bit right justified format so if your $70 is in that format then make sure you type it in the 8-bit format as $E0. Which device is it by the way?
\ Init the I2C
\ BeginTransmission($70) \ assuming the 7-bit address is in normal byte format not right justified
BEGIN I2CST $70 I2C!? 0= UNTIL \ Wait for an ack from device (otherwise just use I2CST $70 I2C!)
\ Send_I2C($00)
\ Send_I2C($47)
$00 I2C! $47 I2C!
\ EndTransmission
I2CSP
\ BeginTransmission($70)
I2CST $70 I2C! \ this time we are going in blind
\ Send_I2C($01)
\ Send_I2C($3B)
$01 I2C! $3B I2C!
\ EndTransmission
I2CSP
Be aware that as I develop Tachyon that I may change some names and the way they operate as I see ways to improve the operation and readability of the code. So I2CST may just be called I2CSTART and I2CSP will be called I2CSTOP although I will still keep the old names too.
Peter,
Is there going sommething wrong in the new version.
Yesterday I tested my I2C device with I2CBUS, and it gives the right addresses ($70,$92 and $A0)
With the new version (binary and extended.fth) it is not working.
I cant test it with the old version because I have over written it and have no backup.
Is there going sommething wrong in the new version.
Yesterday I tested my I2C device with I2CBUS, and it gives the right addresses ($70,$92 and $A0)
With the new version (binary and extended.fth) it is not working.
I cant test it with the old version because I have over written it and have no backup.
Please can you take a look?
Jan
Found the problem, the Forth whas in hex mode and I used the decimal pin numbers!
Just a tip but although it is common Forth practice to set the number base and then hope that all numbers are in that base we like to avoid that irritating problem that you have also discovered. You can force numbers to binary, decimal, or hex using a prefix or a suffix. Why both? Because we can. In Spin we are used to saying $70 which means interpret 70 as a hex number whereas 70 in Spin always means decimal. As you know, in Forth and some other languages (including assemblers) you can set a default radix or base but you can always override this. I try to use common forms although I do detest the 0x format personally. Have a look at the Introduction page and there is a section on number formats. Here's a quick summary:
Hex numbers: $70 70h
Decimal: #112 112d
Binary: %01110000 01110000b
ASCII: "p"
Plus control characters can be represented with a caret such as: ^C
I've been sidetracked from getting the SD system going but that won't take long when I get around to it. In the meantime I have updated a few little things including EXTEND.fth with a few goodies. CONSTANT is now supported so instead of typing in the constant into a definition as before the more efficient form is: "1234_5678 CONSTANT bignum"
An interesting thing I found as I was thinking about doing some error checking when a definition is completed with ; is that as Tachyon Forth does not have any special headers or code field addresses at the start of the definition's code it is possible to fall-through from one definition into the next if there is not an EXIT in between. The compiled kernel bytecode is written this way also but how do we make that happen from the terminal? I tried this and it works. Just for curiosity this is what happens when we start a new definition without completing the one prior.
[FONT=lucida console][B][COLOR=#FF0000]: HELLO ." HELLO " [/COLOR]
[COLOR=#FF0000]: THERE ." THERE " ;[/COLOR][COLOR=#000000] ok[/COLOR]
[COLOR=#FF0000]HELLO[/COLOR][COLOR=#000000] HELLO THERE ok[/COLOR][/B][/FONT]
EDIT: I just looked at how the code displayed on another computer and it was atrocious so I changed the font.
I'm updating my ANSI.fth file with this technique as well which I need to link to the Intro page.
I've been sidetracked from getting the SD system going but that won't take long when I get around to it. In the meantime I have updated a few little things including EXTEND.fth with a few goodies. CONSTANT is now supported so instead of typing in the constant into a definition as before the more efficient form is: "1234_5678 CONSTANT bignum"
An interesting thing I found as I was thinking about doing some error checking when a definition is completed with ; is that as Tachyon Forth does not have any special headers or code field addresses at the start of the definition's code it is possible to fall-through from one definition into the next if there is not an EXIT in between. The compiled kernel bytecode is written this way also but how do we make that happen from the terminal? I tried this and it works. Just for curiosity this is what happens when we start a new definition without completing the one prior.
[FONT=lucida console][B][COLOR=#FF0000]: HELLO ." HELLO " [/COLOR]
[COLOR=#FF0000]: THERE ." THERE " ;[/COLOR][COLOR=#000000] ok[/COLOR]
[COLOR=#FF0000]HELLO[/COLOR][COLOR=#000000] HELLO THERE ok[/COLOR][/B][/FONT]
EDIT: I just looked at how the code displayed on another computer and it was atrocious so I changed the font.
I'm updating my ANSI.fth file with this technique as well which I need to link to the Intro page.
Peter,
The version in Dropbox contains not the CONSTANT structure!
Is it also posible to make a version with VGA and a speed of 57600 Baud?
Yes, I was getting around to updating the binaries but I have been making a few modifications since. Check back very soon, I may update the Intro page to indicate the current version of the binary although the file name will remain the same.
I downloaded via the link the latest 57600 Baud version and the extended.fth
After loading the binary the Forth is running.
But loading the latest version of extend.fth is not posible. Get a lot of What? errors
The versions before where able to load.
Do you have an idee why now not?
Found only problems when using extend.fth from link.
When I used it from the link on the start of the forum and copy the text into my texteditor (ultra edit) and save
it, it runs without any problem!!!
I loaded the 120810 version from Spin source then applied EXTEND.fth with no errors and it did BACKUP.
I wanted to cleanup and start over so I did a COLD . I did WORDS and QWORDS and the EXTEND.fth words were gone.
I did a REBOOT and it came up without t he cold start message and QWORDS et al. were still there. How do I clean out and start over without using Prop Tool to wipe the lower 32K of EEPROM space???
Peter commented that a hard copy of Leo brodie's "Starting Forth" was hard to come by. Search on Amazon, used, but in decent shape, copies are still available.
Thanks Sapieha. Brian Riley suggested that one too and I have the link for it at the bottom of my Intro page.
@Jan: I've found where the problem is and I am just fixing it now. Looks like I wasn't clearing out my XCALL table so while I'm at that I will start testing the YCALL facility which uses the high word of the long as well. The Spin tool is recalcitrant when it comes to things like this where I couldn't use a word, it wanted a long, so in ways Tachyon is structured the way it is because of the limitations of the primary development environment.
I have worked now for a couple of days whith this forth.
I have some experiance withe the standard Forth words!
A lot of words ar unknow for me, there is a sort of list of words?
I have worked now for a couple of days whith this forth.
I have some experiance withe the standard Forth words!
A lot of words ar unknow for me, there is a sort of list of words?
Thanks in advance.
Jan
The source code page is helpful if you look through it as most of the main words are highlighted in some fashion with brief descriptions. I'm not really trying to write a "standard" Forth both because the Propeller is not a standard MCU (hey, we are all "unorthodox" in this department in not going with what's popular) and also because many Forths are based on PC standards and that is definitely not where I want to go. Forth's greatest strength is in embedded systems IMO so I tune my Forth depending upon the MCU and usage.
Some of these words I am using now are also evolving as I am already writing applications with Tachyon and looking at how it could be better, then going back into the kernel and making the changes.
However, I will look to see if there is something I can do. I appreciate the feedback, keep it coming.
I just put up 120810.1730 and Prop Tool 1.3.2 reports "no PUBs found" for the highSpeed Serial RX module I had same problem with 120810.0015. In each case I had to go back to an Aug 5th version to get it to compile.
I am still unable to clear out EXTEND.fth using COLD and REBOOT. COLD works and it issues the COLDstart message and indeed all of EXTEND.fth is gone, BUT I then do a REBOOT and it is all back.
It seems to me that to make this action permanent that you would need to do a BACKUP after you issue the COLD, but you cannot because COLD just got rid of BACKUP! Catch-22 anyone??!!??!!
I noticed the problem with the serial driver and then promptly forgot. It just had to do with some curly problem, you know, the { } in the wrong places. Nothing much, I'll fix it up in a jiffy.
Now I think I explained what happened when you type COLD in that it clears everything back to factory settings.......in RAM....not EEPROM. Just type COLD, don't reset, but load in your EXTEND.fth and it works fine. I've tested this over and over.
I finally am getting a chance to start playing with your wonderful creation.
Currently 2 test target boards: One of pedward's PropKEY USB boards (6.00MHz xtal) and a standard Quickstart (5.00MHz xtal).
I'm currently using CoolTerm on a Mac Mini w/ OS X 10.7.4 - terminal speed is 230400 (fastest it can go).
When I change the _xinfreq to 5_000_000 and the pll to pll16x (80MHz clock) for the Quickstart, everything works fine (zippy software!)
When I change the _xinfreq to 6_000_000 and the pll to pll16x (96MHz clock) for the PropKEY, I get garbage characters output over the terminal and can't match speeds.
baud = 230400 in both cases.
I haven't dug into it but is there something in the character output routines that would tie it to a 80MHz clock?
Other than that, I'm having fun with Tachyon on the Quickstart!
Look at line 1071 in the source or there abouts and just patch this line for now from 80MHz to your 96Mhz : bit_ticks long (80_000_000 / baud ) ' set baud rate
I will tidy up some of these things properly as they were just hard-coded initially to minimize any unnecessary debugging.
I noticed the problem with the serial driver and then promptly forgot. It just had to do with some curly problem, you know, the { } in the wrong places. Nothing much, I'll fix it up in a jiffy.
Now I think I explained what happened when you type COLD in that it clears everything back to factory settings.......in RAM....not EEPROM. Just type COLD, don't reset, but load in your EXTEND.fth and it works fine. I've tested this over and over.
OK, the serial stuff compiles clean now.
I understand about COLD and BACKUP now.
Question - I am using a new board I am working on with 256 KB of EEPROM (2 AT24C1024B's). Is Tachyon taking any notice of and/or making use of the 'extra' storage space beyond 32KB?
Question - when I do an I2CBUS it reports the 2 AT24C1024B's as 4 devices, why?
Question - Has something changed in VGA? I tried the VGA and CON commands yesterday and they worked fine redirecting console output to my VGA monitor. Today I issued a VGA command and it all locks up forcing me to do a manual hardware reset. Also, the DEMO is all screwy and seems too be prematurely ending in a RESET.
Question - I am using a new board I am working on with 256 KB of EEPROM (2 AT24C1024B's). Is Tachyon taking any notice of and/or making use of the 'extra' storage space beyond 32KB?
Question - when I do an I2CBUS it reports the 2 AT24C1024B's as 4 devices, why?
Question - Has something changed in VGA? I tried the VGA and CON commands yesterday and they worked fine redirecting console output to my VGA monitor. Today I issued a VGA command and it all locks up forcing me to do a manual hardware reset. Also, the DEMO is all screwy and seems too be prematurely ending in a RESET.
The larger I2C bus EEPROMs are accessed with a 16-bit address so they are limited to 64K bytes of addressing. The simple trick to get around this is to access the other 64KB on another device address as if it were separate. Using the 8-bit format to represent addresses we end up with:
$A0 = 1st 64KB (write)
$A1 = 1st 64KB (read)
$A2 = 2nd 64KB (write)
$A3 = 2nd 64KB (read)
Of course they could make an I2C bus device accept a 24-bit address and then they wouldn't need two device addresses but then user code would have to be modified to handle it.
BTW, when I say 16-bit address this is not the same as a device address, it is rather the 2 bytes that get sent after a device address (write) that are required to set the EEPROMs internal address counter. Thereafter the address counter will increment automatically when you read bytes back.
Sequence to read bytes from location $1000 (if you can follow):
'
I2CSTART [$A0] [eeprom acks] [$10] [eeprom acks] [$00] [eeprom acks] ....... I2CSTART [$A1] [eeprom acks] [read byte] [we ACK] [read byte] [we ACK] [read byte] [no ACK] I2CSTOP
I haven't been testing VGA lately so I will take a quick look at that tomorrow (3:00AM here)
The larger I2C bus EEPROMs are accessed with a 16-bit address so they are limited to 64K bytes of addressing. The simple trick to get around this is to access the other 64KB on another device address as if it were separate. Using the 8-bit format to represent addresses we end up with:
$A0 = 1st 64KB (write)
$A1 = 1st 64KB (read)
$A2 = 2nd 64KB (write)
$A3 = 2nd 64KB (read)
This is what I2CBUS reports on my 2 AT24C1024B's hardware addressed as 00 and 01 . What you show above must cover, device 00.
Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120810.1730
----------------------------------------------------------------
I2CBUS
Device at 00A0 FF FF FF FF FF FF FF FF
Device at 00A2 00 00 00 00 00 00 00 00
Device at 00A4 FF FF FF FF FF FF FF FF
Device at 00A6 FF FF FF FF FF FF FF FF ok
ok
Comments
Not all Forths operate the same way when you start delving under the hood such as creating new structures. I don't really want to make it work exactly the same as there are far better ways of doing it. However I have modified CREATE to compile the bytecode for a variable by default without assigning any memory and without aligning to longs although I could make that optional. I also needed to modify C, because due to the nature of Tachyon when it compiles on the fly this means that the literals you enter before a C, are already compiled as literals. What was needed was to execute any interactive code up to that point so that C, could use the result.
I have also added CVARIABLE, WVARIABLE, and VARIABLE which not only allocate memory but also align the storage area to their respective boundaries. Now I might add CONSTANTs as well even though I have been getting around it simply with a normal colon definition but certainly a long constant would execute a little faster.
There's probably other stuff I've done but I forget now.... so I'll mention it later if I remember and it's pertinent.
Peter,
Do you have time to look at this question?
Thanks allot
Jan
Hi Jan, that's vey straightforward and this code here should work fine. I have just modified EXTEND.fth a tiny bit so you will need to use the new version. In the old version IC2! returned with an ack flag but most of the time we don't need it so I just made I2C! the ack flag but if I do need to find out I have I2C!? which is actually the old version.
Now as I mentioned earlier in another post that I2C addresses are sometimes referred to in 7-bit right justified format so if your $70 is in that format then make sure you type it in the 8-bit format as $E0. Which device is it by the way?
\ Init the I2C \ BeginTransmission($70) \ assuming the 7-bit address is in normal byte format not right justified BEGIN I2CST $70 I2C!? 0= UNTIL \ Wait for an ack from device (otherwise just use I2CST $70 I2C!) \ Send_I2C($00) \ Send_I2C($47) $00 I2C! $47 I2C! \ EndTransmission I2CSP \ BeginTransmission($70) I2CST $70 I2C! \ this time we are going in blind \ Send_I2C($01) \ Send_I2C($3B) $01 I2C! $3B I2C! \ EndTransmission I2CSPBe aware that as I develop Tachyon that I may change some names and the way they operate as I see ways to improve the operation and readability of the code. So I2CST may just be called I2CSTART and I2CSP will be called I2CSTOP although I will still keep the old names too.
Thanks again for the help.
As answer on your question, this I2C device is a 7-Segment display on the Gravitech shield for the Arduino.
When I use the command I2CBUS then I see the address of $70,$92 and $A0
So I will use these addresses!
There is also a Thermometer, and a EEP on the the board.
Nice board to do some experiments with the I2C bus!!
Last question about the I2C.
Is it also posible to read more bytes in on go?
Supose I wont to read the registers of the DS1307 in one go?
Thanks
Jan
Peter,
Is there going sommething wrong in the new version.
Yesterday I tested my I2C device with I2CBUS, and it gives the right addresses ($70,$92 and $A0)
With the new version (binary and extended.fth) it is not working.
I cant test it with the old version because I have over written it and have no backup.
Please can you take a look?
Jan
Found the problem, the Forth whas in hex mode and I used the decimal pin numbers!
Hex numbers: $70 70h
Decimal: #112 112d
Binary: %01110000 01110000b
ASCII: "p"
Plus control characters can be represented with a caret such as: ^C
An interesting thing I found as I was thinking about doing some error checking when a definition is completed with ; is that as Tachyon Forth does not have any special headers or code field addresses at the start of the definition's code it is possible to fall-through from one definition into the next if there is not an EXIT in between. The compiled kernel bytecode is written this way also but how do we make that happen from the terminal? I tried this and it works. Just for curiosity this is what happens when we start a new definition without completing the one prior.
EDIT: I just looked at how the code displayed on another computer and it was atrocious so I changed the font.
I'm updating my ANSI.fth file with this technique as well which I need to link to the Intro page.
Peter,
The version in Dropbox contains not the CONSTANT structure!
Is it also posible to make a version with VGA and a speed of 57600 Baud?
Cheers,
Jan
Why so slow?
Peter,
This works perfect!
I downloaded via the link the latest 57600 Baud version and the extended.fth
After loading the binary the Forth is running.
But loading the latest version of extend.fth is not posible. Get a lot of What? errors
The versions before where able to load.
Do you have an idee why now not?
Jan
Found only problems when using extend.fth from link.
When I used it from the link on the start of the forum and copy the text into my texteditor (ultra edit) and save
it, it runs without any problem!!!
Jan
I wanted to cleanup and start over so I did a COLD . I did WORDS and QWORDS and the EXTEND.fth words were gone.
I did a REBOOT and it came up without t he cold start message and QWORDS et al. were still there. How do I clean out and start over without using Prop Tool to wipe the lower 32K of EEPROM space???
Good Forth pdf.
http://ficl.sourceforge.net/pdf/Forth_Primer.pdf
For anyone interested to have FORTH programmings PDF.s
Thanks Sapieha. Brian Riley suggested that one too and I have the link for it at the bottom of my Intro page.
@Jan: I've found where the problem is and I am just fixing it now. Looks like I wasn't clearing out my XCALL table so while I'm at that I will start testing the YCALL facility which uses the high word of the long as well. The Spin tool is recalcitrant when it comes to things like this where I couldn't use a word, it wanted a long, so in ways Tachyon is structured the way it is because of the limitations of the primary development environment.
I have worked now for a couple of days whith this forth.
I have some experiance withe the standard Forth words!
A lot of words ar unknow for me, there is a sort of list of words?
Thanks in advance.
Jan
Some of these words I am using now are also evolving as I am already writing applications with Tachyon and looking at how it could be better, then going back into the kernel and making the changes.
However, I will look to see if there is something I can do. I appreciate the feedback, keep it coming.
I am still unable to clear out EXTEND.fth using COLD and REBOOT. COLD works and it issues the COLDstart message and indeed all of EXTEND.fth is gone, BUT I then do a REBOOT and it is all back.
It seems to me that to make this action permanent that you would need to do a BACKUP after you issue the COLD, but you cannot because COLD just got rid of BACKUP! Catch-22 anyone??!!??!!
Now I think I explained what happened when you type COLD in that it clears everything back to factory settings.......in RAM....not EEPROM. Just type COLD, don't reset, but load in your EXTEND.fth and it works fine. I've tested this over and over.
I finally am getting a chance to start playing with your wonderful creation.
Currently 2 test target boards: One of pedward's PropKEY USB boards (6.00MHz xtal) and a standard Quickstart (5.00MHz xtal).
I'm currently using CoolTerm on a Mac Mini w/ OS X 10.7.4 - terminal speed is 230400 (fastest it can go).
When I change the _xinfreq to 5_000_000 and the pll to pll16x (80MHz clock) for the Quickstart, everything works fine (zippy software!)
When I change the _xinfreq to 6_000_000 and the pll to pll16x (96MHz clock) for the PropKEY, I get garbage characters output over the terminal and can't match speeds.
baud = 230400 in both cases.
I haven't dug into it but is there something in the character output routines that would tie it to a 80MHz clock?
Other than that, I'm having fun with Tachyon on the Quickstart!
Thanks for the great work on Tachyon!!
bit_ticks long (80_000_000 / baud ) ' set baud rate
I will tidy up some of these things properly as they were just hard-coded initially to minimize any unnecessary debugging.
I don't mind untidy and hard coded for now.
Thanks!
OK, the serial stuff compiles clean now.
I understand about COLD and BACKUP now.
Question - I am using a new board I am working on with 256 KB of EEPROM (2 AT24C1024B's). Is Tachyon taking any notice of and/or making use of the 'extra' storage space beyond 32KB?
Question - when I do an I2CBUS it reports the 2 AT24C1024B's as 4 devices, why?
Question - Has something changed in VGA? I tried the VGA and CON commands yesterday and they worked fine redirecting console output to my VGA monitor. Today I issued a VGA command and it all locks up forcing me to do a manual hardware reset. Also, the DEMO is all screwy and seems too be prematurely ending in a RESET.
The larger I2C bus EEPROMs are accessed with a 16-bit address so they are limited to 64K bytes of addressing. The simple trick to get around this is to access the other 64KB on another device address as if it were separate. Using the 8-bit format to represent addresses we end up with:
$A0 = 1st 64KB (write)
$A1 = 1st 64KB (read)
$A2 = 2nd 64KB (write)
$A3 = 2nd 64KB (read)
Of course they could make an I2C bus device accept a 24-bit address and then they wouldn't need two device addresses but then user code would have to be modified to handle it.
BTW, when I say 16-bit address this is not the same as a device address, it is rather the 2 bytes that get sent after a device address (write) that are required to set the EEPROMs internal address counter. Thereafter the address counter will increment automatically when you read bytes back.
Sequence to read bytes from location $1000 (if you can follow):
'
I2CSTART [$A0] [eeprom acks] [$10] [eeprom acks] [$00] [eeprom acks] ....... I2CSTART [$A1] [eeprom acks] [read byte] [we ACK] [read byte] [we ACK] [read byte] [no ACK] I2CSTOP
I haven't been testing VGA lately so I will take a quick look at that tomorrow (3:00AM here)
This is what I2CBUS reports on my 2 AT24C1024B's hardware addressed as 00 and 01 . What you show above must cover, device 00.