@RS_Jim - My bad, I was testing on a board that runs a 6MHz crystal and must have inadvertently saved the file. Since the Spin tool doesn't have conditional compile directives I use the old trick of using the block comment { and enabling and disabling which one I want with the line comment ' symbol. Both closing } are preceded by a ' so that they work either way and don't need to be removed or added. Got that? Q&D fixes are also good for sanity checks
BTW, There is a 5v6A version which will become the 5v6 version. There are small speed improvements I'm testing.
I set up some Propeller related CMaps on a public server and now include the link into my signature. Will do this for Tachyon also trying to create order to a creative chaos
I was looking for using IoT5500+P8 to access another webserver
(wunderground.com) to upload weather data.
I wanted to try GETTIME S n example of server access,
but see it is using UDP, but I need FTP.
And it is not working ... Tachyon hangs
sCONNECT I see is commented out now,
which to my memory from years ago
was used to open a socket connection to a server.
of course I can activate it, and make it to work.
Should not be much, as most is already there.
I probably just use sCONNECT to the server, then write my message
and poll for the reply/confirmation. CLOSE socket.
But faster would be if you happen to have an example somewhere already.
@MJB - admittedly I have really only used EASYNET as a server but there is probably a bit I could do to make it easier to connect to a server. I'm redoing EASYFILE at the moment to include permissions and more flexible file creation and also to iron out any little bugs. After that I will look at EASYNET again and add some extra functionality to it as well.
@MJB - admittedly I have really only used EASYNET as a server but there is probably a bit I could do to make it easier to connect to a server. I'm redoing EASYFILE at the moment to include permissions and more flexible file creation and also to iron out any little bugs. After that I will look at EASYNET again and add some extra functionality to it as well.
Thanks for looking into this.
I see you started to code GETTIME anď RESOLVE to convert URL to IP
Then CONNECT and the socket should be open.
W5500 will do most of the work.
Peter seems like a very happy young man looking forward to a bright and wonderful future. So nice to see! We aside have to bring TACHYON into action and be gretaful to him all over space and time!
I am in the process of consolidating both P1 and P2 versions of EASYFILE and EASYNET into one version that can be easily maintained.
However in the process of speeding up compilation I have improved the normal search speed and added a fast search during TACHYON/END block loads.
This means that the line delay can be dropped to 1ms even at 2M baud and pasting the source files into the terminal takes a just a few seconds.
If you want to try the test versions just use 5v6A kernel and EASYFILE2 but these files are only temporary and will become the 5v7 kernel due to these improvements and simply EASYFILE and EASYNET when I have finished testing.
btw there was a big bug in EASYFILE on the P1 which while counting clusters wasn't allocating those clusters when a new file was created.
I have tried to use TACHYON5r6A.SPIN and EASYFILE2.FTH.
I get the following error
0086 ??? in PORT at NUMBER
during paste of FTP.FTH now.
In
pre PORT \ accept port number
LANLED.ON
GETWORD NUMBER dataport W!
LAN PRINT" 200 Port is now " dataport W@ PRINT CR
;
the line
GETWORD NUMBER dataport W!
gets this error, because
NUMBER
is not known any more at the moment.
(NUMBER ( str -- val digits | false ) X Convert a string to a number if possible)
Since in EASYFILE2.FTH we get the information, that GETWORD is depricated and DEFER should be used
(170716 Deprecated GETWORD and using DEFER instead),
I have changed the Glossary of Tachyon words accordingly.
@Prop1Tach - make sure you are using all the latest files including EXTEND which renamed NUMBER to STR>NUM for standardization since there is a NUM>STR function as well.
@Prop1Tach - I see that and have fixed that up too. I'm using 1ms line delay with the latest version and can do a complete build including FTP in under 30 seconds.
"I've started breaking up Tachyon into lots of smaller include files... "
Hello Peter
Just my wish... not being a programmer, my wish is for a bare-bone Tachyon with
a word set for the hardware of the prop, notably the many ways counters
can be used in tandem with the tri-state I/O.
I guess I should just start using PASM, however I'm a fan of old style Forth where
playing with the hardware was easy and productive.
So.. the question. will your parcelling of Tachyon permit compiling a tailor-made Tachyon
just for me?
Serge
"old style Forth" can mean many things
If you mean a full interactive target resident Forth, then that is what Tachyon is. However asking for a "bare-bone" "tailor-made" Tachyon is contrary to what Tachyon is. It already has practically all the counter modes built-in but asking for just these is like asking for the 10th floor apartment but not wanting all the other floors. Forth is built up on Forth, and the counter words are built up on smaller words built up on Forth etc.
However there is no point in asking anything if you haven't tried it. Just load up a binary or load the kernel and paste in EXTEND which has all the counter extensions, if you want to do it manually.
Counter examples:
4 BLINK ( make an LED on P4 blink using a counter )
10 HZ ( make it blink faster )
A 3 APIN 1 MHZ ( output a 1MHZ signal using the A counter on P3 )
B 2 APIN 38,500 HZ ( output a 38,500HZ signal using the B counter on P2 )
1.250 4 VOLTS ( output 1.25V on P4 via an RC network using the last counter selected )
Then there are the ones optimized for audio tones, here are some:
5 SPKR ( select P5 to output an audio signal )
BEEP
SIREN
RING
3 RINGS
500 100 TONE ( output a 500HZ tone for 100 ms )
CLICK
Then there are all the edge detect modes, just string them together like "POS EDGE DETECT" etc to configure the pin etc. The FREQ@ word is a simple word built upon these modes to measure frequency.
Of course all the low levels of these counter modes are available to interact with but you can't interact if you haven't even loaded Tachyon onto your Prop.
--- Open or create a file
pub FMAKE$ ( name -- flg )
--- create default 1MB file if it doesn't exist
FOPEN$ NOT IF 1 MB FILE$ FCREATE$ FOPEN$ THEN
;
FOPEN$ returns the SECTOR address
so FMAKE$ should to ??
here if the file exists nothing is left on the stack ?
and the stack comment should read "sector" not "flg" ??
--- Open or create a file
pub FMAKE$ ( name -- flg )
--- create default 1MB file if it doesn't exist
FOPEN$ NOT IF 1 MB FILE$ FCREATE$ FOPEN$ THEN
;
FOPEN$ returns the SECTOR address
so FMAKE$ should to ??
here if the file exists nothing is left on the stack ?
and the stack comment should read "sector" not "flg" ??
I already came to the same point and tried to document it HERE. Now, as I tried to point to (t)here, I found: it just doesn't work that way. So I started a new multi stage way to identify questions already asked, starting there
I find this to be a good idea: if you have a question the first quest is to find the right words. So you will not get an answer, if the question was never raised. I try to break up questions into a tree structure and so everybody should be able to follow a decision tree: is this the question I also have or was my question never asked. I the first case climbing the tree may lead to an answer. In the second case a normalized question can be asked and an answer may be found in the forum. This answer then completes the tree.
This tree will be a tree of fame. The branches will show who asked the question first, the leafs will document who fed the first answer (if wanted) As CMap tools is free to use, hopefully others will contribute.
Like many "flags" in Tachyon, if the flag is true, it can also carry information such as a sector address. Why not?
A sector address of 0 cannot be a file. The starting sector can still be recalled at any time.
However as mentioned previously I am consolidating the TACHYON and TAQOZ versions into one although there are some low level differences still, but one source. In the process I am continuing to rethink how I want it to operate and how it could be better. I abhor fragmented files and following cluster chains, there is no need for it when a linear system is so efficient, and besides, unlike a Windows hard drive that is continually thrashing the files, for all practical concerns there just isn't any fragmentation that occurs with data files on an SD card in an embedded system such as with the Propeller.
When I create an unknown file I preallocate clusters since memory is very cheap and a default 1MB allocation for a new file may seem absurd when it only ends up ever being 1kB max. However this approach is pragmatic given the runtime requirements of an embedded system and even when the cards were only 4GB that meant it would take 4,000 1MB files before a clean-up might be needed, but that never happens, so why bother. Now 16GB and 32GB are the smallest cheapest cards. The new unknown size file though would always be created after any used clusters so it could grow to 4GB using consecutive clusters during the transfer if needed.
BTW, I do welcome feedback and ideas on how to improve the file system and Tachyon in general, based though not on traditional or academic philosophies, but stuff that just works and cuts through the cruft.
Hi Peter, while you are absolutely right, that there is no difference between unused resourses and allocated unused resources, traditional thinking is different. Limited resources are depleted to gain an advantage, no matter what happens after. On the other hand memory is saved and fragmented, as if we still use magnetic core memories. If for now Tachyon allocates large chunks of memory, that is not used, you are still free to later search for such memory islands and stick them together to hold fragmented files. So I'm perfectly fine with that kind of kind thinking.
Long ago I came up with the idea to spend one kilobit to store a bit and realized, that until the moment I can make use of this idea, a kilobit will be a cheap as a bit today, so the idea will be feasible. In the meantime, the price went down by six decades, So the idea could be brilliant. But there is traditional thinking around.
But for now I have to get familiar with Tachyon, what will take some more time and in doing so I have to consolidate all the questions you have answered over the years, therefore I started the "How to"
--- Open or create a file
pub FMAKE$ ( name -- flg )
--- create default 1MB file if it doesn't exist
FOPEN$ NOT IF 1 MB FILE$ FCREATE$ FOPEN$ THEN
;
FOPEN$ returns the SECTOR address
so FMAKE$ should to ??
here if the file exists nothing is left on the stack ?
and the stack comment should read "sector" not "flg" ??
@"Peter Jakacki"
But returning nothing when the file exists is a bug ... isn.t it?
@ErNa - it's worse than that! Not only is there a test version of EASYFILE but there is also the TAQOZ version being rehashed, all into one. So all those goodies that I've done for TAQOZ including formatting etc will work on the P1 too! In the process Tachyon and TAQOZ will be more compatible which may involve some renaming etc so that the new Tachyon will become a V6 Turbo. Part of this testing involves digging out dozens of different designs of mine and checking it on them too. I am even playing with one of Cluso99's P8XBlade2 modules that I had to replace the crystal with a 6Mhz cylindrical type to get it working though. Wonder what was wrong with it?
If it weren't for compatibility I would never bother with any MS filesystem. Besides none of them are really designed for SD cards or embedded systems. But I try to make the best of it by imposing my own operating conditions once it is in a system.
Hi Peter, compatibility is a must, so we can switch freely between P1 and P2, a larger number normally means some progress, but there may be a dump some time. As we don't no the question to the answer 42. So more of my questions will be answered and I will continue with my How-2-Tachyon. As all starts from the first sector, which may be a MBR, it should be possible to create a decision tree to follow to find out the actual file system.
pri APPEND.BLK ( -- relblk )
FSECT@ FSIZE@ 9 >> OVER+ SWAP ( max min )
BEGIN
--- Find new mid point ( max min mid )
2DUP - 2/ OVER+
--- flag scan method ( max min )
SECTOR DROP
2DUP - 1 >
WHILE
--- if true then too high ( max min flg )
sdbuf C@ scanch C@ =
IF 2DUP - 2/ OVER+ ROT DROP SWAP
ELSE 2DUP - 2/ OVER+ NIP
THEN
REPEAT
NIP FSECT@ -
;
where
2DUP - 2/ OVER+
could be shortened to
2DUP + 2/
or maybe this
pri APPEND.BLK ( -- relblk )
FSECT@ FSIZE@ 9 >> OVER+ SWAP ( max min )
BEGIN
--- Find new mid point
2DUP + 2/ ( max min mid )
--- flag scan method
SECTOR DROP ( max min )
2DUP - 1 >
WHILE
2DUP + 2/ ( max min mid )
--- if true then too high
sdbuf C@ scanch C@ =
IF ROT DROP SWAP
ELSE NIP
THEN
REPEAT
NIP FSECT@ -
;
But I'm not working on EASYFILE anymore. Well, what I mean is that I'm doing something to replace it that is a lot more versatile and handles different media etc. At the moment it is still in its early stages as I sort out the structures and classes required to support multiple SD, SPI Flash, EEPROM, and maybe even Hyperbus memory. I expect to have something up and running by next week though.
At the higher levels it has defining words to create new media classes and devices etc. Here's a sample I'm playing with although that may change radically as I play it out.
--- create a new device class called SD using SDCMDS to access read/write/init/stat functions etc
CLASS: SD SDCMDS ;
--- create new SD device called SD0 using specified pins
DEVICE: SD0 SD &27.24.26.25 ;
--- SERIAL FLASH CLASS
CLASS: SF SFCMDS ;
--- create new SPI FLASH device
DEVICE: SF0 SF &23.24.26.25 ;
--- create a FCB handle called LEXICON that uses SD CLASS DEVICE SD0
FILE: LEXICON SD0 FAT32 ;
--- using LEXICON open a file by the same name called LEXICON.TXT
LEXICON FOPEN" LEXICON.TXT"
So every open file has a file control block that maintains a copy of the directory entry and buffers up to four individual sectors along with write flags and permissions etc. File size is maintained in this fcb and only flushed automatically whenever any data sector needs to flushed.
To simplify things a sector will always be 512 bytes even if it is EEPROM or Flash, and also the directory entry is FAT32 style. Small memories don't need cluster tables etc and the largest serial EEPROM of 2Mbit would only hold a total of 512 sectors anyway. The FORMAT will be able to setup these other memories as if they were FAT32 to the filesystem which also makes it possible to load and save files between devices and SD easily. I have systems with 16MB of SPI Flash for instance that would be sufficient for most tasks and would still allow for their files to be backed up to an SD card when needed. The same also for battery backed PSRAM such as the 64Mbit 8-pin ones from Lyontek which would allow for fast and constant updates before backing up to SD or accessed over FTP.
The focus at present though is on getting SD FAT32 up and running smoothly with a common source for both the P1 and P2.
EDIT: Already I can see now that I reduced the class methods to a single command function, that I don't even need CLASS: anymore.
A newbie here ... I have about 10 of the DEFCON 20 badges available to me and was wondering if one of the Forth wizards here could give me tips on getting Tachyon working on either serial terminal setup or VGA? Serial terminal is fine to start with... what is the best version to use for this P1 based board? What are the serial terminal settings and what tool is best for transferring the file to the P1?
A newbie here ... I have about 10 of the DEFCON 20 badges available to me and was wondering if one of the Forth wizards here could give me tips on getting Tachyon working on either serial terminal setup or VGA? Serial terminal is fine to start with... what is the best version to use for this P1 based board? What are the serial terminal settings and what tool is best for transferring the file to the P1?
via the footer on posts of @"Peter Jakacki" go to dropbox and download the V5 folder.
there you will find most of what you need.
i use BST but Proptool should work as well.
best start with a premade image.
then take the sources in the editor and start reading ...
Yes, just try one of the binaries such as the "Latest Tachyon...." link in my sig. These will automatically work with 5 or 10MHz crystals and normally the baud rate is 115200 but if not try 921600
The binary includes FAT32 and the VGA capabilities can be added with a simple copy and paste. The thing is, don't hold back just click, download, and program the Prop.
EDIT: I found a copy of the schematic (I think it's the right one) that I have attached now. Nothing unusual, so everything should just work.
I used the command line tool under Linux; I think that loading the file into PropellerIDE added some line breaks or something which prevented it from working. Certainly it is working now!
Comments
BTW, There is a 5v6A version which will become the 5v6 version. There are small speed improvements I'm testing.
I used 5.6a to set up my s board! Thanks for the insight re comments.
Jim
I was looking for using IoT5500+P8 to access another webserver
(wunderground.com) to upload weather data.
I wanted to try GETTIME S n example of server access,
but see it is using UDP, but I need FTP.
And it is not working ... Tachyon hangs
sCONNECT I see is commented out now,
which to my memory from years ago
was used to open a socket connection to a server.
of course I can activate it, and make it to work.
Should not be much, as most is already there.
I probably just use sCONNECT to the server, then write my message
and poll for the reply/confirmation. CLOSE socket.
But faster would be if you happen to have an example somewhere already.
I see you started to code GETTIME anď RESOLVE to convert URL to IP
Then CONNECT and the socket should be open.
W5500 will do most of the work.
However in the process of speeding up compilation I have improved the normal search speed and added a fast search during TACHYON/END block loads.
This means that the line delay can be dropped to 1ms even at 2M baud and pasting the source files into the terminal takes a just a few seconds.
If you want to try the test versions just use 5v6A kernel and EASYFILE2 but these files are only temporary and will become the 5v7 kernel due to these improvements and simply EASYFILE and EASYNET when I have finished testing.
btw there was a big bug in EASYFILE on the P1 which while counting clusters wasn't allocating those clusters when a new file was created.
I have tried to use TACHYON5r6A.SPIN and EASYFILE2.FTH.
I get the following error during paste of FTP.FTH now.
In the line gets this error, because is not known any more at the moment.
(NUMBER ( str -- val digits | false ) X Convert a string to a number if possible)
Since in EASYFILE2.FTH we get the information, that GETWORD is depricated and DEFER should be used
(170716 Deprecated GETWORD and using DEFER instead),
I have changed the Glossary of Tachyon words accordingly.
If I change NUMBER to STR>NUM in FTP.FTH, I can paste it without an error.
But I have downloaded FTP.FTH this morning and there is still instead of there.
In the Glossary of Tachyon words I have changed NUMBER to STR>NUM.
Thank you.
so FMAKE$ should to ??
here if the file exists nothing is left on the stack ?
and the stack comment should read "sector" not "flg" ??
I find this to be a good idea: if you have a question the first quest is to find the right words. So you will not get an answer, if the question was never raised. I try to break up questions into a tree structure and so everybody should be able to follow a decision tree: is this the question I also have or was my question never asked. I the first case climbing the tree may lead to an answer. In the second case a normalized question can be asked and an answer may be found in the forum. This answer then completes the tree.
This tree will be a tree of fame. The branches will show who asked the question first, the leafs will document who fed the first answer (if wanted) As CMap tools is free to use, hopefully others will contribute.
A sector address of 0 cannot be a file. The starting sector can still be recalled at any time.
However as mentioned previously I am consolidating the TACHYON and TAQOZ versions into one although there are some low level differences still, but one source. In the process I am continuing to rethink how I want it to operate and how it could be better. I abhor fragmented files and following cluster chains, there is no need for it when a linear system is so efficient, and besides, unlike a Windows hard drive that is continually thrashing the files, for all practical concerns there just isn't any fragmentation that occurs with data files on an SD card in an embedded system such as with the Propeller.
When I create an unknown file I preallocate clusters since memory is very cheap and a default 1MB allocation for a new file may seem absurd when it only ends up ever being 1kB max. However this approach is pragmatic given the runtime requirements of an embedded system and even when the cards were only 4GB that meant it would take 4,000 1MB files before a clean-up might be needed, but that never happens, so why bother. Now 16GB and 32GB are the smallest cheapest cards. The new unknown size file though would always be created after any used clusters so it could grow to 4GB using consecutive clusters during the transfer if needed.
BTW, I do welcome feedback and ideas on how to improve the file system and Tachyon in general, based though not on traditional or academic philosophies, but stuff that just works and cuts through the cruft.
Long ago I came up with the idea to spend one kilobit to store a bit and realized, that until the moment I can make use of this idea, a kilobit will be a cheap as a bit today, so the idea will be feasible. In the meantime, the price went down by six decades, So the idea could be brilliant. But there is traditional thinking around.
But for now I have to get familiar with Tachyon, what will take some more time and in doing so I have to consolidate all the questions you have answered over the years, therefore I started the "How to"
@"Peter Jakacki"
But returning nothing when the file exists is a bug ... isn.t it?
If it weren't for compatibility I would never bother with any MS filesystem. Besides none of them are really designed for SD cards or embedded systems. But I try to make the best of it by imposing my own operating conditions once it is in a system.
while you work on EASYFILE
I found this
where
could be shortened to
or maybe this
But I'm not working on EASYFILE anymore. Well, what I mean is that I'm doing something to replace it that is a lot more versatile and handles different media etc. At the moment it is still in its early stages as I sort out the structures and classes required to support multiple SD, SPI Flash, EEPROM, and maybe even Hyperbus memory. I expect to have something up and running by next week though.
At the higher levels it has defining words to create new media classes and devices etc. Here's a sample I'm playing with although that may change radically as I play it out.
So every open file has a file control block that maintains a copy of the directory entry and buffers up to four individual sectors along with write flags and permissions etc. File size is maintained in this fcb and only flushed automatically whenever any data sector needs to flushed.
To simplify things a sector will always be 512 bytes even if it is EEPROM or Flash, and also the directory entry is FAT32 style. Small memories don't need cluster tables etc and the largest serial EEPROM of 2Mbit would only hold a total of 512 sectors anyway. The FORMAT will be able to setup these other memories as if they were FAT32 to the filesystem which also makes it possible to load and save files between devices and SD easily. I have systems with 16MB of SPI Flash for instance that would be sufficient for most tasks and would still allow for their files to be backed up to an SD card when needed. The same also for battery backed PSRAM such as the 64Mbit 8-pin ones from Lyontek which would allow for fast and constant updates before backing up to SD or accessed over FTP.
The focus at present though is on getting SD FAT32 up and running smoothly with a common source for both the P1 and P2.
EDIT: Already I can see now that I reduced the class methods to a single command function, that I don't even need CLASS: anymore.
via the footer on posts of @"Peter Jakacki" go to dropbox and download the V5 folder.
there you will find most of what you need.
i use BST but Proptool should work as well.
best start with a premade image.
then take the sources in the editor and start reading ...
The binary includes FAT32 and the VGA capabilities can be added with a simple copy and paste. The thing is, don't hold back just click, download, and program the Prop.
EDIT: I found a copy of the schematic (I think it's the right one) that I have attached now. Nothing unusual, so everything should just work.
/opt/parallax/bin/propeller-load -r TACHYON.binary
Now all I have to do is learn Forth! :-D