This is another area where it gets outside my expertise. BUT...
In PropForth, the MCS (Multi Channel Synchronous Serial) has demonstrated itself to be 100% reliable so far (between two prop chips). That is, the channel starts sending and receiving 96 bit packets at full clock speed. (Continuously, for several months, so far). When a character is dropped into the send side, it pops out the receive side. The minimalist error count mechanism has only counted errors when we did the "yank out the wire" test. Otherwise its always there and communicating.
Sal made a GO demo on the PC (internal prototype only) a couple weeks back, and it looked like it worked. He still has to futz with something to make it identical on XP and Ubuntu, but it should be ready for public viewing in a couple weeks and we can dissect it after he's done testing. Hopefully you can find errors and tell us where we've gone wrong and how to fix it. The goal is to make the interface definition such that any language prop implementation will be able to talk to any language PC implementation, at least regarding the byte transfer.
Sorry, been sick last few days. Answer should have been, "YES, but you either have to use what somebody else wrote in forth as prop firmware, or implement CSP channels on the prop in PASM, or some other language."
I am very sure that if you want your GO program to communicate with your Propeller it is not much different than using C or Pascal or Visual Basic. Just another language to talk down a serial link.
Here is the plan for Go interface functionality. Its a little bit different than a regular serial link, in that there are multiple channels.
We will interface to propforth, but anybody could write a compliant CSP interface in any other development language.
1) Hardware: Two I/O pins are used; one pin for send, one pin for receive (more or less).
2) each pin supports 8 simultaneous channels (as of today), there are 16 I/O present, 8 pairs of two.
3) Each channel is full duplex 115K baud. It uses 8 data bits no parity and no stop bit, so uses a 10 bit transfer. Usable throughput is about 113k baud.
4) The PROTOCOL on each channel uses the full duplex. (I sent a byte, did you get it? Yes I did Now I'm ready for another), but to the user, one channel sends and another channel receives.
5) the transfer is synchronous continuous 96 bit packets. Drop a character in the channel, it jumps out the other side.
6) Each I/O channel also has a pointer to (another channel) where the data is to go. This is typically the input to a the propforth interpreter running on a cog, but it could be a dedicated assembler routine to do what ever. The result is we have an input, from a PC terminal command line, directly to a cog on the Prop.
7) We have 8 channels, so we can have 8 terminal sessions open at once, so we can talk to all 8 cogs at the same time. Each session runs at 115k baud. Just to reiterate, this is using 2 I/O pins.
8) There is an option to have more channels with a lower throughput and higher latency. The estimate is that 32 channels would have about 56k baud throughput. The target is 32 channels at 56k baud. This will allow the workstation to connect to many prop chips, so an application could span the cogs of multiple physical chips.
9) the Use model is
a) running complex applications on the workstation/PC and
b) running acquisition and control on the micro controller.
This use model allows deciding what processing is done at each level, on the PC or the micro controller.
Usually some level of filtering is performed near the sensor before data is sent to the PC.
The PC does some convolution, determines feedback ,control is sent back to the micro controller.
The micro controller can react very quickly, and the PC can handle long term stable processing.
FINALLY got it posted. Here is the long promised demo for CSP channels for GO on the PC and proforth on the prop.
The same PC side code should work with a CSP byte transfer implementation in any other language (PASM, C, BASIC, etc)
The same prop code should work with a CSP byte transfer implementation in any other language, Python, Erlang etc. But I don't know if anybody DOES a CSP byte transfer in any other language. I'll try to contact the Python CSP folks this week to see if they want to play. Also I'll ping MGreim and see if he's ready.
Braino,
By the time you have chopped and changed languages at the PC end and then chopped and changed languages at the Prop/target end all you have left is a means of multiplexing many logical comms channels through a single physical link.
That is nothing to do with CSP as formalized by Tony Hoare and others. Please do not call it such.
From another thread: New information, and an contradicting opinion! Now we get interesting.
Sal tells me this is a "standard plumbing" to connect any processor process to any other processor's process, and this is the intent of CSP and this is what he's begun implementing.
Heater tells me I'm talking out my butt again. This can be true, as it often is; but is Sal's statement incorrect? Or am I just totally misunderstand the basic concepts again?
Somebody pipe in before I am shamed into deleting all my posts on the subject for the last several weeks.
Sal is right. This is standard plumbing. After all isn't that what networking and the internet are all about? Connecting disparat computer systems together.
However none of that has anything to do with CSP as it is formally described.
Is Javascript in your web browser talking to PHP in your server via HTTP requests CSP. No.
I'm trying to sort this out and figure out what is what, also.
I haven't read Mr. Hoare's book (original or updated), so I can't quote from it. From the Wiki (sorry) page, CSP is a formal language that has influenced a number of "implemented" programming languages.
I would take this the same as Realtional Algebra is a formal language that has influenced a number of relational database managers and their supporting query languages.
I don't understand the formalism that elevates CSP beyond message passing between subsystems to accomplish a task - whether it is a central processing unit passing an address of channel commands to an I/O processing unit or a browser passing a request packet off to a server to have it fetch data while it goes on and does something else. If CSP as now defined by Hoare and others lends provability to parallel process messaging methods and a caluculus through which to further define and formalize theory, then that is wonderful.....for the Computer Scientists.
As an specific implementation, the GO/Propforth channel support seems to be a useful and functional way to extend the propforth channels that existed back onto a workstation. I look forward to experimenting with it as a way to mesh of interconnected Props running Propforth that are tied back to a workstation...to what end, I do not know. I'm also pondering goForth extensions to support "CSP" and also the Python/CSP implemention as other playgrounds. Whether or not I can formally prove it to be CSP isn't weighing heavily on me right now.
GO refers to them as "goroutines" and support of cummunicating processes. The line may be that it is inherrent in the language syntax and structure rather than implemented through libraries and external data structures.
I don't know, I'm not a computer scientist and generally not a very formal person.....and that I CAN prove!
Sal is right. This is standard plumbing.
However none of that has anything to do with CSP as it is formally described.
Is Javascript in your web browser talking to PHP in your server via HTTP requests CSP. No.
Thanks to Heater. for bringing this up, I looked into this a little deeper. I discussed it with Sal, he tried to straighten me out. Let me try and express this properly:
The problem comes from using the term "CSP channels" as it can imply that it includes everything in Hoare's book. Hoare's book is very large and complex definition and includes a language to describe the constructs and techniques he's trying to get across.
The "channels" are synchronous communication channels between parallel sequential processes. What's important is that it's not just the CSP channels, its how we use them. "How to use them" is what the CSP book is about. More specifically, the Hoare book, as explained to me, is about dealing with multiple Finite State Automata. "How to deal with multiple FSA" is the majority of the book.
Propforth just implements channels, but not "how to use them".
The thing I have been referring to as "CSP channels" would more accurately be described as
-->> INTERFACING TO GO-CHANNELS. <<--
The same technique can be used to interface to other channels. It not meant to be a full blown CSP implementation.
Sal said he tried to discuss CSP channels with several folks over the years, but found he ended up spending too much time just deciphering each others understanding, and gave up. So he's not going attempt to explain it to me so I can explain it on the forum; the folks that understand it don't need explanation, and the folks that don't understand it aren't going to get it without reading the book. That's good enough for me, as I still get to use it, and there are too many other books I need to read first.
The bottom line is we can use these channels in many ways, depending on what the goal is. That is, we can stream data to and from the prop using synchronous channels.
----
I also contacted the Python-CSP author. When we get the interface properly nailed down and defined, she may take a look at it. Then we would get good idea of where this would fit, and if it might be useful someplace.
----
Development Progress:
Right now there is slow turn-around (doing synchronous over asynchronous, remember this is only development), it looks likes 60 characters per second per channel.
The protocol limits the speed. The first pass had an ACK for each character sent. Now Sal is working on a buffering scheme so there is one ack the whole buffer. All the channels share the buffer, the channel talking uses as much of the buffer as it needs. This should be transparent to us.
The plan is to take advantage of the WIZNET (spinerette) hardware, and do transfer over Ethernet. It should reside in 1 cog and be really fast. The function .str is optimized to generate the string in memory and spit out characters at assembler speed, so this part is ready. This will spit characters to the memory in the WIZNET. There will be a separate chunk of code to implement the channels for the WIZnet so it all fits in one cog. Sal is not 100% sure , but the cog should communicate equally well on local LAN or global lan. WITH proper buffer, should overcome latency issues. LAG stalls stuff, but buffer fixes it; instead of lots of .5 second delays compounded, the communications are just a .5 second out of phase. Nifty!
So Sal is working on the SERIAL buffering stuff. The plan is:
1) finish optimizing the unbuffered synchronous transfer
2) do a buffered synchronous transfer
3) put it on the wiznet
The GO-terminal command line interface is very snappy.
The GO-telnet interface is still synchronous over asynchonous with byte-ACK, so its still a bit slow, but you can open telnet sessions to all the cogs at once.
Notice that we can do the same with the current release, v5.03, although communication is on the current release is 57600 baud and a bit too slow to really play with. Of course this only affects the Go-telnet experiment; the rest is still crazy fast.
Please send me a PM with email if you want the BETA emailed to you, I try to answer requests as I receive them.
Sal gave an update yesterday:
- buffered stuff works under windows 4 - 32 channels; 4 channels faster
- the release will include the the original source incremental steps from optimizing forth to assembler.
- tests with 8 channels yield around 1500 cps per channel, up from 200 around cps unoptimized
- Automation beats on the serial ports. Applied assembler optimization on fast load, GO can overrun channels
- possible course for development:
* Its easy in forth to implement a "subset" application language with just a few functions;
* just a few things in a demo like drivers for steppers and servos so its easier to learn and use
- Sal is thinking about a "lead app" to show off CSP channels and go. While some folks understand CSP thoroughly, some of us just know enough to think it might be a cool idea. So Sal is trying to come up with a an inexpensive project to show off how it can be used. Lead app should do-
* multiple inputs
* multiple outputs
* bunch of conflict states with data flow.
* maybe a robot? lots of ins and outs and complex interactions.
* Inexpensive, simple mechanics.
So the first candidates might be:
* Biped, balance bot; four servos and an accelerometer or other sensor
* laser etch-a-sketch, two servos and a cheap laser pointer to draw persistence of vision pictures on a surface
* hypersonic "sound from ultrasound" audio projection
We're open to suggestions. The key parameter is it should be cheap enough that anybody could try it.
The material presented so far is going to be integrated into propforth in support of regression test automation. After this post, I think the discussion will shift back to the propforth thread until some non-forth CSP material comes up. I'm hoping for someone to do C or PASM on the prop to implement that channel interface, and for Python and Erlang implementation of channel interface on the PC. This would be able to happen once the full interface is defined, possibly in the next propforth release.
Any of those projects sound like fun, useful, recreatable efforts. Balance-bots are always fun to play with.
I'm still thinking basic infrastructure and tools. With all the recent activity with wireless, it doesn't seem like wireless CSP channels should be too far down the road.
When I sit down and do it, my BeagleBone is going WiFi and it has FTDI support and Python, so it's certainly a target for the PC side of PropForth/CSP.
The Spinneret can expose channels to the IP world.
PropForth to PropForth mcs channels using CSP is certainly an option.
Multi-Prop PropForth clusters are certainly on my radar.
Yesterday, I fell down this rabbit hole again for a while.
I've got the PyCSP modules loaded and the examples are running. I went with PyCSP instead of python-csp because it is more portable, and is implemented as importable python modules. Python-csp is implemented as its own version of the Python interpreter, which may or may not be a good thing when it comes to managing the CSP stuff.
So, now I need to learn now this CSP stuff works and what it means to this project. There two different sets of documents which share the same concepts and some syntactical candy but there are differences in the implementations. Some things you read about that look interesting were in the old implementation and then changed in the current implementation. Nothing major, just something to be aware of.
For remote processes, one of the "future enhancements" is the concept of "remote evaluators" which fit really well in what we're trying to do with the PC and the Propeller. The channel could be opened up between a PC process and a remote COG under this model. It seems to fit better than the other CSP models and channel connectivity options. This is where I'm headed for now.
Since I've been talking the impossible IDE for PropForth:
I now have PyCSP
a Python based terminal program
a Python based Tiny Forth skeleton ('0 >con' from your PC to connect to a PropForth session?)
PropForth with high-speed channel support (mcs)
.........mix well and leave on your computer for a few days.......who knows what might happen!
For anyone that wants to play along that isn't thrilled about GO (I couldn't handle half-learning ANOTHER language) or Python or Erlang (assume it has CSP-esque channel support) or OCCAM, there is a Java based CSP implementation (JCSP) and a C++ based implementation ( C++CSP). I'm finding more as I hunt around for information. It may not all be "pure" CSP but most are from University environments and do discuss their shortcommings and practical applications when held up against true CSP algebra. Of course, I'm not doing it for the academics or provability of CSP theory.
CSP-esque channel implementations in other Propeller languages would be interesting to see. serialCSP.spin or cspchannel.c, anybody?? (Of course, if you modeled the protocol after the PropForth mcs, then Prop to Prop CSP wouldn't be so impossible.
So, what's your excuse??? It's only your free time!!
Wireless: Sal knows something about wireless, like what the technologies are, how they work, what they cost, and their protocols. (He knows a bunch). So far there are several candidates, but none have hit the sweat spot of low cost, high acceptance, and straight forward interface (for Sal's purposes). Wireless/radio are in the list, and will be added when something changes. The first thing to expect in this direction is "packet radio" which I haven't mentioned yet as I have done no investigation. It might be right after the "Go-Lead-application", if anybody expresses interest.
Thanks for the tips on the other language options, this is the intent, but Sal and I don't have bandwidth to lead. The next public release should have enough detail so anybody with CSP supported can reproduce the PC end of the MCS interface.
Most of the stuff I think you are describing should be doable once the automation infrastructure is nailed down.
To Folks watching: MCS is similar to Beau's high speed serial, differences being MCS is in FORTH and assembler and includes the protocol. Anyone comfortable with Beau's stuff could implement support once the interface is nailed down. I'm looking forward to serialCSP.spin or cspchannel.c becoming interesting to folks next release.
Please try to telnet to my quickstart running GO-channels at 71 (dot) 201 (dot) 87 (dot) 230 (port) 4000
It should allow connections on cog0 through cog3.
Try running the word
cog?
or if you have lots of time the word
words
Now notice that running
words
is very fast; faster than it used to be on a single channel direct connection.
COG6 now uses 1K of its RAM to buffer the channel communications. Fewer channels would go slightly faster, and more channels would go slightly slower, but they are all pretty much the same speed. It seems dependant on the number of CPU's in the host computer (the pc in my lab that the quickstart is talking through).
Hopefully, we can get some numbers this week. the guessimate is about 2000 character per second per channel using 8 channels, which is a little bit better than pre-CSP channels for a single channel. We can configure for 8, 16, or 32 CSP channels over a single serial connection.
This demo is still synchronous over asynchronous, so even though its faster than it used to be, it is still slow than its going to be when we use ethernet hardware.
I tried your site this morning (just now) and got a "Connection Refused" - maybe I hit your maintenance window!
I loaded up the new PropForth and the new GO code and everything worked fine with my C3 and having the GO host on Win7 (I5 - 4 processors indicated). It was faster with the gomuxterm access. Telnet into it from the Win7 laptop as well as my Fedora laptop. I can collect numbers over the next couple of days, if you can give me process to follow. I can host the Prop on various systems ranging from Netbook to i7's if we think that will make any difference. I just need to install Go on the ones that are lacking!
Glad you are making progress - my resources have been diverted for a while.
I can access from my android phone (with wireless off, so it goes through the phone company) and I can see the outside IP address, so I think it should work.
Sometime today I should be able to put up the format for the data Sal is looking for. Lots of projects active today!
...and I can open up 4 session to COG0 through COG3. Is it possible to make COG4 and COG5 available for general use via the mux channels? We seem to have lost them somehow. there I/O isn't linked anywhere but they are still running the interpreter and haven't been tasked to run a word like COG6 and COG7. The mux channels that should be theirs are looped back to themselves.
Just a curiosity...and of course, it's always good to have all the Cogs you can get!
...and I can open up 4 session to COG0 through COG3.
Is it possible to make COG4 and COG5 available for general use via the mux channels?
We seem to have lost them somehow. there I/O isn't linked anywhere but they are still running the interpreter and haven't been tasked to run a word like COG6 and COG7.
The mux channels that should be theirs are looped back to themselves.
For this BETA and the tests, it hard wired for cog0-cog3 to channels for the tests.
COG4 and COG5 are not assigned, you can use these to talk to peripherals and use the channels to communicate with the PC.
There will be support o change all this when the 5.3 public release comes out.
The CSP channels (or Go-channels if you think this does not include enough of the rest of the CSP book yet) is being rolled into the regular propforth kernel support and is in BETA test now. Each of the multiple channels looks like its faster than the single channel used to be; the optimizations to the serial driver more than make up for 8 to 32 channels sharing the serial line. This is still BETA and synchronous over asynchronous, when the Go-Channels support is moved to the Ethernet hardware it is expected to get appropriately faster.
It might be that the number of CPU's on the workstation incrementally affects throughput; and the number of channels has a sweet spot around 8 or 16 channels from the prop side. The beta supports up to 32 channels at this time, this may be adjusted as we get more data. We might have more data by the weekend.
You can telnet to my rig and run the tests on workstation with 1 CPU and 32 channels on the prop.
Telnet to 71 201 87 230 : 4000
hit control C
If nobody else is running the tests, the menu should come up and allow you to run the tests with various parameters.
Comments
In PropForth, the MCS (Multi Channel Synchronous Serial) has demonstrated itself to be 100% reliable so far (between two prop chips). That is, the channel starts sending and receiving 96 bit packets at full clock speed. (Continuously, for several months, so far). When a character is dropped into the send side, it pops out the receive side. The minimalist error count mechanism has only counted errors when we did the "yank out the wire" test. Otherwise its always there and communicating.
Sal made a GO demo on the PC (internal prototype only) a couple weeks back, and it looked like it worked. He still has to futz with something to make it identical on XP and Ubuntu, but it should be ready for public viewing in a couple weeks and we can dissect it after he's done testing. Hopefully you can find errors and tell us where we've gone wrong and how to fix it. The goal is to make the interface definition such that any language prop implementation will be able to talk to any language PC implementation, at least regarding the byte transfer.
http://code.google.com/p/propforth/wiki/GoSetup
EMACS will now use the currently open GO source code file name as the exe output file name.
I am very sure that if you want your GO program to communicate with your Propeller it is not much different than using C or Pascal or Visual Basic. Just another language to talk down a serial link.
We will interface to propforth, but anybody could write a compliant CSP interface in any other development language.
1) Hardware: Two I/O pins are used; one pin for send, one pin for receive (more or less).
2) each pin supports 8 simultaneous channels (as of today), there are 16 I/O present, 8 pairs of two.
3) Each channel is full duplex 115K baud. It uses 8 data bits no parity and no stop bit, so uses a 10 bit transfer. Usable throughput is about 113k baud.
4) The PROTOCOL on each channel uses the full duplex. (I sent a byte, did you get it? Yes I did Now I'm ready for another), but to the user, one channel sends and another channel receives.
5) the transfer is synchronous continuous 96 bit packets. Drop a character in the channel, it jumps out the other side.
6) Each I/O channel also has a pointer to (another channel) where the data is to go. This is typically the input to a the propforth interpreter running on a cog, but it could be a dedicated assembler routine to do what ever. The result is we have an input, from a PC terminal command line, directly to a cog on the Prop.
7) We have 8 channels, so we can have 8 terminal sessions open at once, so we can talk to all 8 cogs at the same time. Each session runs at 115k baud. Just to reiterate, this is using 2 I/O pins.
8) There is an option to have more channels with a lower throughput and higher latency. The estimate is that 32 channels would have about 56k baud throughput. The target is 32 channels at 56k baud. This will allow the workstation to connect to many prop chips, so an application could span the cogs of multiple physical chips.
9) the Use model is
a) running complex applications on the workstation/PC and
b) running acquisition and control on the micro controller.
This use model allows deciding what processing is done at each level, on the PC or the micro controller.
Usually some level of filtering is performed near the sensor before data is sent to the PC.
The PC does some convolution, determines feedback ,control is sent back to the micro controller.
The micro controller can react very quickly, and the PC can handle long term stable processing.
The same PC side code should work with a CSP byte transfer implementation in any other language (PASM, C, BASIC, etc)
The same prop code should work with a CSP byte transfer implementation in any other language, Python, Erlang etc. But I don't know if anybody DOES a CSP byte transfer in any other language. I'll try to contact the Python CSP folks this week to see if they want to play. Also I'll ping MGreim and see if he's ready.
Please see the instructions at
http://code.google.com/p/propforth/wiki/GoSetup20120422
These (should) tell you to also download today's magic
http://code.google.com/p/propforth/downloads/detail?name=20120420mygo.zip&can=2&q=
Could somebody please test this out?
Thanks!
It works, IT'S VERY COOL and you can read more about it here.
Dang you!!
From another thread: New information, and an contradicting opinion! Now we get interesting.
Sal tells me this is a "standard plumbing" to connect any processor process to any other processor's process, and this is the intent of CSP and this is what he's begun implementing.
Heater tells me I'm talking out my butt again. This can be true, as it often is; but is Sal's statement incorrect? Or am I just totally misunderstand the basic concepts again?
Somebody pipe in before I am shamed into deleting all my posts on the subject for the last several weeks.
However none of that has anything to do with CSP as it is formally described.
Is Javascript in your web browser talking to PHP in your server via HTTP requests CSP. No.
I haven't read Mr. Hoare's book (original or updated), so I can't quote from it. From the Wiki (sorry) page, CSP is a formal language that has influenced a number of "implemented" programming languages.
I would take this the same as Realtional Algebra is a formal language that has influenced a number of relational database managers and their supporting query languages.
I don't understand the formalism that elevates CSP beyond message passing between subsystems to accomplish a task - whether it is a central processing unit passing an address of channel commands to an I/O processing unit or a browser passing a request packet off to a server to have it fetch data while it goes on and does something else. If CSP as now defined by Hoare and others lends provability to parallel process messaging methods and a caluculus through which to further define and formalize theory, then that is wonderful.....for the Computer Scientists.
As an specific implementation, the GO/Propforth channel support seems to be a useful and functional way to extend the propforth channels that existed back onto a workstation. I look forward to experimenting with it as a way to mesh of interconnected Props running Propforth that are tied back to a workstation...to what end, I do not know. I'm also pondering goForth extensions to support "CSP" and also the Python/CSP implemention as other playgrounds. Whether or not I can formally prove it to be CSP isn't weighing heavily on me right now.
GO refers to them as "goroutines" and support of cummunicating processes. The line may be that it is inherrent in the language syntax and structure rather than implemented through libraries and external data structures.
I don't know, I'm not a computer scientist and generally not a very formal person.....and that I CAN prove!
Thanks to Heater. for bringing this up, I looked into this a little deeper. I discussed it with Sal, he tried to straighten me out. Let me try and express this properly:
The problem comes from using the term "CSP channels" as it can imply that it includes everything in Hoare's book. Hoare's book is very large and complex definition and includes a language to describe the constructs and techniques he's trying to get across.
The "channels" are synchronous communication channels between parallel sequential processes. What's important is that it's not just the CSP channels, its how we use them. "How to use them" is what the CSP book is about. More specifically, the Hoare book, as explained to me, is about dealing with multiple Finite State Automata. "How to deal with multiple FSA" is the majority of the book.
Propforth just implements channels, but not "how to use them".
The thing I have been referring to as "CSP channels" would more accurately be described as
-->> INTERFACING TO GO-CHANNELS. <<--
The same technique can be used to interface to other channels. It not meant to be a full blown CSP implementation.
Sal said he tried to discuss CSP channels with several folks over the years, but found he ended up spending too much time just deciphering each others understanding, and gave up. So he's not going attempt to explain it to me so I can explain it on the forum; the folks that understand it don't need explanation, and the folks that don't understand it aren't going to get it without reading the book. That's good enough for me, as I still get to use it, and there are too many other books I need to read first.
The bottom line is we can use these channels in many ways, depending on what the goal is. That is, we can stream data to and from the prop using synchronous channels.
----
I also contacted the Python-CSP author. When we get the interface properly nailed down and defined, she may take a look at it. Then we would get good idea of where this would fit, and if it might be useful someplace.
----
Development Progress:
Right now there is slow turn-around (doing synchronous over asynchronous, remember this is only development), it looks likes 60 characters per second per channel.
The protocol limits the speed. The first pass had an ACK for each character sent. Now Sal is working on a buffering scheme so there is one ack the whole buffer. All the channels share the buffer, the channel talking uses as much of the buffer as it needs. This should be transparent to us.
The plan is to take advantage of the WIZNET (spinerette) hardware, and do transfer over Ethernet. It should reside in 1 cog and be really fast. The function .str is optimized to generate the string in memory and spit out characters at assembler speed, so this part is ready. This will spit characters to the memory in the WIZNET. There will be a separate chunk of code to implement the channels for the WIZnet so it all fits in one cog. Sal is not 100% sure , but the cog should communicate equally well on local LAN or global lan. WITH proper buffer, should overcome latency issues. LAG stalls stuff, but buffer fixes it; instead of lots of .5 second delays compounded, the communications are just a .5 second out of phase. Nifty!
So Sal is working on the SERIAL buffering stuff. The plan is:
1) finish optimizing the unbuffered synchronous transfer
2) do a buffered synchronous transfer
3) put it on the wiznet
-- Possibly within two months.(!?)
The default is going to change from 57600 baud to 115k baud in support of Go-channel development.
If anybody else else wants to play with the BETA please PM me with your email address.
Fast Serial will be standard in the public release containing automated testing support, which is targeted for v5.2 in August.
The default serial connection is now 230400 baud.
The GO-terminal command line interface is very snappy.
The GO-telnet interface is still synchronous over asynchonous with byte-ACK, so its still a bit slow, but you can open telnet sessions to all the cogs at once.
Notice that we can do the same with the current release, v5.03, although communication is on the current release is 57600 baud and a bit too slow to really play with. Of course this only affects the Go-telnet experiment; the rest is still crazy fast.
Please send me a PM with email if you want the BETA emailed to you, I try to answer requests as I receive them.
It should allow connections on cog0 through cog5.
Try running the word or if you have lots of time the word
I got COG3, it's like the old teletype days!! I have plenty of time to read things as they go by.
'words' is good for a leisurely afternoon!
The terminal screen next to your is connected locally at 230400 - the difference is noticeable!
- buffered stuff works under windows 4 - 32 channels; 4 channels faster
- the release will include the the original source incremental steps from optimizing forth to assembler.
- tests with 8 channels yield around 1500 cps per channel, up from 200 around cps unoptimized
- Automation beats on the serial ports. Applied assembler optimization on fast load, GO can overrun channels
- possible course for development:
* Its easy in forth to implement a "subset" application language with just a few functions;
* just a few things in a demo like drivers for steppers and servos so its easier to learn and use
- Sal is thinking about a "lead app" to show off CSP channels and go. While some folks understand CSP thoroughly, some of us just know enough to think it might be a cool idea. So Sal is trying to come up with a an inexpensive project to show off how it can be used. Lead app should do-
* multiple inputs
* multiple outputs
* bunch of conflict states with data flow.
* maybe a robot? lots of ins and outs and complex interactions.
* Inexpensive, simple mechanics.
So the first candidates might be:
* Biped, balance bot; four servos and an accelerometer or other sensor
* laser etch-a-sketch, two servos and a cheap laser pointer to draw persistence of vision pictures on a surface
* hypersonic "sound from ultrasound" audio projection
We're open to suggestions. The key parameter is it should be cheap enough that anybody could try it.
The material presented so far is going to be integrated into propforth in support of regression test automation. After this post, I think the discussion will shift back to the propforth thread until some non-forth CSP material comes up. I'm hoping for someone to do C or PASM on the prop to implement that channel interface, and for Python and Erlang implementation of channel interface on the PC. This would be able to happen once the full interface is defined, possibly in the next propforth release.
Any of those projects sound like fun, useful, recreatable efforts. Balance-bots are always fun to play with.
I'm still thinking basic infrastructure and tools. With all the recent activity with wireless, it doesn't seem like wireless CSP channels should be too far down the road.
Yesterday, I fell down this rabbit hole again for a while.
I've got the PyCSP modules loaded and the examples are running. I went with PyCSP instead of python-csp because it is more portable, and is implemented as importable python modules. Python-csp is implemented as its own version of the Python interpreter, which may or may not be a good thing when it comes to managing the CSP stuff.
So, now I need to learn now this CSP stuff works and what it means to this project. There two different sets of documents which share the same concepts and some syntactical candy but there are differences in the implementations. Some things you read about that look interesting were in the old implementation and then changed in the current implementation. Nothing major, just something to be aware of.
For remote processes, one of the "future enhancements" is the concept of "remote evaluators" which fit really well in what we're trying to do with the PC and the Propeller. The channel could be opened up between a PC process and a remote COG under this model. It seems to fit better than the other CSP models and channel connectivity options. This is where I'm headed for now.
Since I've been talking the impossible IDE for PropForth:
.........mix well and leave on your computer for a few days.......who knows what might happen!
For anyone that wants to play along that isn't thrilled about GO (I couldn't handle half-learning ANOTHER language) or Python or Erlang (assume it has CSP-esque channel support) or OCCAM, there is a Java based CSP implementation (JCSP) and a C++ based implementation ( C++CSP). I'm finding more as I hunt around for information. It may not all be "pure" CSP but most are from University environments and do discuss their shortcommings and practical applications when held up against true CSP algebra. Of course, I'm not doing it for the academics or provability of CSP theory.
CSP-esque channel implementations in other Propeller languages would be interesting to see. serialCSP.spin or cspchannel.c, anybody?? (Of course, if you modeled the protocol after the PropForth mcs, then Prop to Prop CSP wouldn't be so impossible.
So, what's your excuse??? It's only your free time!!
Thanks for the tips on the other language options, this is the intent, but Sal and I don't have bandwidth to lead. The next public release should have enough detail so anybody with CSP supported can reproduce the PC end of the MCS interface.
Most of the stuff I think you are describing should be doable once the automation infrastructure is nailed down.
To Folks watching: MCS is similar to Beau's high speed serial, differences being MCS is in FORTH and assembler and includes the protocol. Anyone comfortable with Beau's stuff could implement support once the interface is nailed down. I'm looking forward to serialCSP.spin or cspchannel.c becoming interesting to folks next release.
Please try to telnet to my quickstart running GO-channels at 71 (dot) 201 (dot) 87 (dot) 230 (port) 4000
It should allow connections on cog0 through cog3.
Try running the word
Now notice that running is very fast; faster than it used to be on a single channel direct connection.
COG6 now uses 1K of its RAM to buffer the channel communications. Fewer channels would go slightly faster, and more channels would go slightly slower, but they are all pretty much the same speed. It seems dependant on the number of CPU's in the host computer (the pc in my lab that the quickstart is talking through).
Hopefully, we can get some numbers this week. the guessimate is about 2000 character per second per channel using 8 channels, which is a little bit better than pre-CSP channels for a single channel. We can configure for 8, 16, or 32 CSP channels over a single serial connection.
This demo is still synchronous over asynchronous, so even though its faster than it used to be, it is still slow than its going to be when we use ethernet hardware.
I loaded up the new PropForth and the new GO code and everything worked fine with my C3 and having the GO host on Win7 (I5 - 4 processors indicated). It was faster with the gomuxterm access. Telnet into it from the Win7 laptop as well as my Fedora laptop. I can collect numbers over the next couple of days, if you can give me process to follow. I can host the Prop on various systems ranging from Netbook to i7's if we think that will make any difference. I just need to install Go on the ones that are lacking!
Glad you are making progress - my resources have been diverted for a while.
I can access from my android phone (with wireless off, so it goes through the phone company) and I can see the outside IP address, so I think it should work.
Sometime today I should be able to put up the format for the data Sal is looking for. Lots of projects active today!
I just accessed your Go channeling Propeller from telnet on my iphone via the 4G network - ok, that's just pretty darn cool!!
when I do cog? ro see what's gogin on, I get this:
...and I can open up 4 session to COG0 through COG3. Is it possible to make COG4 and COG5 available for general use via the mux channels? We seem to have lost them somehow. there I/O isn't linked anywhere but they are still running the interpreter and haven't been tasked to run a word like COG6 and COG7. The mux channels that should be theirs are looped back to themselves.
Just a curiosity...and of course, it's always good to have all the Cogs you can get!
For this BETA and the tests, it hard wired for cog0-cog3 to channels for the tests.
COG4 and COG5 are not assigned, you can use these to talk to peripherals and use the channels to communicate with the PC.
There will be support o change all this when the 5.3 public release comes out.
The CSP channels work is now being discussed in the main propforth 5.0 thread.
http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download&p=1099766&viewfull=1#post1099766
The CSP channels (or Go-channels if you think this does not include enough of the rest of the CSP book yet) is being rolled into the regular propforth kernel support and is in BETA test now. Each of the multiple channels looks like its faster than the single channel used to be; the optimizations to the serial driver more than make up for 8 to 32 channels sharing the serial line. This is still BETA and synchronous over asynchronous, when the Go-Channels support is moved to the Ethernet hardware it is expected to get appropriately faster.
We started collecting numbers from the beta testers on throughput.
http://code.google.com/p/propforth/wiki/PF521BETAthroughput
It might be that the number of CPU's on the workstation incrementally affects throughput; and the number of channels has a sweet spot around 8 or 16 channels from the prop side. The beta supports up to 32 channels at this time, this may be adjusted as we get more data. We might have more data by the weekend.
You can telnet to my rig and run the tests on workstation with 1 CPU and 32 channels on the prop.
Telnet to 71 201 87 230 : 4000
hit control C
If nobody else is running the tests, the menu should come up and allow you to run the tests with various parameters.
http://www.amazon.com/The-Way-Introduction-Programming-ebook/dp/B0083RVAJW/ref=tmm_kin_title_0?ie=UTF8&m=AG56TWVU5XWC2