Multiple propeller chips
Dr_Acula
Posts: 5,484
I'm looking at some ideas using multiple propeller chips rather than discrete TTL chips. In many cases, TTL chips work out cheaper but the problem is that every time a design changes a new board needs to be made. I'm thinking it may work out cheaper in the long run to do it all in software 
So - simple design, two propellers, master and slave. There are designs going right back to the beginning of the propeller where one prop can boot another. So - add an SD card, store a binary image of the slave's program on the SD card and send this to the slave. I think this uses three propeller pins - on the slave it is P30, P31 and Reset. On the master these can be any pins?
Next, one might want to send and receive data. But for the design I want, I need to both send data, and also have the slave propeller respond very rapidly to pin changes (I want to use it as the address pins for a ram chip). So while serial might be a good comms protocol, I think clocked ones might be faster.
So, instead of 3 lines, maybe use 4 lines. Reset is a dedicated line. The 3 lines can then be a SPI interface with Clk, DO and DI.
No eeprom on the slave propeller. So the idea is that the master boots the slave propeller using the slave's P30, P31 and Reset. The downloaded program runs an SPI slave object (one is in the Obex - neat!) Then the master talks to the slave via the slave's P30, P31 and P29.
For incrementing address lines, one might send the address as 3 bytes via SPI protocol, but to increment the address, just toggle the Clk line.
There might be another solution using one less pin and configuring the slave as an I2C slave. I haven't explored that as yet.
Advice would be most appreciated!
So - simple design, two propellers, master and slave. There are designs going right back to the beginning of the propeller where one prop can boot another. So - add an SD card, store a binary image of the slave's program on the SD card and send this to the slave. I think this uses three propeller pins - on the slave it is P30, P31 and Reset. On the master these can be any pins?
Next, one might want to send and receive data. But for the design I want, I need to both send data, and also have the slave propeller respond very rapidly to pin changes (I want to use it as the address pins for a ram chip). So while serial might be a good comms protocol, I think clocked ones might be faster.
So, instead of 3 lines, maybe use 4 lines. Reset is a dedicated line. The 3 lines can then be a SPI interface with Clk, DO and DI.
No eeprom on the slave propeller. So the idea is that the master boots the slave propeller using the slave's P30, P31 and Reset. The downloaded program runs an SPI slave object (one is in the Obex - neat!) Then the master talks to the slave via the slave's P30, P31 and P29.
For incrementing address lines, one might send the address as 3 bytes via SPI protocol, but to increment the address, just toggle the Clk line.
There might be another solution using one less pin and configuring the slave as an I2C slave. I haven't explored that as yet.
Advice would be most appreciated!
Comments
Yes, props are so much easier to change configuration. If you have an SD card, then you can use the 24C64 to boot the SD card. This way, you can save a few more cents on the prop as well.
Serial (even if you clock) will be better IMHO than using the I2C or SPI protocol. There is no need to remain within the I2C/SPI speed specs unless you actually want to add some other parts to the bus.
So far, none of my multiple Prop designs have required more than 115,200 baud. Beau has faster prop to prop code if you require it.
Typically, one of my props is just a fast machine built as a RamBlade3 (512KB SRAM and microSD) so I only have 2 pins free (P30 & P31). This prop is always overclocked and running at 104MHz and it fits on a tiny pcb (about 1"x1.5"). I can also build it using my 1" stackable boards, and include an RTC if required.
One of my commercial designs includes the RTC in the RamBlade3 section. This design uses 3 props.
I do not at present use the RamBlade3 to reset the other props, but this can be done simply. I have not bothered to save the eeprom chips on any of these props, but is certainly doable.
BTW I have a new TriBlade3 (thru hole) on the drawing board. The old TriBlade pcb was way too expensive!
BTW2: I have a PropOS working with FTF to/from the PC. It is/was based on your KyeDos, but I separated each of the commands out to be separate programs (just like the old CPM and MSDOS/DRDOS so it makes it easy for anyone to add other OS commands). It is able to call CPM/ZiCog which can then call the OS again. I can FTF files between the OS (FAT32) and CPM one way (CPM to FAT32) but I have not had the time to complete the reverse (need to do the writeout to the CPM file structure).
Hope this helps.
Now I was considering learning more about SPI and setting up a multi micro system using it, instead of UART. Im not sure how fast an AVR can do SPI, but a propeller can do up to 10mhz if im not mistaken, that is much faster than a serial connection. Why do you recommend a UART over SPI? Im not understanding the whole thing about having to stay in the speed specs, I haven't worked with SPI yet outside of canned objects. I know Beau has that nice hi speed object, but he makes it sound more like its for transferring massive amounts of data, where as im just trying to send maybe at the most an array of 10 longs around, but I want them to get to the right chip as quick as possible.
Yea, you got me. I was hoping to sneak this discussion thread in and everyone *except* Cluso would see it
Ok, but I have some ideas to take things further. Let's think of a super propeller with 16 cogs and 64 pins. To make such a thing work in practice we need flexible data links. Serial might be fine as you say. But let's go back to all the discussions we had with the triblade and how it helped realise all the emulations as I don't think we tried a few things.
Take cluso's propeller plus 512k ram solution - the fastest ram solution possible with the propeller, but it leaves us with a few pins free. Consider now a new model - a master propeller with keyboard and SD and display, and a slave propeller with 27 pins talking directly to a ram chip. We can transfer data very fast from the second propeller to and from the ram chip, but that doesn't achieve very much if the pipeline to the master propeller chip is a 115k serial link.
However, we could define the 8 data pins on the ram chip to be a data bus. Connect to 8 pins on the master propeller and we now have a fast data pipeline. Now, with an 8080 style data+address+control bus, it takes at least 8+16+2-4 pins to run such a bus, which is more than a propeller has. But this system is different. The slave propeller is software configerable to be a smart SPI slave. So - program it via 3 SPI pins to enter a certain data comms mode. The mode might be "after you have received this command, clock out 256 bytes via the data bus with the SPI clock pin". And then you could program it to "clock in 64 bytes via the data bus". So you can do away with all the address pins and virtually all the control pins and still achieve faster data rates than a real 8080.
Furthermore, you can even send an instruction to say to the second propeller "stop talking to the ram chip and make those 8 data lines HiZ" and then the master propeller can use those pins for something else.
I'm not sure how much of this has been explored yet. I suspect that back when the initial second booting code was released back in ?2006/7, SD cards were not being used much so it was harder to store precompiled binary images of spin programs. But with things like Kyedos, a compiled spin program could be loaded from an SD card into any one of a number of slave propellers. And it makes debugging easier too if it can be tested first on the main propeller.
What else can we do? The slave propellers can be extremely minimal. They don't need a prop plug to program, nor a regulator, nor a max232, nor an eeprom. In fact, I think all they need are a xtal and the bypass capacitors.
I'm not sure where this will go but I have this general idea of a software 64 pin, 16 cog propeller.
Addit: last night I found the forum thread that had the spin code to load a second propeller but I can't find it just now. But assume for the moment it is there, it would be very useful to wrap it up into a program that could be run by kyedos. Need to pass the name of the file to load eg myprog.exe or myprog.bin, and the three pins the master is using (Tx, Rx, Reset pin).
In one of my multi-prop designs I boot two props out of the same EEPROM. I just connect SDA/SCL in parallel and hold the slave prop in reset until the master has finished booting. This requires only one extra pin for the props so that they can decide wether to execute slave or master code. Of course, you only have 32kB for both programs but it's usually enough for smaller projects.
http://www.altera.com/products/devices/max7k/m7k-index.html
They are even available in PLCC which can be used easily on prototyping boards.
The programmers are expensive if bought from the manufacturers but cheap clones are available on Ebay for less than the price of a Prop Plug.
The motivations for wanting multiple Prop solutions could only be to get more pins, more RAM or more CPU power. In generall my observation is that mostly it would be better to abandon the Prop and get some other device with more of what you need. Seems to me that while chasing these goals with multiple Props one loses out on pins and speed. The solution is slow, the solution is big etc. All the while negating the advantages of the Prop in the first place, simplicity, elegance, self containedness (word?), low power operation etc.
Further, the imminent arrival of the Prop II changes everything. Starting out on a multiple Prop I design now may be a redundant exercise as the PII will arrive before the design is perfected and provide a lot of what you want.
Hope I have not put too much of a downer on proceedings, perhaps there are good cases for multiple Prop II designs I have yet to consider.
P.S. I do see some nice use cases. For example a Prop as an engine doing whatever and a second Prop totally dedicated to video display and keyboad as a terminal. But I tend to think of those interms of two separate devices the embedded device and a terminal that just happen to be Prop based.
For reference, I found the code again that allows a propeller to load another propeller http://forums.parallax.com/showthread.php/86311-Propeller-Loader?highlight=bootloader
The idea of loading two props from the same eeprom is intriguing. That could save a pin as the reset line doesn't need to be controlled. So, you could load Kyedos as the standard program, but for slaves, Kyedos would abort when it doesn't find an SD card, and then enter a mode where it is waiting for a command from the serial pins. From a hardware perspective, could you change the reset delay by putting different value capacitors on the reset line?
Re CPLD devices - these look great. Some are $2 on ebay. Some are $800 (quick search of Jameco), so obviously need to pick the right ones!
Re the P2, I'd prefer to tinker around with prop chips that I have to hand
I think I need to try to incorporate Chip's code from 2006 into Kyedos somehow, and add a command that can load a binary image into another propeller.
Ok, well in a way I'm just getting something working that Chip had working in 2006, but I think it would be super easy to combine this with Kyedos and load files from an SD card rather than a binary file included in a spin program.
Code is below.
The photo is of a new board system called the Centimanes. The Hydra and Cerberus are already taken, so continuing the mythology theme, the Centimanes had 100 arms and 50 heads. Sort of like all the 10 pin cables going everywhere.
The photo shows two boards, the first programming the second. There are a few other peripheral boards in the photo just to show what they look like, and a schematic of the motherboard is attached.
Pins are brought out to 10 pin headers in groups of 4 and groups of 2, so headers can be soldered in as needed. The system is flexible, eg the diagnostic led board could be connected to a socket on the propeller board, or it could be connected to the output of an SPI expander board. Or an I2C expander board.
I have some memory boards being made that have lots of 10 pin sockets for all the address and data pins. To connect - just daisy chain a series of propeller boards so there are enough pins.
I think this is starting to realise the abstract ideal of a propeller with as many pins and as many cogs as you like.
''***************************** ''* Propeller Loader v1.0 * ''* (C) 2006 Parallax, Inc. * ''***************************** ' v1.0 - 13 June 2006 - original version ''_____________________________________________________________________________ '' ''This object lets a Propeller chip load up another Propeller chip in the same ''way the PC normally does. '' ''To do this, the program to be loaded into the other Propeller chip must be ''compiled using "F8" (be sure to enable "Show Hex") and then a "Save Binary ''File" must be done. This binary file must then be included so that it will be ''resident and its address can be conveyed to this object for loading. '' ''Say that the file was saved as "loadme.binary". Also, say that the Propeller ''which will be performing the load/program operation has its pins 0..2 tied to ''the other Propeller's pins RESn, P31, and P30, respectively. And we'll say ''we're working with Version 1 chips and you just want to load and execute the ''program. Your code would look something like this: '' '' ''OBJ loader : "PropellerLoader" '' ''DAT loadme file "loadme.binary" '' ''PUB LoadPropeller '' '' loader.Connect(0, 1, 2, 1, loader#LoadRun, @loadme) '' '' ''This object drives the other Propeller's RESn line, so it is recommended that ''the other Propeller's BOEn pin be tied high and that its RESn pin be pulled ''to VSS with a 1M resistor to keep it on ice until showtime. '' comment Dr Acula 2013 - seems to work fine with BOEn tied low as per standard schematic. ''_____________________________________________________________________________ '' CON #1, ErrorConnect, ErrorVersion, ErrorChecksum, ErrorProgram, ErrorVerify #0, Shutdown, LoadRun, ProgramShutdown, ProgramRun DAT loadme file "bargraph.binary" ' file to send to second propeller VAR long P31, P30, LFSR, Ver, Echo PUB Main Connect(0, 1, 2, 1, LoadRun, @loadme) repeat PUB Connect(PinRESn, PinP31, PinP30, Version, Command, CodePtr) : Error 'set P31 and P30 P31 := PinP31 P30 := PinP30 'RESn low outa[PinRESn] := 0 dira[PinRESn] := 1 'P31 high (our TX) outa[PinP31] := 1 dira[PinP31] := 1 'P30 input (our RX) dira[PinP30] := 0 'RESn high outa[PinRESn] := 1 'wait 100ms waitcnt(clkfreq / 10 + cnt) 'Communicate (may abort with error code) if Error := \Communicate(Version, Command, CodePtr) dira[PinRESn] := 0 'P31 float dira[PinP31] := 0 PRI Communicate(Version, Command, CodePtr) | ByteCount 'output calibration pulses BitsOut(%01, 2) 'send LFSR pattern LFSR := "P" repeat 250 BitsOut(IterateLFSR, 1) 'receive and verify LFSR pattern repeat 250 if WaitBit(1) <> IterateLFSR abort ErrorConnect 'receive chip version repeat 8 Ver := WaitBit(1) << 7 + Ver >> 1 'if version mismatch, shutdown and abort if Ver <> Version BitsOut(Shutdown, 32) abort ErrorVersion 'send command BitsOut(Command, 32) 'handle command details if Command 'send long count ByteCount := byte[CodePtr][8] | byte[CodePtr][9] << 8 ' length of file BitsOut(ByteCount >> 2, 32) 'send bytes repeat ByteCount BitsOut(byte[CodePtr++], 8) 'allow 250ms for positive checksum response if WaitBit(25) abort ErrorChecksum 'eeprom program command if Command > 1 'allow 5s for positive program response if WaitBit(500) abort ErrorProgram 'allow 2s for positive verify response if WaitBit(200) abort ErrorVerify PRI IterateLFSR : Bit 'get return bit Bit := LFSR & 1 'iterate LFSR (8-bit, $B2 taps) LFSR := LFSR << 1 | (LFSR >> 7 ^ LFSR >> 5 ^ LFSR >> 4 ^ LFSR >> 1) & 1 PRI WaitBit(Hundredths) : Bit | PriorEcho repeat Hundredths 'output 1t pulse BitsOut(1, 1) 'sample bit and echo Bit := ina[P30] PriorEcho := Echo 'output 2t pulse BitsOut(0, 1) 'if echo was low, got bit if not PriorEcho return 'wait 10ms waitcnt(clkfreq / 100 + cnt) 'timeout, abort abort ErrorConnect PRI BitsOut(Value, Bits) repeat Bits if Value & 1 'output '1' (1t pulse) outa[P31] := 0 Echo := ina[P30] outa[P31] := 1 else 'output '0' (2t pulse) outa[P31] := 0 outa[P31] := 0 Echo := ina[P30] Echo := ina[P30] outa[P31] := 1 Value >>= 1Ok, compile any spin program and do an F8 and it saves as a .binary file. Change that .binary to .exe as kyedos recognises .exe file extensions (and prefers 8.3 file formats).
Kyedos can run any precompiled program - just type MYPROG and if MYPROG.EXE exists on the SD card it will load and run that program. Nothing new there.
But now, we can use a propeller chip to transfer that precompiled program to another propeller chip.
{This program loads a binary file from an SD card and then sends this file to a second propeller} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 _TV_Enabled = true ' TV display on _TV_Pin = 16 ' group of 3 pins starting at pin 16 _SD_DO = 12 _SD_CLK = 13 _SD_DI = 14 _SD_CS = 15 _SD_WP = -1 ' -1 ifnot installed. _SD_CD = -1 ' -1 ifnot installed. _RTC_DAT = -1 ' -1 ifnot installed. _RTC_CLK = -1 ' -1 ifnot installed. ' prop loader constants #1, ErrorConnect, ErrorVersion, ErrorChecksum, ErrorProgram, ErrorVerify #0, Shutdown, LoadRun, ProgramShutdown, ProgramRun OBJ text: "tv_text" fat: "SD-MMC_FatEngine_No_RTC.spin" ' smaller version of Kye's fat engine with no RTC str: "ASCII0_STREngine.spin" VAR byte LineOfText1[80] ' general purpose string buffer ' prop loader constants long P31, P30, LFSR, Ver, Echo PUB Main text.start(_TV_Pin) ' start TV or VGA text.clearscreen PrintStringCR(string("Testing for SD card")) ifnot( fat.FATEngineStart(_SD_DO, _SD_CLK, _SD_DI, _SD_CS,_SD_WP, _SD_CD, _RTC_DAT, _RTC_CLK, -1)) reboot PrintStringCR(string("SD found")) fat.mountPartition(0) ' mount the sd card PrintStringCR(string("SD mounted")) PrintStringCR(string("Open file")) fat.OpenFile(string("Bargraph.exe"),"R") ' should be 8.3 format ConnectPropeller(0, 1, 2, 1, LoadRun, fat.filesize) ' Res,P31,P30,could read byte 8 and 9, OR use fat.filesize fat.CloseFile PrintStringCR(string("Close file")) 'repeat PUB ExtractCommandline ' there is a file COMMAND.TXT that Kyedos program created to pass parameters ' need to add code eg to parse MYPROGRAM 1 2 3 ' may wish to pass the file to send and the pins to send it on eg PROPLOAD MYFILE 0 PUB PrintStringCR(pstring)' sends pstring to the display text.str(pstring) crlf PUB PrintChar(c) ' sends c to the display text.out(c) PUB crlf PrintChar(13) ' send to display PrintChar(10) ' send to display ' *************** prop loader code ******************* PUB ConnectPropeller(PinRESn, PinP31, PinP30, Version, Command, NumberBytes) : Error P31 := PinP31 'set P31 and P30 P30 := PinP30 outa[PinRESn] := 0 ' RESn low dira[PinRESn] := 1 ' and set as output outa[PinP31] := 1 'P31 high (our TX) dira[PinP31] := 1 ' and set as output dira[PinP30] := 0 'P30 input (our RX) outa[PinRESn] := 1 'RESn high waitcnt(clkfreq / 10 + cnt) ' wait 100ms Communicate(Version, Command, NumberBytes) ' communicate dira[PinRESn] := 0 ' reset pin floating dira[PinP31] := 0 'P31 float PRI Communicate(Version, Command, NumberBytes) | ByteCount BitsOut(%01, 2) 'output calibration pulses LFSR := "P" 'send LFSR pattern repeat 250 BitsOut(IterateLFSR, 1) repeat 250 'receive and verify LFSR pattern if WaitBit(1) <> IterateLFSR text.str(string("Error Connect")) repeat 8 'receive chip version Ver := WaitBit(1) << 7 + Ver >> 1 text.str(string("Version ")) text.dec(Ver) crlf if Ver <> Version 'if version mismatch, shutdown and abort BitsOut(Shutdown, 32) text.str(string("Error Version")) BitsOut(Command, 32) 'send command if Command 'handle command details 'ByteCount := byte[CodePtr][8] | byte[CodePtr][9] << 8 ' length of file ByteCount := NumberBytes ' number of bytes to send BitsOut(ByteCount >> 2, 32) repeat ByteCount 'send bytes 'BitsOut(byte[CodePtr++], 8) ' original code sent from hub memory BitsOut(fat.readbyte,8) ' read byte from SD card and send out if WaitBit(25) 'allow 250ms for positive checksum response text.str(string("Error Checksum")) PrintStringCR(string("File sent")) 'eeprom program command - commented out as not used 'if Command > 1 ' ' 'allow 5s for positive program response ' if WaitBit(500) ' abort ErrorProgram ' ' 'allow 2s for positive verify response ' if WaitBit(200) ' abort ErrorVerify PRI IterateLFSR : Bit 'get return bit Bit := LFSR & 1 'iterate LFSR (8-bit, $B2 taps) LFSR := LFSR << 1 | (LFSR >> 7 ^ LFSR >> 5 ^ LFSR >> 4 ^ LFSR >> 1) & 1 PRI WaitBit(Hundredths) : Bit | PriorEcho repeat Hundredths 'output 1t pulse BitsOut(1, 1) 'sample bit and echo Bit := ina[P30] PriorEcho := Echo 'output 2t pulse BitsOut(0, 1) 'if echo was low, got bit if not PriorEcho return 'wait 10ms waitcnt(clkfreq / 100 + cnt) 'timeout, abort text.str(string("Error Timeout")) PRI BitsOut(Value, Bits) repeat Bits if Value & 1 'output '1' (1t pulse) outa[P31] := 0 Echo := ina[P30] outa[P31] := 1 else 'output '0' (2t pulse) outa[P31] := 0 outa[P31] := 0 Echo := ina[P30] Echo := ina[P30] outa[P31] := 1 Value >>= 1This starts to create the abstract idea of a propeller chip with as many cogs and as much ram as you like. All we need is a comms protocol between chips (and there are many options, starting with serial objects using the download pins) and tasks can be moved off to another propeller. For instance, Kyedos itself uses Kye's SD driver, and every program using Kyedos uses about half the hub ram to run the SD driver. But the SD driver code can be moved off to another propeller, as can the TV or VGA driver and keyboard drivers, freeing up virtually all the host propeller ram for code.
The slave propellers are very minimalist - just the bypass caps and the xtal.
Photo of a simple version using pins 12-15 for the SD card, pins 16-19 for the TV and pins 0-3 for talking to the second propeller. A keyboard can be added on pins 26 and 27. All easily changed in software. And 30+(32-4-14) = 44 spare pins.
Another thing I'm going to have to add to my list of multiprop things to try.
PropForth let's you do this with Forth words. You can cause them to be executed on different COGs now. It needs a little more supporting infrastructure to map the COGs of the slave Props into a nice table for the master to use to dispatch work but he underlying mechanisms are in place. Being able to dispatch .binary blobs to slaves for execution could be lots of fun to play with.
Put a P2 with all its I/O pins at the center as your master prop and you could drive quite a network of P1 slaves. (sort of Hard-Soft peripherals for the P2)
I haven't played with Kyedos yet. I guess I'll have to try that next!
Brain Morpher
http://humanoidolabs.blogspot.com/2012/01/brain-morpher.html
Transposition
http://humanoidolabs.blogspot.com/2013/02/transposition-machines.html
Objects Inside the Chip
http://humanoidolabs.blogspot.com/2012/09/objects-inside-chip.html
Virtual Processing
http://humanoidolabs.blogspot.com/2013/02/is-pure-thought-virtual-process.html
Transformation Machine TMACH
http://humanoidolabs.blogspot.com/2012/08/transformation-machine-tmach.html
A Propeller Tractor Beam
http://humanoidolabs.blogspot.com/2012/09/propeller-tractor-beam.html
Double Enhancement
http://humanoidolabs.blogspot.com/2012/09/double-enhancement.html
More Techniques
The SuperTronic Brain blog talks about some of these effects that run inside the same machine. Such a platform can also handle many of the Lab's long term developed original techniques and inventions as listed below.
http://humanoidolabs.blogspot.com/2012/09/supertronic-brain.html
Cubing
Internal Transforming
Internal Teleportation
Nanites
Partitions
MIMs (Machines in Machines)
Cloning
Assimilation
Radio Brain Thought Monitor
Brain Wave Monitor BWMs
ParaP (PARP) Parallel-Parallel
Jump Over Communications
At-Once Particulator
Electronic Brain Fluid
Hyper Neural Threading
Brain Channeling
No Parts Invention
Intellectual Surfing
Shape Shifting
Internal Swarming
Neural Injection
Que Messaging
OffSetting
Arraying
Hybriding
Wire Sharing
Soft Wiring
Power Reduction
Intellectual Docking
Wireless Remote Control
I was reading the other thread the other day, probably misreading it actually.
For some reason I thought you guys were trying to build a microprocessor.
One prop makes up a 20(?) bit address bus,
one prop makes up the 16 bit data bus,
one prop makes up the control signals and synchronizes everything.
one prop makes up the standard I/O signals.
Weird thought.
cavelamb - yes this started as a different driver for the touchscreen. The 800 pixel screen has slightly different pins and it got me thinking that a design that can work with any touchscreen could be easier with multiple propellers rather than with discrete logic. I'm getting some other ideas too - eg with multiple propellers we can have a touchscreen and a VGA and a TV output. And yes, if we have a 16 bit data bus, and a 20 bit address bus and some control lines, that could talk to another microprocessor. Or all the boards the N8VEM group have built.
Much to learn there is...
I never worried about a shortage of pins. The two prop machine has 2x32=64 pins and the 100 prop machine is at 3,200 pins. What we find in larger number prop machines early on is a need to develop a standardized circuit that can be used with varying software. We have to think about these machines in different ways.
Creating a transposition type machine is not too difficult if most of the 100,000 processors are wired with software. This is useful if the project is a thinking machine. Like multi-purposed software, so too can the hardware evolve to a multi-purpose interface. A number of interface designs for integration into a hybrid are described here.
http://humanoido-labs.blogspot.com/2011/12/big-brain-specs.html
Cavelamb, we are creating internal extensions to the chip. I like to call this “Enhancement.” It’s a process of amplifying processors using software.
To keep things manageable with large numbers, in terms of cost, power consumption, number of wires, I/O, layout, loading, communicating, etc., I developed “No Parts.” This reduces and eliminates parts to make the machine more efficient and makes larger machines possible. A link to a simple example follows.
Tiny Propeller Computer with No Parts
http://humanoidolabs.blogspot.com/2012/02/propeller-elf.html
Big Brain with No Parts Technique
http://humanoido-labs.blogspot.com/2011/12/big-brain-specs.html
You may also want to explore techniques useful for larger multi-prop machines mentioned on the specifications page.
Specifications
http://humanoido-labs.blogspot.com/2011/12/big-brain-specs.html
Cloning, ParaP Parallel-Parallel, Jump Over Communications
Electronic Brain Fluid, Hyper Neural Threading, Brain Channeling
No Parts, Intellectual Surfing, Shape Shifting, Que Messaging
OffSetting, Arraying, Wire Sharing
Maybe I'm a little obsessive about bypass caps, because I would still add two 0.1uF caps per propeller.
I need to research RC clock vs xtal. How fast does the RC network go? And is the RC network accurate enough to run serial comms?
To program a slave propeller takes 3 pins - Tx, Rx and Reset. I am wondering about using just one extra pin and add a Clock for communications once the chip has been programmed. Then it turns into an SPI type interface and there is an SPI slave in the Obex. Also, with a Clock pin, the timing need not be so exact and so humanoido's idea of using the RC network should work fine for many applications.
OR - after the slave is programmed, turn Tx and Rx into an I2C type bus, and make the slave propeller an I2C slave? One line is clock and one data, and again, with a clock pin, RC network would be fine. Plus I think any clocked data transfer system is going to be faster than an unclocked "RS232" like system. If RS232 gets out of sync by one half a bit width over the Start+8bits+Stop time, errors will occur.
Thoughts would be appreciated.
Yes, you need the chip.
No Parts was coined in regard to eliminating some parts in a project and this led to other things. I never really expected to eliminate everything externally. The project to create microscopic machines inside the propeller chip led to turning off various parts, components and circuits internally. That's how it all started inside the chip. So you can apply the no parts technique to the internal workings of the propeller chip.
(The roots can be traced way back to the radios I worked on. I wanted to make a radio mostly invisible and the project had a good deal of success with parts elimination though a base component was still required. The Molecular Microscope project provided a lot of ideas. For the first time, I could look inside the chip. This led to lower emf down to a fraction of a volt. My favorite project is a small scanning telescope inside the chip. I'm hoping to improve resolution of maps showing the inside of Propellers and develop some nice instrument controls.)
The work on OICs or Objects In the Chip illustrates application ideas. To make objects, the chip internal hardware is reconfigured. By turning off some things and turning on other things, objects are made.
Objects Inside the Chip
http://humanoidolabs.blogspot.com/2012/09/objects-inside-chip.html
These blogs are related to this topic.
Propeller Chip Nanotechnology
http://humanoidolabs.blogspot.com/2012/09/propeller-chip-nanotechnology-nano-probe.html
Molecular Microscope
http://humanoidolabs.blogspot.com/2012/09/genius-molecular-microscope-gmm.html
GMM Operations Diagram
http://humanoidolabs.blogspot.com/2012/10/gmm-genius-molecular-microscope-diagram.html
The Molecular Microscopy Initiative
http://humanoidolabs.blogspot.com/2012/09/molecular-microscopy-initiative.html
I am very much guessing here, but I suspect that internally, if the propeller is running code, consumption would stay very constant. The changes would be when pins are turned on and off, and that would depend on the load on those pins. So, maybe a propeller driving an SD card or a VGA display needs bypass caps. But other propeller chips probably do not.
humanoido, I am *very* interested in your clever work networking many propeller chips. What is a good network structure? For instance,. say we have a master propeller and we use 3 pins to talk to a slave propeller. Then we add another propeller. Do we use 3 more pins on the master propeller, or do we use 3 pins on the slave propeller? I guess both are valid options.
I need to think of a way to simplify programming such a network. The Spin Tool is great, but it is not really designed for this. Yet it could be - one could have multiple tabs open, one for each propeller chip, and it would be clever to have a line of text in the code that tells the compiler which propeller to send it to, and whether it goes via another propeller.
I love the idea of abstracting the propeller so it is a chip with as many pins as you want and it also has as many cogs as you want, and you don't really have to think about the physical layout so much. Reading your blog and your work, you are already thinking like this. It is very advanced, and very clever.
Practical things. Increase speed for propeller to propeller communications. If we have two pins, we can have a bidirectional RS232/TTL link. Max 115kbaud. Or maybe we can go faster with an I2C interface. Turn the propeller into an I2C slave. Simple place to start - let's make the second propeller emulate an I2C ram chip. There is a wiki here http://propeller.wikispaces.com/I2C+Slave Perfect. But Aaargh. The links back to the forum got broken with the forum upgrade. Anyone got any updated links to get this code?
Addit - found some PCF8574 emulation code. I2C has 3 pins in that code - clock, data and interrupt. Well, if interrupt needs to be there, maybe it is faster to use an SPI rather than an I2C slave?
The Q Machine
http://forums.parallax.com/showthread.php/146554-Q-Machine
More Information
http://humanoidolabs.blogspot.tw/2012/10/quadalyzer-quantum-analyzer.html
Dr. A,
I've run the following configurations:
1) Master Propeller talking to 4 slaves that are all peers. Each slave is a fully functioning propeller (Prop, crystal and EEPROM) - 2 pins to each slave (TX/RX), RST could be provided also using one more pin on the master for each slave. Each slave was preloaded with code to EEPROM before putting it under the control of the master. You could also have the master load the slave when it reboots but I haven't tried that. You also dedicated a COG on the master for each slave's serial I/O in the case of PropForth. Serial I/O has been run up to 230400 bps.
2) Master propeller talking to (up to 4) slaves with each slave being a bare propeller (Prop and bypass only). Each slave requires 6 pins from the master (RX/TX to 30/31, I2C to 28/29 , RST and XI). The master provides clock to the slave via a counter and also acts as an EEPROM to the slave when it is booting after a reset. This gives you the most control over the slaves but also requires the most pins. I've run this configuration with a single layer of slaves from 1 to 4 wide. You run out of pins at 4 slaves. You also dedicated a COG on the master for each slave's serial I/O in the case of PropForth. Serial I/O has been run up to 230400 bps.
Either configuration can grow in width at each slave layer until you run out of pins on the master. You can grow in depth until you confuse yourself with the number of props and layers you have hooked up.
You can also mix and match between bare slaves and fully configured slaves as you like.
Once you have the hardware set up, you could put various software pieces to drive it and coordinate it. I chose PropForth because the pieces were written to put it together. Similar protocols for booting and Prop to Prop communications could be built in any language you prefer.
It is bunches of fun to play with and I plan on returning once I get some things cleared off my plate. I think its a great way to delegate work load and responsibilities in a robotics platform, which is where I'll be headed. As mentioned earlier, the multi-prop management infrastructure isn't in PropForth yet, so you manually need to do soe work to start words on the various COGs on the individual Props but it's getting closer.
1)Ok, I am going to take the version 5 board and update to version 6. Schematic attached. Same as version 5, but took one of the three i2c sockets and removed that and replaced with a socket so it can be programmed with just a 10 way header and no soldering special connections like on the photos earlier.
2) This leaves me with lots of version 5 boards. Perfectly ok to use as master boards, and fine for slaves too if you are happy to solder a few wires from a ribbon cable. Seeed Studios sell me these boards for $25 for ten. So while it might seem a little crazy to have a board, largely unpopulated, it is a super flexible way of expanding propeller boards since the boards are only $2.50. So - here's the deal. I'm happy to give away some boards for nothing, nix, zero. I've got some more giveaways too. Let's see; 3 meg ram, 14 segment display, dracblade ram (for those old Z80 emulations), I2C to analog output, I2C to digital output, large touchscreen, small touchscreen, 10 led bargraph for diagnostics with screw terminals as well, RCA socket for analog I/O, RS232, SD card, SPI ram, VGA and TV and keyboard combo and even a Z80 slave board. Yep, I've gone crazy with the PCB fab house! But there is a catch. First, you will need some components. And second, while most of these have been tested with software in other designs, many of these boards in and of themselves have not been tested. So - the deal is - I'll send, for free, one or a few of these boards to anywhere in the world. They may or may not work. At worst though, a few wire links will fix any problems. All that I ask in return is you take some obex code (and most of these will run with existing obex code) and post a photo of the working board.
3) @mindrobots - your Forth code is going to fit right in here. I don't think it matters greatly what the hardware is. eeprom or no eeprom. *star* network. Or even super confused model like you say. One board does it all. Even humanoido's super simple model with one propeller chip, one 10 way header and not much else on the board. I reckon this would be great for a robot. I'd welcome some ideas for more peripheral boards - eg servo and motor driver boards.
4) @humanoido - your posts get me thinking even more. I like the cube idea. I like the way you throw in "BEC" in the discussion assuming that the reader knows what a BEC is. And indeed, I find BEC's fascinating. A manifestation of the microscropic quantum world but in a macroscopic form. There are going to be some very strange things to investigate further. Can you teleport them like you can atoms? Do they interfere? Do they remember their past state? Can they predict what an experimenter is going to do in the future like the strange experiments of quantum erasers? One day I hope to understand Bell's Inequalities. I think they are the key to a better understanding of the rules of this strange world. And if you can do some of these calculations in a network of chips, that would be amazing to see!
I don't know if it's clever but it is simple. (I may be doing something totally different from your objectives.) My fav machine uses a line to propagate a program to all props. As I recall, it uses an accurate clock base to propagate the code at lightning speed, then throttle back to RC. (The project needs to be low power and battery operated for a humanoid robot) The OS compensates RC. All programs startup at the same time, then things change. The program evolves to a level of uniqueness for each chip. Then, each parallel operational chip (via one line) can talk to other chips according to the rules of the OS (no two chips can talk at the same time but all chips can think and listen at the same time). Every chip undergoes enumeration so now any chip can become a master or slave and learn from its neighbors or distant colleagues in the collective matrix. Keep in mind, most of my machines do a lot of internal thinking and not a lot of external communicating to keep overhead down and speed up. (Again, new software can load in different characteristic machines, matrices etc.) In one config I used a concept of office workers and bosses for more than one master and specific workers doing different projects. There are three so called old paradigms here. 1) parallel processing a challenge assignment where the sum of the parts determine the whole. 2) birthing one or more living machines. 3) enhancement creating large numbers of neural processors.
That is clever. Ok, let's say we have a super minimalistic operating system. The master boots up and sends a very small program to all the slaves. That is good, because one thing I found with Chip's code is it takes a long time to send a big program - much longer master to slave than PC to master. So - we send this minimalistic program.
Then - the master starts collecting binary files from the SD card and sending them out to the slaves. But not using the download protocol. Rather, we use a clocked SPI protocol which is much faster.
Brilliant idea, humanoido!
What do you do with the checksums coming back from that minimalistic startup program? Only accept the checksum from one slave and assume all the others are going to respond the same so ignore their checksums?
DIY Black Hole & Door to Quantum Dimension
http://humanoidolabs.blogspot.tw/2013/03/diy-black-hole.html
I've more often been charged with general buffoonery!!
I will accept your board offer. No particular requests, just surprise me. Anything that you think we can get working in a mult-propeller (probably robotic) application. I'm up to buying parts and building and debugging with your help on what it was SUPPOSED to do!
I'll send you a PM with shipping info! Thanks for the more than kind offer!!
Indeed we would. I post on this forum, and sometimes people work out who I really am, and sometimes they also realise they live near me, and some of those people have decided to come and see me as patients. We talk for ages about all sorts of things, mostly not related to their health problems
I do kindly ask you not open this black hole until I have finished my multiple propeller project! But of course, isn't it correct that the energy of cosmic rays and other travellers from interstellar space far exceed our particle accelerators on earth? And no destruction of the earth has resulted. So we are safe for you to continue your experiments.
Quantum reality is very strange. It is as if you are only allowed to know a certain amount of information. You can never know more. And the rules travel forward and back in time to prevent you knowing more than a certain amount. It is as if the universe allows us to probe it to a certain level but no further.