you can easily define a string-output-stream by revectoring EMIT to
BYTE bufptr
$FF BYTES mystr
pub EMIT2$ ( char .. ) mystr bufptr + C! bufptr C++ ;
pub to$ ' EMIT2$ uemit W! ;
/// then
to$
/// now you can use any print routines redirected to your string ...
CON /// resets to normal EMIT
I did a generalized version of this for T2, but would need to search for it ...
but this should do
the beauty of FORTH / Tachyon :-)
this is really really an elegant solution. Thank you very much.
BTW: you overtop master Yoda with this by lengths - it is nicer than NUM>STR
I need hours to understand this and it is still not working but there is a new hope ...
Thanks to you both.
you can easily define a string-output-stream by revectoring EMIT to
BYTE bufptr
$FF BYTES mystr
pub EMIT2$ ( char .. ) mystr bufptr + C! bufptr C++ ;
pub to$ ' EMIT2$ uemit W! ;
/// then
to$
/// now you can use any print routines redirected to your string ...
CON /// resets to normal EMIT
I did a generalized version of this for T2, but would need to search for it ...
but this should do
the beauty of FORTH / Tachyon :-)
this is really really an elegant solution. Thank you very much.
BTW: you overtop master Yoda with this by lengths - it is nicer than NUM>STR
I need hours to understand this and it is still not working but there is a new hope ...
Thanks to you both.
sorry @Proplem
I am learning from the master - but I am not there (you know ... it needs lot's of practise - more than I do - to not only get the idea, but also execute it correctly )
so here the corrected version (it happens, when I do not really execute the code ..)
Ahh I love it. Depending upon your requirements you could use a simple method like num>str which does not need a buffer reset or a general string method like mjb's, but be aware that you need to have a way perhaps either from a new line or even revectoring <# to reset the buffer. Once again though, this is left open as it is very easy to roll a custom solution.
you can easily define a string-output-stream by revectoring EMIT to
BYTE bufptr
$FF BYTES mystr
pub EMIT2$ ( char .. ) mystr bufptr + C! bufptr C++ ;
pub to$ ' EMIT2$ uemit W! ;
/// then
to$
/// now you can use any print routines redirected to your string ...
CON /// resets to normal EMIT
I did a generalized version of this for T2, but would need to search for it ...
but this should do
the beauty of FORTH / Tachyon :-)
this is really really an elegant solution. Thank you very much.
BTW: you overtop master Yoda with this by lengths - it is nicer than NUM>STR
I need hours to understand this and it is still not working but there is a new hope ...
Thanks to you both.
sorry @Proplem
I am learning from the master - but I am not there (you know ... it needs lot's of practise - more than I do - to not only get the idea, but also execute it correctly )
so here the corrected version (it happens, when I do not really execute the code ..)
I still sometimes forget to fetch the value from the address ... old habbits from all the other languages ...
now tried and works here.
that was it - should have found it myself, maybe i was too tired. This morning already was successful. I'm currently thinking wether master yoda's solution fits better as the resulting string has to be communicated via telnet so there is also a revectored emit in play which could collide. Have to think about. Tachyon is really fun at the moment
you can easily define a string-output-stream by revectoring EMIT to
BYTE bufptr
$FF BYTES mystr
pub EMIT2$ ( char .. ) mystr bufptr + C! bufptr C++ ;
pub to$ ' EMIT2$ uemit W! ;
/// then
to$
/// now you can use any print routines redirected to your string ...
CON /// resets to normal EMIT
I did a generalized version of this for T2, but would need to search for it ...
but this should do
the beauty of FORTH / Tachyon :-)
this is really really an elegant solution. Thank you very much.
BTW: you overtop master Yoda with this by lengths - it is nicer than NUM>STR
I need hours to understand this and it is still not working but there is a new hope ...
Thanks to you both.
sorry @Proplem
I am learning from the master - but I am not there (you know ... it needs lot's of practise - more than I do - to not only get the idea, but also execute it correctly )
so here the corrected version (it happens, when I do not really execute the code ..)
I still sometimes forget to fetch the value from the address ... old habbits from all the other languages ...
now tried and works here.
that was it - should have found it myself, maybe i was too tired. This morning already was successful. I'm currently thinking wether master yoda's solution fits better as the resulting string has to be communicated via telnet so there is also a revectored emit in play which could collide. Have to think about. Tachyon is really fun at the moment
@Proplem
if you send it to TELNET anyhow, why go via a string instead directly writing to the NW stream?
@Peter - tried newest bleeding edge V4 sources (of today 2017_04_30 14:20 UTC) on IoT5500 with no success (dictionary full when loading EASYFILE). Do you know? Best regards, proplem
@Peter - tried newest bleeding edge V4 sources (of today 2017_04_30 14:20 UTC) on IoT5500 with no success (dictionary full when loading EASYFILE). Do you know? Best regards, proplem
do you have a logfile?
maybe you need a COMPACT before EASYFILE ??
I haven't tried V4 on IoT5500 yet
You need to load and run COMPACT before trying to load EASYFILE but I have to set my line delay to around 50 ms when it is searching the EEPROM dictionary. I have been looking to see what I can do to improve this but anything that needs to read the EEPROM in is going to be slow.
FILL ( src cnt ch -- )
So your cnt of 0 is the same as 4294967295 bytes but obviously you can't have a count of zero.
@Peter,
in V4 the dictionary is moved to EEPROM on COMPACT?
But there is no cache any more?
So the FTP/HTTP words have to be searched in EEPROM (if they get compacted as well)?
Otherwise they still stay in RAM and are fast?
This would slow down the HTTP server otherwise ...
and the dynamic execution of scripts as well.
After a COMPACT and when EASYNET is loaded then all those words are still in hub RAM dictionary so they are searched first. Nonetheless, when any words that are not found in hub RAM then a search will be made in the EEPROM dictionary via the hashtags that are kept in hub RAM. Up to 5 entries from EEPROM might be read before a match is found but it doesn't have to search hundreds so it is still fast.
btw, remember too that Tachyon compiles word by word rather than waiting until the end of the line to do this. So when a line is entered then Tachyon already has it compiled and ready to execute.
@Peter - after your response I tried again to build EASYNET for IoT5500 without success.
- 1 writing kernel - ok
- 2 writing EXTEND.FTH (ldly = 10) - ok
- 3 writing COMPACT.FTH (ldly = 50 ) - ok
- 4 executing COMPACT (ldly = 50 ) - seems ok
- 5 trying to execute BACKUP the word is unknown:
73D0 base
73D8 num
73E0 uswitch
73EC V4
73F2 *end*
( 0160 $341A ok ) BACKUP ???
( 0161 $341A ok )
I saw there is only one minor change in COMPACT.FTH ($4000 was replaced by $5000). I tried with the old value but the problem is still there. After loading COMPACT.FTH executing COMPACT the problem occurs. It seems that a change in kernel or in EXTEND (there were in sum > 150 changes) causes the problem.
You built EASYNET with an 80 MHz platform - maybe you could try with an IoT5500?
You need EXTEND, EASYFILE, then COMPACT after which you can load EASYNET (slowly).
I also just happened to be doing that a bit as I optimize some routines, including COMPACT so that I can add entries to EEPROM after a COMPACT. There's also some other stuff to translate memory addresses to automatically address the first 32k as hub RAM, then the next 4MB as EEPROM, then SD perhaps. This is being done initially so that software that reports status/modules/dictionary etc will treat both sections in the same manner. It's a step towards expanding memory in general and perhaps having code execute from beyond 32k as well.
You need EXTEND, EASYFILE, then COMPACT after which you can load EASYNET (slowly).
I also just happened to be doing that a bit as I optimize some routines, including COMPACT so that I can add entries to EEPROM after a COMPACT. There's also some other stuff to translate memory addresses to automatically address the first 32k as hub RAM, then the next 4MB as EEPROM, then SD perhaps. This is being done initially so that software that reports status/modules/dictionary etc will treat both sections in the same manner. It's a step towards expanding memory in general and perhaps having code execute from beyond 32k as well.
This is the way I do the build (i leave out the "-V4r3" in the filenames ):
1 - kernel
2 - EXTEND.FTH
3 - EASYFILE.FTH
4 - COMPACT.FTH
5 - execute COMPACT
6 - EASYNET.FTH
Is this correct?
@proplem - yes, that is correct. I also do this regularly on IoT5500 as well, no difference except for the clock speed. Can you do WORDS to check what's happened? In case it doesn't understand that you can also hit ^W as a shortcut to WORDS.
However I think maybe it's is just that I changed the kernel to do away with a vector for SEARCH and I now patched SEARCH directly when I COMPACT. This also meant I needed to change the EEPROM search routine too a little, which I am now doing. There's a lot of little improvements but just give me a few minutes to check it all.
@proplem - yes, that is correct. I also do this regularly on IoT5500 as well, no difference except for the clock speed. Can you do WORDS to check what's happened? In case it doesn't understand that you can also hit ^W as a shortcut to WORDS.
However I think maybe it's is just that I changed the kernel to do away with a vector for SEARCH and I now patched SEARCH directly when I COMPACT. This also meant I needed to change the EEPROM search routine too a little, which I am now doing. There's a lot of little improvements but just give me a few minutes to check it all.
@proplem - yes, that is correct. I also do this regularly on IoT5500 as well, no difference except for the clock speed. Can you do WORDS to check what's happened? In case it doesn't understand that you can also hit ^W as a shortcut to WORDS.
However I think maybe it's is just that I changed the kernel to do away with a vector for SEARCH and I now patched SEARCH directly when I COMPACT. This also meant I needed to change the EEPROM search routine too a little, which I am now doing. There's a lot of little improvements but just give me a few minutes to check it all.
Seems to be alright now
Ok - checking ...
@Peter - better but not yet good ( enough :-)
1 - kernel - ok
2 - EXTEND.FTH - ok
3 - EASYFILE.FTH - ok
4 - COMPACT.FTH - ok
5- execute COMPACT - ok
6 - EASYNET.FTH - tachyon is unfortunately sending "garbage" without stopping to minicom
Regards, proplem
Uff - V43 is working on IoT5500. I still have some issues but Tachyon and me are operable :-)
Now I have a question: Is it possible to assign a telnet to a different cog handling communication fully parallel while working interactively via minicom on the serial line?
I think of something like starting 2 interpreters in parallel one in cog 0 and one on another.
Any advice how to do this?
Thanks,
proplem
Uff - V43 is working on IoT5500. I still have some issues but Tachyon and me are operable :-)
Now I have a question: Is it possible to assign a telnet to a different cog handling communication fully parallel while working interactively via minicom on the serial line?
I think of something like starting 2 interpreters in parallel one in cog 0 and one on another.
Any advice how to do this?
Thanks,
proplem
Now to have Telnet run in another cog would certainly be nice but there are a couple of issues I see. For starters the SD card and the Wiznet hardware is accessed via the main Tachyon cog, this is done mainly for efficiency as separate cogs would not only be wasteful but also complicate interfacing and sharing the resource etc. In Spin it was necessary for speed to run PASM in other cogs but Tachyon is fast already plus it has fast SPI instructions and RUNMODs as well.
Secondly though, the "text interpreter" shell is really a word by word compiler which compiles to the end of code memory just as if it were compiling a new definition, except that on an enter it will automatically execute this code without having allocated the code memory so that any new line will start again in the same place, the end of code memory.
So that means if we try to run a text interpreter in the normal fashion then they will be clashing and besides there are other shared variables that would clash too. I know that in other microcontroller Forths there is this "multi-user" built in, even in PropForth for instance, but IMO the reality is that it is of limited use as to do it properly requires memory, of which there is precious little of, especially when you are running a filesystem and Ethernet servers in addition to the many other features. Do other Forths do all this? However that doesn't mean we can't do it, because we could run a "text interpreter" app, perhaps just for telnet. This app could have its own methods for talking over telnet and compile into its own area and perhaps use end of code memory only when it is being allocated. I just connected to Tachyon over telnet on this remote laptop to check with a ?? and I have around 5kB free.
peter@peter-XPS-15-9550 ~ $ telnet 192.168.0.99 10001
Trying 192.168.0.99...
Connected to 192.168.0.99.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
??
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170501.0164
MODULES LOADED:
4C1A: EASYNET.fth WIZNET NETWORK SERVERS 170421.0000
436A: W5500.fth WIZNET W5500 driver 170421.0000
32F4: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1.2 170430-0000
1A40: EXTEND.fth Primary extensions to TACHYON+ kernel - 170427-2200
AUTORUN �
FREQ = 80.0MHz CODE:$58D2 =22226 bytes NAME:$6BF2 =2062 bytes DATA:$7A4C =1084 bytes =4896 bytes free Data Stack (0)
( 0030 $58D2 ok )
btw, there are 1,056 definitions in the WWORDS listing which does not included all the headers that have been reclaimed so that is a lot of stuff going on there.
So I could make it work and still have over 4kB free but I would also have to make the combined I/O run in a dedicated cog, which is not a bad thing really, but requires resource locks and mailboxes for starters. The way it is now if another cog tries to access the filesystem or Wiznet then it must have its direction registers setup correctly while the main cog must release its I/O. It's a pity that cogs OR their outputs since select signals are normally active low and if one cog sets it inactive then another cog cannot force it active etc. Anyhow, that could be settled with a dedicated combo I/O cog I guess. Pullups on shared lines would help too.
This begs the question, to what extent would you use the Telnet interface? Would you want to compile new words, maybe execute immediate one liners, or just execute "commands" for instance?
@Peter - thank you for this statement. I see that you are willing to support as nobody else would do. I'm going to write the requirements to have basis for further discussion. Now I must leave the forum to earn money - thanks a lot
Thanks for the thanks, may the 4th be with you!
Forth is fun, sharing is fun, sharing Forth is even more fun.
@D.P - I never thought that by radically changing how Tachyon operates under the hood that this is would make it appear intimidating. I really wanted to try out some things and I named V4 after one of the four letter NASA missions that seemed appropriate, DAWN - exploring new worlds. So even though V4 is experimental it has now become the new way of doing things without radically changing how we do it on the outside. I use V4 in my commercial projects so it has to work but I had also intended to use P2 for control purposes and when that didn't appear to be practical I looked at ways of doing what I needed to do with another CPU such as ARM or preferably with P1. Even though P1 is very limited compared to many ARM chips, it still is far more flexible in regards to "custom peripherals", that is, the cogs, and the easy assignment of I/O pins.
So V4 was born and incorporated runtime ROMS, simple one wire or RS485 networking that could be used as a console development port, simplified calling both to cog and to high level code etc etc. Plus it was faster in the process. Isn't it like the latest phone with more and better and faster, except it sells for the same price as the old one, free! Everyone would upgrade, surely. I'm still polishing the chrome on this model but it is ready to drive anywhere you want.
btw, EASYFILE in V4 is much improved as one of the things I upgraded was the virtual memory access methods. Even though I have kept all the XC@ methods which can address the first 4GB of the SD card including any files in that range, the V4 software now uses FSC@ methods which specify a 32-bit relative address for the file itself that can be anywhere including outside of the first 4GB of card memory plus it has that extra measure of safety in that you can't accidentally write to other parts of the card.
Comments
this is really really an elegant solution. Thank you very much.
BTW: you overtop master Yoda with this by lengths - it is nicer than NUM>STR
I need hours to understand this and it is still not working but there is a new hope ...
Thanks to you both.
sorry @Proplem
I am learning from the master - but I am not there (you know ... it needs lot's of practise - more than I do - to not only get the idea, but also execute it correctly )
so here the corrected version (it happens, when I do not really execute the code ..) I still sometimes forget to fetch the value from the address ... old habbits from all the other languages ...
now tried and works here.
that was it - should have found it myself, maybe i was too tired. This morning already was successful. I'm currently thinking wether master yoda's solution fits better as the resulting string has to be communicated via telnet so there is also a revectored emit in play which could collide. Have to think about. Tachyon is really fun at the moment
@Proplem
if you send it to TELNET anyhow, why go via a string instead directly writing to the NW stream?
because of incompetence :-) Iwill investigate this. Best regards, and thanks for the tip
proplem
... reading sources ...
do you have a logfile?
maybe you need a COMPACT before EASYFILE ??
I haven't tried V4 on IoT5500 yet
FILL ( src cnt ch -- )
So your cnt of 0 is the same as 4294967295 bytes but obviously you can't have a count of zero.
EASYNET BUILD
in V4 the dictionary is moved to EEPROM on COMPACT?
But there is no cache any more?
So the FTP/HTTP words have to be searched in EEPROM (if they get compacted as well)?
Otherwise they still stay in RAM and are fast?
This would slow down the HTTP server otherwise ...
and the dynamic execution of scripts as well.
btw, remember too that Tachyon compiles word by word rather than waiting until the end of the line to do this. So when a line is entered then Tachyon already has it compiled and ready to execute.
- 1 writing kernel - ok
- 2 writing EXTEND.FTH (ldly = 10) - ok
- 3 writing COMPACT.FTH (ldly = 50 ) - ok
- 4 executing COMPACT (ldly = 50 ) - seems ok
- 5 trying to execute BACKUP the word is unknown: I saw there is only one minor change in COMPACT.FTH ($4000 was replaced by $5000). I tried with the old value but the problem is still there. After loading COMPACT.FTH executing COMPACT the problem occurs. It seems that a change in kernel or in EXTEND (there were in sum > 150 changes) causes the problem.
You built EASYNET with an 80 MHz platform - maybe you could try with an IoT5500?
I also just happened to be doing that a bit as I optimize some routines, including COMPACT so that I can add entries to EEPROM after a COMPACT. There's also some other stuff to translate memory addresses to automatically address the first 32k as hub RAM, then the next 4MB as EEPROM, then SD perhaps. This is being done initially so that software that reports status/modules/dictionary etc will treat both sections in the same manner. It's a step towards expanding memory in general and perhaps having code execute from beyond 32k as well.
1 - kernel
2 - EXTEND.FTH
3 - EASYFILE.FTH
4 - COMPACT.FTH
5 - execute COMPACT
6 - EASYNET.FTH
Is this correct?
However I think maybe it's is just that I changed the kernel to do away with a vector for SEARCH and I now patched SEARCH directly when I COMPACT. This also meant I needed to change the EEPROM search routine too a little, which I am now doing. There's a lot of little improvements but just give me a few minutes to check it all.
Seems to be alright now
1 - kernel - ok
2 - EXTEND.FTH - ok
3 - EASYFILE.FTH - ok
4 - COMPACT.FTH - ok
5- execute COMPACT - ok
6 - EASYNET.FTH - tachyon is unfortunately sending "garbage" without stopping to minicom
Regards, proplem
Thanks in advance and - good night :-)
Sorry - 50 (!!! ms) when writing EASYNET. Now the build was successful! I will test now and thanks a lot and best dreams for you.
Now I have a question: Is it possible to assign a telnet to a different cog handling communication fully parallel while working interactively via minicom on the serial line?
I think of something like starting 2 interpreters in parallel one in cog 0 and one on another.
Any advice how to do this?
Thanks,
proplem
Now to have Telnet run in another cog would certainly be nice but there are a couple of issues I see. For starters the SD card and the Wiznet hardware is accessed via the main Tachyon cog, this is done mainly for efficiency as separate cogs would not only be wasteful but also complicate interfacing and sharing the resource etc. In Spin it was necessary for speed to run PASM in other cogs but Tachyon is fast already plus it has fast SPI instructions and RUNMODs as well.
Secondly though, the "text interpreter" shell is really a word by word compiler which compiles to the end of code memory just as if it were compiling a new definition, except that on an enter it will automatically execute this code without having allocated the code memory so that any new line will start again in the same place, the end of code memory.
So that means if we try to run a text interpreter in the normal fashion then they will be clashing and besides there are other shared variables that would clash too. I know that in other microcontroller Forths there is this "multi-user" built in, even in PropForth for instance, but IMO the reality is that it is of limited use as to do it properly requires memory, of which there is precious little of, especially when you are running a filesystem and Ethernet servers in addition to the many other features. Do other Forths do all this? However that doesn't mean we can't do it, because we could run a "text interpreter" app, perhaps just for telnet. This app could have its own methods for talking over telnet and compile into its own area and perhaps use end of code memory only when it is being allocated. I just connected to Tachyon over telnet on this remote laptop to check with a ?? and I have around 5kB free. btw, there are 1,056 definitions in the WWORDS listing which does not included all the headers that have been reclaimed so that is a lot of stuff going on there.
So I could make it work and still have over 4kB free but I would also have to make the combined I/O run in a dedicated cog, which is not a bad thing really, but requires resource locks and mailboxes for starters. The way it is now if another cog tries to access the filesystem or Wiznet then it must have its direction registers setup correctly while the main cog must release its I/O. It's a pity that cogs OR their outputs since select signals are normally active low and if one cog sets it inactive then another cog cannot force it active etc. Anyhow, that could be settled with a dedicated combo I/O cog I guess. Pullups on shared lines would help too.
This begs the question, to what extent would you use the Telnet interface? Would you want to compile new words, maybe execute immediate one liners, or just execute "commands" for instance?
I think we should dedicate today to Peter and Tachyon for sharing his efforts and success with Forth on the Propeller.
C.W.
Edit: @Peter did you see the PM?
Intimidated to try and "compile" my sources with V4.
Soon I guess, not using easynet but using easyfile is a must.
Forth is fun, sharing is fun, sharing Forth is even more fun.
@D.P - I never thought that by radically changing how Tachyon operates under the hood that this is would make it appear intimidating. I really wanted to try out some things and I named V4 after one of the four letter NASA missions that seemed appropriate, DAWN - exploring new worlds. So even though V4 is experimental it has now become the new way of doing things without radically changing how we do it on the outside. I use V4 in my commercial projects so it has to work but I had also intended to use P2 for control purposes and when that didn't appear to be practical I looked at ways of doing what I needed to do with another CPU such as ARM or preferably with P1. Even though P1 is very limited compared to many ARM chips, it still is far more flexible in regards to "custom peripherals", that is, the cogs, and the easy assignment of I/O pins.
So V4 was born and incorporated runtime ROMS, simple one wire or RS485 networking that could be used as a console development port, simplified calling both to cog and to high level code etc etc. Plus it was faster in the process. Isn't it like the latest phone with more and better and faster, except it sells for the same price as the old one, free! Everyone would upgrade, surely. I'm still polishing the chrome on this model but it is ready to drive anywhere you want.
btw, EASYFILE in V4 is much improved as one of the things I upgraded was the virtual memory access methods. Even though I have kept all the XC@ methods which can address the first 4GB of the SD card including any files in that range, the V4 software now uses FSC@ methods which specify a 32-bit relative address for the file itself that can be anywhere including outside of the first 4GB of card memory plus it has that extra measure of safety in that you can't accidentally write to other parts of the card.