My desktop PC CPU died Sunday, so I have to attach my hard drive to another computer to get the data. This is obviously interfering with my progress.
I struggled a little with the 5MB/s (40Mbps) prop to prop 8 bit single COG-HUB per device data transfers, but got it working solidly. The packet header transfer can use a little tuning now, but I'll leave it as is and focus on Device->Host event notifications. The main problem I had was using waitpeq/waitpne for sync up - the instructions are good at edge detection, but that comes with a price related to the hub window. I switched to using a 2 instruction test/jmp loop signal wait instead and that works fine.
The schematic changes a little for the 5MB/s data. Pin 9 is now common to all Propellers.
There are 14 common pin bits now.
P0-P7 - 8 bit parallel data bus (bidirectional)
P8 - Start/end data transfer indicator (bidirectional) ... key to 5MB/s transfers
P9 - Next Device reset release
P24 - Host->Device Attention signal (with P25 also used for PropID at startup)
P25 - Device->Host acknowledge and Device->Host interrupt
P28 - I2C clock
P29 - I2C data (bidirectional)
I changed the packet header so that the first byte set with the attention bit contains only the device id to open.
This means up to 256 devices could be connected however impractical that may be. The change also allows
using more than 4 basic IPC or Inter Propeller Communications "layer 3" packet types. I need at least 5 types
now for "who-event" polling after an interrupt is detected.
Communications will be via an OSI-like model.
Layer 1 - physical layer (12 of the 14 common pins)
Layer 2 - packet header byte position definition
Layer 3 - data packet header and type (no CRC yet, but will be added)
Layer 4 - packet data and application data integrity/status
Layer 5 - packet connection etc... Application/OS will open/close but sequencing is TBD
Layer 6 - marshalling left to the application ... Propeller byte order will be network order
Layer 7 - Normal Application layer
Hopefully I can grab files off my desktop drive today and continue development.
Hi Jazzed as you know I am totally fascinated by this awesome design. But can I ask should the 8 bit data buss have all the prop chips tied together what I mean is should I tie all the prop chips pins P0-P7 all tied together ? If yes should I use any coupling capacitors ? Jazzed are you going to release any code that will show that all the prop chips are properly connected to each other? Also just to clarify is the schematic complete or is it missing some component connections?
I do have decoupling some caps on the circuit. One decouples the VDD/VSS, the other cleans up the clock from the inverter to the Propeller XI pins (XI pin to VSS). Both are .2uf radial (only because I don't have any .1uf). I'll update the schematic(s) later. I did post the schematic for the new code that I'll be releasing later.
There are 2 designs right now, and once I release the next code I'll be supporting only the new design. The difference is the current design uses P8 for reset and the next one will use P9 (P8 will be used for 5MB/s single COG signalling).
The most important pin connections for startup are P24/25 (with 2.2K pull-ups), P28/29 (with 4.7K pull-ups), pull-up on Device BOEn, and P8 to next device RESn (P9 for the next code release). If any of those are missing, the "Devices" will not boot. For the design to transfer data, pins P0 through P7 need to be connected (and P8 for to be released 5MB/s data code).
I'm using Host/Device rather than Master/Slave because Host/Device is nicer terminology. So Host is the main controller for boot and data transfers and Device(s) are secondary.
I suggest using only 2 Propellers to start out. You can add more as applications are created that would use more Propellers ... at some point soldering all those pins is difficult because of the amount of heat required for the metal. One could use dip sockets instead of big solder blobs [noparse]:)[/noparse]
I won't be creating a special diagnostic any time soon.
CounterRotatingProps said...
What kind of socket is the top-most (or bottom most) prop plugged into?
It's a solder-tail DIP40 with most of the pins removed ... not sure if Parallax sells this type.
I did this so I can plug the Propeller stack into a separate board. The Oscillator, inverter,
and power decoupling are in the socket frame. The EEPROM and resistors are mounted
upside down outside of the socket frame so that I2C clk/dat conveniently touch the Prop pins.
@mikediv, I forgot to mention that console is available on all Propeller pin bits P30/31.
The host boot message should look like this:
OctoProp BootID 03
OctoProp Host!
Waiting for devices: 1234
The Device console will output as below and pin bits P16..19 will set states for the Device ID.
OctoProp BootID 02
OctoProp Device
At some point the P16..19 "diagnostic bits" should be just printed on the Device console.
Jazzed as always awesome stuff I love your work, Jazzed did I miss somehting I never saw any software for this or am I totally blind entirely possible by the way
Thanks Jazzed
mikediv, the first thread post contains OctoPropDemo1.zip under the pictures. The OctoProp4.png shows the schematic supported by that package. The package will boot all Propellers, run some data transfer tests, reboot and repeat. If you attach another Propeller with a console that is not connected to the eeprom, you can use it to run the Propalyzer code and check the waveforms.
Jazzed see what I mean about being blind I don't know why I thought that file was just a jpeg thanks man I am building this on a breadboard as we speak
@Andrew, That's a pretty cool idea. Looks kind of like a digital quilt [noparse]:)[/noparse]
One could have a 2 or 4 wire serial links on each side of the square (with
cross-overs on two sides), and still have lots of pins left over for user apps.
It would be good to have it in two styles - as the one Andrew's link show, i.e., side to side. The other, a stackable, over/under option. The best would be to combine both!
Then we could have a PropBrick. (And the 'transputer' might live again [noparse]:)[/noparse])
CounterRotatingProps said...
It would be good to have it in two styles ...
The RPC code should be able to accommodate both. Once I finish the stackable low level
IPC transport stuff, the RPC interface is next.
I'll contribute to the quilted Propeller problem if someone else wants to lead that effort.
Combining the approaches should not be too hard. Do you 256 Propeller IDs is enough?
only problem with the quilt is connector costs. any idea what is used?
I can get pcbs cheap for the quilt.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Hi I've attached a new schematic (OctoPropINTn.png) and demo code (OctoPropDemoSeparateInt.zip) to the first post. This variation has infrastructure for Device to Host asynchronous notification interrupts and 5MB/s data in a single cog per Propeller. I may be able to squeeze the INT function into the ACK to save a pin, but the notification will be less asynchronous.
The package also includes the BMA debugger vintage 1.5 (also updated in the BMA topic) for the ParallelHost.spin code and can be enabled in the ParallelHost.start method (disabled by default).
Next on the plate is RPC registration and execution, adding SDCARD etc..., then creating a multiprocessing application.
Hey jazzed I know I have said this before but it is really incredible that you and others are willing to share your designs with the rest of us . I know its just a hobby for a lot of us but a lot of your stuff is easily commercial grade yet you freely share it including your code
guys like you are the primary reason if not the sole reason I keep coming back and buying Parallax products. No other community, PICs, AVR's, Arms, I have them all has anything near this kind of support and its because of you guys sharing your great ideas with the rest of us.
Not trying to be a brown nose but Parallax reads these posts they should throw guys like you a bone so you will keep coming back and doing what you do. I can tell you it translates into sales for Parallax. Every Parallax sensor I have purchased was because some member
shared his project or code with us allowing me to learn how to use them far easier than anything else . A lot of us are not coders myself included so to be able to get code to verify my project works means everything to me. Keep it up man Thanks
Jazzed this is the best multi prop thread to date. The first thing I do when I log on is to come right here and check what you have added.
No, obviously you cannot shift the hub access window, but you can choose the best cog if you want to align it to the correct window.
What I mean is this. You can determine by cnt, the access window of each cog by using a pin change while all cogs are in a waitpxx state, Then, by an access to hub followed by a sample of cnt, determine the latency from the pin change.
I use a similar technique to set the cogs exactly 1 clock apart to do sampling for my datalogger. However, as soon as hub access is performed, this exact relationship is lost. But, it is possible to resync back into an exact cycle by then issuing a waitcnt to delay a few clocks.
These are just ideas which you may find useful to achieve whatever you are actually trying to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hi Ray. Ok that's an interesting idea and is possible in my comm driver. Things look pretty solid now empirically with the reboot test, but I'll do a counter survey to check margin since there is about 100ns of play in the 5MB/s data window. Thanks for clarifying.
jazzed said...
Ok that's an interesting idea and is possible in my comm driver.
FWIW, if you want to avoid actually accessing the hub to determine your hub-window-cnt-value simply sample cnt with the first instruction the cog executes. Your hub slots are now at value + 2 + 16n.
mov value, cnt ' first cog instruction (location $000)
cogid id ' no access penalty
Comments
My desktop PC CPU died Sunday, so I have to attach my hard drive to another computer to get the data. This is obviously interfering with my progress.
I struggled a little with the 5MB/s (40Mbps) prop to prop 8 bit single COG-HUB per device data transfers, but got it working solidly. The packet header transfer can use a little tuning now, but I'll leave it as is and focus on Device->Host event notifications. The main problem I had was using waitpeq/waitpne for sync up - the instructions are good at edge detection, but that comes with a price related to the hub window. I switched to using a 2 instruction test/jmp loop signal wait instead and that works fine.
The schematic changes a little for the 5MB/s data. Pin 9 is now common to all Propellers.
There are 14 common pin bits now.
P0-P7 - 8 bit parallel data bus (bidirectional)
P8 - Start/end data transfer indicator (bidirectional) ... key to 5MB/s transfers
P9 - Next Device reset release
P24 - Host->Device Attention signal (with P25 also used for PropID at startup)
P25 - Device->Host acknowledge and Device->Host interrupt
P28 - I2C clock
P29 - I2C data (bidirectional)
I changed the packet header so that the first byte set with the attention bit contains only the device id to open.
This means up to 256 devices could be connected however impractical that may be. The change also allows
using more than 4 basic IPC or Inter Propeller Communications "layer 3" packet types. I need at least 5 types
now for "who-event" polling after an interrupt is detected.
Communications will be via an OSI-like model.
Layer 1 - physical layer (12 of the 14 common pins)
Layer 2 - packet header byte position definition
Layer 3 - data packet header and type (no CRC yet, but will be added)
Layer 4 - packet data and application data integrity/status
Layer 5 - packet connection etc... Application/OS will open/close but sequencing is TBD
Layer 6 - marshalling left to the application ... Propeller byte order will be network order
Layer 7 - Normal Application layer
Hopefully I can grab files off my desktop drive today and continue development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
I do have decoupling some caps on the circuit. One decouples the VDD/VSS, the other cleans up the clock from the inverter to the Propeller XI pins (XI pin to VSS). Both are .2uf radial (only because I don't have any .1uf). I'll update the schematic(s) later. I did post the schematic for the new code that I'll be releasing later.
There are 2 designs right now, and once I release the next code I'll be supporting only the new design. The difference is the current design uses P8 for reset and the next one will use P9 (P8 will be used for 5MB/s single COG signalling).
The most important pin connections for startup are P24/25 (with 2.2K pull-ups), P28/29 (with 4.7K pull-ups), pull-up on Device BOEn, and P8 to next device RESn (P9 for the next code release). If any of those are missing, the "Devices" will not boot. For the design to transfer data, pins P0 through P7 need to be connected (and P8 for to be released 5MB/s data code).
I'm using Host/Device rather than Master/Slave because Host/Device is nicer terminology. So Host is the main controller for boot and data transfers and Device(s) are secondary.
I suggest using only 2 Propellers to start out. You can add more as applications are created that would use more Propellers ... at some point soldering all those pins is difficult because of the amount of heat required for the metal. One could use dip sockets instead of big solder blobs [noparse]:)[/noparse]
I won't be creating a special diagnostic any time soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
RE·your pentaprop:
What kind of socket is the top-most (or bottom most) prop plugged into?
Is that something Parallax carries?
thanks
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I did this so I can plug the Propeller stack into a separate board. The Oscillator, inverter,
and power decoupling are in the socket frame. The EEPROM and resistors are mounted
upside down outside of the socket frame so that I2C clk/dat conveniently touch the Prop pins.
@mikediv, I forgot to mention that console is available on all Propeller pin bits P30/31.
The host boot message should look like this:
The Device console will output as below and pin bits P16..19 will set states for the Device ID.
At some point the P16..19 "diagnostic bits" should be just printed on the Device console.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Thanks Jazzed
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
antipastohw.blogspot.com/2009/08/introducing-illuminato-x-machina.html
I think a 44 pin qfp Propeller would look much nicer on those boards...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
WBA-TH1M Sensirion SHT11 Module
Special Olympics Polar Bear Plunge, Mar 20, 2010
One could have a 2 or 4 wire serial links on each side of the square (with
cross-overs on two sides), and still have lots of pins left over for user apps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Then we could have a PropBrick. (And the 'transputer' might live again [noparse]:)[/noparse])
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The RPC code should be able to accommodate both. Once I finish the stackable low level
IPC transport stuff, the RPC interface is next.
I'll contribute to the quilted Propeller problem if someone else wants to lead that effort.
Combining the approaches should not be too hard. Do you 256 Propeller IDs is enough?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
I can get pcbs cheap for the quilt.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/24/2009 10:32:14 PM GMTThe package also includes the BMA debugger vintage 1.5 (also updated in the BMA topic) for the ParallelHost.spin code and can be enabled in the ParallelHost.start method (disabled by default).
Next on the plate is RPC registration and execution, adding SDCARD etc..., then creating a multiprocessing application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
guys like you are the primary reason if not the sole reason I keep coming back and buying Parallax products. No other community, PICs, AVR's, Arms, I have them all has anything near this kind of support and its because of you guys sharing your great ideas with the rest of us.
Not trying to be a brown nose but Parallax reads these posts they should throw guys like you a bone so you will keep coming back and doing what you do. I can tell you it translates into sales for Parallax. Every Parallax sensor I have purchased was because some member
shared his project or code with us allowing me to learn how to use them far easier than anything else . A lot of us are not coders myself included so to be able to get code to verify my project works means everything to me. Keep it up man Thanks
Jazzed this is the best multi prop thread to date. The first thing I do when I log on is to come right here and check what you have added.
No, obviously you cannot shift the hub access window, but you can choose the best cog if you want to align it to the correct window.
What I mean is this. You can determine by cnt, the access window of each cog by using a pin change while all cogs are in a waitpxx state, Then, by an access to hub followed by a sample of cnt, determine the latency from the pin change.
I use a similar technique to set the cogs exactly 1 clock apart to do sampling for my datalogger. However, as soon as hub access is performed, this exact relationship is lost. But, it is possible to resync back into an exact cycle by then issuing a waitcnt to delay a few clocks.
These are just ideas which you may find useful to achieve whatever you are actually trying to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools