Thanks MJB.
What I was really interested in was whether Peter had written another interface, or used one of the existing 3 interfaces.
Unfortunately, all the pasm drivers use a different interface mechanism which makes swapping them a nightmare.
So you can see there isn't much PASM in the Tachyon SD interface, it mainly relies on the SPIxx instruction and a small block r/w module that gets loaded into the cog as needed. The result is that you don't need to dedicate a cog just for SD and the interface is simple and flexible as it no longer has to pass commands and parameters to a preprogrammed black box (cog).
What's a good board to practice Tachyon with? How do I get started and what are the advantages over C and SPIN
Any board at all will run Tachyon and the system will automatically detect 5 or 10MHz crystals as well. But if you want to really test out Ethernet and of course SD then I will have to say that you really should use something like my IoT5500+P8 @96MHz which despite its very compact size really packs a punch. However it is I/O limited but interestingly no where near as limited as the Spinneret. There's still at least 9 I/O available on the small LANJACK footprint. Alternatively I do have another board that has RS485x2, RS232(5in3out), USB, SD, IoT5500 integrated, VGA + audio out and other signals on a pin header etc.
As to advantages that depends upon whom you ask but I don't sell Tachyon, I made it because Spin just wasn't fast (and compact) enough, because any other "language" either ran out of memory to gain speed or ran too slow etc. So Tachyon is based on very zippy bytecode and it's zippy because the 8-bit code is a jump address to the routine in the first 256 longs of the Tachyon VM cog. But it's fast also because the Forth kernel is tailored to suit the Propeller rather than some unpopular ANSI standard written with PCs in mind. It's also fast in terms of testing code because it is target resident and interactive so you can talk to it. The other thing about the interactive part is that it also allows you to do loops and other stuff on an interactive command line that normally requires a compiled definition in other Forths.
Also I/O devices such as LCDs, serial, VGA, etc are designed as streaming I/O so you can redirect output to the VGA rather than the serial console and it will work the same to the best of its capabilities. Normally you find many device drivers written with their own special VGA.CR and VGA.HOME and the same for other devices. In Tachyon you could type on an interactive line this little demo:
VGA PRINT" HELLO WORLD" LCD PRINT" HELLO WORLD" MORSE PRINT" HELLO WORLD" CON PRINT" HELLO WORLD"
Yes, Tachyon is a Forth so it uses a stack to hold parameters and to some people they see it as back to front, or is that front to back? If you are not locked into the mindset of seeing the world as north pole being up and south being down then there is some hope for you. But don't try to learn Tachyon, just use it and build your programs interactively by testing out little things first. Design top down in your head but implement the building blocks that the top level words/definitions will need.
How powerful and compact is it? You do know I have the compiler and kernel and utilities and virtual memory FAT32 filesystem and Ethernet web and FTP servers running on a standard Prop without any tricks or extra memory expansion cards etc. Oh, and there are still at least 5 cogs and application memory to spare.
What's a good board to practice Tachyon with? How do I get started and what are the advantages over C and SPIN
just take any prop board, even a breadboard setup (just converted an Arduino beginner within an afternoon to a Tachyon fan)
download
Peter's Tachyon Explorer-Image from here
load it in with PropTool - RAM load will do initially unless you want to install to EEPROM
and then open a terminal at 115200 (thanks Bob)
type (with SPACES !!!)
2 2 + . <enter>
or
WORDS
or
QW
...
and you are up for running Peter's tutorial from here
re:just take any prop board, even a breadboard setup (just converted an Arduino beginner within an afternoon to a Tachyon fan)
download
Peter's Tachyon Explorer-Image from here
load it in with PropTool
and you are up for running Peter's tutorial from here
Ok for fun I tried it .
Then I opened the serial term and changed the baud rate to 11200
and typed words (because that is the only forth thing I know LOL) It spit out a bunch of words .
re:just take any prop board, even a breadboard setup (just converted an Arduino beginner within an afternoon to a Tachyon fan)
download
Peter's Tachyon Explorer-Image from here
load it in with PropTool
and you are up for running Peter's tutorial from here
Ok for fun I tried it .
Then I opened the serial term and changed the baud rate to 11200
and typed words (because that is the only forth thing I know LOL) It spit out a bunch of words .
try the following to get some info about your hardware
lshw
lsio
I'm trying to set up Tachyon on an Activity Board WX. I got Tachyon 2.7 source, EXTEND.FTH, and SDCARD.FTH from the Dropbox directory, compiled and downloaded Tachyon with the PropellerIDE, then downloaded first EXTEND.FTH, then SDCARD.FTH with CoolTerm (on a Mac). Tachyon and EXTEND seem to work, but I get the following when downloading SDCARD:
0226
.. error in SDCS at PCB $C3 = IF *error*.
What am I missing? I would like to download SDWORDS.FTH and I have several 128K files on the card like FILE0001.TXT, FILE0002.TXT and WORDS.DCT.
Sorry Mike, saw your PM but was a bit too busy to check it out properly. I will try the same procedure later on and get back to you as it is a mystery at present. I will see if I can give you a header file for the activity board which will be used by SDCARD.fth to compile for that board etc.
I'm trying to set up Tachyon...
0226
.. error in SDCS at PCB $C3 = IF *error*.
What am I missing? I would like to download SDWORDS.FTH and I have several 128K files on the card like FILE0001.TXT, FILE0002.TXT and WORDS.DCT.
Mike
You are not missing anything Mike, PCB is not defined.
Try putting
0 == PCB
above the IFNDEF &SDCS line and recompile. Around line 64
Check the pin assignments in the IFNDEF &SDCS block to make sure they match the board you are using.
Peter usually has a header file for each board but I would prefer simple generic modules that have a config a simple config at the top to avoid this type of "user" error.
I have confirmed that this will compile but I don't use this version of SDCARD.fth,
I'm trying to set up Tachyon on an Activity Board WX. I got Tachyon 2.7 source, EXTEND.FTH, and SDCARD.FTH from the Dropbox directory, compiled and downloaded Tachyon with the PropellerIDE, then downloaded first EXTEND.FTH, then SDCARD.FTH with CoolTerm (on a Mac). Tachyon and EXTEND seem to work, but I get the following when downloading SDCARD:
0226
.. error in SDCS at PCB $C3 = IF *error*.
What am I missing? I would like to download SDWORDS.FTH and I have several 128K files on the card like FILE0001.TXT, FILE0002.TXT and WORDS.DCT.
Mike
hi Mike,
while DP's suggestion might work right now,
I would suggest to follow Peter's way of creating a board-ini file.
In the old days, when Tachyon and it's components (Extend, SD, File, NW ..) changed 3 times a week it was a bad idea to rely on patching those.
Better have the board-ini file like on Peter's dropbox the CE1372.fth, SPINNERET.fth or QS.fth from the headers folder, which you load in after EXTEND.
I am sure you can adapt one of those.
Markus
here my PropBOE board ini file
TACHYON
[~
\ by MJB
\ load after EXTEND.fth
FORGET PropBOE.fth
pub PropBOE.fth ." PropBOE HARDWARE DEFINITIONS 150827.1930 " ;
{
DESCRIPTION
These are the header files that define the functions of the pins plus any other special functions needed for the PropBOE boards. Although these definitions are not strictly required they do simplify integration of the various Tachyon Forth modules which will be automatically configured to run on the PropBOE
}
( for PropBOE board )
*
*
( P8X32A PINOUTS )
( PIN MASK NAME HDR2X20 DESCRIPTION )
{ --- P0 .. P15 are generic GPIO and not specifically assigned
#P0 |< == S9 --- Pin 1 S9 through 100K
#P1 |< == S8 --- Pin 2 S8
#P2 |< == S7 --- Pin 3 S7
#P3 |< == S6 --- Pin 4 S6
#P4 |< == S5 --- Pin 5 S5
#P5 |< == S4 --- Pin 6 S4
#P6 |< == S3 --- Pin 7 S3
#P7 |< == S2 --- Pin 8 S2
--- * SD CARD SPI *
#P8 |< == &SDDO --- Pin 9 Data from SDCARD S/D input
#P9 |< == &SDCK --- Pin 10 SDCARD clock S/D resistor
#P10 |< == &SDDI --- Pin 11 Data to SDCARD
#P11 |< == &SDCS --- Pin 12 SDCARD chip select (cut pullup for card detect)
---
}
{
#P12 |< == &WNCK --- Pin 13 W5200 clock
#P13 |< == &WNDO --- Pin 14 MISO from W5200
#P14 |< == &WNDI --- Pin 15 MOSI to W5200
#P15 |< == &WNCS --- Pin 16 W5200 chip select
}
--- * servo headers *
#P14 |< == Servo1
#P15 |< == Servo2
#P16 |< == Servo3
#P17 |< == Servo4
#P18 |< == Servo5
#P19 |< == Servo6
--- Microphone
#P20 |< == MICA --- Delta-Sigma ADC pin 20 & 21
#P21 |< == MICB --- Delta-Sigma ADC pin 20 & 21
--- uSD Header
#P22 |< == &SDDO --- Data out from SDCARD
#P23 |< == &SDCK --- SDCARD clock
#P24 |< == &SDDI --- Data to SDCARD
#P25 |< == &SDCS --- SDCARD CS
--- DACs & LEDs
#P26 |< == DAC1 --- Pin 26 DAC1 & LED1
#P27 |< == DAC2 --- Pin 27 DAC2 & LED2
--- I2C 4-channel ADC
#P28 |< == &SCL --- I2C clock
#P29 |< == &SDA --- I2C data
( LEDS )
\ do what needs to be done to turn off all the LEDs
pub !LEDS DAC1 DAC2 OR OUTCLR ;
{
pub ERRORLED ( on/off -- ) LED5 OUT ;
pub LANLED ( on/off -- ) LED4 OUT ;
pub SDERRLED ( on/off -- ) LED3 OUT ;
pub SDBSYLED ( on/off -- ) LED2 OUT ;
pub READYLED ( on/off -- ) LED1 OUT ;
}
{
pub WRESET ( on/off -- ) NOT &WNRST OUT ;
pub WPWRDN ( on/off ) &WNPWDN OUT ;
}
\ Usage: $130630 DATE! \ set the date to the 30th June 2013
$150827 DATE!
$120000 TIME!
{ \ the definitions from EXTEND should do ?
pub .TIME TIME@ L>W .BYTE ." :" W>B .BYTE ." :" .BYTE ;
\ Print date in international format YYYY/MM/DD (otherwise 1/12/2013 could be 1st of December or 12th of January)
pub .DATE DATE@ L>W ." 20" .BYTE ." /" W>B .BYTE ." /" .BYTE ;
pub .DT .DATE SPACE .TIME ;
}
\ Do what we need to do to init this pcb
pub !PCB
!LEDS
;
" PropBOE" 0 STRING PCB$
#40001 == PCB --- not sure what this is used for MJB
]~
END
?BACKUP
Didn't have a (.ini) file handy and it becomes just another step for someone trying out Tachyon who is not stewed in the sauce already.
"#40001 == PCB --- not sure what this is used for MJB "
This comment says it all, PCB is defined in SDCARD.fth and that's the whole problem Mike was having.
Anyway Mike MJB and myself have used Tachyon successfully so post your questions. And show us that activity board file you create.
Hi DP -
yes
SDCARD.fth should contain an
IFNDEF PCB 0 == PCB }
and all would compile fine
SD pins could be specified later if needed.
actually I think this
--- Used to set C3 SD method etc
TRUE == C3CARD
pub C3 $C3 ' PCB 1+ ! &32.10.9.11 SDPINS ' C3CARD ucard W! ;
}
pub SDCS ( on/off -- )
PCB $C3 = IF
8 LOW 8 HIGH IF 5 FOR 25 DUP HIGH LOW NEXT THEN
ELSE
IF &SDCS OUTCLR ELSE &SDCS OUTSET THEN
THEN
;
should NOT be in SDCARD.fth but should go in a C3.fth ini file as
pub SDCS ( on/off -- )
8 LOW 8 HIGH IF 5 FOR 25 DUP HIGH LOW NEXT THEN
;
and
pub SDCS ( on/off -- ) ... ;
in SDCARD.fth become
IFNDEF SDCS pub SDCS ( on/off -- ) ... ; }
board specific ini files are helpful and not so hard to create.
would be good to have those for the standard boards.
when I made my PropBOE.fth ini file I searched Peter's source files and could not find a use for PCB,
this change in SDCARD.fth has been introduced later.
@mike welcome to TACHYON, it is good of the Tachyon community grows a bit.
I have been running my weather station program successfully with Tachyon, but only on a VGA display. I would like to have it run on the smaller (7") TFT display, which requires a TV text type input. What steps in Tachyon can I take to move from the VGA to the TV text type display?
There is a question about the Tachyon license that comes up from time to time especially in emails and pms. When I say it's open-source, it's open-source. Many of these open license agreements simply end up hampering the one with good intentions as those others who want to do what they want to do will do it anyway. There's no skin off my nose as I developed it for my own commercial projects and anyone else who wants to use it can or will use it.
Tachyon may be the greatest thing since sliced bread for the Prop but it seems most are stuck with a fixed mindset and think as if RPN was the defining factor too. Reverse is just a word that gets applied when it's different from how things are traditionally done when it could just as well have been the other way around traditionally. In the "RPN" world (from this world's view) everyone would say that A = B + C is so difficult and back to front when you have already started with B and C, well you just add (+) them, then store (!) the result in A, with the compiled instructions looking exactly like that.
@K6MLE: The VGA driver could be replaced with a suitably modified version of a TV object but I've been too busy to look myself though.
Is there a serial version of your Propeller Hardware Explorer? I see a link to a VGA version in your signature.
Obviously you haven't tried that then The serial console is always active and the VGA version simply incorporates the driver and high level words for VGA but doesn't use this as a default although you can easily set it to do so.
Is there a serial version of your Propeller Hardware Explorer? I see a link to a VGA version in your signature.
Obviously you haven't tried that then The serial console is always active and the VGA version simply incorporates the driver and high level words for VGA but doesn't use this as a default although you can easily set it to do so.
No, I haven't tried it yet but I just downloaded it and will try it soon. Thanks!
Has anyone considered creating a public key encryption appliance based upon the Propeller and written in Tachyon? If it could be done in such a way as to make use of most of the cores, might it not be able to perform the encryption in realtime to a serial bit stream? This thought occurred to me while driving home today and I thought I'd throw it out to those more fluent in Tachyon than myself.
Has anyone considered creating a public key encryption appliance based upon the Propeller and written in Tachyon? If it could be done in such a way as to make use of most of the cores, might it not be able to perform the encryption in realtime to a serial bit stream? This thought occurred to me while driving home today and I thought I'd throw it out to those more fluent in Tachyon than myself.
sounds like a quite compute intense task to me
and then it is probably better run in a PASM COG than multiple TACHYON COGs.
Of course you then can use it from TACHYON
I'm just coming to this party, but I am very interested in trying this out; I would like to make my sailboat autopilot a bit spunkier by moving from Spin to Tachyon, rethinking the use of floating point along the way.
I have the kernel+EXTEND (2.7) running on a USB Protoboard, and will be trying the SD codes soon. When I ask for WORDS or QWORDS I see a list of 167 predefines, but this is far less than are shown on the google docs "Introduction". For example, ==, pri, pub don't show up. Variable is in the Introduction document, but Tachyon 2.7 doesn't know it. This is making it tough to know what is there to build on... and I know there is a lot here.
Am I missing something? Do I dig into the source for this ?
I'm just coming to this party, but I am very interested in trying this out; I would like to make my sailboat autopilot a bit spunkier by moving from Spin to Tachyon, rethinking the use of floating point along the way.
I have the kernel+EXTEND (2.7) running on a USB Protoboard, and will be trying the SD codes soon. When I ask for WORDS or QWORDS I see a list of 167 predefines, but this is far less than are shown on the google docs "Introduction". For example, ==, pri, pub don't show up. Variable is in the Introduction document, but Tachyon 2.7 doesn't know it. This is making it tough to know what is there to build on... and I know there is a lot here.
Am I missing something? Do I dig into the source for this ?
Hi Paul, welcome to the party! I'm just getting back into the Tachyon seat myself and starting to tidy a few things up before I release some new enhancements both for P1 and P2.
Your terminal emulator may be trying to do handshaking as it may not be keeping up with the listing. turn off handshaking or slow down the baud rate with "57600 CONBAUD", reset and try again. Also soft handshake had been rendered useless by the PC's use of large transmit/receive buffers that queue the handshake characters along with all the other characters. I recommend using either TeraTerm if you are on Windows or minicom on Linux.
There are a lot of traditions in Forths that should have been left in the past and in my opinion the use of VARIABLE is one of them. I want to be able to say what kind of variable, how many of them, and also include others in the same list rather than having a line for each and every one of them. The other thing is sometimes you just want to allocate an area just for buffers and variables, you don't want Forth code headers mixed in there as it can be a battlefield and sometimes you just need to wipe the whole area, so keep code clear of it. This is how I do it:
To declare a plain variable we say: LONG <myvar>
Now if we just want a byte: BYTE <myvar>
If we want 20 bytes: 20 BYTES <myvar>
Of we could have a list of variables: LONG <myvar>,<tempvar>,<bufvar>,<sotherevar>
Perhaps we want that battlefield so we allocate an area like we do in SDCARD.fth: 176 BYTES sdinfo
Then we can use that as the ORG for allocating Data Storage units like this:
sdinfo ORG --- Use Tachyon reserved buffer space for SD card (normally at $7400)
#64 DS cid --- Card ID
#64 DS csd --- Card Specific Data
#4 DS ocr --- Operating conditions register
So cid for instance is actually compiled as a address constant pointing to the area in sdinfo. This works the same as any variable too.
Thanks Peter! I am using Teraterm, the 57600 8N1 causes a lot of screen junk to appear, but I can do manual math and it works properly. Still the same list of 167 predefines.
I see that you are doing several things to make Tachyon look/feel like Spin. I was using == thinking they were variables, but I see == is aliased to CONSTANT (or other way about?) . Is there a real difference between constants and variables in Tachyon ?
I find that there are traditional words in Forth that clutter and other words that just don't stand out as they should. Case in point is the dot word used to print out numbers, they get lost in text especially certain fonts and I much prefer to have an alias called PRINT that really stands. Now there are some that really stand out to the point of clutter such as CONSTANT and in a whole list of defines it takes over which is why I much prefer something more discrete such as == so that the value and the name stand out instead.
That's my take on this aspect but it does not fundamentally change Forth from a programmer's perspective though. Under the hood it is quite different and it is unlike some Forths that try to be ANSI compliant for which I can't understand why because most of the ANSI stuff was obviously designed with resource abundant PCs in mind whereas we are working in the nitty-gritty world of microcontrollers and getting the most out of the least!
TeraTerm works fine up to 921600 baud as far as I remember but typically I either run my systems at 115200 for compatibility or at 2M baud if I want a zippy screen update such as with SPLAT.
Does the larger QWORDS listing in the document show a fully loaded system, ? I just want to know if have done something wrong here.
Last Q for now : for a typical program, is the Tachyon version expected to take up more or less space than the Spin equivalent? I know 'it depends', but I'll bet you have a sense of which way the size goes. Speed seems to be a hands-down win for Tachyon. With the kernel + EXTEND I have 5.7K free, still need SD, MULTIFATS, (sp?) and the program.
Actually, what I likethe most about Tachyon is that it forces you to think about what's going on.
OK, still flailing about, but if I uncomment SMALL in EXTEND.fth then words gives an extended listing of 712 words. Plus it has ~9K free mem, about 2x previous. Still don't know what I' m doing, but my head is starting to stretch around this ...
Does the larger QWORDS listing in the document show a fully loaded system, ? I just want to know if have done something wrong here.
Last Q for now : for a typical program, is the Tachyon version expected to take up more or less space than the Spin equivalent? I know 'it depends', but I'll bet you have a sense of which way the size goes. Speed seems to be a hands-down win for Tachyon. With the kernel + EXTEND I have 5.7K free, still need SD, MULTIFATS, (sp?) and the program.
Actually, what I likethe most about Tachyon is that it forces you to think about what's going on.
Hi Paul,
if you really want to learn Tachyon there is no way around reading the source code.
Start with EXTEND.fth and later the Tachyon kernel itself.
This is also a great learning in PASM itself - that'S how I started with the propeller just exactly when Peter started his Tachyon.
At that time almost without documentation.
btw. WORDS gives the full words list QWORDS is the quick and short version of it.
And if you need more space the dictionary can be offloaded to higher EEPROM or SD card.
have fun
Markus
By default EXTEND will pretty much compile the whole source but you can also specify what to include too although it is more common to make a small build simply by defining SMALL (CREATE SMALL) before you load EXTEND. With a small build there is over 8k free and still enough memory to load the file system and some user code. However around 10k of the 32k RAM is taken up by the dictionary and if you want more room then typically you would load EEWORDS module and then run COMPACT to create a fast indexed dictionary lookup in upper EEPROM. This frees an enormous amount of RAM and allows the networking modules to be loaded and still have room for a sizable application.
In terms of how compact Tachyon is compared to Spin I know that even though they both use bytecodes albeit quite differently, and even though Tachyon interactive compiles and resides on the Prop itself rather than compiles on a PC, and even though Tachyon's symbol table (dictionary) resides in Prop memory, that I can still run as mentioned the full network system with FAT32 and application which is not something I have seen done in Spin or any PC compiled "language" (CMIIW).
Here is the QWORDS listing from the Prop I'm working on which has the filesystem loaded plus some test code.
As MJB mentioned about reading the source code while it can help a lot I suppose that it is more helpful when you get stuck as looking at the source can shed some light on the inner workings. I try to keep things simple and practical and it would be nice if TF interactively suggested code completion and stack usage etc but there is only so much one can do with 32k. Mind you I could actually add a lot of interactive help once the filesystem is in place.
EDIT: Here is a link to an editable glossary that I am redoing. If there is word you are not sure about then simply insert a question above that line.
Thanks folks. Now that I get a more complete word listing, it is a bit easier to see what is there in the dictionary ... still not sure why the SMALL model gives the larger word list, but the added code space will be good. It is interesting to go from a syntax-rich/vocabulary poor programming style to the opposite in forth.
I'm going to start coding up the flux gate I2C, and use the MAX SPI 8-digit display driver (from MJB ?) to show angles etc. Trouble for me is that my current SPIN codes used floating point and matrix-like math to do the tilt compensation.
Cheers!
Comments
So you can see there isn't much PASM in the Tachyon SD interface, it mainly relies on the SPIxx instruction and a small block r/w module that gets loaded into the cog as needed. The result is that you don't need to dedicate a cog just for SD and the interface is simple and flexible as it no longer has to pass commands and parameters to a preprogrammed black box (cog).
Any board at all will run Tachyon and the system will automatically detect 5 or 10MHz crystals as well. But if you want to really test out Ethernet and of course SD then I will have to say that you really should use something like my IoT5500+P8 @96MHz which despite its very compact size really packs a punch. However it is I/O limited but interestingly no where near as limited as the Spinneret. There's still at least 9 I/O available on the small LANJACK footprint. Alternatively I do have another board that has RS485x2, RS232(5in3out), USB, SD, IoT5500 integrated, VGA + audio out and other signals on a pin header etc.
As to advantages that depends upon whom you ask but I don't sell Tachyon, I made it because Spin just wasn't fast (and compact) enough, because any other "language" either ran out of memory to gain speed or ran too slow etc. So Tachyon is based on very zippy bytecode and it's zippy because the 8-bit code is a jump address to the routine in the first 256 longs of the Tachyon VM cog. But it's fast also because the Forth kernel is tailored to suit the Propeller rather than some unpopular ANSI standard written with PCs in mind. It's also fast in terms of testing code because it is target resident and interactive so you can talk to it. The other thing about the interactive part is that it also allows you to do loops and other stuff on an interactive command line that normally requires a compiled definition in other Forths.
Also I/O devices such as LCDs, serial, VGA, etc are designed as streaming I/O so you can redirect output to the VGA rather than the serial console and it will work the same to the best of its capabilities. Normally you find many device drivers written with their own special VGA.CR and VGA.HOME and the same for other devices. In Tachyon you could type on an interactive line this little demo:
VGA PRINT" HELLO WORLD" LCD PRINT" HELLO WORLD" MORSE PRINT" HELLO WORLD" CON PRINT" HELLO WORLD"
Yes, Tachyon is a Forth so it uses a stack to hold parameters and to some people they see it as back to front, or is that front to back? If you are not locked into the mindset of seeing the world as north pole being up and south being down then there is some hope for you. But don't try to learn Tachyon, just use it and build your programs interactively by testing out little things first. Design top down in your head but implement the building blocks that the top level words/definitions will need.
How powerful and compact is it? You do know I have the compiler and kernel and utilities and virtual memory FAT32 filesystem and Ethernet web and FTP servers running on a standard Prop without any tricks or extra memory expansion cards etc. Oh, and there are still at least 5 cogs and application memory to spare.
just take any prop board, even a breadboard setup (just converted an Arduino beginner within an afternoon to a Tachyon fan)
download
Peter's Tachyon Explorer-Image from here
load it in with PropTool - RAM load will do initially unless you want to install to EEPROM
and then open a terminal at 115200 (thanks Bob)
type (with SPACES !!!)
2 2 + . <enter>
or
WORDS
or
QW
...
and you are up for running Peter's tutorial from here
re:just take any prop board, even a breadboard setup (just converted an Arduino beginner within an afternoon to a Tachyon fan)
download
Peter's Tachyon Explorer-Image from here
load it in with PropTool
and you are up for running Peter's tutorial from here
Ok for fun I tried it .
Then I opened the serial term and changed the baud rate to 11200
and typed words (because that is the only forth thing I know LOL) It spit out a bunch of words .
lshw
lsio
0226
.. error in SDCS at PCB $C3 = IF *error*.
What am I missing? I would like to download SDWORDS.FTH and I have several 128K files on the card like FILE0001.TXT, FILE0002.TXT and WORDS.DCT.
Mike
You are not missing anything Mike, PCB is not defined.
Try putting
0 == PCB
above the IFNDEF &SDCS line and recompile. Around line 64
Check the pin assignments in the IFNDEF &SDCS block to make sure they match the board you are using.
Peter usually has a header file for each board but I would prefer simple generic modules that have a config a simple config at the top to avoid this type of "user" error.
I have confirmed that this will compile but I don't use this version of SDCARD.fth,
Give it a try.
hi Mike,
while DP's suggestion might work right now,
I would suggest to follow Peter's way of creating a board-ini file.
In the old days, when Tachyon and it's components (Extend, SD, File, NW ..) changed 3 times a week it was a bad idea to rely on patching those.
Better have the board-ini file like on Peter's dropbox the CE1372.fth, SPINNERET.fth or QS.fth from the headers folder, which you load in after EXTEND.
I am sure you can adapt one of those.
Markus
here my PropBOE board ini file
"#40001 == PCB --- not sure what this is used for MJB "
This comment says it all, PCB is defined in SDCARD.fth and that's the whole problem Mike was having.
Anyway Mike MJB and myself have used Tachyon successfully so post your questions. And show us that activity board file you create.
Hi DP -
yes
SDCARD.fth should contain an and all would compile fine
SD pins could be specified later if needed.
actually I think this should NOT be in SDCARD.fth but should go in a C3.fth ini file as and in SDCARD.fth become
board specific ini files are helpful and not so hard to create.
would be good to have those for the standard boards.
when I made my PropBOE.fth ini file I searched Peter's source files and could not find a use for PCB,
this change in SDCARD.fth has been introduced later.
@mike welcome to TACHYON, it is good of the Tachyon community grows a bit.
Tachyon may be the greatest thing since sliced bread for the Prop but it seems most are stuck with a fixed mindset and think as if RPN was the defining factor too. Reverse is just a word that gets applied when it's different from how things are traditionally done when it could just as well have been the other way around traditionally. In the "RPN" world (from this world's view) everyone would say that A = B + C is so difficult and back to front when you have already started with B and C, well you just add (+) them, then store (!) the result in A, with the compiled instructions looking exactly like that.
@K6MLE: The VGA driver could be replaced with a suitably modified version of a TV object but I've been too busy to look myself though.
Is there a serial version of your Propeller Hardware Explorer? I see a link to a VGA version in your signature.
Obviously you haven't tried that then
sounds like a quite compute intense task to me
and then it is probably better run in a PASM COG than multiple TACHYON COGs.
Of course you then can use it from TACHYON
I have the kernel+EXTEND (2.7) running on a USB Protoboard, and will be trying the SD codes soon. When I ask for WORDS or QWORDS I see a list of 167 predefines, but this is far less than are shown on the google docs "Introduction". For example, ==, pri, pub don't show up. Variable is in the Introduction document, but Tachyon 2.7 doesn't know it. This is making it tough to know what is there to build on... and I know there is a lot here.
Am I missing something? Do I dig into the source for this ?
Hi Paul, welcome to the party! I'm just getting back into the Tachyon seat myself and starting to tidy a few things up before I release some new enhancements both for P1 and P2.
Your terminal emulator may be trying to do handshaking as it may not be keeping up with the listing. turn off handshaking or slow down the baud rate with "57600 CONBAUD", reset and try again. Also soft handshake had been rendered useless by the PC's use of large transmit/receive buffers that queue the handshake characters along with all the other characters. I recommend using either TeraTerm if you are on Windows or minicom on Linux.
There are a lot of traditions in Forths that should have been left in the past and in my opinion the use of VARIABLE is one of them. I want to be able to say what kind of variable, how many of them, and also include others in the same list rather than having a line for each and every one of them. The other thing is sometimes you just want to allocate an area just for buffers and variables, you don't want Forth code headers mixed in there as it can be a battlefield and sometimes you just need to wipe the whole area, so keep code clear of it. This is how I do it:
To declare a plain variable we say: LONG <myvar>
Now if we just want a byte: BYTE <myvar>
If we want 20 bytes: 20 BYTES <myvar>
Of we could have a list of variables: LONG <myvar>,<tempvar>,<bufvar>,<sotherevar>
Perhaps we want that battlefield so we allocate an area like we do in SDCARD.fth: 176 BYTES sdinfo
Then we can use that as the ORG for allocating Data Storage units like this: So cid for instance is actually compiled as a address constant pointing to the area in sdinfo. This works the same as any variable too.
Have a look at that for now and see how you go.
I see that you are doing several things to make Tachyon look/feel like Spin. I was using == thinking they were variables, but I see == is aliased to CONSTANT (or other way about?) . Is there a real difference between constants and variables in Tachyon ?
Pretty cool stuff.
That's my take on this aspect but it does not fundamentally change Forth from a programmer's perspective though. Under the hood it is quite different and it is unlike some Forths that try to be ANSI compliant for which I can't understand why because most of the ANSI stuff was obviously designed with resource abundant PCs in mind whereas we are working in the nitty-gritty world of microcontrollers and getting the most out of the least!
TeraTerm works fine up to 921600 baud as far as I remember but typically I either run my systems at 115200 for compatibility or at 2M baud if I want a zippy screen update such as with SPLAT.
Last Q for now : for a typical program, is the Tachyon version expected to take up more or less space than the Spin equivalent? I know 'it depends', but I'll bet you have a sense of which way the size goes. Speed seems to be a hands-down win for Tachyon. With the kernel + EXTEND I have 5.7K free, still need SD, MULTIFATS, (sp?) and the program.
Actually, what I likethe most about Tachyon is that it forces you to think about what's going on.
if you really want to learn Tachyon there is no way around reading the source code.
Start with EXTEND.fth and later the Tachyon kernel itself.
This is also a great learning in PASM itself - that'S how I started with the propeller just exactly when Peter started his Tachyon.
At that time almost without documentation.
btw. WORDS gives the full words list QWORDS is the quick and short version of it.
And if you need more space the dictionary can be offloaded to higher EEPROM or SD card.
have fun
Markus
In terms of how compact Tachyon is compared to Spin I know that even though they both use bytecodes albeit quite differently, and even though Tachyon interactive compiles and resides on the Prop itself rather than compiles on a PC, and even though Tachyon's symbol table (dictionary) resides in Prop memory, that I can still run as mentioned the full network system with FAT32 and application which is not something I have seen done in Spin or any PC compiled "language" (CMIIW).
Here is the QWORDS listing from the Prop I'm working on which has the filesystem loaded plus some test code.
As MJB mentioned about reading the source code while it can help a lot I suppose that it is more helpful when you get stuck as looking at the source can shed some light on the inner workings. I try to keep things simple and practical and it would be nice if TF interactively suggested code completion and stack usage etc but there is only so much one can do with 32k. Mind you I could actually add a lot of interactive help once the filesystem is in place.
EDIT: Here is a link to an editable glossary that I am redoing. If there is word you are not sure about then simply insert a question above that line.
you might want to have a look here as well,
where I collect interresting snippets of Peters forum comments.
https://docs.google.com/document/d/1tMlS3Oa8Sqa4LD90inoA9-JfhzuG_8m-yphxWHdFlZM/edit
I'm going to start coding up the flux gate I2C, and use the MAX SPI 8-digit display driver (from MJB ?) to show angles etc. Trouble for me is that my current SPIN codes used floating point and matrix-like math to do the tilt compensation.
Cheers!