A simple Propforth *How To* for seamless communications between Props.
Ron Sutcliffe
Posts: 420
Forthers et al
I know that a few Propforth users have had difficulty setting up the coms system.
It is only a draft copy and is part of my ongoing Propforth Docs.
Hope it helps
Ron
I know that a few Propforth users have had difficulty setting up the coms system.
It is only a draft copy and is part of my ongoing Propforth Docs.
HOW SET UP A PROP WITH FULL ACCESS TO SERVICES ON A SECOND PROP
This tutorial explains how to set up PropForth to communicate between cogs and between Props.
A synchronous multi channel communication protocol between 2 Props uses 2 pins. Providing 8 full duplex I/O channels which can easily connect to forth the IO.
YES, there are eight full duplex chanels per cog !
Part1 - because of the beautiful architecture of the prop, cogs via channels on the same Prop chip can communicate with each other.
The LogicAnalyzer can be used to look at these signals. Part2 will cover communications between two Props.
Load PropForth.spin using the Propeller Tool. Reboot and from the supplementary folder load fs.f and fswrite.f.
DO NOT REBOOT, enter saveforth. Then reboot. Paste mcs,f from the supplimentary folder to the terminal window.
Type fsls to confirm that msc.f file is now included in the eeprom file system.
Connect two free Prop pins together via a ~200ohms series resister. The example below uses pins 24 and 26, if you
use different pins you will have to modify the code to suit your configuration. You are now ready to start setting up a MCS system, between two cogs
DO NOT RE-BOOT DURING THE SETUP PROCESS
Start by setting up the two mcs cogs, master and slave, enter the following two lines of code
c” hex 16 18 ff 0 mcsmaster” 4 cogx
c” hex 16 18 ff 3 mcsslave” 5 Cogx
The above code will start two cogs, 4 and 5
The next step is to paste the LogicAnilyzer from the supplimentary to the terminal window.
enter lac to run LA (logicAnalyzer) and confirm that the mcs cogs are running. You don't need to configure or trigger LA in the example. All we need to know is that the two cogs are running. Use the esc key to exit LA
Transactions between the two Pins
==========================
1B_____________________________________________________________________________________________________
1A_____________________________________________________________________________________________________
19_____________________________________________________________________________________________________
18-_---__--__---__--__---__---__---_---__---_---__--__---__---__---_---__--__---__---_---__---__--__---__--__---__---_---__---__--
| | | | | | | |
080.0 uS| 100.0 uS| 180.0 uS| 200.0 uS| 280.0 uS| 300.0 uS| 380.0 uS| 001.0 mS|
| | | | | | | 17_____________________________________________________________________________________________________
16-_---__--__---__--__---__---__---_---__---_---__--__---__---__--__---__--__---__---_---__---__--__---__--__---__---_---__---__--
15_____________________________________________________________________________________________________
14_____________________________________________________________________________________________________
| | | | | | | |
080.0 uS| 100.0 uS| 180.0 uS| 200.0 uS| 280.0 uS| 300.0 uS| 380.0 uS| 001.0 mS|
After confirming that the two cogs are running. Set up three channels in cog 0. There are 8 channels available in each cog, but set up three only for now.
0 0 5 0 (ioconn)
0 1 5 1 (ioconn)
0 2 5 2 (ioconn)
The first line of the code above connects cog0 channel 0 > cog5 channel 0. The other two lines should be obvious.
Finally connect a terminal to the master cog. It will become clear later.
4 0 term
Sets up one instance of term which communicates with cog4, the master cog. From the current cog (cog6 by default).
Cog4 then communicates with cog0 via the two pins 24 and 26. See the code line 0 0 5 0 (ioconn)
Cog0 on the term Prop is required to run the services provided by the Slave Prop
We can see this if we enquire on the cogs status by entering cog?
The Pin and Hub connections
======================
Cog:0 #io chan:1 PropForth v4.5 2011JUL25 7:10 2 0(0)->5(0)
Cog:1 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:2 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:3 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:4 #io chan:3 MCS 4(0)->7(0) Terminal is connected to master cog
Cog:5 #io chan:3 MCS 5(0)->0(0) Slave is connected to cog0 channel 0
Cog:6 #io chan:1 PropForth v4.5 2011JUL25 7:10 2 6(0)->4(0)
Cog:7 #io chan:1 SERIAL 7(0)->6(0)
Prop0 Cog0 ok
The link between master and slave is via a resistor between pins 24 and 26.
Here' s the fun part. 1 cog can drive 5 Props. Once running , the services of the other cogs connect seamlessly to
the current cog on the master prop, covered below in Part 2.
Part 2 Setting up second Prop which supports an SDCard
==========================================
Connect two free pins from master Prop to two Free pins on the slave Prop use ~200ohms series resister between the connecting pins. The example below uses pins 8 and 9 on the slave prop and pins 16 and 18 on the master Prop.
If you use different pins you will have to modify the code to suit your configuration.
********* Note the master pin on the master Prop is pin 16 and the master pin on the slave Prop is 8, Pins 9 and 18 are slave pins. *******
You are now ready to start setting up a MCS system, between two cogs.
The code for the slave is shown below. Firstly cog4 is started then the channel connections are made. The 200 ms delay is shown just in case the code is built into a script. This should allow time for the Props to sync up. (maybe)
c" hex 8 9 ff 3 mcsslave" 4 cogx
200 delms
0 0 4 0 (ioconn)
0 1 4 1 (ioconn)
0 2 4 2 (ioconn)
The master code below requires no channel connections in this example. Then master Prop uses term to communicate via the forth IO
c" hex 10 12 ff 3 mcsmaster" 3 cogx
3 0 term
The slave Prop running the Sdcard File system is now available to the master Prop in the current cog
Below is the log of the set up of the master Prop
Prop0 Cog6 ok
c" hex 10 12 ff 3 mcsmaster" 3 cogx
Prop0 Cog6 ok
3 0 term
Hit CTL-F to exit term \ This is a response from term
sd_init \ request by master prop current cog for sd services
Prop0 Cog0 ok
mountsys \ request slave prop to mount file system
Prop0 Cog0 ok
ls \ list the root dir
151 .partion-sys/
82 .sdcardinfo
88 .autousr.f
85 .autoload.f
Prop0 Cog0 ok
fread .sdcardinfo \ read the sdcard info
SDCard size: 3,872,250 Kbytes
File System: sys
Start Block: 1
End Block: 65,538
File System Size (blocks): 65,537
File System Size (bytes): 32,760 Kbytes
File System: usr
Start Block: 65,538
End Block: 7,744,512
File System Size (blocks): 7,678,974
File System Size (bytes): 3,839,480 Kbytes
Prop0 Cog0 ok
Below see the Cog status
Prop0 Cog0 ok
cog?
Cog:0 #io chan:1 PropForth v4.5 2011JUL25 7:10 2 0(0)->4(0)
Cog:1 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:2 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:3 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:4 #io chan:3 MCS 4(0)->0(0)
Cog:5 #io chan:1 PropForth v4.5 2011JUL25 7:10 2
Cog:6 #io chan:1 PropForth v4.5 2011JUL25 7:10 2 6(0)->7(0)
Cog:7 #io chan:1 SERIAL 7(0)->6(0)
Prop0 Cog0 ok
This is a draft copy only which will be fleshed out when Sal Sanci's PF5.0 is released shortly
Hope it helps
Ron
Comments
The tutorial is in the docs subdirectory of the download package .
../doc/test-4.1.1SerialLoopback.txt
It'd named "test" but is actually the instruction on how to use the function (this will be fixed in the next release). The tutorial shows how to talk from one cog to another using serial in a loop back comfiguration, just stick another device on the same pin (and don't start the second serial session) to use as a regular serial.
If you have questions, please ask. The plan is to add web pages for each tutorial when questions arise. This is because specific questions are more efficient than trying to write a general instruction that anticipates all posiible questions (I tried that, it didn't work at all). You can start a thread or PM me (or continue in this thread, but its a bit off topic)
A little OT, but it does relate in that, it uses the definition term. The definition term differs from the version used in the mcs system in that it only pops the cog# off the stack. The channel# is always 0 when using a Duplex Serial system, beause the demo code only starts one instance of FullDuplexSerial.
You can direct queries to the Propforth Wilki site but I am working with prof and the group to get some of the basic documentation together so happy to help in the meantime.
The top post has been updated, I think it makes a bit more sense now.
: term ." Hit CTL-F to exit comterm" cr cogid swap iolink begin key dup 6 = if drop 1 else emit 0 then until cogid iounlink ; : demo txPin rxPIN baudrate cog# startserialcog 10 delms cog# term ;cheers
Ron
One is asynchronous communications, this is similar to full duplex serial. A baud rate is selected, and data is sent as usual. This is typically for communicating with a terminal or other n external devicce.
The other is synchronous serial, which is similar to Beau's High Speed Serial. Sal calls synchronous serial MCS or Multi-Channel Serial. I would prefer to call it High Speed Multichannel Synchronous Serial, but we decided that we couldn't pronounce HSMSS as a word. Anyway, sync serial runs at near clock speed, and continuously sends and recieves 96 bit packets. The effect is that a user or an application can transparently talk to cogs on another physical chip with no appearant delay or lag. Of course, its not exactly the same as talking to a local cog but so far we haven't had a use case where it was a problem. The difference between MCS and Beaus' High Speed serial is (I think) Beau's is faster because it is the raw implementation and Sal's is slightly slower because it includes the protocol and error tallying (which one would probably need with Beau's anyway).
As Ron said, we plan to get the documentation cleaned up a bit better when the 5.0 release comes out in the near future. (If I ever get off my butt, quit playing with my 3D printer, and finish testing 5.0)
Yep, I should have made a clear distinction between the the two, synchronous and asynchronous protocols used in Propforth.
I still have not got my head around the re-sync issue. There is provision to use a line for reset in mcs. (used in mcsnorom) Do you know if the master prop also uses the line to reset the slave if it drops out..?
I have never hooked up a reset line, because I don't run slaves without eeproms.
Ron
Solution found........connect term to master prop instead of a slave. Then write my own reset system, if I loose a slave just send a reset.
Then figure out a onreset routine to resync, or find one, in the tin of worms