TetraProp is a Propeller Platform board with four onboard Propellers. Steve writes…
TetraProp is a PropellerPlatform compatible board with four Propellers. It is designed for distributed parallel procecessing experiments. Each Propeller Island is an individulal unit with headers for user connections.
Headers allow interconnections for user’s design
Four independent Propeller islands on one board
Propeller and EEPROM are SMD
Other components through-hole for easy modification
Jumper selectable reset type
Socket for crystal
PropPlug header for every Propeller
All stacker pins on 0.1″ grid for connecting to a protoboard.
One more photo;
Make a robot friend with Adafruit’s CRICKIT – A Creative Robotics & Interactive Construction Kit. It’s an add-on to our popular Circuit Playground Express, FEATHER and other platforms to make and program robots with CircuitPython, MakeCode, and Arduino. Start controlling motors, servos, solenoids. You also get signal pins, capacitive touch sensors, a NeoPixel driver and amplified speaker output. It complements & extends your boards so you can still use all the goodies on the microcontroller, now you have a robotics playground as well.
1) Look at the pair of annular rings surrounding the vias under the 4 EEPROM chips, they look they’re pretty much touching. I have a difficult time believing these aren’t inferring a clearance errors. I feel that way about many of the vias on the board, actually…
2) The crystals are being run raw into the propeller chips? No resistors/caps associated with those?
3) The resistors on the left side of the board have silkscreen outlines that touch their associated headers. I realize small as possible is good, but space conflicts will only make you unhappy…
4) Unless I’ve acquired sudden, unexpected blindness, 3.3V and GND appear to be tied together…
I am not related to this board, but
2) Crystals run raw into propeller chip – it’s according to Parallax spec. I was curious first, but they suggest it themselves.
I took the picture of the two TetraProp boards shown above. I built them this last weekend.
Concerning George’s comments.
1) The vias do look like they’re touching in the picure you linked to. I have an unpopulated board in front of me and there is clearance between all the vias. I think the CAD image makes them look closer than they are. The board works fine.
2) The crystal on all the Propeller boards Parallax sells run the crystal “raw”. That’s the way it’s supposed to be.
3) The resistors on the left side of the board are normally not populated. They’re there if you want one Prop to program another. You’ll note there’s also a pad for a smt resistor. (There isn’t an associated header for those resistors.)
4) You ought to see an eye doctor about your unexpected blindness.
I purchased four of these boards and I’m very pleased with them.
I can’t say anything about the annular rings on this PCB but I know they can be put pretty close together. I assume that some ERC rule checking was done so I wouldn’t worry about it too much.
The propeller is designed to connect the crystal directly so that also isn’t a problem, although if I would have designed the board, I might have made it possible to use one crystal for all propellers so they’re all in sync. I suppose because the crystals are socketed, this is still possible with some tinkering.
I think the resistors are really only needed if you use the internal brownout protection (BOE pin). In the "standard" Parallax schematic, there are no resistors attached to the RES pin.
The 3.3V and GND don’t appear to be tied together in the schematic so I think what you’re seeing is two overlapping PCB layers. Too bad the original schematic and layout files aren’t available to see exactly what’s going on but it would seem to me that any kind of testing would fail if these are shorted.
This is a great project and I wonder when we’re going to see TetraProp shields 🙂
1) What you see is solder mask. DRC is fine.
2) Propeller does not need any extra components for crystals.
3) Fair point. Current customers don’t seem to care though.
4) No, 3.3V and ground are not tied together.
I’ve built many functional TetraProp boards.
"I might have made it possible to use one crystal for all propellers so they’re all in sync. I suppose because the crystals are socketed, this is still possible with some tinkering."
This is the biggest design flaw IMHO. The board should have been designed with careful symmetric layout to allow all the processors to be clocked by a single crystal, ideally by a clock distriubution chip that allows either a single directly connected crystal or an external clock (think GPS disciplined across many of these boards).
Symmetric layout is critical for clock distribution with simple multi-processor boards like this. The design looks quite symmetrical in the first place. There should have been an "Island" in the center to allow for all four processors to share one clock.
It has been a while since I’ve dealt with the Propeller-I. But from experience I suggest that in order to really take advantage of this board (multi-propeller), you will need to live in PASM (propeller assembler), NOT the SPIN on-die interpreted language (very slow in comparison).
But there is power in the ability to mix SPIN and PASM across cores, but synching the cores running PASM code is a pain (not Propeller’s fault, it is the nature of multiprocessor stuff).
Also each of the Propeller cores are very memory limited in terms of code space.
Oh yes – keep in-mind (big caveat) that almost all PASM Propeller instructions take four clock cycles; hardware/microcode limited. A RISC architeture like used in the small AVR micro-controllers typically take one clock cycle per instruction. But you have to take into account that one propeller core runs at something like 40MHz whereas an AVR ATtiny-like thing runs at half that rate. But more clocks per instruction add-up fast and bog you down.
So again, in my opinion – this board is a nice "glue" approach to ganging four Props. But…
I’d really like to see someone buld a Propeller-centric board that is surrounded with a bunch of inexpensive CPLD’s. The Prop would upload config bitstreams to the CPLD’s then manage them at the application layer. Again all centrally and coherently clocked. That would be interesting.