Thanks,
I tried Senaterm too. Terminal IDE fixed the new line issue with blueterm, but I cannot paste data.
With the others, including Senaterm I have yet to find the right setup to handle also the copy and paste with line delay.
In the last few days I had not the possibility to try again, but at the moment I have not found yet the perfect Tachyon companion.
Massimo
Spent some good time studying the Tachyon source code to try to understand its architecture, and wound up learning the basic facts about the propeller chip architecture in the first place. I'm impressed with both.
I find Tachyon 2.1 to be very useable already. I'm now experimenting with fast D/A conversion right out of a pair of propeller pins with just a couple of resistors and a capacitor. It seems possible to output well over 30 k samples per second with 10-bit resolution using the video generator hardware, which seems capable of running a lot faster than the counter could in the duty cycle mode. The idea is to run two D/A channels with 5 bits resolution each (in a highly chopped duty cycle mode), with a 32:1 resistor ratio so one channel will represent the lowest 5 bits and the other the highest 5 bits. If I get it to work well I will share the Tachyon code.
I am grateful to Peter for sharing his Tachyon creation and even its source code, in the open source spirit, which was also a part of the Forth tradition since its early days.
Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.
Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.
but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.
An alternative to consider is Raspberry Pi. For about the same cost (overall) it provides Ethernet, and pretty much a whole workstation for free. It only costs two I/O lines on the prop. The wiznet stuff has its uses, but RPi might give more bang for the buck, and be a much more powerful general solution.
Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.
Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.
It just so happens that I have a WIZ820io 5200 based module sitting on the bench waiting to be bombarded by a Tachyon stream so that it will be ready 3 month ago! Unfortunately the Tachyon stream may be a bit delayed so that it only ends up being ready in February!
It just so happens that I have a WIZ820io 5200 based module sitting on the bench waiting to be bombarded by a Tachyon stream so that it will be ready 3 month ago! Unfortunately the Tachyon stream may be a bit delayed so that it only ends up being ready in February!
Let me know if there is anything I can do to help. I can test and do more just need a starting point, always the most difficult part.
@Braino The RPi is great but I am trying to reduce accidental complexity with less parts / software so I'll be patient and try to help Peter Tachyon support the module in question.
Let me know if there is anything I can do to help. I can test and do more just need a starting point, always the most difficult part.
@Braino The RPi is great but I am trying to reduce accidental complexity with less parts / software so I'll be patient and try to help Peter Tachyon support the module in question.
I think modules like the RPi are great for desktop or bench systems but when we are trying to design a specific product or even just to add more networking capabilities to the Prop itself then it's better to go down the more difficult road and help the Prop "develop" those abilities too. If everyone took the "easy" road and used embedded PCs then we would not be having this discussion on the Propeller forum as there would be no such thing. I do agree however with supplementing the Prop with additional hardware (or vice-versa) when necessary but keeping the complexity down so that I would perhaps use an ARM chip itself with the Prop rather than a whole ARM module.
To make it easier for anyone who wants to be a part of (or just follow along) the Tachyon networking project based initially on the WIZnet W5200 I will start up a Google docs project page with some initial documentation and primitives to access the chip and registers. From there we can add capabilities to the Prop. The W5200 seems to be a sensible solution for the Prop because of the hardwired TCP/IP design of the chip which minimizes scarce Prop resources and also the I/O efficient SPI interface. I want to implement serial over TCP and also FTP capabilities to the Prop so let's see what this little baby can do then.
I think modules like the RPi are great for desktop or bench systems but when we are trying to design a specific product or even just to add more networking capabilities to the Prop itself then it's better to go down the more difficult road and help the Prop "develop" those abilities too. If everyone took the "easy" road and used embedded PCs then we would not be having this discussion on the Propeller forum as there would be no such thing.
Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.
FTP!!!!!!! OK, Peter, that brings up the matter of getting a file system for the SD !!!!!
Yes, but you do realize that if it's FTP then the memory can stay embedded and so it can be any file system that suits? It doesn't have to be FAT16 or the mangled FAT32 neither of which are really suitable for incremental read/write filing with SD or Flash memory. It helps if an embedded SDFS allocates a large or specified contiguous chunk that doesn't need to reallocate as it grows and also if changing the actual file size would not require writing the same location over and over. I have found it far better that a marker stamp is appended to the end of the file when it's updated which is scanned for and read back into RAM only on mounting as this saves the poor directory sector from premature and certain wear. Even with wear leveling there are costs involved.
What shall I call this embedded file system? Since the SDFS term is used already to refer to a deduplicating file system for virtual environments then perhaps I could call this new file system FMFS for Flash Memory File System as that covers our little SPI Flash chips as well as SD.
The FMFS would still be structured in such a way that it would be compatible with FAT if the media is safely ejected. At that time or even on a reset the directory and file allocation table information can be updated etc. This suits the way I use Flash memory at least.
Hmmmmm, though a lot slower, FMFS, would apply to the EEPROM as well.
Yes Captain EEPROM, that's a LOT slower but FS for EEPROM is a lot simpler too as file sizes are small also but when compared to SPI Flash at the same price point the SPI Flash is at least 50 times faster with 50 times the memory. I will look at allowing various memories to be use with the FMFS however so it can be scaled according to the hardware resources and all P1 systems have EEPROM too. FMFS file access methods are designed to treat the file as virtual memory with none of that sequential access baggage from the tape drive and floppy era thank you.
Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.
I see where you guys are coming from, but just keep in mind that the Arduino is being paired with the Raspberry Pi. I believe that the Raspian distribution includes the development tools, or they are just an apt-get away. There's already a shield called Alamode that mates with the Pi. I hope that Parallax at least discusses this internally, and takes a close look at the market. There's no shame in extending the Pi's capabilities.
I see where you guys are coming from, but just keep in mind that the Arduino is being paired with the Raspberry Pi. I believe that the Raspian distribution includes the development tools, or they are just an apt-get away. There's already a shield called Alamode that mates with the Pi. I hope that Parallax at least discusses this internally, and takes a close look at the market. There's no shame in extending the Pi's capabilities.
The Prop can be paired with a PC or a tablet just as easily as it could be paired with a RPi. If P1 was all we had then as one of the many solutions we could link to the RPi, but we are really looking forward to and preparing for P2. The fact that Aduino is being paired with the RPi is not really a concern, I mean we're not thinking of using ATMegas either, are we? Really though, all the RPi projects are centered around the RPi, not Arduino or Prop etc which become nothing more than glorified peripheral chips extending the RPi's capabilities..
The Prop can be paired with a PC or a tablet just as easily as it could be paired with a RPi. If P1 was all we had then as one of the many solutions we could link to the RPi, but we are really looking forward to and preparing for P2. The fact that Aduino is being paired with the RPi is not really a concern, I mean we're not thinking of using ATMegas either, are we? Really though, all the RPi projects are centered around the RPi, not Arduino or Prop etc which become nothing more than glorified peripheral chips extending the RPi's capabilities..
I just think that it's one possible way for Parallax to get some exposure. The RasPi is cheap and can go into places where you probably wouldn't put a laptop or tablet. There's some synergy in the educational market - I think that Parallax has some excellent educational materials. I don't know if the potential market is big enough to excite Parallax, but the RasPi is hot right now so I hope it's been considered. I don't know how the RapPi will fare in the long run. Some of the promises aren't quite there yet - e.g. Scratch doesn't run all that smoothly quite yet. And many people may move on to other low cost platforms if price is what attracted them.
I don't know if the potential market is big enough to excite Parallax, but the RasPi is hot right now so I hope it's been considered. I don't know how the RapPi will fare in the long run. Some of the promises aren't quite there yet - e.g. Scratch doesn't run all that smoothly quite yet. And many people may move on to other low cost platforms if price is what attracted them.
Raspberry Pi certainly is hot right now (http://www.cnn.com/2012/12/21/tech/innovation/raspberry-pi-computer-upton/index.html). You get so much for so little. I wouldn't be surprised if it is a strong, even dominant, player in the educational space for some time. Whether or not Parallax can piggyback on that success profitably is another question.
Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.
Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.
Just for your interest I started playing with the W5100 on the Spinneret with the aim of using the W5200 but I'm writing the code totally clean in that I'm not referring to any existing code. Sometimes it helps to follow existing code but it can also lead you down a cramped path so I am just having fun interactively exploring the WIZnet registers and functions at present to see what I can do and get away with as well.
In typical Tachyon fashion I have a Google document and corresponding webpage document that can be viewed by anyone if you like to follow along. The document is both the source code and the documentation. This at least for the present gives you the low-level primitives to start working with while the functions are built up to what I need at least.
What a nice treat for the long winter rainy nights in the PNW (pacific north west for non-locals), got a Prop BOE with a wiz5200 module all wired up and ready, thx Peter.
What a nice treat for the long winter rainy nights in the PNW (pacific north west for non-locals), got a Prop BOE with a wiz5200 module all wired up and ready, thx Peter.
I've just added IP notation to the kernel so that I can just enter addresses like 192.168.0.50 using a simple & prefix like this &192.168.0.50 so that the number is forced to decimal bytes with each dot packing the decimal digits up into an IP address correctly.
Ah ha... Tachyon is back to shaking up the Propeller Forth world. I am looking forward to Forth on the Propeller 2.
In the meantime, I am rather mired in ArrayForth, a sub-set of ColorForth for the GA144 these days. It is all very weird, one has to use the right colors to program. I prefer mono-chrome Forth, but this is all from the workshop of Chuck Moore himself. So I try to learn it anyway.
Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.
I concur. I recently learned a good bit about the Propeller chip, because I have long been familiar with the ways of Forth, and Tachyon made the Propeller chip approachable to me (the same would probably have happened if by accident I had stumbled upon PropForth first). This chip is in a class by itself (until it becomes outclassed by its big brother P2). This hardware architecture can break all kinds of sound barriers in situations where fast execution and multitasking environment rank high in the priority chain.
I would start to explore experimental ways of networking several propellers using Tachyon as a development strategy because of its superb ability to get things debugged, particulalrly flexible and open-ended things such as networking protocols. This is bound to lead to the discovery of good protocols (robustness, high speed, extensibility, etc..). When it does, these protocols may become worthy of porting to other hardware platforms using other software tools and methodologies, not because they were created in a propeller-specific Forth dialect, but because they have practical merit, so everyone will benefit. This could for instance benefit both the propeller and the RPi platforms, because the pairing between them would provide bridging between wide scope protocols such as TCP and UDP (over IP) and narrow scope protocols such as what I am dreaming aloud about, first propeller-to-propeller using Tachyon for its development advantages, and later on, if something of real value comes of it, more options and possibilities for everyone, within every development paradigm.
I've been doing bits and pieces on the Spinneret and playing with Telnet sessions. Now you can Telnet into the Forth console and interactively write programs over the internet. When I get some time later on today I will tidy up the code a little and lock it in then allow anyone who likes to Telnet in to my Spinneret running Tachyon. The WIZnet code and driver runs out of the same cog as the Tachyon console and consumes less than 1K of code at present. Next step after tidying the Telnet is to add FTP.
BTW, here's a quick session:
[FONT=courier new]peter@peter-XPS-L702X-Mint14 ~ $ telnet 192.168.0.80
Trying 192.168.0.80...
Connected to 192.168.0.80.
Escape character is '^]'.
.VER
.VER
Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
ok
MY QWORDS
MY QWORDS
S LW WDUMP TELNET TERM wKEY (wKEY) wEMIT wTXSTR wTX PPPoE MACRAW IPRAW UDP TCP
CLOSED PORT SOCK_ARP2 SOCK_ARP1 SOCK_ARP SOCK_LAST_ACK SOCK_TIME_WAIT SOCK_CLOSING SOCK_FIN_WAIT
SOCK_SYNRECV SOCK_SYNSENT SOCK_PPOE SOCK_MACRAW SOCK_IPRAW SOCK_UDP SOCK_CLOSE_WAIT SOCK_ESTABLISHED
SOCK_LISTEN SOCK_INIT SOCK_CLOSED =CON =DISCON =RECV =TIMEOUT =SENDOK RECV SENDKEEP SENDMAC SEND
CLOSE DISCON CONNECT LISTEN OPEN RXREAD RXSIZE@ TXWRITE TXREAD TXFREE@ sPRO sSSIZE sDPORT
sDIP sDHAR sPORT sSTAT sINTS sCMD sMODE SOCKET @SOCKET UPORT UIP TXSIZ RXSIZ RETRYS
RETRYTIME INTMASK INTS@ SRCIP SHAR SUBNET GATEWAY wMODE WIZ2@ WIZ2! WIZ4! !WIZIO WIZ@ WIZ!
=WRD =WWR WSEL WRST WCK WCE WDI WDO
ok
ok
[/FONT]
The W5200 is significantly different to the W5100 register layout which is not un-expected of course. Time to put away the 5200 module and breakout my spinneret, this forth is a little above my comfort level to mess with until I have more experience, nice work Peter.
The W5200 is significantly different to the W5100 register layout which is not un-expected of course. Time to put away the 5200 module and breakout my spinneret, this forth is a little above my comfort level to mess with until I have more experience, nice work Peter.
I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?
The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.
I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?
The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.
Having coded large "socket" based applications in everything from Ada to C it's scarry to see how simple the layout for sockets can be in Forth/Tachyon.
Thanks for removing so much accidental complexity, the WIZ820io w5200 based module is not put away just moved to make room for the spinneret. The socket code is straight forward, I was referring to how to modify the driver, I'm not ready for this in Tachyon/Forth yet.
I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?
The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.
Great! Now I have something worthwhile to do with that Spinneret I purchased during a sale not long ago (I didn't need it but couldn't resist the temptation). I too am astounded at how easy all this looks. Scary? Perhaps. Certainly impressive!
Forth support on the Propeller, in particular TACHYON, really stands out in my view. Anyone wanting to learn Forth or do work with Forth in an embedded environment would be remiss in overlooking the Propeller. Please keep up the fantastic work, Peter!
I can't seem to connect to the spinneret after using either of the last two kernels, latest being 21_130216,1200. I've tried with 115_000 and 230_400 baud, standard rates I use with success (yes I did remember to modify the baudrate and clock settings in the default tachyon code). Minicom seems to connect but no IO? The spinneret is powered with +5v and using a parallax prop plug. TACHYON is constantly restarting and sending it's banner correcty to minicom?
I usually do all my TACHYON work with PBOE or a PPDB.
Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
Cold start - no user code - setting defaults
UPDATE: Got it to connect once, don't know how, but can't repeat, no - consistency?
UPDATE2: OSX 10.8.2 damage, everything works peachy under my Win7 VM on this machine, drat.
UPDATE3: My OSX setup works correctly with the PBOE and PPDB, something about the prop plug, even though programs download correctly, fast, minicom doesn't work correctly. TeraTerm pass through from the VM to the physical port on the Mac is not usable to "build" the extensions.
UPDATE4: My trusty 1 gen MacBook Pro with the matte screen was truely worth replacing the HD with a SSD.
Everything works perfectly here in 10.6.8.
Comments
I've had no trouble using it with a chinese BT/Serial-to-Prop (once I switched to FullDuplexSerial4Port (thanks Tracy)).
I tried Senaterm too. Terminal IDE fixed the new line issue with blueterm, but I cannot paste data.
With the others, including Senaterm I have yet to find the right setup to handle also the copy and paste with line delay.
In the last few days I had not the possibility to try again, but at the moment I have not found yet the perfect Tachyon companion.
Massimo
I find Tachyon 2.1 to be very useable already. I'm now experimenting with fast D/A conversion right out of a pair of propeller pins with just a couple of resistors and a capacitor. It seems possible to output well over 30 k samples per second with 10-bit resolution using the video generator hardware, which seems capable of running a lot faster than the counter could in the duty cycle mode. The idea is to run two D/A channels with 5 bits resolution each (in a highly chopped duty cycle mode), with a 32:1 resistor ratio so one channel will represent the lowest 5 bits and the other the highest 5 bits. If I get it to work well I will share the Tachyon code.
I am grateful to Peter for sharing his Tachyon creation and even its source code, in the open source spirit, which was also a part of the Forth tradition since its early days.
http://shop.wiznettechnology.com/Sub_Modules/en/product/detail_page.asp?cateid=48&pid=1161
This module is well tested with a couple of prop 1 driver sets here's one:
http://obex.parallax.com/objects/869/
Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.
An alternative to consider is Raspberry Pi. For about the same cost (overall) it provides Ethernet, and pretty much a whole workstation for free. It only costs two I/O lines on the prop. The wiznet stuff has its uses, but RPi might give more bang for the buck, and be a much more powerful general solution.
It just so happens that I have a WIZ820io 5200 based module sitting on the bench waiting to be bombarded by a Tachyon stream so that it will be ready 3 month ago! Unfortunately the Tachyon stream may be a bit delayed so that it only ends up being ready in February!
Let me know if there is anything I can do to help. I can test and do more just need a starting point, always the most difficult part.
@Braino The RPi is great but I am trying to reduce accidental complexity with less parts / software so I'll be patient and try to help Peter Tachyon support the module in question.
I think modules like the RPi are great for desktop or bench systems but when we are trying to design a specific product or even just to add more networking capabilities to the Prop itself then it's better to go down the more difficult road and help the Prop "develop" those abilities too. If everyone took the "easy" road and used embedded PCs then we would not be having this discussion on the Propeller forum as there would be no such thing. I do agree however with supplementing the Prop with additional hardware (or vice-versa) when necessary but keeping the complexity down so that I would perhaps use an ARM chip itself with the Prop rather than a whole ARM module.
To make it easier for anyone who wants to be a part of (or just follow along) the Tachyon networking project based initially on the WIZnet W5200 I will start up a Google docs project page with some initial documentation and primitives to access the chip and registers. From there we can add capabilities to the Prop. The W5200 seems to be a sensible solution for the Prop because of the hardwired TCP/IP design of the chip which minimizes scarce Prop resources and also the I/O efficient SPI interface. I want to implement serial over TCP and also FTP capabilities to the Prop so let's see what this little baby can do then.
FTP!!!!!!! OK, Peter, that brings up the matter of getting a file system for the SD !!!!!
Yes, but you do realize that if it's FTP then the memory can stay embedded and so it can be any file system that suits? It doesn't have to be FAT16 or the mangled FAT32 neither of which are really suitable for incremental read/write filing with SD or Flash memory. It helps if an embedded SDFS allocates a large or specified contiguous chunk that doesn't need to reallocate as it grows and also if changing the actual file size would not require writing the same location over and over. I have found it far better that a marker stamp is appended to the end of the file when it's updated which is scanned for and read back into RAM only on mounting as this saves the poor directory sector from premature and certain wear. Even with wear leveling there are costs involved.
What shall I call this embedded file system? Since the SDFS term is used already to refer to a deduplicating file system for virtual environments then perhaps I could call this new file system FMFS for Flash Memory File System as that covers our little SPI Flash chips as well as SD.
The FMFS would still be structured in such a way that it would be compatible with FAT if the media is safely ejected. At that time or even on a reset the directory and file allocation table information can be updated etc. This suits the way I use Flash memory at least.
I see where you guys are coming from, but just keep in mind that the Arduino is being paired with the Raspberry Pi. I believe that the Raspian distribution includes the development tools, or they are just an apt-get away. There's already a shield called Alamode that mates with the Pi. I hope that Parallax at least discusses this internally, and takes a close look at the market. There's no shame in extending the Pi's capabilities.
The Prop can be paired with a PC or a tablet just as easily as it could be paired with a RPi. If P1 was all we had then as one of the many solutions we could link to the RPi, but we are really looking forward to and preparing for P2. The fact that Aduino is being paired with the RPi is not really a concern, I mean we're not thinking of using ATMegas either, are we? Really though, all the RPi projects are centered around the RPi, not Arduino or Prop etc which become nothing more than glorified peripheral chips extending the RPi's capabilities..
I just think that it's one possible way for Parallax to get some exposure. The RasPi is cheap and can go into places where you probably wouldn't put a laptop or tablet. There's some synergy in the educational market - I think that Parallax has some excellent educational materials. I don't know if the potential market is big enough to excite Parallax, but the RasPi is hot right now so I hope it's been considered. I don't know how the RapPi will fare in the long run. Some of the promises aren't quite there yet - e.g. Scratch doesn't run all that smoothly quite yet. And many people may move on to other low cost platforms if price is what attracted them.
Just for your interest I started playing with the W5100 on the Spinneret with the aim of using the W5200 but I'm writing the code totally clean in that I'm not referring to any existing code. Sometimes it helps to follow existing code but it can also lead you down a cramped path so I am just having fun interactively exploring the WIZnet registers and functions at present to see what I can do and get away with as well.
In typical Tachyon fashion I have a Google document and corresponding webpage document that can be viewed by anyone if you like to follow along. The document is both the source code and the documentation. This at least for the present gives you the low-level primitives to start working with while the functions are built up to what I need at least.
Well then, if you or anyone else would like to collaborate on the project then you are quite welcome to. Just go to https://docs.google.com/document/d/1lsoQ440F-RBMkL84cfUrUic563UsiFIJT-OHCPmPn-0/edit# and apply for permission to edit.
I've just added IP notation to the kernel so that I can just enter addresses like 192.168.0.50 using a simple & prefix like this &192.168.0.50 so that the number is forced to decimal bytes with each dot packing the decimal digits up into an IP address correctly.
In the meantime, I am rather mired in ArrayForth, a sub-set of ColorForth for the GA144 these days. It is all very weird, one has to use the right colors to program. I prefer mono-chrome Forth, but this is all from the workshop of Chuck Moore himself. So I try to learn it anyway.
I concur. I recently learned a good bit about the Propeller chip, because I have long been familiar with the ways of Forth, and Tachyon made the Propeller chip approachable to me (the same would probably have happened if by accident I had stumbled upon PropForth first). This chip is in a class by itself (until it becomes outclassed by its big brother P2). This hardware architecture can break all kinds of sound barriers in situations where fast execution and multitasking environment rank high in the priority chain.
I would start to explore experimental ways of networking several propellers using Tachyon as a development strategy because of its superb ability to get things debugged, particulalrly flexible and open-ended things such as networking protocols. This is bound to lead to the discovery of good protocols (robustness, high speed, extensibility, etc..). When it does, these protocols may become worthy of porting to other hardware platforms using other software tools and methodologies, not because they were created in a propeller-specific Forth dialect, but because they have practical merit, so everyone will benefit. This could for instance benefit both the propeller and the RPi platforms, because the pairing between them would provide bridging between wide scope protocols such as TCP and UDP (over IP) and narrow scope protocols such as what I am dreaming aloud about, first propeller-to-propeller using Tachyon for its development advantages, and later on, if something of real value comes of it, more options and possibilities for everyone, within every development paradigm.
May they multiply and prosper, all of them!
BTW, here's a quick session:
I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?
The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.
Having coded large "socket" based applications in everything from Ada to C it's scarry to see how simple the layout for sockets can be in Forth/Tachyon.
Thanks for removing so much accidental complexity, the WIZ820io w5200 based module is not put away just moved to make room for the spinneret. The socket code is straight forward, I was referring to how to modify the driver, I'm not ready for this in Tachyon/Forth yet.
Forth support on the Propeller, in particular TACHYON, really stands out in my view. Anyone wanting to learn Forth or do work with Forth in an embedded environment would be remiss in overlooking the Propeller. Please keep up the fantastic work, Peter!
I usually do all my TACHYON work with PBOE or a PPDB.
Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
Cold start - no user code - setting defaults
UPDATE: Got it to connect once, don't know how, but can't repeat, no - consistency?
UPDATE2: OSX 10.8.2 damage, everything works peachy under my Win7 VM on this machine, drat.
UPDATE3: My OSX setup works correctly with the PBOE and PPDB, something about the prop plug, even though programs download correctly, fast, minicom doesn't work correctly. TeraTerm pass through from the VM to the physical port on the Mac is not usable to "build" the extensions.
UPDATE4: My trusty 1 gen MacBook Pro with the matte screen was truely worth replacing the HD with a SSD.
Everything works perfectly here in 10.6.8.
_Really neat stuff here Peter.
This word is helping me debug my stuff
Also these two words are needed to set the destination IP and PORT when in "client" mode?