" MYFILE.TXT" leaves a pointer to that string on the stack. So either interactively or compiled we would use FOPEN$ which expects a string pointer which after executing leaves a flag on the stack, zero/false if that failed or the sector address which can also be taken as a true flag. Either way this can be read again with @FILE. There are 4 buffers including the directory entry for each open file. Normally a file opens as read-only but a RW or append directive is used when we intend to write.
To dump a file I forgot to add the FS modifier as dump is normally used to do a hex and ASCII memory dump. Use ram or sf or sd for flash or sd raw etc.
Peter, I've been reading your intro to Tachyon for Propeller. This is amazing. It's so low level, but intuitive. It's like building drivers in real time. It's really appealing- I'm going to give it a shot over this holiday break while I tend to me girlfriend and newborn (3 days until the c section).
Also Peter, I've thought long and hard about my implementation and project requirements and decided the best solution would be, at least for the prototype, to use a Raspberry Pi B+ to send data over UART to the prop and allow the prop to function simply as an overpowered I/O chip. Do you think I'll find any trouble programming the prop from a raspi? Is that even possible with it loaded with Tachyon? I know the SimpleIDE has been ported to raspi.
Also Peter, I've thought long and hard about my implementation and project requirements and decided the best solution would be, at least for the prototype, to use a Raspberry Pi B+ to send data over UART to the prop and allow the prop to function simply as an overpowered I/O chip.
I don't know, what you need the RasPi for ... - SD filesystem and even NW + FTP / webserver are possible with prop & Peter's WizNet interface.
Do you think I'll find any trouble programming the prop from a raspi? Is that even possible with it loaded with Tachyon? I know the SimpleIDE has been ported to raspi.
When running Tachyon there is no conventional programming & IDE any more - no SimpleIDE needed. You just send new code, like commands on serial. You try it out. And when it works you do a BACKUP .... done.
Unfortunately, I've been having a very hard time getting started with Tachyon. I've looked through the source code .spin file and can see all of the functions, but I don't have a month to cross reference each PASM function and work through what each Tachyon dictionary entry actually does. Learning it is definitely a long time goal because I can see it's obviously a very powerful environment for programming.
If you have never realty used forth before this sometimes seems like a steep learning curve, everything is so strange as you try to take it all in. However forth encourages interactive incremental programming so the thing is not to take it all in in one go. Start off with just implementing interactively some simple base functions and build your program from those simple blocks that you have already tested and understand. That's how I started, just writing a couple of lines of code and seeing it work, very different from a full on pre thought out before I knew what i was really doing exercise while I wrangled with the compiler itself.
If you can very briefly describe what you are trying to do we can start off with some simple functions and get them to work. Many times the inspiration of that early part helps you to see a simpler and better way of approaching the problem.
Thanks Peter, a lot of what I feel is missing for me is probably example programs to reference. Among the dozens, if not hundreds, of words in the standard and extended TF dictionaries, I'd really appreciate just a little guidance in terms of what functions are extremely important, common, or powerful; I've noticed COGREG is used in almost every function.
As for what I'd like to accomplish, I'd like to write a program that receives a byte/number through the serial terminal (I'm using teraterm, per your recommendation), and sends it serially to a 595 shift register. I admit I haven't done much in terms of device driver design, and I'm sure a 595 is almost certainly compatible with the SPI function in the TF dictionary, for an excersize I think it'd be great to help introduce me to key functions and concepts. And a 595 is simple enough a device that it would be less a project on figuring out how to use a device than to use Tachyon.
Thanks Peter, a lot of what I feel is missing for me is probably example programs to reference. Among the dozens, if not hundreds, of words in the standard and extended TF dictionaries, I'd really appreciate just a little guidance in terms of what functions are extremely important, common, or powerful; I've noticed COGREG is used in almost every function.
As for what I'd like to accomplish, I'd like to write a program that receives a byte/number through the serial terminal (I'm using teraterm, per your recommendation), and sends it serially to a 595 shift register. I admit I haven't done much in terms of device driver design, and I'm sure a 595 is almost certainly compatible with the SPI function in the TF dictionary, for an excersize I think it'd be great to help introduce me to key functions and concepts. And a 595 is simple enough a device that it would be less a project on figuring out how to use a device than to use Tachyon.
Just to get started then it couldn't be simpler but first you need to setup your I/O pins with the SPIPINS word which expects one byte encoded long that specifies the clock, data out, data in, and chip select. For the 595 you could drive it with as little as 2 I/O if perhaps you were just using LEDs but let's use 3 lines so that the chip select signal ends up clocking the latch after it's done. First the setup, assume we use P0 for the clock, P1 for the data and P2 for the latch:
&02.01.01.00 SPIPINS
The & notation encodes decimal bytes in much the same manner we encode IP masks like 255.255.255.0 etc where each group represents a byte. This notation is compact and efficient and it is also just as easy to make that mask a constant if we want to reuse it like this:
&02.01.01.00 == HC595
So you could just as easily say:
HC595 SPIPINS
Now this sets up the masks and direction of the pins ready to be used by any of the SPIWR and SPIRD variants and the data in could be anything if we are not using it but in this case I set it the same as the data out. By default any reference to an SPI routine will automatically enable the chip select and when we are done with it all we can manually deselect the SPI device. For the HC595 this deselect means the "latch clock" goes from low to high which will transfer the shift-register contents to the output latch internally in the 595.
From the top and all in one interactive line let's try to send $F1 to the 595:
&02.01.01.00 SPIPINS $F1 SPIWRB DROP 2 HIGH
That was too easy, but what happened? Well after setting up the I/O mask for the SPI port we told it to write a byte to the SPI port and then take the chip select (latch clock) high. The SPIWR leaves the rotated left data on the stack so we can continue on with another byte in the long etc but in this case we discard it with DROP.
How about another one-liner after we have done this that counts up through a byte with a delay:
0 256 ADO I SPIWRB DROP 20 ms LOOP
The ADO is basically the same as DO in Forth except it expects a start index and a count so we start from 0 and loop 256 times where "I" fetches the current loop index value onto the stack then passes that to SPIWRB after which we discard it and wait for 20 ms before looping.
If you chained four 595 shift registers together for 32-bits you could send like this:
$F102A455 SPIWR DROP 2 HIGH
You can build the basics into your own definition easily enough now that you can see how it works, very simple really.
Thanks Peter, a lot of what I feel is missing for me is probably example programs to reference. Among the dozens, if not hundreds, of words in the standard and extended TF dictionaries, I'd really appreciate just a little guidance in terms of what functions are extremely important, common, or powerful; I've noticed COGREG is used in almost every function.
As for what I'd like to accomplish, I'd like to write a program that receives a byte/number through the serial terminal (I'm using teraterm, per your recommendation), and sends it serially to a 595 shift register. I admit I haven't done much in terms of device driver design, and I'm sure a 595 is almost certainly compatible with the SPI function in the TF dictionary, for an excersize I think it'd be great to help introduce me to key functions and concepts. And a 595 is simple enough a device that it would be less a project on figuring out how to use a device than to use Tachyon.
Hi GIS,
sure the first place to start is the Introduction from Peter's footer.
Reading the Tachyon source is great if you understand or wnat to learn PASM and go really in deep on Tachyon. That is how I got into PASM and FORTH in the very early days of Tachyon.
Then a next step is EXTEND.fth
And here https://docs.google.com/document/d/1tMlS3Oa8Sqa4LD90inoA9-JfhzuG_8m-yphxWHdFlZM/pub is my collection mostly of Peter's code / explanation snippets from the Tachyon thread.
AND you can ask here in the forum - of course ;-)
have fun
Markus
Comments
To dump a file I forgot to add the FS modifier as dump is normally used to do a hex and ASCII memory dump. Use ram or sf or sd for flash or sd raw etc.
Peter has proved just what can be done quite simply. Better yet, he has put Tachyon out there for all to see and use!
Also Peter, I've thought long and hard about my implementation and project requirements and decided the best solution would be, at least for the prototype, to use a Raspberry Pi B+ to send data over UART to the prop and allow the prop to function simply as an overpowered I/O chip. Do you think I'll find any trouble programming the prop from a raspi? Is that even possible with it loaded with Tachyon? I know the SimpleIDE has been ported to raspi.
Just any editor and a terminal will do.
If you can very briefly describe what you are trying to do we can start off with some simple functions and get them to work. Many times the inspiration of that early part helps you to see a simpler and better way of approaching the problem.
As for what I'd like to accomplish, I'd like to write a program that receives a byte/number through the serial terminal (I'm using teraterm, per your recommendation), and sends it serially to a 595 shift register. I admit I haven't done much in terms of device driver design, and I'm sure a 595 is almost certainly compatible with the SPI function in the TF dictionary, for an excersize I think it'd be great to help introduce me to key functions and concepts. And a 595 is simple enough a device that it would be less a project on figuring out how to use a device than to use Tachyon.
Just to get started then it couldn't be simpler but first you need to setup your I/O pins with the SPIPINS word which expects one byte encoded long that specifies the clock, data out, data in, and chip select. For the 595 you could drive it with as little as 2 I/O if perhaps you were just using LEDs but let's use 3 lines so that the chip select signal ends up clocking the latch after it's done. First the setup, assume we use P0 for the clock, P1 for the data and P2 for the latch:
&02.01.01.00 SPIPINS
The & notation encodes decimal bytes in much the same manner we encode IP masks like 255.255.255.0 etc where each group represents a byte. This notation is compact and efficient and it is also just as easy to make that mask a constant if we want to reuse it like this:
&02.01.01.00 == HC595
So you could just as easily say:
HC595 SPIPINS
Now this sets up the masks and direction of the pins ready to be used by any of the SPIWR and SPIRD variants and the data in could be anything if we are not using it but in this case I set it the same as the data out. By default any reference to an SPI routine will automatically enable the chip select and when we are done with it all we can manually deselect the SPI device. For the HC595 this deselect means the "latch clock" goes from low to high which will transfer the shift-register contents to the output latch internally in the 595.
From the top and all in one interactive line let's try to send $F1 to the 595: That was too easy, but what happened? Well after setting up the I/O mask for the SPI port we told it to write a byte to the SPI port and then take the chip select (latch clock) high. The SPIWR leaves the rotated left data on the stack so we can continue on with another byte in the long etc but in this case we discard it with DROP.
How about another one-liner after we have done this that counts up through a byte with a delay:
The ADO is basically the same as DO in Forth except it expects a start index and a count so we start from 0 and loop 256 times where "I" fetches the current loop index value onto the stack then passes that to SPIWRB after which we discard it and wait for 20 ms before looping.
If you chained four 595 shift registers together for 32-bits you could send like this:
$F102A455 SPIWR DROP 2 HIGH
You can build the basics into your own definition easily enough now that you can see how it works, very simple really.
Hi GIS,
sure the first place to start is the Introduction from Peter's footer.
Reading the Tachyon source is great if you understand or wnat to learn PASM and go really in deep on Tachyon. That is how I got into PASM and FORTH in the very early days of Tachyon.
Then a next step is EXTEND.fth
And here https://docs.google.com/document/d/1tMlS3Oa8Sqa4LD90inoA9-JfhzuG_8m-yphxWHdFlZM/pub is my collection mostly of Peter's code / explanation snippets from the Tachyon thread.
AND you can ask here in the forum - of course ;-)
have fun
Markus