OctoProp Demo
jazzed
Posts: 11,803
Here's the result of my Propeller project from over the last week or so.
OctoProp is a Parallel Bus Host/Device architecture design that provides 137 free user pins.
The posted code provides for repeatedly booting the Propellers and testing the communications path.
Future versions will provide RPC infrastructure for Remote Procedure Calls and loading COGs.
Today's version is limited by convention to 8 Propellers, but up to 64 could be connected by software.
Connecting 64 Propellers this way may of course prove impractical in a hardware sense.
The design uses a chain boot from one EEPROM, so Propellers boot one at a time (one per second).
There are no per Propeller ID bits, but two of the 12 bus lines (8 data + 2 control + 2 EEPROM)
are used for serial communications between the Host and all Devices in the ID enumeration scheme.
Many more details are covered in OctoPropDemo.spin.
Updated schematic for correct BOEn connection.
Moved PentaProp pic to top post. PentaProp.jpg is a picture of my development set.
I'm using a 3 AAA NiCad battery pack for power and a PropPlug for download/debug.
Added OctoPropINTn drawing for use with the next code version. Shows P8 common and P9 controls reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools Post Edited (jazzed) : 9/27/2009 6:00:10 PM GMT
OctoProp is a Parallel Bus Host/Device architecture design that provides 137 free user pins.
The posted code provides for repeatedly booting the Propellers and testing the communications path.
Future versions will provide RPC infrastructure for Remote Procedure Calls and loading COGs.
Today's version is limited by convention to 8 Propellers, but up to 64 could be connected by software.
Connecting 64 Propellers this way may of course prove impractical in a hardware sense.
The design uses a chain boot from one EEPROM, so Propellers boot one at a time (one per second).
There are no per Propeller ID bits, but two of the 12 bus lines (8 data + 2 control + 2 EEPROM)
are used for serial communications between the Host and all Devices in the ID enumeration scheme.
Many more details are covered in OctoPropDemo.spin.
Updated schematic for correct BOEn connection.
Moved PentaProp pic to top post. PentaProp.jpg is a picture of my development set.
I'm using a 3 AAA NiCad battery pack for power and a PropPlug for download/debug.
Added OctoPropINTn drawing for use with the next code version. Shows P8 common and P9 controls reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools Post Edited (jazzed) : 9/27/2009 6:00:10 PM GMT
Comments
OctoPropDemo This program supports running up to 255 Propellers simultaneously and provides a communications channel controlled by the Host to other Propeller Devices. To achieve this a Parallel bus structure with chained reset is used. The primary communications path between Propellers (data plane) is a parallel 8 bit data bus which (in the first incarnation) is controlled by an ATN and ACK signal. This allows for Host/Device interaction with only one host and one Host/Device at a time. Another design may allow for bus mastering where any Propeller can take on the Host role (TBD). An EEPROM is attached to all Propellers pins 28,29. The EEPROM is used for booting. Current Features: 1) Code is known to work reliably with 5 Propellers ... one line change would allow up to 255. 2) Host read/write to any Device is implemented at up to 5MB/s (256 byte transactions). 3) 5MB/s transaction byte lengths are controlled by assertion of the P8 signal. 4) Up to 137 pins are free for the user on 8 Propellers (17 per Propeller + 1). 5) Propellers boot one at a time from EEPROM (about one bootup per second). 6) Asynchronous notifications are available on INTn for "Device" -> "Host" messaging. Future enhancements: 1) RPC register/run will be added so the "Host" can ask "Devices" to run methods. 2) Add code to dispatch Host messages to any of 64 COGs. Having to boot N Propellers at one second per device from EEPROM is quite slow for a large number of devices. At some point after infrastructure development is finished, having an EEPROM per device with unique IDs programmed would be recommended. The current chained boot method will be used until infrastructure development is finished. Can you imagine the frustration of programming N EEPROMs for each build during development? Booting all propellers from EEPROM (or download for the host) will be done as follows: 1. The first Propeller to come out of reset (selected by BOEn tied low) will download the boot program from EEPROM or download from the user PC. 2. The boot program queries the ATN/ACK bits (the BootID) and assign the Propeller ID (PropID). If the BootID is $3, the booting Propeller takes the Host role and assumes PropID 0; else (BootID <> $3) the Propeller takes Device role and asks* the Host for a PropID. * The host Propeller starts an instance of FullDuplexSerial on the ATN/ACK pins (BootID) with inverted sense (tx/rx idle produces BootID <> $3) as a "DTE" device. The next Propeller to boot will detect BootID <> $3 and take the device role which will configure an instance of FullDuplexSerial on the BootID pins as "DCE" (the opposite of DTE) so that the device can communicate with the host. After the device serial link is up, it will post ASCII "+" to the host. The host is waiting for "+", for a predetermined number of devices. When the host receives "+" it sends an enumerated PropID ASCII digit (1-9) back to the device. The device receives the digit and stores it as a number. To allow more than 9 devices, the PropID being sent needs to change to a non-ASCII number. 3. Once the booting Propeller's role is established, it sets the next reset release pin. If the propeller is the host, it will go into the device enumeration loop. Once the devices have all been enumerated, the ATN/ACK pins are released from serial connection and go high while the host bus driver starts. If the propeller is a device, it will start polling ATN/ACK (BootID) for $3 again. Once $3 is detected on BootID, the device knows it's safe to start the device bus driver. While the device is polling the BootID, the device number is emitted on pins P16,17,18 ... if these pins need to be used after boot, they should be released. 4. The next Propeller in the chain boots from EEPROM and starts step 2 above. Once all propellers are booted, normal operation can begin. Data Transfers: All packet data tranfers are via 5MB/s links. This is accomplished by using a "terminate" bit on P8 in conjunction with the data bus bits P[noparse][[/noparse]0:7]. P8 will be high (set by the TX side) while bytes are in process. At the end of the byte stream, the TX will clear P8 and P[noparse][[/noparse]0:7] to terminate the data transfer. Either the host or device can control P8. Interrupt line: An interrupt line INTn is used for asynchronous Device->Host notifications. At some point the function of the INTn line might be removed, but this would cause higher response latency as the Host would need to poll for notifications periodically. Today, the INTn notification works as follows. At any point, one or more devices can assert the INTn line by pulling the bit low. When the host is not transfering data, this bit is polled. If the host detects a low on the INTn pin, a survey is performed on all devices to determine interrupt sources. When a source is found, the source ID is placed in an interrupt queue. The application can survey the interrupt queue and handle events. Most events will be responses to RPCs, so COG code can be used to deal with matching results with closing pending RPCs. At this time, any pending RPC or other interrupt reason must be handled by using a data transfer message per event. Seems like a waste to not add other information to the interrupt event queue such as process id and return codes. Normal application operation will use RPC over an OSI-like model. OctoProp OSI Model: Layer 1 - physical layer (13 of the 15 common pins) ... INTn could be eliminated later. Layer 2 - packet header byte position definition Layer 3 - data packet header and type (no CRC, but could be added at big COG/performance cost) Layer 4 - packet data and application data integrity/status (no TCP ... sequenced UDP only). Layer 5 - packet connection etc... Application RPC ... device open,close,read,write,etc... Layer 6 - All RPC parameters/return will be long. Use Propeller byte order. No XDR, etc... Layer 7 - Normal Application layer Remote Procedure Call (RPC) function: The RPC is not based on a standard set of functions such as is common for network distributed computing as used in NFS or NDIS. RPC here is self-contained and will not attempt to follow any standard. RPC methods/functions will be sent to the devices and will be registered in a device/method enumeration scheme. The host will negotiate with a device for placing code in residence on the device. If there is room on the device, an agreement is made and the device will return a function serial number. If there is no room, the host will move to the next device looking for space. Once an object, application, function, or method is registered, the host is free to invoke the RPC. RPC handling will be done using sequence numbering. The host will send a request with a sequence ID. If the device has already processed the ID request, it will ignore the function and return the ID+1. If the request fails for some reason, the device will return the ID to let the host know to resend the request ID. Once a request has been processed, the ID+1 is returned. This way the host/device guarantees function without the application being involved. Statistics on RPC retries will be kept for performance monitoring. If an RPC is synchronous, the response can provide the application response. If the request is asynchronous, the host will queue the response as pending if a response is required. If a pending request is in the queue and an RPC response comes asynchronously, the RPC queue COG will coordinate response resolution and upstream delivery. After a certain time pending entries may get stale ... if they cause memory problems or are endangering other asynchronous events, the oldest pending queue entries may be retired (statistics should be kept). Definitions: Host - The primary controller in a bus structure also known as the Master. Device - Secondary devices in a bus structure that are not hosts. Data Plane - A communications path where data transfer is the primary usage. Control Plane - A communications path where control signaling is the primary usage. BootID - in this case the BootID is on the ATN/ACK pins and shifted to make 0, 1, 2, or 3. PropID - the identifier assigned to a given Propeller. PropID is used for parallel bus data.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/27/2009 5:19:29 AM GMT▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Nice prop sandwich, makes me hungry just lookin at it.
a.k.a. Cogwich.
Now the challenge is, what to do with all those pins and all that processing power.
One could make a n-axis milling machine motor controller with plc and then some entirely in spin.
[noparse]:)[/noparse]
What would be cool is to design two PCBs and implement a 1..N stackable design. A baseboard containing everything for Prop ID 0, 8-pin header along one side for the shared bus, a 4-8 pin header for the non-bus dedicated pins (power, clock, etc), and right angle headers providing access to the per-Prop IO pins out of the back end of each board. Each stackable board with the same header placement, but with stackable headers (male on the bottom, female on top) for connecting to the baseboard and the same R/A headers providing per-Prop IO out of the back end.
Or, a backplane board for the common pins, with per-Prop IO on the other end of things. It'd be fun to get a hold of a surplus PLC racks to repurpose for this end.
Obviously, there are a lot of ways to do this... just an exciting thing to think about. Bad time for me to find a new job- some extra cash for a project like this with so few DIP props to go around.
The next challenge (IMHO) is writing a framework that will put that power to use in a way that will allow as much code reuse as possible for the distributed processing aspects of each application.
How great would it be if Catalina or Brad's Spin Compiler could be adapted to handle much of the delegation and inter-board/chip communication? It could be done- a shame bstc's code can't be had.
Thanks for sharing! [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Neurons can attach and detach to eachother. (structure of memory and behavior)
Neurons that fire together, wire together. (learning)
Neurons that don't fire together, de-wire. (forgetting stuff, dumping one skill for another)
So ability to send data to certain props, and code that says if one I/O fires when another does, then they will trigger eachother.
Attach various sensors, code minimal rules, and ... watch it learn.
"Dendrites branch from the cell body and receive messages. A typical neuron has about 1,000 to 10,000 synapses (that is, it communicates with 1,000-10,000 other neurons)."
Hmm, 1,000 different I/o to simulate a single neuron.
137 free pins on 8 props.
137 * 8 = 1,096.
64 props, 1,096 I/O to simulate the most basic neuron.
137 * 73 = 10,001.
584 props, 10,001 I/O to simulate the most complex neuron.
The human brain has one hundred billion neurons.
So 584 props times 100 billion = 58.4 trillion props to simulate the human brain. (not counting sensory input/ output )
Uhh, we have a long way to go, lets get started.
58.4 trillion props * $7.99 =
$466.616 trillion dollars to make AI.
Internal load current for room temperature toggling of a pin at 20 MHz for a Propeller in a DIP package varies on the order of 300 µA.
300 uA * 16 (approx # of pins free per prop) = 4,800 ua per prop.
4.8 ma * 58.4 trillion = 16.37 billion AMPERE
LOL
(im sure the numbers I propose are not exact)
SO HAL can be HAD for:
-$466.616 trillion dollars (not including construction costs, or the power plant, or the land to hold it all)
-16.37 billion AMPERE
-58.4 trillion props
I'd rather just find a hot female, and make a kid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License
"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "
The dsp/fpga king is dead, long live the prop.
Post Edited (Clock Loop) : 9/10/2009 9:43:45 PM GMT
with the limited ability and vocabulary so at best you will mostly here """ DAD I WANT"""" or and my favorite " DAD WHEN CAN I HAVE""""" and lets not forget how stupid they will let you know you are. I do not know how I have managed to live for 50 years without the direct influence of my kids telling me how dumb I am and all the things I don't know... And as far as cost per neuron well from where I am sitting my $8,00 prop chip has been a wise investment,,, Oh and the cost of college !!
Well I got off point
Prop Chips $8,00 apiece with the ability to be stacked in parallel the more you add together the greater the work they can perform
Daughters all the money I have every earned and then some, While they have the ability to be added together(paralleled) this usually generates more work for dad and at a higher cost per unit
So Clock Loop enjoy the hot female and then sit back and watch your creation or creations develop into wonderful amazing human thinking machines he he he
And then wish you had just bought all those prop chips to begin with
Let me stress I love my kids more than anything and this is meant a humor but anyone out there with children are laughing because you know exactly what I talking about
@mikediv, Almost every application I've written for Propeller requires more resources that exist on chip, so I'll go back and look at some of those for this platform. I have teenage children too: a boy and a girl. I've finally decided a fixed allowance for my girl is much better than "dad can I have $10?" every day [noparse]:)[/noparse]
You see, 8 Propellers gives 64 COGs and 256KB of HUB memory which can realistically run a full Spin program per Propeller loaded from SD card or some other place like a network server. If you want better data performance and a large number of pins are not so important, you can make the communications mechanism 16 bit wide and have much faster data rates for even the smallest packet. At about $70 and change depending on your parts source for a "cogwich" as shown, I figure that's not such a bad deal for doing something with this unique architecture that I've grown quite fond of.
Others and I have discussed doing a project something like this for a long time and I figured I owed it something more than hypothetical lip-service.
Now that I have a boot mechanism that works solidly in a minimal way (minimal -vs- the value add that is), can share data between Propellers (pass messages, etc...), and is not a P.I.T.A. to use from a development standpoint, I'll be optimizing the design further as mentioned before and writing applications that take full advantage of all the hardware.
The thing is, every time I get serious about a Propeller project, I end up running into this silly lack of memory problem. With multiple Propellers connected like this, the development environment may not be as easy as the normal one, but instead of being strapped by scarcity of resources as usual, I can move on AND algorithmic performance will not have to suffer because of some kind on-demand external memory. I figure either I do something radical or move on to the XMOS chip or something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
On your schematic it may·not be obvious to some that·DBUS from the top to the bottom are connected.
Clocking:·Suggest you remove one input pin of the NAND gate and tie to 3V3 to reduce xtal loading. BTW I just realised you have inverted the clock, so not only do you have a slight delay 2nS? but you have inverted the clock to all the other props.
You should have no problems with the track lengths for the bus with this nesting, but if you try this on a pcb, be careful, it may not work at·the speed you hope for.
And now we know who has been wasting the precious DIP Props
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Are you booting them off of the same eeprom in sequence?
Where are you tying the resets?
Where is your bus? I didn't see it in the diagram.....now I see it.
Post Edited (hinv) : 9/11/2009 12:37:04 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Ken
I'm aware of a handful of IPC/RPC methods, but I was talking about something at a higher level of abstraction. Something akin to the XMOS's software architecture or some of the distributed processing APIs that exist. The compiler would be configured to know how many Props there are, seeing this system as being a single Prop with 64 cogs. IPC/RPC handled automatically, etc. You'd be writing code for a single machine, not a network of machines; communication and code pushed around as a part of this.
That, or you can just wait until the Prop II comes out! I'm not personally a Parallax Partisan- I'm rather new to actually using their stuff- but no matter how you look at it, the Prop II is pretty exciting. Just tossing that out there. [noparse]:)[/noparse]
Yes, the boot is "chained" .... Here is the procedure:
1. The first Propeller to boot (BOEn low)
- sees BootID 3 (pins 24,25 pull-up)
- becomes the "HOST"
2. The HOST:- sets BootID pins to serial port mode 3
- releases the first "DEVICE" reset by asserting pin 13 (P8)
- listens for "+" for a predefined number of devices.
- when receiving"+", the Host sends the next PropID to the new DEVICE.
3. For each DEVICE to boot:- the DEVICE sees BootID <> 3
- configures BootID pins to null modem serial port
- sends "+", waits for a PropID
- stops BootID serial port
- releases the next "Device" reset
- waits for BootID to become 3
- and then starts DEVICE parallel bus COG
4. Finally, after the predetermined number of DEVICEs are booted:- the HOST turns off the BootID serial port which makes BootID == 3
- starts the "Host" parallel bus COG
- runs the first user application.
Pin 13 of each Propeller is connected to RESn of the next Propeller.The BOEn of DEVICE Propellers are pulled high so that DEVICEs remain reset until RESn is asserted.
The Remote Procedure Call (RPC) system will be responsible for managing program load and execute on the DEVICE Propellers.
The RPC will be implemented as a "register it" / "execute it" RPC. RPC modes are one of the 4 commands available between HOST and DEVICE on the Parallel bus in the current HOST/DEVICE packet byte 1.
An RPC register command will start a code transfer to the target DEVICE hub memory and launch a Spin COG or a PASM COG depending on the COGID in byte 1. The HOST would then set up a method registry for the RPC execute to use for method mapping lookup. One could send an entire SPIN program to a Propeller and run it using RPC.
The RPC execute command will wrap the PropID, COGID, method enumeration, parameters, and send to the target DEVICE. RPC should be synchronous or asynchronous. Having asynchronous communications for return codes or pointer parameters is useful for RPC performance ... this is TBD but should be do-able with the common SCL pin and a Queue data structure in the HOST. Being able to register an RPC as synchronous or asynchronous allows user flexibility.
Asynchronous RPC would let the user arrange for the whole stack if necessary to work one given problem ... true multiprocessing.
What you are suggesting is indeed attractive. I also like some of your hardware ideas ... expandable [noparse]:)[/noparse]
The main problem with changing the compiler seems to be that Spin only allows up to 256 methods. The other problem would of course be getting someone to support that mode without substantial interest from the user community.
Propeller II is mainly a curiosity and will be released whenever Chip is ready which could be months to years from now ... at his leisure on whatever schedule he is happy to keep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
That would be up to the user. I've laid out the current road map in other posts. The end goal is full simultaneous parallel processing (not SMP) distributed computing ability with N Propellers running Spin, PASM, or your choice of other languages.
An infrastructure for queuing processes or other system level methods are TBD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
You mean you can't even get a price break at 58,400,000,000,000 units???
..Steve
Well, I figured in a tip for the massive workload.
If you use the QFN package that's about 288.7 million cubic feet for one brain!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
That would take up the entire state of IOWA, which is 56,272 sq mi.
Plus 1 mile in height.
Post Edited (Clock Loop) : 9/12/2009 3:52:15 PM GMT
So assuming that has some value, external logic required for that would likely be as big as Texas. Of course to produce so many chips in a reasonable period of time, the Chinese would end up using all of earth's natural resources and create a big black haze of pollution that would consume the earth and throw us into another ice-age. We won't need asteroids or gamma ray bursts to kill us.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Excellent work jazzed. I've been procrastinating over something similar for months - even bought some more Prop's and stuck 'em on breadboards, but that's as far as I got. Y'see; I started sketching out ideas for using Beau's high-speed serial and a token-passing serial bus, but then I got side-tracked; wondering what I'd use it for (darned that practicality streak!). I also started wondering *why* anyone might want multi-master capability and, well, I've not come up with any answer, so the project's stalled.
OctoProp's re-kindled my desire to just build it anyway, so I'll be following this thread closely
BTW: My design has an EEPROM for each Prop. I'm thinking that it'll speed the boot process - it'll put every Prop into a state ready to accept it's code to run. The idea is that one of the Prop's will have a SD card containing task binaries. Any Prop will be able to request any binary
I've not really thought much beyond the concept - I'm sure there'll be some gotchas in there - so guess I'll have to find the 25th hour in each day to get started!
Keep up the good work m8.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
“Before you criticize someone, you should walk a mile in their shoes. That way when you criticize them, you are a mile away from them and you have their shoes.” - Jack Handey.
One reason multi-master is good is to simplify and speed up the request/notification process. The parallel bus I'm using will require using an "interrupt" or bit-poll notification mechanism and a "poll" of which device(s) created the message notice. This is obviously not instantaneous and the notifications get moved to a more linear handler. With multi-master serial, you can have completely independent tasks running if necessary. Of course one would be limited by the number of possible connections (4 pins each for 14Mbit/s and 2 pins each for the 8Mbit/s or less connections).
I also like the idea of separate EEPROMs ... once the system is fully coded and bug-free. For development purposes though, I just can't imagine programming 8 different EEPROMs with different PropID settings. Once the "system" design is flexible enough and works solidly, separate EEPROMs would be a good move.
I may create an abstraction layer so that the RPC design could be used with any type of bus connection, but my priority is my current hardware.
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
True, but if someone needs production quality, Propgalore is an option.
I though you would enjoy the fact that I'm making Propgalore feasible
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
I do wonder a bit about only one eeprom, and the longer boot time it requires.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Yes i do appreciate it. Any project that pushes the limit of the prop is a good project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.