In the years since I learned of micro controllers I have worked with several from Motrola, Renasis, TI. But none were so easy to get working and none having a development system as useful and open as the spinstudio. I have only been playing with the prop since January and have already developed an entire product line based on this wonderful chip. It will take a lot to coax me away from the propeller(Infinite core quantum processor).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
We are using 2 each of the AD1871 in our devices. That's how we get the 4 channels of data. You can check out the datasheet if you are interested in this chip:
Both channels on one chip are read by a single cog. These chips spit out data from one channel then the other so there's no way to sample both channels from a single chip at the same time. One might be able to code something that allowed reading of channel L from 2 separate chips at the same time in a single cog. Fortunately, we didn't have to figure that out. I'm not pushing these chips on you, despite what it might sound like, I simply wanted to let you know that reading data which is being clocked out of the ADC @6.144Mhz is doable. I think if you search for Beau's SPI engine you may find he's done even better than that.
As for the multiply, have a look at Ale's comment in this thread:
First, I am new to the Propeller, second, I like to program in BASIC and I love BASCOM and the Atmel chips.
I needed to do something beyond what I could do with BASCOM and the Atmel so I tried the Propeller.· I really don't like the spin language and in the end, to do what I wanted, I had to use ASM.· Having never written in SPIN or ASM before, it started out with a bad feeling.·
After messing around for a bit I got my ASM code working, well, not only working, but working very good.· I actually like PASM better than SPIN and frankly, I don't think I could do what I am without the Propeller.·
As for winning popularity contests, I suspect that with some good C compilers now being available, more programmers would try the Propeller.· C is certainly very popular as the language of choice for micro programmers.· Myself, I hate C and thought I hated ASM even more, but the Propeller sure changed my mind.
Having given it a whole-hearted try, I must say I will continue to consider the Propeller for any new projects I dream up. I am impressed and certainly am curious about the upcomming Prop2 that keeps getting hinted at in this forum.·
Howdy.· After a long hiatus, I'm back looking at the propeller, and I still haven't been able to make up my mind if it's a platform I'd regularly use or not.
I have successfully done a couple of propeller test projects, like a·scrolling 16 x 32 led matrix http://forums.parallax.com/showthread.php?p=725126) and some video projects, but it seems I either can't wrap my mindset over the prop ideology or it just doesn't work for me.· Fwiw, I've been working with micros since 6502/z80 days, so I feel I have a good understanding of what is going on, it's more a matter of determining the benefits.
I am typically an AVR guy on a day to day basis, but I like to experiement with other platforms like the propeller (also doing some ARM7 stuff now).
It seems to me that the Propeller tries to be too much and suffers as a consequence.· One the one hand, it appears to target the beginner crowd with Spin and the object library; on the other I quickly find that to· accomplish anything of significant performance you must revert back to assembly.· Assembly on it's own is not bad, but it is slower to develop and you lose the rapid development aspect.· Chip's own analogy on why the Propeller works equally applies here:
"Imagine a program written entirely in assembly language. It takes a long time to write, but it is fast, compact, and reliable by virtue of its directness. Now imagine a program written in some high-level language which leverages objects acquired from elsewhere. It is relatively easy to write, but compiles into something big and slow, and may have some undesirable characteristics that are out of your control."
Now to me, something like C is typically a great compromise because you get an easier development compared to asm yet most of it's speed.· But if you go with C on the Propeller you loose the object library, which in reality are your 'hardware features' like I2C you'd get with other chips by default, and you'd have to write and test code for all of those things.· And on ICC C at least, you loose a cog for the kernel and incur LMM speed penalties.
The parallel processing idea is initially intriguing, but my take is that you often end up using cogs to replicate features that other chips offer in hardware, so it's kind of a wash.· And if you program in Spin then you end up dedicating 1 copg as the interpetor.· While there may be limited applications that could truly benefit from the parallel processing aspect, I would think that you could implement traditional interrupt code to accomplish.· I guess the argument is that the Propeller makes this easier to deal with, but if you end up having to code in asm then I think you loose the 'easy' benefit.
I've only used the Demo Board, but unless I'm mistaken any Propeller project is a 2 chip minimum because you need to store the firmware in an external eeprom.· This seems to be a rather curious requirement, one that I would expect complicates project designs for beginners and adds unneeded complexity to more simple projects.··While I understand that the 3.3V design is probably due to clock speed and/or power consumption, I think this also makes it a bit more complicated for beginners or for otherwise 'simple' designs where you'd look to a small microcontroller.
For more advanced projects, it seems the small 32K memory space is a serious limitation.· I think the 20/160 speed advertising is a bit confusing, because you won't nearly approach that with Spin, which is estimated to be 40x - 100x slower than pasm, and it will also suffer if you need the LMM pragma (pasm being limited to 496 instructions).· The lack of true debugging like JTAG seems a serious blow to 'true' professional applications.
For what it's worth, I'm not anti-Propeller, I'm just having a difficult time appreciating how the Propeller would replace any of the existing chip architectures from a generic project pov.· Certainly the Propeller does have some niche benefits - like it's video capabilties - but other than that I'm unsure it will really take off.·· If I had to infer, I'd guess Parallax doesn't think the Prop is doing as well as they hoped and it also appears the Imagecraft folks are seeing lackluster interest.
I'm open to comments; if I am really overlooking something that I could help get my mindset around why I'd want to really use this I'm all ears.
Actually, I think you'd find that Parallax thinks the Propeller is doing quite well at this point. You have to remember that Parallax takes the "long view" and assumes that products will be around for a long time (look at the BS1 for an example). The kind of contributions from the user community are already "snowballing". We now have a self-supporting Propeller with an editor and Spin compiler / assembler. All you need is a keyboard, TV monitor, and SD card. There are now 4 Spin compilers including Parallax's and 2 C compilers including ImageCraft's. There are emulators for the Z80 and 6802. There's a very sophisticated multi-channel vocal tract synthesizer with a phoneme processor and lots more. Hanno's 12-Blocks looks like a great tool for introducing the Propeller to new users and the educational market in general.
The Propeller is, at its heart, a microcontroller and it's deliberately designed for flexibility. That may not be what you want for your project, but that's what it's designed for. Other choices that were made when the design was begun include the manufacturing process involved and approximate chip size. The process determines what's possible to be included in the device, like no EEPROM. It also determines things like minimum power consumption and operating voltage. The chip size determines what's available for the tradeoffs of memory size vs. number of cogs vs. complexity of the cogs, etc.
You mention the lack of JTAG as a serious blow. Unless you've already allocated all the cogs and all the I/O pins to other functions, it only takes one cog and one I/O pin (for black and white) to add a video display for debug output. There are now several debuggers that use a PC for control and display including Hanno's ViewPort.
Yes, the 32K memory size is a limitation for some projects. It's a major portion of the chip area and, to increase it to the next level (64K) would roughly double the already large chip area. The Prop II design, by going to a different manufacturing process, quadruples that, but requires two supply voltages and a much higher quiescent supply current.
Yes, the Propeller requires an external EEPROM for most uses. That's a result of the manufacturing process chosen which does not allow for the special oxide layer needed or the additional "high voltage" needed for programming. Obviously, other chip processor manufacturers can combine flash memory with SRAM and processors. I don't know what intellectual property issues come into play or other costs or tradeoffs would be involved to use a process that allows for the combination, but EEPROM is pretty cheap now and the board area involved is small. You can also use a larger EEPROM and use the extra memory for data storage or use FRAM for faster and more frequent updating, etc.
Anyway, the Propeller is not made to be all things for all people. If it's a bad fit for what you need to do, by all means use something else that's a better fit. The Propeller happens to be a very reliable, straightforward, reasonably fast and powerful microcontroller that's very very flexible. It will be around for a long time and well supported.
Thanks for the insight.· In case I was not clear, my intent was not so much to critque the Propeller so much as trying to understand if I am overlooking benefits in comparison to other development resources currently available, such as the avr.· Certainly the chip is not without potential, and to be the first multicore processor targeted to the hobbiest is a credit to Parallax.
I understand that debugging can be accomplished to a degree by deligating a cog to the task and in combination with Hanno's Viewport, which I have been experimenting with.· But if I understand correctly, you can't trace the execution of multiple cogs simultaneously, so if you have an application where cogs interact or otherwise depend on each other it can get complicated.· You also seem to have to reconfigure the code knowing in advance which variables you want to monitor, rather than being able to view them as desired as many other debuggers allow.· Hopefully a software Propeller simulator will become available so you could test code offline.
As an aside, my JTAG comment was more directed towards commercial application of the Propeller...
edit -
While the deligation of a cog to the debugger is not in itself a bad thing, aren't you also losing a cog if your code is spin based?· So then you're down to 6 cogs.
I understand that debugging can be accomplished to a degree by deligating a cog to the task and in combination with Hanno's Viewport, which I have been experimenting with. But if I understand correctly, you can't trace the execution of multiple cogs simultaneously, so if you have an application where cogs interact or otherwise depend on each other it can get complicated. You also seem to have to reconfigure the code knowing in advance which variables you want to monitor, rather than being able to view them as desired as many other debuggers allow. Hopefully a software Propeller simulator will become available so you could test code offline.
There are already propeller simulators available and have been for a number of years now.
People manage to produce fantastic, amazing code without the use of a debugger. It's incredible what you can learn about an architecture while you are trying to figure out why your code is running into the weeds.
Agent420 said...
While the deligation of a cog to the debugger is not in itself a bad thing, aren't you also losing a cog if your code is spin based? So then you're down to 6 cogs.
I don't see how you are "losing a cog" if you are running SPIN. SPIN/PASM/C/BF.. it matters not, you still need a cog to run the code.
Yes, you give up an extra cog if you need a dedicated debugger, but then you can just toggle a pin and monitor that with a LED or a CRO and not lose the extra cog. Debuggers are highly overrated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I also usually work with ARM and AVR chips and program them using C.
I'm finding the propeller is great to add to an ARM/AVR project for it's video hardware.
The prop is cheap enough and small enough that it's a no-brainer adding it to simplify some tasks
that are hard to do using ARM/AVR. Even after adding in the xtal and eeprom parts you are way below 10 dollars
when parts are bought in quantity. I'm working on a project now where adding the prop has let me change from
a more expensive ARM to a cheap AVR because the prop handles the few things we needed the ARM for... total cost
of the hardware has dropped several dollars and programming has been greatly simplified for all concerned as
I have programmed the prop to act as a black box the other coders just have to send commands to.
Saving and making money is the most important thing around here.....I save programmer hours and hardware parts cost
by using the prop.
I understand that debugging can be accomplished to a degree by deligating a cog to the task and in combination with Hanno's Viewport, which I have been experimenting with.· But if I understand correctly, you can't trace the execution of multiple cogs simultaneously, so if you have an application where cogs interact or otherwise depend on each other it can get complicated.· You also seem to have to reconfigure the code knowing in advance which variables you want to monitor, rather than being able to view them as desired as many other debuggers allow.· Hopefully a software Propeller simulator will become available so you could test code offline.
edit -
While the deligation of a cog to the debugger is not in itself a bad thing, aren't you also losing a cog if your code is spin based?· So then you're down to 6 cogs.
How much debugging could you do on the Z80 and 6502????·· ·
You keep talking about losing a cog....well, there are 8 of them.....which is 7 more than all other microcontrollers! What you are saying is that the propeller is bad because to do anything with it you need a a few cogs.....well other microcontrollers do not have any cogs and to do anything with them you have jump though hoops to get
the illusion of parallel processing.....the propeller does real parallel processing and that is what the cogs are for and there are 8 of them and thus you do not lose one when you use it....you are using it.....and there are others for use to achieve real parallel processing.
[color=black]I've been working with micros since 6502/z80 days, so I feel I have a good understanding of what is going on,[/color][color=black]I am typically an AVR guy on a day to day basis, but I like to experiement with other platforms like the propeller (also doing some ARM7 stuff now).[/color]
[color=black]It seems to me that the Propeller tries to be too much and suffers as a consequence. One the one hand, it appears to target the beginner crowd with Spin and the object library; on the other I quickly find that to accomplish anything of significant performance you must revert back to assembly. Assembly on it's own is not bad, but it is slower to develop and you lose the rapid development aspect. Chip's own analogy on why the Propeller works equally applies here:[/color]
The propeller does not try to do too much......it is the people that use the propeller that try to do things with it that seem to be too much to some people. That is only because the propeller is able to do so much more than people are used to do with other microcontrollers. · The performance does not suffer at all.....the combination of PASM objects with SPIN wrappers makes the propeller able to achieve amazing performance with the ease of programming for a novice. · Actually most microcontrollers have to be programmed with ASM to get them to do anything useful. And the novice is excluded from the ability to do that since there is no other solution except to program with ASM. But with the propeller Spin and PASM objects even the novice can achieve performance that approaches the fastest of controllers out there. · The propeller is an amazing chip and Spin is a delight. Even if you lose some speed with PASM you are still able to achieve with it more than you can achieve with many other microcontrollers and with the REAL PARALLEL processing ability you can do things that are not possible with other microcontrollers. · How many controllers you know can have the ability to support a PS2 keyboard and·mouse with a ·2 joysticks and TV output as well as VGA as well as Stereo Sound output and sound input and graphics engine and Serial I/O and and still have enough processing power and I/O pins to do control of devices and and and .....?????? and ALL ON ONE CHIP. · But above all.....I think you are just not appreciating the Parallel Processing aspect of the propeller. It is by far the biggest advantage it has over any controller out there.....if you just understand what that means you will not be able but to LOVE the propeller. · Also having an external EEPROM is actually an advantage in many ways.....you can replace it when it goes faulty... you can make it bigger if you need instead of being stuck with the fixed on board limitation..... · Imagine that you have a product that needs upgrading....by just replacing the EEPROM (cheap and small) you can upgrade the device....instead of replacing the expensive Controller....especially if the controller is soldered on the PCB. ·
I don't see how you are "losing a cog" if you are running SPIN. SPIN/PASM/C/BF.. it matters not, you still need a cog to run the code.
Yes, you give up an extra cog if you need a dedicated debugger, but then you can just toggle a pin and monitor that with a LED or a CRO and not lose the extra cog. Debuggers are highly overrated.
Perhaps I misunderstood the documentation regarding the spin interpretor...· I thought it ran as a dedicated cog.
Yes, that is how I am viewing the Propeller right now.· Without a doubt the video capabilities intrigue me the most.·· There are also occasional time where parallel processing would be better than what I could accomplish with a conventional interrupt.· So right now I consider the Prop more a specialized feature chip with general controller abilities than the other way around;· I think I would tend to pair a Prop with an avr or similar as well.
Brad, · Debuggers are not highly overrated.....people who can program do not need them....but people who cannot really program need them .....so to enable amateurs to appear to be programmers, they are needed....therefore there is a use for them.
I used to think about combining an AVR and a Prop. A comparable AVR is the Atmega32: 32K Flash, 2K SRAM, 32 I/O pins, 16MHz. Important for my home hacking is 40 pin DIP package, availability and similar price.
But reflecting on it I thought "Why not just use another Prop instead." Save myself all the hassle of having two different developments environments, downloaders etc etc. Bear in mind I do all my development in Linux. Using an AVR does not seem to be worth it. Apparently others came to the same conclusion, hence the TriBlade Prop an Morpheous etc.
If I was going to build a small board with Prop plus another CPU the other would have to be something big enough to run Linux (which can be pretty small now a days) for all that serious OS lovelyness, networking, USB hosts etc with the Prop providing the I/O, sound, video, real-time control etc.
By the way, what's the issue with debuggers, over the decades they have not been much use to me, often more causing more confusion than they fix. You can do amazing things with just a LED for output. Even more amazing if you have direct video console output.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
SamMishal said... well other microcontrollers do not have any cogs and to do anything with them you have jump though hoops to get the illusion of parallel processing.....the propeller does real parallel processing and that is what the cogs are forand there are 8 of them and thus you do not lose one when you use it....you are using it.....and there are others for use to achieve real parallel processing.
While I will not deny that parallel processing is not without merit, I also think that it is the end result or requirement that matters and rather than how it was accomplished, whether that be by multiple cogs or a conventional processor via interrupts.· And once you require common memory or io access, you're potentially waiting for the hub which I think may equalize things to some degree.
SamMishal said... Actually most microcontrollers have to be programmed with ASM to get them to do anything useful. And the novice is excluded from the ability to do that since there is no other solution except to program with ASM. But with the propeller Spin and PASM objects even the novice can achieve performance that approaches the fastest of controllers out there.
I respectfully disagree.· There are excellent free C or shareware Basic compilers for platforms like the AVR, and boards like the Arduino are targeted directly at novice users.· All these offer easy to use compiled libraries that run at high speed.· If anything, I would suggest that it is more a requirement to learn pasm on the Propeller because Spin on it's own is much slower, and if what you need to accomplish has not already been submitted as a pasm object, you would need to code it yourself in order to get the speed benefit; whereas customized C code would be compiled to asm.
SamMishal said... How many controllers you know can have the ability to support a PS2 keyboard and·mouse with a ·2 joysticks and TV output as well as VGA as well as Stereo Sound output and sound input and graphics engine and Serial I/O and and still have enough processing power and I/O pins to do control of devices and and and .....?????? and ALL ON ONE CHIP.
I will not deny that the video capabilties of the Prop are unique - but in fairness that is the one hardware feature that is built into the chip.··Other chips offer hardware I2C, SPI, UART etc that seem to typically require a dedicated cog.· I think if we put the video capabilities aside, the playing field is more equalized.
SamMishal said... Also having an external EEPROM is actually an advantage in many ways.....you can replace it when it goes faulty... you can make it bigger if you need instead of being stuck with the fixed on board limitation..... · Imagine that you have a product that needs upgrading....by just replacing the EEPROM (cheap and small) you can upgrade the device....instead of replacing the expensive Controller....especially if the controller is soldered on the PCB.
There again, most other controllers offer onboard eeprom of much larger size, and can be reprogrammed in circuit.· So I don't see much benefit there; in fact it complicates simple 1 chip solutions.
SamMishal said... But above all.....I think you are just not appreciating the Parallel Processing aspect of the propeller. It is by far the biggest advantage it has over any controller out there.....if you just understand what that means you will not be able but to LOVE the propeller.
I agree with you here... it is this aspect of the Propeller that intrigues me the most, yet I'm not certain how much it really apllies to the vast majority of projects that I do, and I'd have to think that most hobbiests may not actually require parallel processing either.· I'm really on the fence on this one.· Is it easier to set up a new cog vs an interrupt?· Perhaps.· Does that ability outweigh the potential code size limitations or spin execution speed?· Might depend.
I've got some free time now which is why I'm back looking at the Prop... perhaps it will come to me ;-)· I mean, I did buy the demo board, so it's not like I'm just here to knock it around [noparse]:)[/noparse]
Fascinating topic as always [noparse]:)[/noparse] Aside from the expected ranting from certain members ....
If you want to run PASM on all cogs, you can. Linus Akesson did this with his LFT demo.
If you want to run a SPIN interpreter (default), it takes a COG. If you want to run C LMM interpreter like ImageCraft C, it takes a COG.
If you want a debugger, one way or another you have to use a COG unless there is room in the "interpreter" COG.
There is no way to debug "any given COG" on demand ... yet To debug any COG PASM does require giving up some COG resources.
Yes, there are challenges with Propeller. There were also challenges in writing programs on punch cards (not exactly the same).
With challenge comes opportunity to eliminate the challenges. I think it all depends on what you want.
For a user application mind-set, Propeller is fine if you want to do relatively small but timing critical projects.
If one needs bigger and more efficient operating code space, other controllers or general CPU may be more appropriate.
It seems the Propeller fits somewhere between the 6-pin atTiny and the atMega328 for code space.
heater said...
By the way, what's the issue with debuggers, over the decades they have not been much use to me, often more causing more confusion than they fix. You can do amazing things with just a LED for output. Even more amazing if you have direct video console output.
I'll admit that good writing good code negates the need of a debugger.· But I'd much rather have a good debugger on hand for the complex logic bombs that can arise in a complex project than keep tweaking my code to flash an led or print a variabel on the screen.
The Propeller is just one type of screw you can buy at the hardware store. If you need a longer / shorter one or a countersunk one, buy a PIC or Atmel or whatever. The Prop does quite some things much better than the rest, and in other things he simply fails.
This is nothing Prop-war-like, it's just picking the right tool (µC) for a job given.
Things would change quite a bit if Props would exist in different packages with a different number of IOs, with built-in ADCs/DACs and internal EEPROM or more RAM and such. Some things will never happen, so you might be better served with alternatives.
These last points are the keystone for Parallax to enter the industrial high volume-market. In industry, you reduce costs by reducing footprint, chip-price, and having as much as possible integrated into the chips. An external ADC is a no-go. Just look at the incredible selection of PICs. There is certainly one that fits (as long as a Prop isn't better suited for the task). It simply costs too much. In low-volume, things are quite different.
Not saying, that PIC or Atmel or $whatever is better, they are *different*.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
jazzed said...
Fascinating topic as always [noparse]:)[/noparse] Aside from the expected ranting from certain members ....
If you want to run a SPIN interpreter (default), it takes a COG. If you want to run C LMM interpreter like ImageCraft C, it takes a COG.
If you want a debugger, one way or another you have to use a COG unless there is room in the "interpreter" COG.
There is no way to debug "any given COG" on demand ... yet To debug any COG PASM does require giving up some COG resources.
Yes, there are challenges with Propeller. There were also challenges in writing programs on punch cards (not exactly the same).
With challenge comes opportunity to eliminate the challenges. I think it all depends on what you want.
For a user application mind-set, Propeller is fine if you want to do relatively small but timing critical projects.
If one needs bigger and more efficient operating code space, other controllers or general CPU may be more appropriate.
It seems the Propeller fits somewhere between the 6-pin atTiny and the atMega328 for code space.
I just want to reiterate that it's not my intent to be a Prop-basher...· I'm just an old 8 bit dog struggling with the new tricks ;-)
To clarify the Spin interpreter, which is the default configuration... that does require a dedicated cog?· So a Spin based app really leaves 7 cogs free for user code?
No bashing interpreted [noparse]:)[/noparse] ... You quoted my whole post except the line about Linus' work ... fascinating.
Yes, clearly by default, there are only 7 COGS left for the user. Spin is a bytecode language like Java for example that needs a VM.
The interpreter lives in ROM, but runs in a COG. You can however restart the SPIN COG to run any other VM as I implied.
jazzed said...
No bashing interpreted [noparse]:)[/noparse] ... You quoted my whole post except the line about Linus' work ... fascinating.
Yes, clearly by default, there are only 7 COGS left for the user. Spin is a bytecode language like Java for example that needs a VM.
The interpreter lives in ROM, but runs in a COG. You can however restart the SPIN COG to run any other VM as I implied.
Oops, not intended...· I originally was going to quote a portion and then thought perhaps the whole thing.· Seems I goofed up in my copy and paste.
You might understand my desire for a proper debugger ;-)
Sorry this thing about SPIN somehow "wasting" a COG is nonsense.
SPIN is an interpreter yes. You write a single threaded program in SPIN, the interpreter runs in a COG and in turn "runs" (interprets) your program. One program, one thread, one COG. There is no COG "wasted" you want to run your program after all. No different than using BASIC or Forth or C or ASM.
If you write a program with n parallel threads in SPIN you will be running n interpreters in n COGs. There is no wastage.
If you write a program in PASM that runs in a COG and has some SPIN access methods included in its object, say a serial port driver. Then those access routines are run by the calling application when called and run in the callers "thread". There is no wasted COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As for "logic bombs" and debuggers. I have often come across bugs which are intermittent, random, unpredictable. They are usually something to do with memory corruption or threads corrupting each others memory in subtle ways. It's just these hard case where you need a debugger where you find they are no help what so ever. For the simple bugs, like a logic error with a wrong result a debugger is not normally required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well I guess the debugger thing is personal preference then. Maybe it's my work habits.· Either way, after almost 30 years of coding I still like to trace program flow while watching registers and stacks over just setting a flag or printing a variable.· There are still things that catch me off guard after all this time.· Certainly you can resolve errors·without the aid of these things, but they are nice to have.
I'll have to look into the simulators that are available... technically I tend to do much of my debugging offline in the software realm.
As for the spin interpreter cog, I thought the documentation was a bit vague but what you say makes sense.· I did note that the Imagecraft C compiler does dedicate a cog however.
Not sure about the ImageCraft C compiler. I though the idea was that it used one COG to execute your code which has been compiled to LMM PASM and then optionally used another COG to take care of floating point operations. Anyone like to enlighten us about that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
spin uses a cog, just like pasm. But, you CAN run 8 cogs of spin or 8 cogs, some running spin, some with pasm.
Now what can the prop do? With 1 x 64KB-512KB SRAM, 1 x eeprom, 1 prop, 1 microSD and a serial port (plus xtal, resistors and capacitors and power supply/battery you can run CPM2.2 under emulation at about a 4MHz Z80. With a second prop connected to the serial port, you can have keyboard, mouse, VGA, TV stereo, and still some pins for other goodies. Now how many other microcontrollers can do that for $8 each? And only 1 device to stock! Every time you want to design a pic or avr, you have to decide what hardware goodies you want inside (I2C, SPI, etc) and then you choose a new device. No common pcbs here!
But, if you have a simple design, sure a $2 pic or avr might do the job.
I am planning to use a pic10F2xx for <50cents to convert a PS2 Keyboard/Mouse to 1 pin serial. It is in tiny a sot23 6pin package. As they say, horses for courses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
FWIW, I did not say a COG is wasted; I just explained objectively the way it works. Wasted is a subjective term. Continuing objectively: The ImageCraft C compiler reuses the Spin COG, so 7 COGs are left for the user just like in Spin. If for some reason you really need floating point (transendentals, etc...), it will use another COG (or two?) ... just like Spin.
Subjectively: The problem with the Gear simulator is that it starts stepping in spin byte-codes ... almost impossible to understand without a listing. ViewPort lets you step through Spin, etc... the problem with that is the debugger is an afterthought addition which is frustrating to me at least.
I think I'm just misinterpreting the phrasing here, for example: "The ImageCraft C compiler reuses the Spin COG, so 7 COGs are left for the user...". Seven COGs for the user implies that the first one is not for the user. But it is running the users C code.
Never mind, I'm sure we all get how it goes now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm, I guess it could have been described better in stand-alone terms. I was comparing apples to apples. Other than the fact that there is a language difference and C uses LMM, there is no difference between C and Spin resource wise. Your previous post covered it pretty well I thought. If I did not explain anything new, that's fine. At least you have confirmation of your hypothesis.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
We are using 2 each of the AD1871 in our devices. That's how we get the 4 channels of data. You can check out the datasheet if you are interested in this chip:
www.analog.com/en/analog-to-digital-converters/audio-ad-converters/AD1871/products/product.html
Both channels on one chip are read by a single cog. These chips spit out data from one channel then the other so there's no way to sample both channels from a single chip at the same time. One might be able to code something that allowed reading of channel L from 2 separate chips at the same time in a single cog. Fortunately, we didn't have to figure that out. I'm not pushing these chips on you, despite what it might sound like, I simply wanted to let you know that reading data which is being clocked out of the ADC @6.144Mhz is doable. I think if you search for Beau's SPI engine you may find he's done even better than that.
As for the multiply, have a look at Ale's comment in this thread:
http://forums.parallax.com/showthread.php?p=803129
Having said all this in favor of the prop, I'd like to know the results of a prop to AVR32 competition.
I needed to do something beyond what I could do with BASCOM and the Atmel so I tried the Propeller.· I really don't like the spin language and in the end, to do what I wanted, I had to use ASM.· Having never written in SPIN or ASM before, it started out with a bad feeling.·
After messing around for a bit I got my ASM code working, well, not only working, but working very good.· I actually like PASM better than SPIN and frankly, I don't think I could do what I am without the Propeller.·
As for winning popularity contests, I suspect that with some good C compilers now being available, more programmers would try the Propeller.· C is certainly very popular as the language of choice for micro programmers.· Myself, I hate C and thought I hated ASM even more, but the Propeller sure changed my mind.
Having given it a whole-hearted try, I must say I will continue to consider the Propeller for any new projects I dream up. I am impressed and certainly am curious about the upcomming Prop2 that keeps getting hinted at in this forum.·
Chris
I have successfully done a couple of propeller test projects, like a·scrolling 16 x 32 led matrix http://forums.parallax.com/showthread.php?p=725126) and some video projects, but it seems I either can't wrap my mindset over the prop ideology or it just doesn't work for me.· Fwiw, I've been working with micros since 6502/z80 days, so I feel I have a good understanding of what is going on, it's more a matter of determining the benefits.
I am typically an AVR guy on a day to day basis, but I like to experiement with other platforms like the propeller (also doing some ARM7 stuff now).
It seems to me that the Propeller tries to be too much and suffers as a consequence.· One the one hand, it appears to target the beginner crowd with Spin and the object library; on the other I quickly find that to· accomplish anything of significant performance you must revert back to assembly.· Assembly on it's own is not bad, but it is slower to develop and you lose the rapid development aspect.· Chip's own analogy on why the Propeller works equally applies here:
"Imagine a program written entirely in assembly language. It takes a long time to write, but it is fast, compact, and reliable by virtue of its directness. Now imagine a program written in some high-level language which leverages objects acquired from elsewhere. It is relatively easy to write, but compiles into something big and slow, and may have some undesirable characteristics that are out of your control."
Now to me, something like C is typically a great compromise because you get an easier development compared to asm yet most of it's speed.· But if you go with C on the Propeller you loose the object library, which in reality are your 'hardware features' like I2C you'd get with other chips by default, and you'd have to write and test code for all of those things.· And on ICC C at least, you loose a cog for the kernel and incur LMM speed penalties.
The parallel processing idea is initially intriguing, but my take is that you often end up using cogs to replicate features that other chips offer in hardware, so it's kind of a wash.· And if you program in Spin then you end up dedicating 1 copg as the interpetor.· While there may be limited applications that could truly benefit from the parallel processing aspect, I would think that you could implement traditional interrupt code to accomplish.· I guess the argument is that the Propeller makes this easier to deal with, but if you end up having to code in asm then I think you loose the 'easy' benefit.
I've only used the Demo Board, but unless I'm mistaken any Propeller project is a 2 chip minimum because you need to store the firmware in an external eeprom.· This seems to be a rather curious requirement, one that I would expect complicates project designs for beginners and adds unneeded complexity to more simple projects.··While I understand that the 3.3V design is probably due to clock speed and/or power consumption, I think this also makes it a bit more complicated for beginners or for otherwise 'simple' designs where you'd look to a small microcontroller.
For more advanced projects, it seems the small 32K memory space is a serious limitation.· I think the 20/160 speed advertising is a bit confusing, because you won't nearly approach that with Spin, which is estimated to be 40x - 100x slower than pasm, and it will also suffer if you need the LMM pragma (pasm being limited to 496 instructions).· The lack of true debugging like JTAG seems a serious blow to 'true' professional applications.
For what it's worth, I'm not anti-Propeller, I'm just having a difficult time appreciating how the Propeller would replace any of the existing chip architectures from a generic project pov.· Certainly the Propeller does have some niche benefits - like it's video capabilties - but other than that I'm unsure it will really take off.·· If I had to infer, I'd guess Parallax doesn't think the Prop is doing as well as they hoped and it also appears the Imagecraft folks are seeing lackluster interest.
I'm open to comments; if I am really overlooking something that I could help get my mindset around why I'd want to really use this I'm all ears.
Post Edited (Agent420) : 8/11/2009 2:13:57 PM GMT
The Propeller is, at its heart, a microcontroller and it's deliberately designed for flexibility. That may not be what you want for your project, but that's what it's designed for. Other choices that were made when the design was begun include the manufacturing process involved and approximate chip size. The process determines what's possible to be included in the device, like no EEPROM. It also determines things like minimum power consumption and operating voltage. The chip size determines what's available for the tradeoffs of memory size vs. number of cogs vs. complexity of the cogs, etc.
You mention the lack of JTAG as a serious blow. Unless you've already allocated all the cogs and all the I/O pins to other functions, it only takes one cog and one I/O pin (for black and white) to add a video display for debug output. There are now several debuggers that use a PC for control and display including Hanno's ViewPort.
Yes, the 32K memory size is a limitation for some projects. It's a major portion of the chip area and, to increase it to the next level (64K) would roughly double the already large chip area. The Prop II design, by going to a different manufacturing process, quadruples that, but requires two supply voltages and a much higher quiescent supply current.
Yes, the Propeller requires an external EEPROM for most uses. That's a result of the manufacturing process chosen which does not allow for the special oxide layer needed or the additional "high voltage" needed for programming. Obviously, other chip processor manufacturers can combine flash memory with SRAM and processors. I don't know what intellectual property issues come into play or other costs or tradeoffs would be involved to use a process that allows for the combination, but EEPROM is pretty cheap now and the board area involved is small. You can also use a larger EEPROM and use the extra memory for data storage or use FRAM for faster and more frequent updating, etc.
Anyway, the Propeller is not made to be all things for all people. If it's a bad fit for what you need to do, by all means use something else that's a better fit. The Propeller happens to be a very reliable, straightforward, reasonably fast and powerful microcontroller that's very very flexible. It will be around for a long time and well supported.
http://www.parallax.com/Store/Microcontrollers/PropellerChips/tabid/142/CategoryID/18/List/0/SortField/0/Level/a/ProductID/332/Default.aspx
Just an observation.
of the wind from UPENE this year, we are nearing a hundred signups.
I'd say the Propeller is continuing to ramp up...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I understand that debugging can be accomplished to a degree by deligating a cog to the task and in combination with Hanno's Viewport, which I have been experimenting with.· But if I understand correctly, you can't trace the execution of multiple cogs simultaneously, so if you have an application where cogs interact or otherwise depend on each other it can get complicated.· You also seem to have to reconfigure the code knowing in advance which variables you want to monitor, rather than being able to view them as desired as many other debuggers allow.· Hopefully a software Propeller simulator will become available so you could test code offline.
As an aside, my JTAG comment was more directed towards commercial application of the Propeller...
edit -
While the deligation of a cog to the debugger is not in itself a bad thing, aren't you also losing a cog if your code is spin based?· So then you're down to 6 cogs.
Post Edited (Agent420) : 8/11/2009 3:35:16 PM GMT
There are already propeller simulators available and have been for a number of years now.
People manage to produce fantastic, amazing code without the use of a debugger. It's incredible what you can learn about an architecture while you are trying to figure out why your code is running into the weeds.
I don't see how you are "losing a cog" if you are running SPIN. SPIN/PASM/C/BF.. it matters not, you still need a cog to run the code.
Yes, you give up an extra cog if you need a dedicated debugger, but then you can just toggle a pin and monitor that with a LED or a CRO and not lose the extra cog. Debuggers are highly overrated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I also usually work with ARM and AVR chips and program them using C.
I'm finding the propeller is great to add to an ARM/AVR project for it's video hardware.
The prop is cheap enough and small enough that it's a no-brainer adding it to simplify some tasks
that are hard to do using ARM/AVR. Even after adding in the xtal and eeprom parts you are way below 10 dollars
when parts are bought in quantity. I'm working on a project now where adding the prop has let me change from
a more expensive ARM to a cheap AVR because the prop handles the few things we needed the ARM for... total cost
of the hardware has dropped several dollars and programming has been greatly simplified for all concerned as
I have programmed the prop to act as a black box the other coders just have to send commands to.
Saving and making money is the most important thing around here.....I save programmer hours and hardware parts cost
by using the prop.
·
You keep talking about losing a cog....well, there are 8 of them.....which is 7 more than all other microcontrollers!
What you are saying is that the propeller is bad because to do anything with it you need a a few cogs.....well
other microcontrollers do not have any cogs and to do anything with them you have jump though hoops to get
the illusion of parallel processing.....the propeller does real parallel processing and that is what the cogs are for
and there are 8 of them and thus you do not lose one when you use it....you are using it.....and there are
others for use to achieve real parallel processing.
The propeller does not try to do too much......it is the people that use the propeller that try to do things with it that seem to be too
much to some people. That is only because the propeller is able to do so much more than people are used to do with other microcontrollers.
·
The performance does not suffer at all.....the combination of PASM objects with SPIN wrappers makes the propeller able to achieve
amazing performance with the ease of programming for a novice.
·
Actually most microcontrollers have to be programmed with ASM to get them to do anything useful. And the novice is excluded from
the ability to do that since there is no other solution except to program with ASM. But with the propeller Spin and PASM objects
even the novice can achieve performance that approaches the fastest of controllers out there.
·
The propeller is an amazing chip and Spin is a delight. Even if you lose some speed with PASM you are still able to achieve
with it more than you can achieve with many other microcontrollers and with the REAL PARALLEL processing ability you can
do things that are not possible with other microcontrollers.
·
How many controllers you know can have the ability to support a PS2 keyboard and·mouse with a ·2 joysticks and TV output as well as VGA
as well as Stereo Sound output and sound input and graphics engine and Serial I/O and and still have enough processing
power and I/O pins to do control of devices and and and .....?????? and ALL ON ONE CHIP.
·
But above all.....I think you are just not appreciating the Parallel Processing aspect of the propeller. It is by far the
biggest advantage it has over any controller out there.....if you just understand what that means you will not
be able but to LOVE the propeller.
·
Also having an external EEPROM is actually an advantage in many ways.....you can replace it when it goes faulty... you can
make it bigger if you need instead of being stuck with the fixed on board limitation.....
·
Imagine that you have a product that needs upgrading....by just replacing the EEPROM (cheap and small) you can upgrade
the device....instead of replacing the expensive Controller....especially if the controller is soldered on the PCB.
·
Regards
Samuel
·
@HollyMinkowski:
Yes, that is how I am viewing the Propeller right now.· Without a doubt the video capabilities intrigue me the most.·· There are also occasional time where parallel processing would be better than what I could accomplish with a conventional interrupt.· So right now I consider the Prop more a specialized feature chip with general controller abilities than the other way around;· I think I would tend to pair a Prop with an avr or similar as well.
·
Debuggers are not highly overrated.....people who can program do not need them....but people who
cannot really program need them .....so to enable amateurs to appear to be programmers, they are
needed....therefore there is a use for them.
Sam
But reflecting on it I thought "Why not just use another Prop instead." Save myself all the hassle of having two different developments environments, downloaders etc etc. Bear in mind I do all my development in Linux. Using an AVR does not seem to be worth it. Apparently others came to the same conclusion, hence the TriBlade Prop an Morpheous etc.
If I was going to build a small board with Prop plus another CPU the other would have to be something big enough to run Linux (which can be pretty small now a days) for all that serious OS lovelyness, networking, USB hosts etc with the Prop providing the I/O, sound, video, real-time control etc.
By the way, what's the issue with debuggers, over the decades they have not been much use to me, often more causing more confusion than they fix. You can do amazing things with just a LED for output. Even more amazing if you have direct video console output.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I respectfully disagree.· There are excellent free C or shareware Basic compilers for platforms like the AVR, and boards like the Arduino are targeted directly at novice users.· All these offer easy to use compiled libraries that run at high speed.· If anything, I would suggest that it is more a requirement to learn pasm on the Propeller because Spin on it's own is much slower, and if what you need to accomplish has not already been submitted as a pasm object, you would need to code it yourself in order to get the speed benefit; whereas customized C code would be compiled to asm.
I will not deny that the video capabilties of the Prop are unique - but in fairness that is the one hardware feature that is built into the chip.··Other chips offer hardware I2C, SPI, UART etc that seem to typically require a dedicated cog.· I think if we put the video capabilities aside, the playing field is more equalized.
There again, most other controllers offer onboard eeprom of much larger size, and can be reprogrammed in circuit.· So I don't see much benefit there; in fact it complicates simple 1 chip solutions.
I agree with you here... it is this aspect of the Propeller that intrigues me the most, yet I'm not certain how much it really apllies to the vast majority of projects that I do, and I'd have to think that most hobbiests may not actually require parallel processing either.· I'm really on the fence on this one.· Is it easier to set up a new cog vs an interrupt?· Perhaps.· Does that ability outweigh the potential code size limitations or spin execution speed?· Might depend.
I've got some free time now which is why I'm back looking at the Prop... perhaps it will come to me ;-)· I mean, I did buy the demo board, so it's not like I'm just here to knock it around [noparse]:)[/noparse]
Post Edited (Agent420) : 8/11/2009 8:01:32 PM GMT
If you want to run PASM on all cogs, you can. Linus Akesson did this with his LFT demo.
If you want to run a SPIN interpreter (default), it takes a COG. If you want to run C LMM interpreter like ImageCraft C, it takes a COG.
If you want a debugger, one way or another you have to use a COG unless there is room in the "interpreter" COG.
There is no way to debug "any given COG" on demand ... yet
Yes, there are challenges with Propeller. There were also challenges in writing programs on punch cards (not exactly the same).
With challenge comes opportunity to eliminate the challenges. I think it all depends on what you want.
For a user application mind-set, Propeller is fine if you want to do relatively small but timing critical projects.
If one needs bigger and more efficient operating code space, other controllers or general CPU may be more appropriate.
It seems the Propeller fits somewhere between the 6-pin atTiny and the atMega328 for code space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
This is nothing Prop-war-like, it's just picking the right tool (µC) for a job given.
Things would change quite a bit if Props would exist in different packages with a different number of IOs, with built-in ADCs/DACs and internal EEPROM or more RAM and such. Some things will never happen, so you might be better served with alternatives.
These last points are the keystone for Parallax to enter the industrial high volume-market. In industry, you reduce costs by reducing footprint, chip-price, and having as much as possible integrated into the chips. An external ADC is a no-go. Just look at the incredible selection of PICs. There is certainly one that fits (as long as a Prop isn't better suited for the task). It simply costs too much. In low-volume, things are quite different.
Not saying, that PIC or Atmel or $whatever is better, they are *different*.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
To clarify the Spin interpreter, which is the default configuration... that does require a dedicated cog?· So a Spin based app really leaves 7 cogs free for user code?
Yes, clearly by default, there are only 7 COGS left for the user. Spin is a bytecode language like Java for example that needs a VM.
The interpreter lives in ROM, but runs in a COG. You can however restart the SPIN COG to run any other VM as I implied.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Right!
You might also say, its a waste of resources.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
You might understand my desire for a proper debugger ;-)
SPIN is an interpreter yes. You write a single threaded program in SPIN, the interpreter runs in a COG and in turn "runs" (interprets) your program. One program, one thread, one COG. There is no COG "wasted" you want to run your program after all. No different than using BASIC or Forth or C or ASM.
If you write a program with n parallel threads in SPIN you will be running n interpreters in n COGs. There is no wastage.
If you write a program in PASM that runs in a COG and has some SPIN access methods included in its object, say a serial port driver. Then those access routines are run by the calling application when called and run in the callers "thread". There is no wasted COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll have to look into the simulators that are available... technically I tend to do much of my debugging offline in the software realm.
As for the spin interpreter cog, I thought the documentation was a bit vague but what you say makes sense.· I did note that the Imagecraft C compiler does dedicate a cog however.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now what can the prop do? With 1 x 64KB-512KB SRAM, 1 x eeprom, 1 prop, 1 microSD and a serial port (plus xtal, resistors and capacitors and power supply/battery you can run CPM2.2 under emulation at about a 4MHz Z80. With a second prop connected to the serial port, you can have keyboard, mouse, VGA, TV stereo, and still some pins for other goodies. Now how many other microcontrollers can do that for $8 each? And only 1 device to stock! Every time you want to design a pic or avr, you have to decide what hardware goodies you want inside (I2C, SPI, etc) and then you choose a new device. No common pcbs here!
But, if you have a simple design, sure a $2 pic or avr might do the job.
I am planning to use a pic10F2xx for <50cents to convert a PS2 Keyboard/Mouse to 1 pin serial. It is in tiny a sot23 6pin package. As they say, horses for courses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, 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 (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Subjectively: The problem with the Gear simulator is that it starts stepping in spin byte-codes ... almost impossible to understand without a listing. ViewPort lets you step through Spin, etc... the problem with that is the debugger is an afterthought addition which is frustrating to me at least.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Never mind, I'm sure we all get how it goes now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230