Five Forths Propeller Platform?
mindrobots
Posts: 6,506
Yes, this is a continuation of my Multi-Propeller-configurations-with-PropForth-v-5.0 thread but who could resist getting to use a thread title like "Five Forths Propeller Platform"?
Underneath is a Gadget Gangster Propeller Platform USB giving me one propeller, power and an SD card.
On top is one of jazzed's Tetra-Props giving me 4 Propellers in a nice compact (PP-USB compatable) footprint.
Giving me FIVE Propellers
Each Propeller was loaded with a copy of PropFORTH....so it's FIVE FORTHS!
Ok, enough of that.
Total platform resources:
5 x P8X32A with 6.25MHz crystals, each with dedicated 64KB EEPROM
After loading Forth and configuring communication links:
31 free Forth COGS
128 free pins
SD Card
Host PC connectivity
The independent Propellers leaves more resources available for the cluster than the dependent Propellers used in my first hardware configuration.
The Master and 4 slaves are in what I refer to as a horizontal configuration in my other thread. One master Prop (and Forth image) is the controller for all 4 slaves. There is a 56kb serial connection between the master and each slave. Each connection at this time requires a dedicated COG.
The intent is to make the SD card available but I'm having some issues with the SD version of the Forth kernel (Note to P.B. - I still need to identify and document problem with SD kernel)
A 4-port serial driver for PropForth would also be a nice feature (time to port some SPIN/PASM items from the OBEX?)
The slaves are running the standard PropForthEEPROMKernel modified to handle the faster crystal. The only changes made were to each Propeller propid variable so they identify themselves uniquely in the Forth prompt.
The master was running the SD kernel but was moved back to the EEPROM kernel until my SD problem is identified.
The only Forth words added were taken from the NOROM tutorial to setup the serial COGs and a simple terminal interface from master to slave.
Master Pin usage:
P0-P3 -> SD card
P4-P19 -> FREE PINS
P20 -> Slave 4 P30
P21 -> Slave 4 P31
P22 -> Slave3 P30
P23 -> Slave 3 P31
P24 -> Slave 2 P30
P25 -> Slave 2 P31
P26 -> Slave 1 P30
P27 -> Slave 1 P31
P28-P29 -> EEPROM
P30-P31 -> RX/TX to Host PC
Slave 1-4 Pin Usage:
P0-P27 -> FREE PINS
P28-P29 -> EEPROM
P30-P31 -> RX/TX to Master
As it stands now, you can use the simple terminal to go from master to each of the slaves. This is currently all manually but you can get everywhere and you can run Forth words on any of the 30 free COGs (I don't really consider the console COD on the master free at this point).
Now that the hardware is functional on both platforms (I still need to build at least one more QuickStart Proto Board with another Propeller on it), I need to start doing some research and experimenting on how to make the switch from Prop to Prop transparent through the use of the PropForth Channels (more code study required) and wrappers for the PropForth words that deal with COGs and I/O to the Forth interpreter (cog?, cogx, abortcog, >con, etc.). I also need to look at the MCS synchronous multi-channel communication support.
A near term goal is to be able to sit at a terminal connected to the cluster and be able to use a COG # and transparently connect to, execute or otherwise control that COG. Now, you can do that on a single Propeller with COG0 - COG7. If you reference COG8, it should know that's COG0 on slave 1 and connect accordingly. COG21 ?? - Slave3, COG 5, no problem!
Up to this point, this can all be recreated with fairly standard hardware (PP-USB & Tetra-Prop) and the standard PropForth V5.0 if anybody wants to play along at home.
Note to P.B. - yes, this will be added to my documentation obligation for the Wiki.
Note to jazzed: The TetraProp is great for this project but it really turns into a prickly beast when you start putting pins in all the header locations. I'll need to get another one AND female headers to go with it!
Underneath is a Gadget Gangster Propeller Platform USB giving me one propeller, power and an SD card.
On top is one of jazzed's Tetra-Props giving me 4 Propellers in a nice compact (PP-USB compatable) footprint.
Giving me FIVE Propellers
Each Propeller was loaded with a copy of PropFORTH....so it's FIVE FORTHS!
Ok, enough of that.
Total platform resources:
5 x P8X32A with 6.25MHz crystals, each with dedicated 64KB EEPROM
After loading Forth and configuring communication links:
31 free Forth COGS
128 free pins
SD Card
Host PC connectivity
The independent Propellers leaves more resources available for the cluster than the dependent Propellers used in my first hardware configuration.
The Master and 4 slaves are in what I refer to as a horizontal configuration in my other thread. One master Prop (and Forth image) is the controller for all 4 slaves. There is a 56kb serial connection between the master and each slave. Each connection at this time requires a dedicated COG.
The intent is to make the SD card available but I'm having some issues with the SD version of the Forth kernel (Note to P.B. - I still need to identify and document problem with SD kernel)
A 4-port serial driver for PropForth would also be a nice feature (time to port some SPIN/PASM items from the OBEX?)
The slaves are running the standard PropForthEEPROMKernel modified to handle the faster crystal. The only changes made were to each Propeller propid variable so they identify themselves uniquely in the Forth prompt.
The master was running the SD kernel but was moved back to the EEPROM kernel until my SD problem is identified.
The only Forth words added were taken from the NOROM tutorial to setup the serial COGs and a simple terminal interface from master to slave.
fl
\ setup serial connections
: connect-slaves
c" 27 26 57600 serial" 4 cogx
1 4 sersetflags
c" 25 24 57600 serial" 3 cogx
1 3 sersetflags
c" 23 22 57600 serial" 2 cogx
1 2 sersetflags
c" 21 20 57600 serial" 1 cogx
1 1 sersetflags
;
...
fl
\ a simple terminal which interfaces to the a channel
\ term ( n1 n2 -- ) n1 - the cog, n2 - the channel number
[ifndef term
: term over cognchan min
." Hit CTL-F to exit term" cr
>r >r cogid 0 r> r> (iolink)
begin key dup h6 = if drop 1 else emit 0 then until
cogid iounlink ;
]
...
Master Pin usage:
P0-P3 -> SD card
P4-P19 -> FREE PINS
P20 -> Slave 4 P30
P21 -> Slave 4 P31
P22 -> Slave3 P30
P23 -> Slave 3 P31
P24 -> Slave 2 P30
P25 -> Slave 2 P31
P26 -> Slave 1 P30
P27 -> Slave 1 P31
P28-P29 -> EEPROM
P30-P31 -> RX/TX to Host PC
Slave 1-4 Pin Usage:
P0-P27 -> FREE PINS
P28-P29 -> EEPROM
P30-P31 -> RX/TX to Master
As it stands now, you can use the simple terminal to go from master to each of the slaves. This is currently all manually but you can get everywhere and you can run Forth words on any of the 30 free COGs (I don't really consider the console COD on the master free at this point).
Now that the hardware is functional on both platforms (I still need to build at least one more QuickStart Proto Board with another Propeller on it), I need to start doing some research and experimenting on how to make the switch from Prop to Prop transparent through the use of the PropForth Channels (more code study required) and wrappers for the PropForth words that deal with COGs and I/O to the Forth interpreter (cog?, cogx, abortcog, >con, etc.). I also need to look at the MCS synchronous multi-channel communication support.
A near term goal is to be able to sit at a terminal connected to the cluster and be able to use a COG # and transparently connect to, execute or otherwise control that COG. Now, you can do that on a single Propeller with COG0 - COG7. If you reference COG8, it should know that's COG0 on slave 1 and connect accordingly. COG21 ?? - Slave3, COG 5, no problem!
Up to this point, this can all be recreated with fairly standard hardware (PP-USB & Tetra-Prop) and the standard PropForth V5.0 if anybody wants to play along at home.
Note to P.B. - yes, this will be added to my documentation obligation for the Wiki.
Note to jazzed: The TetraProp is great for this project but it really turns into a prickly beast when you start putting pins in all the header locations. I'll need to get another one AND female headers to go with it!
1024 x 768 - 109K
1024 x 1365 - 186K
Comments
Great pictures!
I ship stacking headers with full kits to fill every hole. The headers are not soldered so you can do what you like. That's the only sane solution I know.
Thanks for putting your board to good use!
--Steve
My Tetra-prop is second-hand. If I get another Tetra-prop from you and add it to the stack, I can have 240 free pins and 59 COGs!!!! The RAW propeller power there is frightening!!
I need to check the current draw through the PP-USB. Things were starting to get a bit warm around the regulators after a while. I might need to hook up an auxiliary power unit if I actually try to do anything productive.
I'm pretty sure the propeller platform regulators are rated at 1A each, but your power brick may be rated less. Your power brick may be sweating it more than the regulators even if the regulators are getting a bit warm. The Propeller Datasheet has more information on current consumption. The rule of thumb I've used is about 12.5ma/COG at 80MHz. So for 5 propellers, you're looking at 500ma with all COGs in the stack running full on without wait instructions.
I also sell PP stuff here at Wulfden. On my original PP (DIP40) kit, I supply beefier regulators as well as healthy heat sinks.
@Jazzed made a good point about the wall wart supplying power, but the real PP gotcha is the power switch. I know most of us have got to be pushing a half amp through them but they are ONLY rated at 0.25A! I recommend in my kits not installing it and subbing a piece of heavy wire instead. for PP USB you might need to dig out the solder sucker!
I have one of Jazzed's TetraProp boards too ... bought with PF in mind. I bought an extra bare PCB to make a connector board
I've purchased from you in the past - I may need to pick up a healthier PP when I hook up the flux-capacitor for the big stack of tetra-props!
Get's your up and running! It's fun to wander around from Prop to Prop and COG to COG starting up Forth words and then leaving them to run.
Yup. Maybe that's a heater
Just found this...
The Go-Channels demo should allow 32 teraterm sessions to all the cogs at the same time over the master's USB serial. The byte-ack version is slow, the buffered version (2-4 weeks) will be faster, and the spineret/wiznet version (another 2-6 weeks) will use the Ethernet hardware and should have maximum throughput (crazy fast). The Go program on the PC loads the master RAM dictionary with the GO-channel support, this takes the place of the MCS code. But the demo does not cover the slave yet, you are breaking new ground.
...
The default prompt is
I asked Sal to design it so that the slaves increment the prop number, and the cogs have an absolute number
But we started to stumble with how to handle the "overhead cogs". Should these be included in the numbering scheme, so the physical number of the cog is displayed:
is the last cog listed, and the "overhead cogs" have to be skipped by the application? Your findings and opinions will be appreciated here.
...
SD problem: Please open an issue and list your steps so we can reproduce it. It may be the order in which you call the initialization words, or skipping something. The tutorial might be unclear.
...
Thanks for your efforts on this.
I need to look how the COGIDs are set up and used but what if you just use (propid * 8) for the base COG on a Propeller and then make the +1 through +7 entries as required?
Being able to do c" blah" 30 cogx would be really cool. Having cog? give you something back like:
(changes in red)
Converting back and forth between absolute COG # and Prop#, COG # is relatively simple.
Some of the words need protection so you don't switch the console to them or some such silly thing. On a standard config, it's OK to do "5 >con" and switch the console to COG5 but you don't want to do a "7 >con" or you kill the serial I/O when it switches. I think >con should only let you go to open or free consoles.
PropForth already knows what is running on each COG, cog? shows this for a single propeller, so for a Master Propeller, it could duplicate this structure for each slave prop and then it could do task distribution across the cluster. The cogx word targets a specific cog but there's no reason there couldn't be a newcog word that would send the command string to any available cog as long as it is running the same Forth image (and dictionary content). This new table and cognew word would give you transparent work distribution rather easily. The cogreset word and others would also need to be made multi-prop aware. Some of this can be done with wrapper words around existing words but some of it is fundamental PropForth infrastructure, I believe.
This is a fascinating are to explore and each rock you turn over reveals an amazing number of new critters that need addressing!
We are ending up with a group of "system" COGs and a group of "application" COGs. When building the cluster, you need control over all the COGs by specific number in many cases. When building the application and running it, you need at best to target a generic application COG on possibly a specific Propeller. If my GPS is connected to pins on Prop2, I don't care which free COG I get to run the GPS words but I do care that it is on Prop2 since the physical connection is there. If I just need a COG to crunch something, then I don't care which COG or which Prop.
I just loaded GO onto my Win7 desktop so I can play with CSP and channels and multi-prop (plus another distraction). I guess I need to do this on the laptop to so I can multi-task while watching TV in the lounger!
I just reloaded the 5 Propellers with the new Forth (thank goodness for conference calls) and fired it up with the higher speed links - it still works and is quick like bunny rabbit!
I still need to do something practical with this but now, I can reach my goal at faster speeds, whatever that goal may be!!
Then you could move around some serious data....faster than most people's internet connection!
I got a suggestion, build a development system so that you don't need a PC anymore!
Doug
I don't think I knew about BeauNet. That would be good for the links between props. I'll have to look at integrating it into PropForth. Thanks for the suggestion!
The VGA and keyboard were put back into the last PropForth. This would make for a nice development system. The other good combination is to front the TetraProp with a Spinerette running the PorpForth Telnet server - This gives you a headless development system you can just set some place and then Telnet in from where ever you are comfortable.
I would like to play with different interconnects to see which ones work best. My opinion, is because BeauNet only uses 2 pins(and those are scarce on a single prop system) that it is a good for many things. An 8 bit ring might be useful for high bandwidth stuff, but usually high bandwidth needs access to memory, so the use of pins (8 in, 8 out) would mean that you couldn't use the fastest memory at the moment which is parallel SRAM like Cluso did with his RamBlade http://forums.parallax.com/showthread.php/116893-RamBlade-Prop-SRAM-microSD-addon-to-run-ZiCog-CPM-PropDos-Catalina-etc would be not possible.
Does PropForth do XMM yet?
The SD card can also be used for storage of word definitions and you can load from SD and then forget as needed.
The Multi-Prop configuration makes this a bit better since you have 1 dictionary per Prop. You can load up a Prop with its "worker words" on top of the kernel and then just start things up in various COGs from the master Prop.
MCS is similar to Beaunet, (if I understand it correctly) with the addition of error correctionand protocol. And it is very fast, talking to a cog on a separate physical chip is the same as talking to a cog on a local chip. I don't how this will affect the multitasker on PF6.0, but we haven't needed more than 8 cogs for the multitasker yet.
There are no plans for XMM support, as this has not been needed. We have only been doing microcontrol scale applications. In cases where large storage is needed, we use SD, this has proven sufficient. I believe the SD is faster than the prop, so it has not been the bottleneck so far.
Although there is a single common dictionary, I belive individual cogs can load assembler routines and execute them without affecting the dictionary the other cogs see.
Also, we can load a file from SD that is a script (with no new defitions) as large as we want (up to the size of the card), and execute it all day. But we have not had an application that need such a huge application yet, so I haven't tried it.
you don't really need spinneret. a serial wifly or a cheap bluetooth module should get you the console on the remote unit (either PC or tablet or anything else)..
I think this is one of the most terrific feature of forth on the propeller, together with the interactivity.
Massimo
Yeah, the more H learn about forth,the more I like it....just wish I had more time to play
Consider BT modules work with android and pc but not with iphone and ipad.
Peter started with propforth, and from the posts he's using them with Tachyon.
forums.parallax.com/showthread.php/139838-How-to-use-those-cheap-Bluetooth-modules-with-the-Prop-(and-more)
forums.parallax.com/showthread.php/147879-Bluetooth-amp-Propeller!
Propforth has many pages in the wiki too
code.google.com/p/propforth/w/list
If I remember correctly propellerpowered had them in stock too.
Massimo
Edit: propellerpowered.us/index.php?route=product/product&path=25_62&product_id=167
HC05 and HC06 on EBAY
http://www.ebay.com/itm/1pcs-RS232-TTL-HC-05-Wireless-Bluetooth-Transceiver-Module-/110929280210?pt=LH_DefaultDomain_0&hash=item19d3e67cd2
http://www.ebay.com/itm/6P-HC-06-Arduino-Bluetooth-Host-Transceiver-Module-Interface-RF-Wireless-Serial-/300938558947?pt=LH_DefaultDomain_2&hash=item461155fde3
Get the mounted ones with 6 pins