Why use a prop?
mwalimu
Posts: 44
I have been working on a propeller controller for a Roomba. While I was digging through some stuff I found a evaluation board for a a Cypress PSoC chip. It's got a 29466 chip(roughly equivalent to an ATMEGA328). I realized that I could easilly use that instead of the Propeller, in fact, the PSoc has several advantages, it has on board ADC, DAC, PWM, etc, all of which can be configured by the user in a variety of different ways.
It got me to thinking (not always a good thing). For the most part the cogs on the Prop is being used to create peripherals that are generally available on other chips, so why use it over another chip?
What projects are best suited for parallel processing?
(sorry, I left out the subject)
It got me to thinking (not always a good thing). For the most part the cogs on the Prop is being used to create peripherals that are generally available on other chips, so why use it over another chip?
What projects are best suited for parallel processing?
(sorry, I left out the subject)
Comments
2. Any soft peripheral can be assigned to any pin or pin group. (Try that with an Atmel chip.)
3.There are way fewer special function registers to learn with a Prop, so development turnaround is much quicker. (Would you call the PSoC chip a "rapid dev solution"?)
4. Parallax's legendary support and ... well... this forum!
-Phil
try to find a chip that has 12 serial interfaces plus a TV output.
Easy to do with the propeller.
And yes, what PhiPi says about the special function registers, the interface pinout and rapid prototyping are from my point of view the killer arguments. You don't have to waste a second for thinking about which interface needs to be connected to which pins. This makes the PCB design job much easier. SFR's are really a pain and one bit set wrong can cause hours of debugging. Interrupt programming is also a pain and building failsafe systems needs a lot of experience. The more hardware resources are used, the more complex the interrupt programming will be.
So, very easy things can be done with other uC as easy as with the propeller, but the more complex the system is, the more advantages are on the propeller side.
Alot of people ask me this. I really can't say why they should use one if they are comfortable with something else.
As long as they don't ask me for help when they aren't able to finish a project with the micro of their choice I have no problem.
Otherwise, they should use a prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Other microcontrollers can only do one thing at a time. The Propeller can do several different things all at the same time!
I eventually want to put in a solar water heating system. I will want to monitor the roof water temperature, the water tank temperature, activate a pump, have a display, and have button(s) to press for this and that. I think the Propeller would be ideal for something like that.
With another microcontroller, it would be too busy doing other stuff to check for a button press. Or I would need to use interrupts and an interrupt handler.
I would think I could more quickly get my system up and running with a Propeller. Much easier! And much easier to add say a new display later on or additional buttons to display something.
Also the propeller is·more "modular". If I wanted to add a remote display, I could work on that one feature with another Propeller. Then easily add that object to the working system. With other microcontrollers, adding something like I2C (or whatever) and changing configuration bits/interrupts could cause other things to stop working.
For example I·just downloaded·a C serial program for a Pic which uses the memory space allocated for the USB.
Development of systems that have to communicate to each other. For example using an RF module. With a propeller you only need one prop, using 2 different COGs for implementing the protocol and it's so easy to verify that what you send with one COG equals what you receive with the other. When you're done with the protocol you can run the same object in 2 different propellers which makes no difference.
Now try that with another uC. Even if you can handle 2 RF modules you have to use interrupts. This means when you then put the protocol code into the target systems it can behave very different. So, if you really want to make sure that it all works out you need 2 development boards.
The Propeller architecture makes for very easy program building with its multi-cores and therefore interrupt free programming with total timing determinism. This makes adding new little features or adopting modules from others extremely quick and easy to do. You don't have to constantly worry that consuming a little time with the next new feature will break you whole app or make you code into a fragile mess.
This Spin language is very easy to pick up and the Propeller Tool very easy to use.
When you need speed the Propeller assembly language PASM is about the simplest I have ever come across. It's direct integration into Spin programs is a doddle.
Then there is the OBEX, a wonderful playground of ready made programs, objexts device drivers.
Features like video generation, audio/analog I/O are the icing on the cake.
Now, a lot of this may not matter so much if you are building a million embedded devices for a minimal parts cost but it's perfect in educational/hobby settings. It's perfect for a huge world of applications where a quick prototype or development is required.
Don't forget if you depend on built in peripherals of normal micros you will quite likely end up having to select a new chip for each application. Keep stocks of different variants of the same micro. Get your head around the capabilities/limitations of each one.
With the Prop you can keep a bin full of them. They are a general purpose "blank slate" that can be adopted for many varied applications.
I don't think you will find another micro-controller forum with such a quick and helpful turn around as this one. That comes from the enthusiasm of the Propeller users which I believe comes from that "philosophy" I opened with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
However, cogs are also useful for doing other things at the same time. Don't forget the props speed. Don't forget you have 32KB of hub sram as well as the cog sram plus usable sections of code in hub ROM. And you have a high level language (spin) for when speed is not required which is typically the main loop of a program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
With the prop, you put each one of your tasks in a separate cog. You can get guaranteed performance from a cog and you don't worry about an interrupt or a context switch impacting behavior on a time-critical task. In this way I think the prop has the potential for much more robust and predictable behavior than a single-core device.
As an example, I developed an internet-enabled alarm clock. It updates a LED display, outputs to TV, streams audio from SD to speaker for custom alarm tone, processes keyboard events, and continually updates itself via NTP over ethernet. All of these tasks in different cogs. All of these tasks running concurrently without interfering with each other.
The OP is right that more peripherals might be handy, such as ADC or serial or usb. Maybe the prop II will give us some of that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
Shame it does not go to 11 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
People here have done amazing things with Propeller that are impossible with comparable AVRs. We all do what we like when we can. If you like AVR or PIC and certain software development paradigms, do that. If you want to get indefinitely hooked and don't mind a little eccentricity, do Propeller [noparse]:)[/noparse]
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I have to reiterate PhiPi's number four - this forum, and the UPEs are the main reason that I have purchased so much Propeller stuff. Yeah, the Prop itself is a pretty impressive chip and all, but the people who are into it are pretty much the biggest selling point to me. When you get together with other people interested in something, it is easy to get/stay interested in that thing (whether they get together on a very active forum like this, or in person at something like the Unofficial Propeller Expos.) Most of my business is related to the Atmel families, and so a lot of my effort goes into that, but I have never seen anything like the Prop Expos in any other modern chips. AVR Freaks is nice, but they are not quite as active and they are spread out more than the Propheads, and I've never seen anything like our Expos in the AVR areas. There is something infectious about getting together with an excited crowd, and so the Prop and other Parallax things are moving, more and more, into my development plans
Art
Using the 8mhz built in oscillator to save the cost of an xtal.
I need something done 20,000 times a second...So I'm using
timer 1 ... ISR(TIMER1_COMPA_vect) and I have an absolute
maximum time of 400 cycles inside the timer1 interrupt routine
and if I even get close to that maximum all #$%^ will cut loose.
So the ISR is getting coded in assembler, the rest is in C.
I have 3 interrupt routines going at once...it's messy in there!
And everything jitters a bit.
I'd rather be using a prop! If it wasn't for the price difference I
would be. (1.40 vs 7.19 in quantity 100)
I can't imagine using something else as long as a prop is price
competitive.
If there was a 2.00 2 cog prop I'd be using it right now instead
of this cranky tiny88.
On a Prop, I have no such problems. My current flying thing uses 5 cogs:
1) Remote input
2) Servo output
3) Gyro / Accelerometer I2C input / IMU
4) Serial output (debugging)
5) Main flight loop
Doing the same thing on a single-threaded piece of hardware is remarkably convoluted and awkward. I've done it, but it's painful, even on a chip with dedicated I2C, serial, PWM, and pulse timers.
Jason
Go with the Propeller.
·
I'm learning to use the freescales RS08,
hard to get started·with codewarrior compared how·easy·PropTool is.
Only 150 bytes of ram available at anytime, have to use a page window·for each 64bytes
·
Freescaled 8bit online forum is one boring place.
Post Edited (tonyp12) : 6/14/2010 9:43:50 PM GMT
I find the Propeller paradigm and development model to be straightforward, easy to use, and, not least, fun! As others have already mentioned in this thread, the special function registers used by other MCUs to control their on-chip peripherals seem absolutely convoluted, messy, and easy to screw something up with minor errors than the I/O model on the Propeller. After reading 1200 page data sheets on other MCUs, 900 pages of which are dedicated to the peripherals, the Propeller's simple dira and ina/outa registers are refreshing.
for some type of control or data aqusistion or as of late a self contained and auto functioning random target· system for pellet gun shooting its the prop .. It just helps me· be a better designer I can honestly say with all the PICs and other MCU's or even CPU's I know of nothing with the power and ease of use as the prop .. Oh and not to give anyone a big head or bigger head lets not forget this fourm plain and simple have you ever found a better place for support regardless of the chip?? Just taking that into consideration its very nice to be able to come here and say hey guys can anyone help me with X I am on lots of other sites and have meet some nice people but nothing at this level
Post Edited (mikediv) : 6/14/2010 11:08:26 PM GMT
For the most part when I look at projects done on the prop it seems that cogs are used to implement devices and one cog is used to drive the computing part of the project. That doesn't seem to me to be an improvement over a well designed single core chip.
For what tasks is parallel processing a good solution?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The early bird gets the worm but the second mouse gets the cheese.
the prop destroys these tasks.
No need to be unpleasant. I just wanted some opinions on parallel processing that goes beyond making cool peripherals.
On a non-parallel system, there are always interactions to consider. Code bodies can be written so that there are few to no interactions, acting like a prop, but that's a skill and time burden not present on a prop. And there's a whole testing cycle not present on a propeller either. This isn't a small task, and the sale of libraries designed that way is done for that reason. On a prop, objects can be combined in a lot of ways, with only modest planning being required.
Robust solutions could be done with tasks operating in parallel, doing the same thing. If one fails, the solution remains viable.
The ability for the chip to actually output what another part of the chip is doing is damn cool. I've done a little of that, using one COG to tell me what the code on another one is doing with the pins.
What about cases where a given signal input requires that a lot of things happen at once? Several COGs, each waiting to perform a task, could all begin that task at the time of detection.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
I'm not trying to be unpleasant. I'm just saying that when you categorize everything everyone has described as just more "cool peripherals" one wonders if you were paying attention.
Your original question was "What projects are best suited for parallel processing?" I think this was answered over and over again. The answer is "Most Projects." [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The early bird gets the worm but the second mouse gets the cheese.
If you'll read the forums, it's easy to conclude that people are using the prop to emulate peripherals because that is what a lot of the posts are about (emulating SID chips, video drivers, etc) and it's where there are some really cool and visible results. However, I don't think that's what the prop is really about. As K2 summed it up in his post, "the real world is parallel". People have lots of varied backgrounds when it comes to programming, so I'm unsure of what you're experiences are, but much of the stuff I do involves several tasks that have to take simultaneously. This is true whether I'm programming a microcontroller, writing a Windows application, or doing Linux kernel work. To serialize several parallel tasks on a single uniprocessor is always an imperfect process because one task always needs to be interrupted by another. If you have multiple cores then you can actually do the parallel tasks in parallel, the way they were meant to be done.
I find the propeller to be much more about basic design philosophy and much less about what specific peripherals can be implemented.
Yes indeed and that's a reasonable and natural architecture in a lot of applications.
Perhaps but which of the well designed single core chips do you want for an app?
1) The same Prop chip can provide an infinite variety of peripherals (within the performance limits). One does not need a large inventory/knowledge/access to a lot of different versions of the same architecture, ARM, PIC whatever.
2) Design changes are easier. Want to move that UART to different pins? Easy. Want to swap that serial link for something else? Easy. etc etc etc
3) What about when you want to drive a "weird" peripheral? I have a project on the back burner to drive a 4 wire communications protocol that would be very hard to do on a regular micro with bit-banging and interrupts. This is an example of "software defined silicon" a term coined by XMOS whose chips offer similar multicore functionality. You can implement logic in software using a few pins that would otherwise have to be done in discrete chips or an FPGA.
4) Those well designed single core chips may well be fine. But how easy are they to use in practice? Generally you cant just throw another blob of code in there to handle some new functionality and know that it will just run with out disturbing the existing application. Often it requires hooking into the interrupt system or the RTOS being run. Then you have to worry about how that has disturbed the timing of everything else. Or perhaps it requires peripheral blocks or I/O pins you have already assigned to something else.
Well we are talking "micro-controller" here so anything that need to interface to the real world for status monitoring/control functions. Especially if there are stringent requirements for deterministic timing and there are multiple external activities going on. Like that helicopter you are trying to stabilize.
The "software defined silicon" idea absolutely requires parallel processing and timing determinism.
In general you can forget about the Prop for the traditional idea of "parallel processing" i.e. as a way to accelerate number crunching on large sets of data. The "super computer" approach. There are better ways to get that kind of performance and the required communication bandwidth between nodes.
The Prop is after all a micro-controller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There is another object (Debug_1PinTV) which displays characters on a TV. You just output a character to a hub location and the cog takes the character and places it into the screen buffer. If it is a control character, such as clear screen, carriage return, up/down/left/right (a basic terminal emulation) the cog also performs this. If a scroll is required, it does this also. And, it is also displaying the characters on the TV. By this I mean, it is also reading in the screen buffer and converting the characters to dots using it's inbuilt font and supplying this to the counter logic to form a composite video output to your TV, all with the aid of 1 resistor and 1 prop pin (it is only B&W). Normally, the TV uses 3 pins and 3 resistors to get composite color (NTSC or PAL). So here we not only have the complex TV generation hardware, but also a small terminal emulation as well (VT100 style sub-set), all without the main user program worrying about such things. All without interrupts and registers to worry about controlling.
Yet another object is the Keyboard object. It interfaces to a standard PS2 PC keyboard using 2 pins and 4 resistors plus 5V for the keyboard. There is also a 1pin version using 3 resistors and 5V. These objects not only provide the hardware interface and the software to communicate with the keyboard (uses an I2C style protocol), it also optionally performs the conversion from the keycodes to ASCII before it places the characters into the hub buffer. So once again, no interupts and no complex registers to control by the main user program.
So, you can see from these examples, the multiprocessors (cogs)·are used more than just emulating the hardware blocks found in other micros, but they also add a degree of intelligence to these basic blocks so they become "smart peripheral blocks", processing the smarts in parallel to your main code.
Of course, you can also enlist cogs to do other processing in parallel. That is what Jason is doing in his quadcopter designs. Sure, the same can be done with one of the bigger ATMega cpus (see Sparkfun) but it is much simpler in a prop (for the programmer) to have each block of code processed independently and in parallel. No interrupts to worry about.
You could use a second·cog to do some complex calculation by storing the values to be used in hub memory and then continue with something else. The second cog would take these values and perform the required calculations and place the results back into hub memory for the main program to use at a later time. This task would be executed in parallel.
Quite often I have found that the main program now can be written in Spin because it·no longer has to be fast in execution. This of course makes your program easier to follow and hence debug and maintain.
I hope this helps you understand some of the advantages of the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The answer is: every task is originally something parallel. It is serialized artificially to handle the task by a single "processor". Why, for example, does a picture say thousand words? Because perception of a picture goes in parallel, while words, spoken in parallel can not carry more information then the sound of 1000 vuzuelas! Describing a picture is a process of serialization, then, later after reading, the picture can be present in brain as one item, that is, "parallel".
But as we teach people how to solve problem with serial processors, they do not realize, what the problem was originally, but they see their skills. And as serialization is a problem and needs skills, we are proud to solve those second level problems.
But Chip pointed us to this: there is a better solution, I give You the tool!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz