Use of Propeller
amveronis
Posts: 21
As you all know, I am new to the Prop, and I have thanked you for your welcome. I have gone through some of the applications already completed, and I have been very disappointed. Some of the applications I saw could be done with a PICAXE -08m. Someone recently has produced and sells a Propeller board, and all the demonstration I saw was how to turn on and off an LED! or how to work with an SD memory card!Or how we can connect the Prop to a TV and get "Hello World". I was warned that, if I am looking for serious parallel prcessing, the Prop is not the way to go. I have realized that, but,! If this is the best we can do, then why 8 cogs?Why even two cogs? I have done more sophisticated projects using an Arduino and, certainly, an ARM. Someone was gracious enough to provide me with an FFT project using the prop, and I really liked it. Can we form a group that would work on a little more sophisticated projects? I do not mean to downgrade the intelligence of the members in this wonderful forum, but could someone lead to some projects that have used the Prop's parallelism?The only reason I joined this forum is because I am truly interested in parallel processing and not turning holiday lights on and off.
I apologize if my post sounds too critical. I did not mean it that way.
Andrew
I apologize if my post sounds too critical. I did not mean it that way.
Andrew
Comments
First of all, don't let Leon's comments scare you away from the Prop. It's true that the Prop is rarely used to do parallel processing. Most Prop applications use the independent cogs as programmable peripheral devices and co-processors. Some applications have used all 8 of the cogs for this purpose. The Prop is certainly capable of doing parallel processing, and it would be nice to seem someone do this. Maybe you could give it a try.
Dave
Blinking LEDs is not the most challenging application or useful result to many. Hollywood types like LEDs, but there are many other cheap little devices that can do it too. I enjoyed the LED sheep videos where herders made a Mona Lisa composite with hundreds of pictures of sheep with LEDs on their backs - indeed a remarkable achievement. That being said ....
Propeller can run 7 small, reasonably fast programs and one larger, slower program all at once or variations of that.
There have been very interesting things done with Propeller and many have been discussed on these forums. You can find them if you have years to browse
I think some good questions at this point are:
I can both agree and disagree.
If You use one COG as CommPort to PC, one for FFT, one for F32 (floating point).
You have still 5 COG's that can RUN different SPIN programs in parallel. Yes I know someone will say TO little memory to be usable!
BUT with efficiency of SPIN still much can be done in Parallel processing.
I thought this was the key question. Whether it pleases trolleon or not is irrelevant.
But you can do all that easier and cheaper on a $3 ARM or dsPIC chip!
My answer was NOT what is easier --- BUT to show him what are possible on Propeller.
Give it a chance and find out what the chip can really do.
http://forums.parallax.com/showthread.php?129612-My-Current-Prop-Based-CNC-Photos
MCU:s used to be found in microwaves ovens, dishing machines, code locks etc.
The Propeller was one of the first MCU:s to be powerful enough for more advanced applications. (like video and audio)
For an MCU, the Propeller is extremely competent and outperforms, for an example, the ATmega328P (found in aurdino uno) by a long shot.
While the Propeller can't compare performance wise to even a standard ARM, it certainly can do things that even the ARM would struggle with. (like analog video and spdif)
Here are some clips of the Propeller chip doing awesome things:
http://www.youtube.com/watch?v=HF1Z9evXor0 (The whole thing with motor control, video, mouse, keyboard and program runs on a couple of Propeller chips)
http://www.youtube.com/watch?v=6gEMKYnUADE (Uses a single Propeller with no external memory or DACs)
http://www.youtube.com/watch?v=LpfgI3UUTMg (This requires perfect timing and would be VERY hard to do on an interrupt driven processor)
http://www.youtube.com/watch?v=6vp5krplhxE (Uses a single Propeller with no external memory or DACs)
http://www.youtube.com/watch?v=EJcbxrdErkY (Uses a single Propeller with a SD card connected to load data from)
Good luck trying to do even a cut down version of anything from the clips above on an Aurdino.
/Johannes
http://ics.nxp.com/products/lpc1000/datasheet/lpc1763.lpc1764.lpc1765.lpc1766.lpc1767.lpc1768.lpc1769.pdf
and the tiny (2.3mm x 2.3mm) LPC1102:
http://ics.nxp.com/products/lpc1000/datasheet/lpc1102.pdf
They are often cheaper than an 8-bit MCU, like an AVR, and software development is much easier.
One doesn't see many embedded applications with a VGA display. If a display is needed, designers usually select an MCU with an LCD controller.
Any of the above applications could be implemented on a conventional device, just as easily, and probably cheaper.
In progress: http://code.google.com/p/propforth/
Feel free to join.
Long live the Prop!
Andrew
There is a thread about using Propellers for an ANN, I don't think it is a suitable device for that sort of application.
This chip is now available:
http://www.general-vision.com/products/chips-and-modules/CM1K-Chip/index.html
One of my first serious projects with the Propeller was a coincident photon counter with a bunch of peripherals. It was a system that continously read six channels of temperature, 8 simultaneous channels of frequency, utilized a real time clock, had some basic mouse control of the photomultipliers' high voltages, output some data onto a TV and read tons of data onto an SD card in CSV format. It all ran on a single Propeller chip.
I think people on this forum have done many complicated things with this chip, but only a tiny fraction of it ever gets documented.
Excellent. I invite you to join us in trying to do some useful ANN things with Propeller. All ideas are welcome!
Some of us have started discussing ways to achieve this here: http://forums.parallax.com/showthread.php?132152-Simulating-neurons-with-an-array-of-props.&p=1007773&viewfull=1#post1007773 I haven't had much time to persue it lately because of other commitments, but I have finished a PCB that can be used for multi-propeller experiments here: http://forums.parallax.com/showthread.php?131538-50-TetraProp(tm)-Boards-now-ready-to-ship-!&p=998005&viewfull=1#post998005
While the Propeller can't really be used with traditional huge array memory algorithms and floating point weights, activation, and connection states would need to be done in scaled integer math, it's parallel processing abilities can be employed to do many calculations on aggregate. Unfortunately each COG is really limited to about 20MIPS, so it will take a large number of Propellers to achieve similar computational power to a PC. However, the connections strengths as a function of time may have better change resolution.
As always, Leon tries to divert us away from trying to do substantial things with Propeller. It is best to just ignore him.
Hi Andrew
The propforth multiprop configuration allows one to string together as many props as needed. Logically, the interface to cogs on the slave prop is the same as to cogs on the local prop. Of course, the physical link is slower, the developer is responsible for taking the link throughput into consideration. Eventually the plan is to try some ANN with this, it will likely be a different approach to in the "simulating nuerons" thread.
As Leon pointed out, the prop is complete unsuitable for whatever he has in mind (which is generally "using a different chip"), but is the prop is complete suitable for what I have in mind, which is "playing with the prop".
Can you suggest some references for ANN so we can get up to speed with where you are coming from, where you want to go, and how we can get there?
I'm particularly interesteds in method that do not require large amounts of additional fast RAM, but instead could be made to work with for example SD cards.
It also has to generate fast PWM (9 bit at 192kHz) for the class-D output, implement volume control, do sigma/delta conversion, asynchrounously handle the NRF24L01+ transceiver module, implement sample buffering with locks, handle the UI.
The overall idea is to have two battery powered speaker units without wires, plug an iPod/analog audio source into one unit and then select which unit gets left hand channel and which gets the right (the other unit acts as a slave). Oh and drive 2 red/green LEDs
I'll hopefully be posting some more details when everything is together and working (new PCBs arrived today), but it seems like quite a good work-out for the Propeller architecture, and would be tough to get working with an interrupt-driven architecture without dedicated I2S hardware.
I am porting a program which consists of 12,000 lines of 80186 assembly language from one hacked embedded controller to its 80386-based successor. (We have to use these controllers for complicated reasons, although one day we look to porting this application itself to Propellers.) The whole thing is a nightmare of interrupt levels, overhead in firmware I don't control, and no documentation so everything has to be tested.
The purpose of this thing is to control a $40,000+ machine that sorts food products by weight. The products fly across an in-motion scale, are weighed and various decisions are made, and they go onto a separator where one of four to sixteen pneumatic arms might knock it into a hopper. It's all done by timing, the only sensors in the entire system are a scale-entry photo-eye and the in-motion scale weight sensor.
For years I had one of these machines in the shop in case I got a chance to work on the program. Three months ago we opened a new office and the Powers that Be decided to relocate the idle machine to that office (300 miles from here) in hopes of selling it.
Shortly afterward, we faced a crisis in availability of the old 80186 based instrument. Our cool plan to port it to the Propeller has to go on hold, because we don't have time; even if the port doesn't use all the new box's cool features we have to get something we can use in critical service situations. There are a lot of plants out there that go DOWN when these machines are inoperable.
So about a year and a half ago I had started on this project, and gave it up when we decided a propeller port would be better -- but that involves building our own hardware, which we now don't have time to do. I had gotten much of the user interface ported (no small task as the displays are quite different) but I had gotten to the point where I needed the actual $40,000+ machine to go further -- and my machine is now in Memphis.
So after a bit of an epiphany on the drive home, I decided to build my own machine -- in cyberspace. Particularly, in Hub RAM.
The controller I'm programming gets most of its I/O via IIC, and the Propeller does IIC very nicely, but this required the Prop to be an IIC slave pretending to be a whole bank of PCF8574's. This needed to be written in PASM as the master runs at 75 KHz and Spin wasn't quite fast enough. That took about three days.
I then set up a small voltage divider to generate millivolt level "load cell signals" via PWM, and verified its operation; that took a couple of hours. I then hooked the demoboard up to a small VGA display and wrote a machine simulator which throws product across hte scale, generates weight signals, and visually displays when gates and arms are actuated and removes product if an arm intercepts it. That was done entirely in Spin and took another two days or so.
I verified that it worked right with the original software in the 80186 box, and now I have a virtual $40,000 machine for debugging purposes that lives on a DemoBoard. And it's a lot more convenient to hit the space bar on a PS/2 keyboard than it is to stand up and stick something on a conveyor belt.
Eventually I'll have to hook it up and test with a real machine before it's ready for customers, but now instead of weeks in a distant city it will be days and that spent doing mostly special case debugging, not basic functionality. The week I burned building the simulator has already been paid back with interest as I work on the real application, and my employer is extremely pleased not to be putting me up in a hotel for several weeks to get this thing done.
It might have been possible to throw this simulator together with another product, but not with any I've ever encountered. The complete separation of the new I2C code, the PWM, the video and keyboard user interface, and the actual simulator code in Spin which touches all of those things only lightly, made what would have been a heavy-duty development task in any other environment I've ever used a breeze.
You might not consider that a "sophisticated" application; like many other cool Prop projects it's just using the cogs to do I/O and timing while one big slow cog does the business logic. But it's the totally fluid mix of those things, the ability to throw them together in any combination without consideration to what pin can do what, which makes such a small thing take a week instead of a month to develop, thus worth doing instead of being more of a hassle than just driving to Memphis a few times. That sort of thing is the real genius of the P8X32A.
By being able to disect the time critical sections of code into their own cogs without the worry of interrupts affecting the timing makes the code so much easier to test and debug. It is so much easier to debug a small simple program than a big complex one.
amveronis: There have been many apps done with the prop that show some of the features of parallel processing in the prop. They are just not necessarily readily visible. Each of the functions can certainly be done with most other micros. It is the combination of them that makes the prop such a pleasure to program. For instance, the video stands alone - it does not affect other code by using interrupts. So it is available in modules, for various resolutions. Same thing applies to PS2 interfaces, SD (SPI) and I2C interfaces. Micah even has USB running (master or slave), although not fully USB compliant, but neither are many of the software USB implementations out there.
Perhaps one use I have done is a datalogger. The prop takes 4 clocks per instruction (most instructions, few exceptions). I used 4 cogs interlaced (1 clock cycle stepped) to sample the pins. So sampling can be done every 12.5ns (80MHz clock) or 10ns (overclocked 100MHz) or faster (I overclock regularly at 104MHz with optional 108MHz). While the program cannot maintain this for any length of time (IIRC about 1700 samples), it does show how the multi-processing works. My code for this is in the OBEX, as are other variants.
I have a debugger that traces each pasm (or spin) instruction (slows the cog down to do this) and a separate cog takes each instruction and fully decodes this and passes it to the pc. This program takes no space from the cog ram and does not require any modification to the actual cog code whatsever. See Zero footprint debugger in OBEX. Jazzed did a debugger too, and IIRC it is somewhat based on my debugger.
You will find that there is a lot of code in the OBEX. Much of that is often derived from other works which may also be in the OBEX. Unfortunately, we don't always find the time to post our code to the obex, and it may only be found on this forum.
I do agree that the sample code is pretty lame for a person with lots of experience. However, the samples are there just to temp people, and give them a feel for the prop. Certainly you can see that getting the prop to run is simple and not daunting like most other micros (no complex command lines or batch files). Also you can see that getting multiple cogs to work is a breeze - the multiple cogs each flashing leds independantly is just a taste of what the prop can do.
Really, it is up to your own imagination of what you want each cog in the prop to do.
Leon: Get a life and go elsewhere! Your negativity is booring!
http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/Harprit/List/0/SortField/4/ProductID/683/Default.aspx
Blinking LEDs get the point across.
Would "Hello World" exercises have cachet were they "What Hath God Wrought?" exercises?
Maybe somebody will write, "Programming With PASM - An Advanced User's Guide to Parallel Processing".
Andrew
This is one of the applications I admire. I know there are plenty more out there. Lets get them documented.
Andrew
The Prop, in all its glory, has given the opportunity for the creation of other formidable products. Look at 12Blocks, PropBasic, Propforth.
Long live the Prop!
Andrew
(Which is probably why Leon doesn't like it... he likes to interrupt... )
Nearly 20 years ago, a buddy and I built a digital timer(a class in microprocessor technology. We had to 'build a box with input, an 8051 in the middle and useful output'... )
The result was a monster...
8 independent 'programs' that could overlap activation of any of the 4 relays, a countdown timer(which could also overlap a running program), a 100 year calendar(correct from 1980 to 2080)...
We had to be extremely careful about the interrupts as whenever the clock rolled over to a new second, a lot of updates took place.
(Updating the clock as we didn't have a RTC to read off of. Displaying the time, if the display was in clock mode, date if in that mode, 'relay status' if in that mode and so on. Checking if any relays needed switching on or off)
Of course, we also had to account for the time spent reading off the 'keyboard'.
(Done with the same interrupts. I think we had 20/second?)
The UI was a 'state machine' and the rest was done with interrupts.
It was a mess of 3000 lines of assembly code.
A lot of it was written with speed, not 'economy' in mind, and we even ended up using a lot of inline code that should have been a subroutines, just because we didn't dare waste the cycles doing all the PUSHing and POPing and CALL and RETing...
The 'nightmare' scenario was 'what if someone pressed a key just as the clock rolled over on new years eve'?
We actually calculated how many cycles a all the diffrent 'rollowers' would take, with cascading effects and all, just to be certain we had enough time to get it all done in the 50mS beforethe next interrupt.
Most MCUs only support one or two levels of interrupts, and one is usually the 'NMI'(Non-Maskable Interrupt) which as the name says, can't be blocked, and usually can't be further interrupted.(This interrupt is often used for serial comms on older computers. Especially popular on Z80 based computers as it didn't have a serial port built-in like the 8085 did. Using NMI meant you could 'bit bang' and save a chip or two in the design. This was possible on the Z80 because it had a double set of registers and could switch between them with a single 4cycle instruction, instead of PUSHing and POPing.)
So, if you want a deterministic system, where you know when your code runs and for how long...
Modern MCUs have lots of interrupts, the 16-bit PICs typically have 126 interrupt vectors. I've never found interrupts difficult to use and they are essential if you are using lots of peripherals in an application, as is often necessary.
Levels, no...
Even the old Z80 had 127 interrupt vectors, plus the NMI.
The problem isn't how many different interrupts you can handle, but how many you can have at one time.
Writing code that CAN handle having one interrupt routine interrupted by a higher priority one is not aways easy.
And if you have any delicate timing going around at all... you may end up with weird stuff happening.
So, if none of the applications people have used the Propeller is 'suitable', pray tell; what kind of tasks is it suited for?
(I can't ever remember seeing you recommend it for anything... )
Code that can handle lots of interrupts isn't difficult to write, there are lots of complex real-time applications that work perfectly well, which handle far more peripheral functions than a Propeller can manage. I've written a couple myself, using ARM MCUs.
I've recommended it to several people on other forums for various applications. I can't remember the details, but they usually involved CNC or robotics.