PDA

View Full Version : Comparing Propeller with other Microcontrollers



william chan
01-08-2009, 09:02 PM
I hope this is allowed and viewed with an open mind.

1. How many microcontrollers can change clocking speed during runtime like the propeller can?
2. How many single chip microcontrollers has a built in high level language interpreter like spin?
3. How many microcontrollers consumes less current than the propeller per mips?
4. At 20Khz clock, how does the current consumption of the Prop compare with other microcontrollers? ( when only one cog is used )
5. How does Propeller's selling price compare with other 32bit microcontrollers with about the same processing power? (MIPS)
6. How does the Propeller's selling price compare with other multi-core microcontrollers? ( similar quantity breaks )

I think if more competitive advantages of the Propeller are known, the more people will use it in their products.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Leon
01-08-2009, 09:09 PM
The four-core XMOS chip has 10 times the performance (1600 MIPS), 64k per core and eight times as many I/Os (256), but only costs $33! It does use a lot more power, of course. It also has very efficient XC and C compilers and excellent real-time debugging.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/8/2009 2:17:07 PM GMT

simonl
01-09-2009, 12:58 AM
Hmmm, at $13 I'm not sure I've seen ANY other uC that comes close to the Propeller in terms of simplicity of use, and few others that I'd consider hobbyist friendly.

Sure there are the PICs; AVRs; and Arduinos, but then you have to mess around with all that <ehem> interrupt stuff http://forums.parallax.com/images/smilies/freaked.gif

Like Leon, I'm intrigued by the XMOS chip, but @ $33 it's not really accessible to the hobbyist - as it's a BGA chip. If you want an XMOS to do hobby stuff with, you'll need their XC-1 Dev Kit, and that's closer $99!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
-------------------------------

www.norfolkhelicopterclub.com (http://www.norfolkhelicopterclub.com)

You'll always have as many take-offs as landings, the trick is to be sure you can take-off again http://forums.parallax.com/images/smilies/wink.gif
BTW: I type as I'm thinking, so please don't take any offence at my writing style http://forums.parallax.com/images/smilies/smile.gif

waltc
01-09-2009, 01:31 AM
Interrupts aren't black magic nor impossible for mere mortals to understand. If you can write a video driver or writing assembly code on a regular basis you're more than capable of understanding interrupts.

And for simple applications you don't have to use interrupts at all or can get by with a round robin scheduler. Mandatory they are not.

RiJoRi
01-09-2009, 01:41 AM
2. How many single chip microcontrollers has a built in high level language interpreter like spin?

I know of two with built-in HLLs. Neither are made any longer, AFAIK. There was a FORTH* chip (R2500???) with built in FORTH, and Nat Semi made an 8073 with a BASIC interpreter built in.

Oh, yeah, the 8052-BASIC chip. You can get the interpreter on the 'net, and burn an 8052 with it, but Intel is not producing them any longer, again AFAIK.

But I do not think ANY of them had the ease & functionality of SPIN. http://forums.parallax.com/images/smilies/hop.gif

--Rich
* Please, no discussions on how high-level FORTH is, nor if it's a language! :D

Leon
01-09-2009, 01:45 AM
The Intellasys SEAForth chip has 40 cores each running compiled Forth. They are expensive at over $60 each in small quantities. Package is QFN.

Single-core XMOS chips will be available in QFN.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/8/2009 6:57:18 PM GMT

Paul Baker
01-09-2009, 02:20 AM
Guys don't be suprised if this thread gets moved to the Sandbox, Chris made the warning about a month ago that these conversations belong there, until then carry on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

parts-man73
01-09-2009, 03:01 AM
It confuses me why users of other microcontrollers have such disdain for the Propeller. I mentioned it on another microcontroller forum (which by the way, is not for any specific micro, so it wasn't like I was posting on another company's turf) and I received responses that made it obvious that they didn't want to hear about the Propeller.

I really think that if they got over themselves and tried it, they'd love it. (if they went into it with an open mind)

I do believe there is the right tool for the right job. Just as you wouldn't try to drive a nail with a screwdriver, you don't need a Propeller to drive a HD44780 LCD. I simple $3 PIC will suffice. But the speed in which you can develop a project always impresses me (that coupled with the fact the I have an abundance of Propeller circuit boards around http://forums.parallax.com/images/smilies/smilewinkgrin.gif ) that I use a propeller in most every project nowadays.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian

uController.com (http://uController.com) - home of SpinStudio - the modular Development system for the Propeller

PropNIC (http://uController.com) - Add ethernet ability to your Propeller! PropJoy (http://uController.com) - Plug in a joystick and play some games!

SD card Adapter (http://uController.com) - mass storage for the masses Audio/Video adapter (http://uController.com) add composite video and sound to your Proto Board

Oldbitcollector (Jeff)
01-09-2009, 03:13 AM
I too have experienced the "stigma" but have chalked it up to the old
microcomputer wars of the 80's. Everyone rallied around their personal
computer. (Even if you were a teen and mom and dad made the purchasing decision.)

The computer flame war attitude was about a worthless in the 80's as the
current micro-controller attitude. I'm a fan of the Propeller because of it's
incredible easy-to-use power. I can understand the concept of using the
right tool for the job when in a situation where production is a consideration,
but for hobby use, every micro-controller socket in my projects is Propeller shaped.

It's just not worth tooling up for a $3.00 chip when I'm already tooled up for
a universal $14.00 chip. The savings doesn't add up for something one-off.

Sandbox in 3.. 2.. 1..

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

potatohead
01-09-2009, 03:31 AM
Folks, we have ignition!

Re: Scheduler / Interrupts

I really like not having to think about both. The trade off is thinking through how to use the COGs together. No free lunch there, of course. Still, when it's easy, it's really, really easy on the Prop, so it's a net gain from where I stand.

Agreed with OBC. It looks an awful lot like the 80's, from that perspective doesn't it? This stuff is like religion, in that regard. More fun to be agnostic, IMHO.

Intertia is a powerful thing. Lots of tool chains in place, skill sets well tuned, etc...

The only thing to be done is to just be good ambassadors for the Prop. Having a lot of fun sure does pack a punch! In the end, that's what gets it all done, where mind share is concerned. And like I posed in the other thread: If the activity level sustains Parallax, does it matter?

I really don't think it does for quite some time. So, I just look at that and mostly ignore it.

Also IMHO, a big part of the stigma (which I've run into very little actually) lies in newbies. Everybody wants theirs to endure, mostly because they know the scene and change is hard. When new people enter in, they make learning / job choices. The more of these we get, the better the prop community is as a whole. So, it's in the interests of some where perhaps it's a big tougher to cultivate the "having fun" factor, to marginalize that.

Again, it just won't matter, as long as the activity that is happening is enough to sustain Parallax.

I like smaller scale computing. Always have. Nothing out there today even came close to getting me hooked. I'm happy for that, am learning a ton. I know I'm not all that far off the mark, so the mission is being accomplished. No worries past that.

...and it's only gonna get better!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Ken Gracey
01-09-2009, 03:43 AM
@Brian: I have an idea about this, too, as a web-trolling forum visitor. I'll hazard a guess why you were not greeted.

Most people relate Parallax to the BASIC Stamp. In the BASIC Stamp's earlier years there were not a whole of alternatives - mainly only the MELabs PICBASIC compiler was the big competitor. Time passed and lots of alternatives came into existence for hobbyists with BASIC languages (AVRs, Arduinos, etc. the list is long as you know). Hobbyists felt the BASIC Stamp's price of $49+ was too high for what it is - after all, they can now program a $3 chip! They probably didn't need us anymore at this point [unless they wanted to use the SX, or wait around for the Prop). Never mind that the PBASIC interpreter has been rock-solid.

At this point such an educated or skilled customer may not have benefited from what the $49 price tag enabled us to do for our customers. But, this price enabled our company to create a whole program around the BASIC Stamp. In other words, it generates profit that goes straight back into the company in the form of: educational tutorials for Stamps in Class; long-term developments of products like the Propeller; sensor R&D; support staff to answer questions; staff who can layout chipd, PCBs, advertising, etc. This is all perfect stuff for the getting-started customer.

As we excelled in getting newbies started we also eventually lost a few customers to more appropriate solutions for their production projects. The educators had many reasons to stay with us, and many hobbyists did as well.

So, if they expressed problems with Parallax, it's probably because they associated us only with the BASIC Stamp and they no longer felt a benefit from paying $49 for a BS2-IC. Whenever somebody moves from the BASIC Stamp to a single chip they always find the BASIC Stamp over-priced. Sometimes this feeling manifests itself in negativity towards our new products, even though no time was taken to review them. The educational tutorials, support and related benefits were of less use to post-BASIC Stamp customer as they derived less benefit from such support.

This will change as Parallax becomes more well-known for the Propeller, and appreciated for designing our own microcontrollers. People will become more open as time passes.

Ken Gracey
Parallax, Inc.

Ken Gracey
01-09-2009, 03:53 AM
Regarding "inertia" and sustainability. . . Parallax's products shall endure for the long term. You won't be getting any "End of Life" notices about the P8X32 processors, I assure you. We have 21 years of business behind us and many more ahead of us, and there's no difference between the relationship we have with the customer today vs. 21 years ago. You still rule the roost in this company and will do so in the future. Profit is not our motivating factor. Designing interesting products, supporting our customers, and offering a solid work environment for our team is more important.

Sounds like a bunch of corporate rah-rah perhaps, but that's the mode in which we operate.

Ken Gracey
Parallax, Inc.

Jetfire
01-09-2009, 04:27 AM
But why does the BS2 still cost $50?

The propeller is great for having a wide range of capabilities and making it easy to use.

How many micros make it easy to blink an LED or drive 4 TVs at the same time?

mirror
01-09-2009, 04:28 AM
I see the Propeller as having two features which are almost uniquely distinct from any other micro processor:
1) Determinism : Code that's written into a COG will always run with the same level of performance. Imagine a VGA or serial driver COG that got interrupted - it would then either output an involuntary "blanking pulse" or "stretched bit" as a result. This doesn't happen in the Propeller!
2) Orthogonality : Any COG can drive any pin with any of the functional features within the chip. Period! No special cases!

To answer some of William's questions.
1) Lots of processors can change clock speed. I do it with a PIC for power saving.
2) GNU C compilers (free) are available for lots of micros.
3) I haven't investigated power consumption, but as it is such a widely introduced claim I'm sure there would be multiple contenders.
4) I was switching the aforementioned PIC between 4MHZ and 32kHz operation - the application ran for more that a year on a CR2032 battery.
5) ARM processors are cheap (with lots of performance) - but not available as DIP.
6) I don't know the answer, but I don't think it's interesting in any case.

The Propeller is a great "general" solution to lot's of problems, and represents an excellent starting point. If you start to push hard in a specific areas of performance, then it start to look increasingly incapable. This needs examples:
1) Propeller does VGA / TV output, but if you wanted 1280x1024 by 32 bit colour with 3D graphis you'd go somewhere else.
2) Propeller talks to SD cards, but if you want 4 bit interfacing at the speed limit of the currently avialble cards you'd look at a chip with a dedicated SD driver hardware.
3) Hanno does video scanning, but nobody on this forum considers the Propeller to be a serious contender for video scanning. Maybe as the background controller with programmable logic doing the heavy lifting.
4) Bean does video overlay, but once again something that would be unlikely to be used in broadcast qaulity video applications.
5) If you need more RAM... It's just not pretty on the Propeller.
6) High speed USB2 or 100M ethernet...

I have always find that choosing the right processor for a job is a long and arduous task. Many hours of reading the data sheets, trying to find the right match for a particular task.

Oh, did I mention how much I hate reading through data sheets. Especially those pages that describe how all the various pins are multiplexed between functions (I can spend a day on that page alone!!!).

One thing I really, really, really like about the P8X32A is that there are only three choices: DIP, QFP and QFN!!! And I am NOT talking about packaging - as most other chips have a range of peripheral variations just to make life even harder!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Harley
01-09-2009, 05:30 AM
RiJoRi said...

I know of two with built-in HLLs. Neither are made any longer, AFAIK. There was a FORTH* chip (R2500???) with built in FORTH, and Nat Semi made an 8073 with a BASIC interpreter built in.



I'd not heard much of the 8073 for years. Back in the late '90s I had no development system for the chip so wrote my own assembler in FutureBASIC (ran on a Mac). Such fun; but way too many iterations to finish the project for my own use.

But with the Prop dev system, one can get to using the Prop almost 'immediately'. Working with the Prop is really much more fun and productive. But in its time, the 8073 was a novel IC.
http://forums.parallax.com/images/smilies/yeah.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

hal2000
01-09-2009, 05:37 AM
I understand the XC-1 is more complicated
Propeller always works in 32 bit
Displaying the XC-1·asembler you realize that XC-1 no, some things just 16bit
XC-1 is more powerful, that is true
But it is more complicated 16 add 32 mov ...........· ufffhttp://forums.parallax.com/images/smilies/confused.gif
I think we have to make soon parallax Propeller II
I think that propeller is a good idea
But it's bad that late in leaving Propeller II


Sorry for my bad English

Greetings

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Does the curiosity killed the cat?

Envio editado por (hal2000) : 1/8/2009 10:56:38 PM GMT

Ken Gracey
01-09-2009, 06:12 AM
@jetfire: because our customers pay it and it supplements the ability for re-investment in Parallax (we created the Propeller without external assistance). Customers who buy BASIC Stamps do so for a variety of reasons related to support hardware, tutorials, code examples, quick development, etc. and they find it a reasonable value.

Ken Gracey

SRLM
01-09-2009, 07:12 AM
I bought the BS2 way back when because at the store that I went to (Fry's) they had the WAMC kit, and it did all sorts of interesting things and (this is the most important part) it came with two books that appeared very friendly to my eyes. If those books weren't there, then I would not have bought the kit. I still wouldn't have bought it if it was $50, instead of $150, since what I really wanted was to be able to understand the material. So, I'm glad that I payed for the chance to get the knowledge, and the hardware to help me express that knowledge.

Kye
01-09-2009, 07:16 AM
Look, for all the awsome-sauce-ness the propeller chip has there is one feature that makes it really good.

8 PROCESSORS

How wonderful is it to simply program your serial, mouse, keyboard, video, and·audio drivers all independently and not need to worry about how much time each one takes up.

And then, once you have you're foundation setup you can·do higher level stuff, like building an operating system, without needing to worry about timing·problems.

When the propeller two comes out, there will be no argument. 16 cores... you just can't say no.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Luis Digital
01-09-2009, 07:54 AM
Kye said...
When the propeller two comes out, there will be no argument. 16 cores... you just can't say no.


16 cores???

I think that Chip should clarify all the capacities of the new Propeller II.

Ken Gracey
01-09-2009, 08:07 AM
@Luis. No, he shouldn't. Such a statement of features only gets us in trouble: people "wait" for the next Propeller; if it changes from his description it does/doesn't meet expectations; and it creates upset customers because these things take a long time and people expect them to be done really quickly.

Ken Gracey

Whit
01-09-2009, 08:11 AM
Ken Gracey (Parallax) said...
Regarding "inertia" and sustainability. . . Parallax's products shall endure for the long term. You won't be getting any "End of Life" notices about the P8X32 processors, I assure you. We have 21 years of business behind us and many more ahead of us, and there's no difference between the relationship we have with the customer today vs. 21 years ago. You still rule the roost in this company and will do so in the future. Profit is not our motivating factor. Designing interesting products, supporting our customers, and offering a solid work environment for our team is more important.

Sounds like a bunch of corporate rah-rah perhaps, but that's the mode in which we operate.

Ken Gracey
Parallax, Inc.
Ken,

It may be corporate rah-rah, but in my experience· - it is all true!


hal2000,

Your Avatar says it all...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+


"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney

Kye
01-09-2009, 08:51 AM
To clarify my statement, read the 700+ tread about the propeller 2. There are "details" but not details...

Its the one were Chip asks about what you guys want, and don't revive it for godsake....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 1/9/2009 7:15:04 PM GMT

potatohead
01-09-2009, 11:44 AM
Nothing wrong with getting the word out, from time to time, Ken.

A whole lot of companies just can't say that. Good differentiator.

Those are nice to have right now.

@Kye, nice job on your driver set. I think you will prove spot on with Prop II, minor details aside.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Ale
01-09-2009, 01:36 PM
@Hal2000: The XS-1 is a 32 bit uC (each core) that the instruction word is either 16 or 32 bits has nothing to do with what difines a processor as 8, 16 or 32 bits (normally it would be the path in and out of the ALU). Have a look at the instruction description (xs1inst87.pdf) and see it for yourself. Most instructions take 4 clocks so 4 threads are interleaved, or it cab be 8.

The Basic stamp may seem expensive, but also allows many people with not so many programming/electronics skills to develop easily and fast many different applications (controllers, temp regulators, and things like that). See it as a fast time-to-market or time-to-done, where 50 bucks is offset by the many hours saved, even for people with greater skills. You put it connect it to sensors/peripherals and done, not a bad deal.

The prop is something different, different concepts, I'm really amazed at what can be done, and how easily you get it done, the price does not seem that steep then: faster time-to-done.

Post Edited (Ale) : 1/9/2009 8:06:14 AM GMT

hal2000
01-09-2009, 06:07 PM
Ale, I do think
I think not understand English well, anything a bit difficult
is very difficult for me

So I think it is easy for all propeller
XS-1 at the moment is valuable for me (I do not understand the mix of 16bit and 32 bit asembler "

Parallax has to make a collection in the forums to get money for propeller II


I hope to be understood.


Whit you're right, I had an accident with a propeller, and this is the result

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Does the curiosity killed the cat?

Leon
01-09-2009, 06:28 PM
If you have questions about the XS-1 you should use the XLInkers forum.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

soshimo
01-10-2009, 01:49 AM
Just to reinforce what Ken said. I remember about 6 or 7 years ago I was doing some basic stamp stuff, just playing around mostly. I had my favorite electronics supply store I would visit weekly to discuss everything BS related. I remember one day there was a distinctive shift in attitude away from the basic stamp and towards the oopic (mainly, probably due to the price). I decided, wtf, if I'm going pic I'll just go all the way and migrated away from basic stamp for a bit after that (not to mention Microchip used to have a very generous sample program which as since been scaled way back). For the DIY hobbyist with limited budget (or cheap like me) it was attractive that I could drop a regulator, a chip, a crystal, and a few discretes and have myself a dev environment - total cost less than 5 bucks probably.

Also, I'd like to address the issue of interrupts not being deterministic. I'd like to submit to you the 8088 which was completely interrupt driven. At 4.77Mhz it didn't have trouble being deterministic. Now, if you wrote a crappy IRQ driver, yeah, you could crash the system (just like if you write a crappy hardware driver today), but that was all about software and had nothing to do with the inherit limits of the hardware (though it was fun to tweak the timer tick driver and make your floppy drive squeal http://forums.parallax.com/images/smilies/devil.gif)

That being said, I'm still a Propeller fan, just wanted to point out that interrupt driven computing has been around for a very long time, in fact I am are using an interrupt driven microprocessor as I write this (my fingers hitting the keys are causing hardware interrupts).

Phil Pilgrim (PhiPi)
01-10-2009, 02:10 AM
The only reason interrupts were invented in the first place was to accommodate asynchronous events with a single-threaded processor. Fortunately, the Propeller doesn't have that limitation and, thus, does not need interrupts. To want them for the Propeller is rather like someone with two healthy legs yearning for crutches.

-Phil

Baggers
01-10-2009, 02:12 AM
soshimo, surely by typing and causing hardware interrupts, you're affecting the deterministic timing as the processor has to be interrupted to handle the keyboard, unless it has external processor, which is polled by the main processor, ( which is in effect what the prop does ) hence keeping the processing in a deterministic state, ie say your processor was also creating a VGA or Composite display, PAL for example, hitting the keys would affect the timing in the display, which could in effect cause a loss of sync.
which I think is the point that mirror was trying to make about interrupts, they cause ( as their title implies ) interruptions to the flow of the program.
the 8088, was not creating the display, yes you can use interrupts to write keyboard/mouse drivers etc, but you start doing things like doing a display driver, that HAS to have the highest interrupt priority, as anything that stops that breaks the display, whereas the prop can do it because you know the timing won't be affected by anything, other than how it's coded. ( OK, or maybe a loss of power, or crystal failing to pulse lol. )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

jazzed
01-10-2009, 02:49 AM
Always a wonderful and lively topic :)

The other reason interrupts were invented which is very rarely mentioned here is to allow a timer process to fire from a deterministic separate hardware source for waking up kernel scheduling and tasking in a determinate manner.

Of course the analog of that second piece of hardware in propeller is a separate "background" cog, and thus it is not necessary for an external single hardware interrupt to actually happen because you can use a soft-event number or whatever from the "background" cog to control kernel scheduling and tasking.

One argument is that traditional scheduling and tasking is not necessary with propeller because of extra processors. Of course those resources are limited and if you need more processes than cores, then multiple tasks must be performed in cogs which does not necessarily need to be deterministic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

heater
01-10-2009, 03:25 AM
Having multiple processors has one very great advantage over interrupts in the ease of development.

On a single CPU + interrupts system whenever I want to add a new hardware device driver to my project I have to integrate it's interrupt handling with with whatever I've got running already. I have to figure out how to hook into some new priority level or chain onto a level that is already in use. I have to figure out what priority every new part should run at and if it will disturb something else. If I already have something like a video driver than needs deterministic timing (highest priority maybe) and then I need another device with stringent deterministic requirements then I'm out of luck. Just can't be done. Not to mention having to figure out how to set up some interrupt controller hardware with masks and modes etc etc.

Compare with the Prop where I can just grab a nice object from Obex, or create a new one, throw it at a COG and I'm done !

Of course that is why (partly) real time operating systems were developed. But that is another boatload of complexity to have to learned. Of which there have been many over the years.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99
01-10-2009, 11:01 AM
I beg to differ about the reason why interrupts were invented.

They existed on the first 8008 and 6800 microprocessors (circa 1975). There was no such thing (on micros) as multi-tasking, or even an operating system. The interrupts were used to interface to peripheral chips. Remember, back then, there were no internal periperals. The external peripherals were UARTs (which predated the micros (from about 1972). Motorola and Intel both produced parallel peripheral chips (Motorola PIA). The interrupts were used to identify service to the chip was required. Zilog later (with the Z80) used vectors for interrupts.

Later, board(s) full of chips were made to interface to the micros to do video displays using composite video (monochrome and initially 32x16 and 40x16).

The prop doesn't need interrupts. This takes away it's inherent design objective of not requiring them due to 8 independant cogs. If you want interrupts, use another chip with the complexity it brings. The prop is a simple chip designed for hobbyists that just happens to also have great professional uses (although vastly under-recognised!).

Now try doing VGA on other single chips without dedicated VGA hardware on-chip http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

fixitman
01-10-2009, 11:27 AM
Somebody needs to make a PLC based on this chip. And an eaiser software too. It would make my job easy

jazzed
01-10-2009, 12:53 PM
Cluso99>> I beg to differ about the reason why interrupts were invented.
Ok http://forums.parallax.com/images/smilies/smile.gif
The other reason interrupts "are used" which is very rarely mentioned here ....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Praxis
01-10-2009, 02:16 PM
It's been while since I posted on this forum and this thread really tickles me.

Comparing the prop to other microconrollers - the small memory size of the prop.

When it comes to coding 32K is adequate for a lot of embedded applications however when you have an application that requires embedded bitmaps/wave files etc then 32k is an issue.

Now some of you will respond and say use an object that allows interfacing to an SD card etc but this presents issues with additional parts not to mention there then needs to be a method to load the data into the card etc.

As for interupts, well if the prop had hardware support for serial interfaces, SPI, I2C etc then say no more.

Cheers.


Further reading:
en.wikipedia.org/wiki/Interrupt (http://en.wikipedia.org/wiki/Interrupt)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus

Phil Pilgrim (PhiPi)
01-10-2009, 02:47 PM
Praxis said...
... if the prop had hardware support for serial interfaces, SPI, I2C etc then say no more.

The Propeller does have hardware support for these interfaces, and a lot more. The hardware is a set of configurable peripherals that can be microcoded to emulate a whole host of interfaces and other functions. You see, when I replace "cogs" with "configurable peripherals" and "programmed" with "microcoded", "hardware support" doesn't sound so far-fetched, does it? http://forums.parallax.com/images/smilies/smile.gif

-Phil

potatohead
01-10-2009, 03:00 PM
Sigh...

And that's the sticking point in most comparisons. Determinism gets missed in that code as hardware discussion. It's a very significant differentiator for the Propeller. Once an interface is up and running on a COG, it IS hardware to the other ones.

Edit: In fact, I think discussing the differences would be a very enlightening discussion!

Anyone game?

How is either adding hardware, or custom hardware that resides on chip, different from a COG running dedicated code for that task?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/10/2009 8:07:17 AM GMT

Phil Pilgrim (PhiPi)
01-10-2009, 03:54 PM
Okay, but I'm not sure I can contribute anything more "enlightening" than this: From a behavioral (i.e. black-box or I/O) point of view, they're identical. From a programming standpoint, considering assigned hub memory as the equivalent of peripheral communication registers, they're identical. Heck, the "peripherals" even support DMA. What else matters? To ascribe significance to other structural departures one from the other would be to create a "distinction without a difference".

Um, how's that? Now it's time to for me hit the sack. I'll see where this "stick poked in the wasp's nest" went come morning. http://forums.parallax.com/images/smilies/smile.gif

-Phil

heater
01-10-2009, 05:44 PM
I'm sure interrupts have been around long before the 8080 etc. Why does do so many have a problem with not having them ?

To me a background task and an interrupt handler one CPU is logically equivalent to the task and the handler running on two processors (COGs) with shared RAM. Physically things are different, a lot more silicon, more performance for the background thread, potentially deterministic timing, potentially lower latency for the interrupt handler. All sounds good.

That is up to the point where you run out of COGS and start to think "damn, if I could only hook this new code into an interrupt handling chain and share a COG between tasks" But guess what, by that stage you are probably pushing a little micro controller to far anyway and heading for problems.

To me having a bunch of processors that I can program to behave like peripheral devices is logically equivalent to having one processor surrounded by hardware peripheral devices. Again physically things are different for single chip solutions I have to be careful to select the chip with the devices I want in the latter case and changes in hardware requirements will be harder as development goes on. All sounds good for the former.

That is up until the point that I find the programmable software solution in a COG is just not fast enough e.g. for USB....

Conclusion: Logically old style interrupts and hardware devices is logically equivalent to a pile of programmable COGs and shared RAM. Practically there may be limitations in speed of COGS or number of possible devices(COGs). which may make one long for the traditional approach. But that is a limitation of the available technology and implementation rather than in concept.

In the early 70s Marconi Radar Ltd built it's own mini computer the Locus 16 for use in radar systems. It was almost a micro as it used bit slice chips. Anyway it had interrupts and peripherals but it also had LOCKS (Which did not turn up on micros till the 8086 I think) Why? because it was intended to be used as a multi-processor system with a general purpose CPU card a display processor, shared RAM etc etc. All be it in a rack full of cards rather than on a single chip. Looking at a top level architecture of a Locus 16 system you would see something rather like a Prop. This was not uncommon in those times.

See here for nice Lous16 system diagram www.radartutorial.eu/19.kartei/karte112.en.html (http://www.radartutorial.eu/19.kartei/karte112.en.html)

This software driven approach is an ever growing trend as silicon gets smaller and cheaper. See the latest graphics cards or the XMOS chip. The Propeller just happens to be a small example of this.

Why do my posts always get so looooong... ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon
01-10-2009, 07:13 PM
When I worked for English-Electric-Leo-Marconi Computers in the 1960s, we manufactured a mainframe computer with an optional seven levels of interrupt.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Cluso99
01-10-2009, 07:42 PM
In the 70's I worked on an ICL (formerly Singer and Friden) mini-computer. It survived to the 90's. It had no interrupts as such. I/O (terminal, disk and tape) were just reads and writes which waited for a response. It had hardware multi-tasking (like 20 cogs with their own cog memory) and hub memory. There were software locks in the operating system. In many respects, it reminds me of the prop.

@Phil: I agree, the Prop has a multipurpose cogs to implement peripheral hardware.

Interrupts just complicate the software in my opinion.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Leon
01-10-2009, 08:16 PM
I used to know someone who programmed Singer minis. I remember him telling me that they used a pre-processor written in SNOBOL with the assembler.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/10/2009 1:22:55 PM GMT

Erik Friesen
01-10-2009, 09:29 PM
I think part of the reason the prop shines is that you don't have to spend half the time getting your header files straight and in proper sequence, and followed by getting the right include paths set and other annoying details.

The sad thing is that for low-lowmid complexity projects a pic24 can do a lot of what the prop can. MIPS is not a fair comparison in a way as when you can offload CRC,USB,I2C, and other peripherals that is really the same as having another cog, it seems to me. Plus the ability to program all these details in a high level language is an advantage.

One thing that is clear to me though is that most of the projects I have done vastly under utilize the props capabilities.

Cluso99
01-10-2009, 09:35 PM
@Leon: Most coding was done in assembler - 16 x 60bit risc instructions, dual instruction, all decimal (including memory), no registers (except 3 index registers). eg MULT 10 decimal (digits) by 10 decimal gives 20 decimal result. Cobol was possible but rarely used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Leon
01-10-2009, 10:10 PM
It was SNOBOL, the string-processing language, not COBOL. I was told that the SNOBOL pre-processor was needed because of the complexity of the 60-bit instructions, to make things easier for the programmer

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

jazzed
01-10-2009, 10:50 PM
Maybe someone should write an "interrupt" object to put in the obex to satisfy newbies. It might not be appreciated as it is "not as expected", but would at least show how to do it. We were all newbies once who didn't exactly get it.

@phil, I understand what you mean by DMA in prop-sense, but DMA has generally been a hardware assistant. High performance peripherals are just not possible without hardware DMA. A more fitting term would be soft-DMA since it is a software thing in prop.

@Cluso99 I wrote software for Singer Link Flight Simulation in the 80's - many fond memories. In school in the 70's I wrote progams on punch cards; the advance to paper-tape was very welcome :) The early "personal computer" C=, etc... cassette-tape and floppy drives were just wonderful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Cluso99
01-10-2009, 11:24 PM
@Leon: Think we are referring to different machines. The 60bit instruction was 10 x 6bit ASCII characters and most of us engineers and programmers could write object code from our head as the instruction set was so regular.

@Jazzed: A friend used to repair the Qantas Link Simulators in the late 70's. I hardly used punched cards or paper-tape. Went straight to (hard) disk in 1974.

Anyway, back to the Interrupt topic (and DMA). Until you have experienced the prop you do not realise how simple it is without the interrupts.

See my thread "What are your cogs doing now?". There doesn't seem to be anyone requiring interrupts there yet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

potatohead
01-11-2009, 01:21 AM
@Phil, that's where I was going. I really can't see any significant difference.

@soshimo, isn't that just latched instead of deterministic? In that model, the single CPU has a speed that exceeds that necessary to address the events in a timely manner. It's gonna spend some time on idle. Has to, otherwise things break down. Time assurances come in the form of minimum latency. That's true of the Propeller too, of course.

However, on a non-multiprocessor system, it's not really possible to write a series of instructions (in general) and count on their execution time being constant. Something's gonna happen. It's going to happen because the interrupts are there. And there is one CPU essentially. It's also highly likely to have caching and such, further impacting the time to execute.

A kernel is needed to manage everything. It is necessary because the system isn't deterministic. Where there is trouble, you add clock speed and power, or some dedicated bit of silicon and power comes with that too and move on.

Multi-core systems help with this, but still, it's essentially one CPU, and those cores conflict with memory / bus access. The dynamics are the same.

To me, this all boils down to that kernel being there and systems level programming often being necessary to write it, or manage somebody else's kernel, or work within the limits of it, if that kind of programming is to be avoided. One CPU, where there are a balance of tasks is why we have operating systems, kernels and such. Have to.

On Propeller, that kernel isn't necessary for a very large number of tasks. Scale and complexity can require it, and if that's the case, one can be written, and that's that. Factoring that extreme out however, leaves us with a machine that simply does not have ONE CPU. It is, in fact a multi-processor, and there is no bus / memory contention! Code complexity will absolutely go down. To a Propeller user, those tasks are overhead where attention is required to manage the solution itself, not address the problem at hand.

I think the significance of this goes under rated a very high percentage of the time in these discussions.

The trade off (and there always is one) is often having to factor your compute problem differently. IMHO, it is this re-factoring that is foreign to people, and thus the source of contention, not core functionality differences. There is a case that this is a wash, given the task of also having to select and learn about add on silicon solutions. That and cost are kind of expensive compared to a measure of grey matter time one would normally spend on a Propeller to accomplish the same thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

RinksCustoms
01-11-2009, 01:50 AM
I know it's not a uController but the new Intel i7 core processor still cannot hold a candle to the prop I in the respect that it is still basically a single core but detects by software as 8 core, where the prop is ACTUALLY 8 cores bundled by the HUB.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! (http://pidgin.im/) So easy a caveman could do it...
http://folding.stanford.edu/ (http://folding.stanford.edu/) - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats. (http://vspx27.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=78528)

Tracy Allen
01-11-2009, 02:29 AM
Phil Pilgrim (PhiPi) said...
Okay, but I'm not sure I can contribute anything more "enlightening" than this: From a behavioral (i.e. black-box or I/O) point of view, they're identical. From a programming standpoint, considering assigned hub memory as the equivalent of peripheral communication registers, they're identical. Heck, the "peripherals" even support DMA. What else matters? To ascribe significance to other structural departures one from the other would be to create a "distinction without a difference".

Um, how's that? Now it's time to for me hit the sack. I'll see where this "stick poked in the wasp's nest" went come morning. http://forums.parallax.com/images/smilies/smile.gif

-Phil


From a hardware standpoint, peripherals can often be built with static logic and therefore operate at low power independent of the CPU clock. That is combined with wake-up-on-change logic that is more or less linked with the interrupt system. It might be a single pin or keypad, or a static counter or an SPI input, but it can operate at essentially zero power. The Prop can throttle back to ~20khz, and quickly come up to ~12mhz and then to full xtal operation on the PLL, but there is latency. I guess what I am trying to say is that from a programming standpoint the hub memory and microcode may be equivalent, but other system considerations will still make it worthwhile to consider a dedicated peripheral.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

Paul Baker
01-11-2009, 02:49 AM
nutson said...
I fear we will see more comparisons prop vs xxx appearing in this forum this year. The vast amount of transistors that can be put on a silicon chip, is driving many chipmakers into multi-core designs. Yesterday Creative unveiled its VII chip, with 2 ARM processors, 24 stream processors and a lot of peripherals look here http://creativezii.com/2009/01/creative-zii-platform-unveiled/#more-30 . This 24 core chip, clearly aimed at the multimedia OEM market, seems to be a SIMD design that can process 3 instruction streams with 8 data streams each, delivering 10GFLOP total, suggesting a 400MHZ core speed. Impressive is the library of multimedia processing functions, virtually all thinkable picture, sound and video processing functions are available. Once Nvidia and ATI enter this market we can expect some fireworks.

For the DIY, hobby and enthusiasts market all these numbers do not mean much, here the ease of programming, debugging, and building systems with their choice of peripherals interfaced is more important, and Parallax has done a very good job with the propeller. Hope the propII will expand on that. Software controlled image processing??·

Nutson
There, your post is in the right thread. Now delete your two other posts by clicking the red X in the upper right hand corner of the bottom post, then the red X in the top post, but you must do this before anyone else replies to the (no subject) thread or you won't be able to delete the top post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

Phil Pilgrim (PhiPi)
01-11-2009, 03:16 AM
Tracy,

You're right: microprogrammed hardware is typically somewhat slower and/or less energy-efficient than that which is hard-wired. There's always a tradeoff between speed/power consumption and flexibility. But cogs can also idle at low power while waiting for a change. Consider the WAITPEQ instruction. While it's waiting for the right input at full clock speed, the cog is consuming about a tenth its normal power. Throttled back to 20KHz, that can be as low as 3uA, albeit with higher "resume" latency, as you point out.

I'm not sure what you mean by "static logic" in this context. To me "static" implies that the clock can be turned off, with the hardware state maintained until clocking is resumed. Many micros allow indpendent clock control of individual peripherals to save power. But for the peripherals to operate after wakeup, there still has to be a clock. Peripherals operating completely independent of the CPU clock would have to use "asynchronous logic". I'm not aware of any micros (yet) that have taken this step. Such logic is much more difficult to design, although the savings in power consumption can be substantial. But perhaps I misunderstood your comment.

I see where you're coming from, nonetheless, since a lot of what you do is battery-operated and can sit for months on end, waking up periodically to collect data unattended. For such apps, the Prop may be power overkill, both in compute and current-consumptive terms, with the BS2pe and TI's MSP430 still reigning supreme.

-Phil

soshimo
01-11-2009, 06:31 AM
I never said the 8088 was the first interrupt driven chip - I submitted it as an example of a well used and well known chip that used interrupts. And what someone else pointed out is correct, interrupts are design specifically to interface the cpu with hardware. It eliminates the need for the cpu to have to waste duty cycles polling. Publish/Subscribe mechanisms have been around for a very long time and are still in wide use today, from hardware to software solutions. To discount them is to say that whole sectors of computing have it all wrong just because an 8 core chip emulates hardware when over 10% of its resources are used up. You are still limited to 8 perephrials (unless I am sorely misunderstanding the cog concept of one task per cog) whereas in an interrupt driven system you have essentially no limit to the amount of perephrial devices you can talk to.

@potatohead - you are correct, without hardware determinacy you must rely on software synchronization which effectively emulates the hardware determinacy. This requires a kernel and support software. In the case of the 8088 and the XT architecture this was partially in BIOS (the bootstrap) and the rest was loaded off disk (floppy and later, if you were rich, hard drive). Without the boostrap it was basically a really expensive 4.77Mhz oscillator http://forums.parallax.com/images/smilies/rolleyes.gif. I can also see your point on bus contention (although, the limited amount of RAM really makes that a moot point since there isn't much TO contend).

william chan
01-11-2009, 07:26 AM
Phil,

Are you saying that the Prop's total chip current consumption at 20Khz is 30uA while one cog is active and 3uA while WAITCNT?
I can't find this info anywhere on the datasheet.
Funny thing is that the datasheet always mentions current consumption per cog but never mentions current consumed by the hub.

This is interesting because I am also currently working on another battery powered project.

The wake up latency is not a problem to me for communications because the message sender can always send the wake up signal a few times until the Prop has woken up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Paul Baker
01-11-2009, 07:51 AM
william chan said...
Funny thing is that the datasheet always mentions current consumption per cog but never mentions current consumed by the hub.

Figure in section 9.1, line labeled Hub Only.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

potatohead
01-11-2009, 09:44 AM
@soshimo IMHO, contention is a relative thing in that scale might move the problem into play, or out of play, depending on both size and overall complexity. Prop II will scale, highlighting this point much greater than we see currently, as size will then play a greater role in the differentiator.

I think, referring to a Propeller as "8 core" isn't all that valid. It's really a true, deterministic multi-processor. This is quite different from a CPU, with 8 cores.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

william chan
01-11-2009, 10:04 AM
Ok, you got me there....

Why does spin loops consume more current than assembly loops?
Is it due to hubs accesses using more current?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Phil Pilgrim (PhiPi)
01-11-2009, 10:42 AM
William, your're back! I thought you just threw the ball into the scrum and left. http://forums.parallax.com/images/smilies/smile.gif I was wondering the same thing about the difference between asm and spin current consumptions.

-Phil

Cluso99
01-11-2009, 11:27 AM
Without knowing definatively, I would be reasonably certain the spin access to hub would require the hub logic and hub memory access to use additional power http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Post Edited (Cluso99) : 1/11/2009 9:09:30 AM GMT

Phil Pilgrim (PhiPi)
01-11-2009, 12:05 PM
To me it would make more sense if it were the other way around. The hub is running all the time, regardless of what the cogs are doing, so that should be a constant current draw. When a cog accesses the hub, it may need to wait its turn, so the current draw should go down during the ensuing idle intervals, resulting in a net current decrease compared to cog-only execution. It makes me wonder if the two lines in the graph got switched.

-Phil

Addendum: I just tested my theory regarding switched graph lines and disproved it. At 80MHz, a Spin cog consumes about 3mA more than an Asm cog. 'Still can't understand why.

BTW, did you know that the Demo Board has a handy jumper that you can remove for doing current measurements? It's labeled IVDD.

Post Edited (Phil Pilgrim (PhiPi)) : 1/11/2009 6:24:50 AM GMT

waltc
01-11-2009, 12:43 PM
fixitman,

If someone actually bothered to make a serious Prop based PLC package(at the very least like Rabbit Semiconductors PLC kit) with software that made a attempt to conform to IEC 61131 programming standard then it might happen.

But folks in the industry need tools they can compare and test in the field and so far there aren't any.

Also theres another element to consider, no one ever got fired for going with the industry big dogs. When I was a instrument and controls electrician at the local cement plant/quarry the company was wedded to Gould/Modicon PLC's and the only alternatives they were considering when I left were from Allen Bradley. In short they only dealt with outfits with proven track records.

FWIW

Paul Baker
01-11-2009, 03:07 PM
The reason a cog running spin code takes more current than assembly is that the memory drivers in hub are being used. Swinging the lines around and thier associated capacitance requires extra current. When the hub does nothing on a cog's slot it leaves the memory drivers inactive therefore consuming less current.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)

Phil Pilgrim (PhiPi)
01-11-2009, 03:52 PM
Paul,

I started a new thread on the subject here (http://forums.parallax.com/showthread.php?p=775952), so as not to diverge from the original topic of this one. After reading it, you may wish to revise your explanation a little. http://forums.parallax.com/images/smilies/smile.gif

-Phil

Invent-O-Doc
01-12-2009, 06:48 AM
The reason that other microcontroller forum types show disdain for the prop or basic stamp has nothing to to with its technical strengths or weaknesses. You see, parallax products can be used by regular people, not just electrical engineers. (Although many good engineers do) People like to think of themselves as special (having special knowledge, privileges ,etc). They stick with their chips precisely because they are harder to get started with or use because it is a 'barrier to access'. In their mindset, a chip with a very low barrier to use is unwelcome.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
----------------------------------------
Thomas Talbot, MD
Gunpowder, MD, USA

João Geada
01-12-2009, 07:13 AM
Invent-O-Doc:

you know how absurd that sounds? That people whose living depends on delivering working products would not use
something that would be easier/cheaper/better to use, particularly in the ruthlessly competitive electronics industry?

Engineering is not an easy profession and there are lots of balancing acts and tradeoffs required to make a product
meet its requirements (price/performance/features/etc). The propeller doesn't always (or possibly even often) fit in
that sweet spot.

[yeah, I am a professional engineer]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
João

soshimo
01-12-2009, 07:19 AM
I have to concur with João. It might be cool and hip while in college to be proud of the fact that you can master something with a difficult entry barrier or steep learning curve, but in the professional realm it's all about risk management. Trust me, the guys with the money don't care how "cool" a technology is, they care if it's 1. Cheap, 2. Fast, 3. Makes Profit. Well, they really only care about #3, but #1 and #2 have a direct impact on the bottom line. I can't tell you how many times I've gone to my manager with what I know is a superior method or idea only to be told to work with what we have. Why? Because it cost dollars to retool production operations on the whim of a designer. If it's not broken don't fix it is pretty much the attitude in any environment other than R&D and R&D has to have a proven track record of producing product that makes money or they find another job - nobody likes dropping money in a black hole. Those are pretty much my observations, please share with us if and how yours are different.

potatohead
01-12-2009, 07:25 AM
I can totally see that dynamic in play. Good observation!

It's not all that uncommon for people to be insecure about their value, instead leveraging tech as some sort of ante they've paid.

As technology continues to improve and the rate of improvement continues to escalate, the good stuff trickles down to common knowledge. This is happening with micros right now, and the Propeller is one of the leaders in this. (That's why I like the thing! I can get into complex stuff, if I have to, but when learning, or enjoying it as a hobby, why bother?)

Anyway, what happens is either a person needs to continue to reinvest in new gateway skills, (and this is both annoying and productive at the same time) or come to some level of acceptance on the greater importance of people skills. Been through that. I'm better now!

The thing about staying on the ramp is that a considerable portion of time that could be used to build value, either for the person or the enterprise they work for, is used to stay on the ramp itself. The appeal of that ramp leads to lock in, and all sorts of games played by vendors who compete not only on the core value proposition of their offerings, but on how they can exclude the value of others! Total mind share game.

Once you step off of that, then tech is much easier to evaluate, apply and how you do business, who you do business with and other basic things carry a lot more weight.

The "special" part in this maybe understanding or niche skills. All good. It may also be in how you work with others, the kinds of relationships you build, or some combination of the two. Experience over time does tend to make climbing the ramp easier, so that's a plus. However, climbing it often has diminishing returns as a given market segment matures.

The key then, in all of this, if one wants to preserve their "entitlement" is not to downplay or marginalize other tech. That's just annoying. Really, what is of interest is:

1. identification of disruptive technologies

2. building the relationships necessary to apply them.

IMHO, Propeller is somewhat disruptive in that it lowers the barrier to entry on dedicated computing or embedded computing solutions. There is a significant movement on this right now, with Arduino and others introducing more friendly packages, and a growing amount of activity surrounding this kind of thing in general. This is good to see!

Have seen it before, multiple times. In my industry, it's been going on for a while now. At first there is a split where the lower barrier to entry products remain limited enough to not seriously impact the entrenched higher barrier products and services. Over time, that split fades as both camps bend a little to close the gap. Saturation happens, and consolidation happens. Sometimes legal things happen to keep the barriers in play artificially too. I can see that happening in this space big time.

When all of that plays out, the people who end up with the best overall value proposition are those with the people and business savvy to play well with others, not the ones with the "best" overall tech.

Of course, for those who have earned entitlements, and who have not focused on both those and general business people skills, this is a significant threat! LOL!!! Always happens. Always will. Either get along, or keep jumping to the next niche! Either is fine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

potatohead
01-12-2009, 07:33 AM
Re: Professional engineers.

You guys are rational, and of course are gonna apply stuff to the best of your ability. That's not where the dynamic plays out! This is an artifact of business and the dual obligation to develop new stuff, and preserve existing revenue at the same time! The dynamic in play actually makes your job tougher, as there are often barriers put into place, just for the purpose of biasing those otherwise rational decisions!

Sucks, but that's how the major leaguers play. This is always how they play, and it does not matter what industry you are talking about. The core rules are the same. Head games are the same.

Working as a contract professional, for a smaller company, or as an originator of technology, such as Parallax, are the few niches where it's possible to avoid all of this crap!

My day job involves being in the sales channel. We work with larger firms, who originate software technology, and to some degree hardware. (that's gotten really ugly, so we largely stay out) They do this crap constantly! Our value is in sorting that out, helping people to use the tech for their means, and to get it to play together. This is not easy every year.

Anyway, I know it's a bit off topic for the detail, but Invent-O-Doc does have a valid contribution to this topic!

The good news is that influence is in play now, and will diminish over time as the tech rolls over a cycle or two, leaving us with a lower barrier across the board.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Paul Baker
01-12-2009, 08:05 AM
There's more truth to Invent-O-Doc's comments than there should be. The people who think this way think of it in terms of job security (If I'm the only one that understands how it works, then they aren't going to fire me, I'm too indespesible). This type of thinking is prevelant in the IT field, and it creeps into the engineering fields as well. It typically happens in small to mid size companies where the engineer to non-engineer ratio is rather small (the same criteria when it happens with IT guys).

Engineers work in logic, but that doesn't mean that thier actions are always guided by logic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/12/2009 1:14:54 AM GMT

SRLM
01-12-2009, 08:12 AM
At my old high school, we had one guy who knew how to work the computer system, and they fired him. He was replaced with a guy who didn't know anything about networking or computers, and (no surprise) the system started having all sorts of problems. Yet for all that, he started instituting new rules that gave him more power... Moral of the story is that a one-track design team works.

william chan
01-12-2009, 09:29 AM
So far in this thread, nobody has stepped up to say that another multi-core microcontroller has lower cost than the Propeller.

Does this mean that the Propeller is currently the cheapest multi-core microcontroller in the world?

It must be one hell of a deal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Leon
01-12-2009, 10:45 AM
I've already pointed out that the XMOS chip could be considered to be better value - four cores and 32 hardware threads (it's like having 32 processors) giving 10 times the performance (1600 MIPS), 256 I/Os, 256k RAM, and better development tools, for $33:

www.xmos.com (http://www.xmos.com)

It's not as hobbyist-friendly, coming in a 512BGA or 144BGA package, but they will soon have a single-core device giving 400 MIPS with eight threads in a QFN package. That will cost $1 in quantity.

They are intended for professionals, replacing FPGAs and DSPs in many applications, but many hobbyists are using them, including several Propeller-heads.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 3:56:49 AM GMT

potatohead
01-12-2009, 12:04 PM
Yeah, but it's not a multi-processing micro controller. In this, the Propeller is unique at this time. Multi-core carries with it some functional implications, many of which are the subject of this thread!

Those impact the value proposition. And I'll highlight just a couple.

Some differences from the data sheet


said...

From a software design standpoint, this means that the minimum performance
of a thread can be calculated by counting the number of concurrent threads at
a specific point in the program. In practice, performance will almost always be
higher than this because individual threads will sometimes be delayed waiting
for input or output and their unused processor cycles taken by other threads.
Further, the time taken to re-start a waiting thread is always at most one thread
cycle.
The set of n threads can therefore be thought of as a set of virtual processors
each with clock rate at least 1=n of the clock rate of the processor itself. The only
exception to this is that if the number of threads is less than the pipeline depth
p, the clock rate is at most 1=p.
Each thread has a 64 bit instruction buffer which is able to hold four short instructions
or two long ones. Instructions are issued from the runnable threads
in a round-robin manner, ignoring threads which are not in use or are paused
waiting for a synchronization or input-output operation.


This is one of the areas where multi-core designs differ from the multi-processor design of the Propeller. The peak computer of the XMOS chip is high, because it does not execute it's instructions in a simultaneous and concurrent way, like a COG does. This higher peak compute is then necessary, because it's really more of a linear computing device, with a lot of silicon dedicated to making it perform well on simultaneous tasks.


said...

Certain instructions cause threads to become non-runnable because, for example,
an input channel has no available data. When the data becomes available,
the thread will continue from the point where it paused. A ready request to a
thread must be received and an instruction issued rapidly in order to support a
high rate of input and output.
To achieve this, each thread has an individual ready request signal. The thread
identifier is passed to the resource (port, channel, timer etc) and used by the
resource to select the correct ready request signal. The assertion of this will
cause the thread to be re-started, normally by re-entering it into the round-robin
sequence and re-issuing the input instruction. In most situations this latency is
acceptable, although it results in a response time which is longer than the virtual
cycle time because of the time for the re-issued instruction to pass through the
pipeline.



So, this is more of a latched system than a deterministic one. (I think they are being less than honest about this!) In addition, the overhead required to understand it runs considerably higher than that required on the Propeller. If this were not the case...


said...

The XCore scheduler therefore allows threads to be treated as virtual processors
with performance predicted by tools. There is no possibility that the performance
can be reduced below these predicted levels when virtual processors are combined.



...they would not be stating that performance is "predicted by tools" and exhibits a minimum level of such. Also, there are a lot of various states the scheduler can be in. This increases complexity and indeterminate behavior.

A Propeller user, by contrast can simply know what their performance is going to be, and also know response times, because the system is deterministic throughout. It being a multi-processor actually simplifies this calculation further, due to the fact that instructions are running concurrently, not round robin. The high level of compartmentalization the COGs bring to the table, means also being able to isolate timing touchy code, from the body of more relaxed code without having to worry about interdependence to the degree required on XMOS.

The big innovation here, on the part of XMOS, is really more about encoding a scheduling kernel into silicon.

This is a very different value statement, than the one presented to us on the Propeller! IMHO, one that impacts the overall worth of that $33. And that's just comparing 8 COG's to the multi-core design of the XMOS. Frankly, this is apples and oranges.

It's save to say, $33 worth of parts and a breadboard gets you doing the same kinds of things, and arguably same kinds of performance in many cases. That's a wash.

From the looks of things, and granted I've not looked all that far, Propeller is much simpler in many ways.

Don't get me wrong. The XMOS stuff looks pretty cool. There are enough differences, many of which are the subject of this thread, that make simple performance and hardware specifications worthless where overall value judgments are concerned.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

potatohead
01-12-2009, 12:06 PM
I can't help but point out that 1600MIPS / 10 threads = 160 MIPS.

On Propeller, we get 20 MIPS * 8 COG's = 160MIPS.

:P

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Leon
01-12-2009, 12:37 PM
In what sense is the XMOS chip not a multiprocessing controller? Each core operates independently, in parallel, with very high-speed communication links between cores. Operation is fully deterministic, with 10 ns I/O granularity. Threads are implemented in hardware, with single-cycle switching between threads. Proper debugging facilities are available via a standard JTAG interface. The XMOS instruction set was designed to support efficient compilers, assembly language is rarely required. Parallel processing is very easy with the XC language, here is a small program of mine which tests communication with an prototyping board I made for my XC-1 kit:




#include <xs1.h>
#include <platform.h>


// LED on proto board (X2D2)
on stdcore : out port led_port = XS1_PORT_4A;

void flash_LED(out port led_port)
{
timer t;
unsigned time;
unsigned onOff = 1;

t :> time;

while(1)
{
led_port <: onOff;
time = time + 100000000;
t when timerafter(time) :> time;
onOff = !onOff;
}
}


int main(void)
{
par
{
on stdcore : flash_LED(led_port);
}
return 0;
}





It's basically standard C with extensions for parallel processing and threads. The par construct enables execution of a function on any core.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 5:44:01 AM GMT

potatohead
01-12-2009, 12:41 PM
It is possible to have one thread, read the state of an I/O pin set by another one directly?

Does the number of threads impact the number of instructions per second executed?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Leon
01-12-2009, 12:53 PM
potatohead said...
It is possible to have one thread, read the state of an I/O pin set by another one directly?

Does the number of threads impact the number of instructions per second executed?


The value of an input can be read by one thread and passed to another thread, or another core. There is some latency, of course, but it is deterministic. It's very low between threads.

Each thread is allocated up to 100 MIPS, so four threads can be running on one core at 100 MIPS each. Conceptually, I don't think it is very different from the Propeller, if you think of threads as cogs. Threads communicate directly, whereas cogs communicate via the hub on the Propeller. It doesn't really make much difference to the programmer.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 5:59:15 AM GMT

potatohead
01-12-2009, 01:05 PM
On the matter of the cores, given one thread is running, do they run concurrently, as in two instructions happening at the same moment in time?

It's difficult to consider threads as COGs. They are not the same thing.

A thread is one element in a greater body of code. A COG is a discrete compute unit, that may or may not exhibit threaded program flow. A COG may run it's own body of code, apart from bodies running on other COG's. These things can be quite different!

One thing I don't yet grok is if the cores can do this. And if they do, are their instructions happening at the same moment in time, or in a scheduled fashion?

Edit: Again, my point not being to diminish the XMOS stuff. We are however having a discussion that compares micro-controllers. A related topic is their relative value proposition.

The differences I highlighted impact the value proposition of the two designs, and that of course then hints at where their strengths are.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/12/2009 6:47:56 AM GMT

Mike Green
01-12-2009, 01:45 PM
My understanding of a thread on the XMOS is that of an active state. Essentially, an XMOS processor has several sets of registers and can switch among them. Each set of registers contains the current state of an execution thread (including the program counter). The processor executes one at a time. I don't know whether there's some automatic switching or if one thread gives up control to another.

By comparison, a Propeller cog has only a single execution thread. You can construct several different threads, but their state is not completely saved automatically, only the program counter (with JMPRET). The carry and sign flags have only one copy and would have to be explicitly saved. I consider the special registers to be shared resources from a threading standpoint.

Paul Baker
01-12-2009, 02:05 PM
While there are several things XMOS seems to do very well, I think there is importance to one of potatohead's points.

That is the issue of determinism, from what I can tell there is no way of getting it on a XMOS unless you only have a single thread on a core. XMOS states repeastedly about how the timing of threads interplay and how threads can be placed in wait states thereby releasing cycles to the other threads.

This is proof that XMOS when having more than one thread is non-deterministic because a thread doesn't know when it's being given extra cycles due to another thread being placed in a wait state. While this approach has the advantage of being able to eek out as much power as possible out of the chip, it vastly complicates being able to pick up a piece of code that is timing critical and being able to make it work right off the bat unless you dedicate an entire core to it.

This is an area where the Propeller absoutely excels at, it is a simple matter to pick up an object from the exchange place it in your code and have it work from the get go.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/12/2009 7:22:15 AM GMT

Leon
01-12-2009, 02:25 PM
potatohead said...
On the matter of the cores, given one thread is running, do they run concurrently, as in two instructions happening at the same moment in time?

It's difficult to consider threads as COGs. They are not the same thing.

A thread is one element in a greater body of code. A COG is a discrete compute unit, that may or may not exhibit threaded program flow. A COG may run it's own body of code, apart from bodies running on other COG's. These things can be quite different!

One thing I don't yet grok is if the cores can do this. And if they do, are their instructions happening at the same moment in time, or in a scheduled fashion?

Edit: Again, my point not being to diminish the XMOS stuff. We are however having a discussion that compares micro-controllers. A related topic is their relative value proposition.

The differences I highlighted impact the value proposition of the two designs, and that of course then hints at where their strengths are.


Threads operate consecutively. That is why I said that they are similar to cogs. XMOS threads are different from threads used on conventional processors.

As Mike has said, each thread has a set of registers which are used for inter-thread communication. Switching between threads only takes 1 clock.

Using multiple threads is completely deterministic:

"The instruction set includes instructions that enable the threads to communicate
and perform input and output. These
• provide event-driven communications and input-output with waiting threads
automatically descheduled.
• support streamed, packetised or synchronised communication between
threads anywhere in a system.
• enable the processor to idle with clocks disabled when all of its threads are
waiting so as to save power.
• allow the interconnect to be pipelined and input-output to be buffered."

If it wasn't it would be impossible to replace FPGAs with XMOS chips, which is a major market for them.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 7:34:48 AM GMT

Paul Baker
01-12-2009, 02:31 PM
Im sorry Leon but this quoted directly from thier datasheet contradicts your statements on determinism:


said...

From a software design standpoint, this means that the minimum performance
of a thread can be calculated by counting the number of concurrent threads at
a specific point in the program. In practice, performance will almost always be
higher than this because individual threads will sometimes be delayed waiting
for input or output and their unused processor cycles taken by other threads.

If a thread gains extra cycles, it simply cannot be deterministic.

Synchronization is not the same as determinism.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/12/2009 7:36:56 AM GMT

Leon
01-12-2009, 02:35 PM
That is dealt with by the development tools: there is a cycle-accurate simulator, and a timing tool is under development. I'm getting a copy for beta testing. The minimum performance can be calculated, as you say, and the actual performance can then be predicted. It's essentially the same sort of procedure as carrying out a timing analysis for an FPGA.

David May, who designed the chip, has written this document on the XMOS architecture:

http://forums.parallaxinc.com/www.xmos.com/system/files/xs1-87.pdf (https://www.xmos.com/system/files/xs1-87.pdf)

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 7:44:36 AM GMT

potatohead
01-12-2009, 02:41 PM
That's where I was headed essentially.

We had this same discussion on Propeller II attributes actually. Determinism is a very strong attribute. Lots of value there. I would argue symmetry also is strong. A COG is a COG.

I think the single cycle thread switching on the XMOS is cool actually. I also think it's performance / instruction size ratio is very good. Want to keep it friendly, after all! If you need some significant peak compute, that design can deliver it. The trade-off there is a nice one. The cost is complexity overall however.

I would add the overall utility of the Propeller, given only discrete components to work with, is arguably higher also. It's a simpler design all the way around, both hardware and software. That's highly likely to be more important to hobby / prototype projects however. Don't know.

With respect then to "better value" on XMOS, this is highly subjective. Really depends on what tools and modes of working one is used to. I think there is a strong case to be made that having to learn something new is a factor with both designs. On Propeller, there is SPIN and PASM, with C now too. So there is new learning on the languages, and about the COG / HUB relationship. On XMOS, there is the intricate scheduler, and understanding how code snippets are going to run together. Straightforward debugging facilities are necessary, where they arguably are not always so on Propeller. Plenty of learning there too, with the reality that once the learning is done, there will be less fussing around with code to be combined. IMHO, that's a clear plus for Propeller in the longer term.

Plus we've got tricks on Propeller! Having one COG display on the TV, the pin state changes made by another one is pretty damn cool! Makes me wonder about other things also. Look at the 6502 project Dennis did. I've been following a few other projects like this, and interfacing with other CPU's isn't always easy. Lots of little states to track down, and determinism plays a big factor in making it manageable.

I think if we were to duplicate that effort, with the two chips being discussed, the complexity and overall malleability of the Propeller design would both be significantly lower.

My point is that at the hardware level, the Propeller does exhibit some of the same characteristics it does at the code level.

From a business standpoint, that may well mean faster time to market, and more products per cycle to market. Both are very potent multipliers. Potent enough to be a consideration on this thread.

My .02

(plus a little, and I'll be quiet now, for a while.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Leon
01-12-2009, 02:54 PM
Having used both chips, I feel that including video circuitry on the Propeller, and the use of Spin, make it less useful in professional applications. I'd rather have had JTAG debugging and programming, more memory, and a proper compiler.

A major advantage of the XMOS architecture is scalability - if one chip doesn't have enough performance it's very easy to add additional chips. Five-wire Xlinks can be used for high-speed on-board inter-chip comms, and two-wire Xlinks for connecting boards together. The two-wire links can operate over several feet, if necessary. The whole system will still be deterministic. They are working on a 16 chip board - 25,600 MIPS!

XMOS is thinking of putting eight cores on a chip, they probably won't go any further. The existing silicon uses the TSMC 90nm process, eight cores would presumably mean using the TSMC 45 nm process.

XMOS is a very small company, like Parallax, with only 50 people. They spent $16 million over three years getting the chip designed and into production, they have just received a second tranche of $16 million. Three well-known VC companies provided the funding. It's also British!

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 12:04:07 PM GMT

Phil Pilgrim (PhiPi)
01-12-2009, 02:54 PM
Having finally looked at the XMOS instruction set, I realize even more how lucky I am to using the Propeller. As is typical of architectures optimized for high-level languages, it's a rather baroque edifice, which I would not want to program in assembly. The Propeller's architecture and instruction set, by comparison, are much more regular and predictable. Plus, being able to make any instruction conditionally executable is a huge advantage for efficient assembly code. The Propeller's power lies not only in its speed and parallelism, but also in its simplicity.

I'm sure the XMOS chip will create its own priesthood of skilled conjurors, accomplished in the intricate incantations that make it function and to whom its acolytes will be beholden. Fortunately for Propeller users, that power rests in the hands of us laypeople.

-Phil

Paul Baker
01-12-2009, 02:54 PM
Gotcha Leon, don't get me wrong I think there's alot of cool things going for the XMOS, but I personally like to have an inate uderstanding of whats going on in a chip rather than having to rely on a tool chain to tell me what's going on for me. I like to be able to think on the silicon level rather than having a nebulous cloud seperating me from the chip. It's much like my first car a Pinto station wagon, it was a clunker but I was able to do repairs on it myself when something went wrong. Now I barely trust myself to change the oil in my current car, and while I wouldn't go back because of safety and better fuel efficiency etc, I do miss being able to tinker.

@Phil, yeah I had noted the·sparseness of the instruction set in a Sandbox thread, what I was most disturbed by is that the only conditionals it supports is·whether a register is or isn't a 0, never could figure out how to test for overflow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/12/2009 8:03:38 AM GMT

Leon
01-12-2009, 03:02 PM
Several people have written sizeable applications in XMOS assembler. Ones that spring to mind are VGA and high-speed (480 Mbps) USB. I agree that it isn't easy - I'm learning to use it myself and finding it somewhat challenging. Most users will use XC or C (the two may be mixed in the same application), or other HLLs.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

potatohead
01-12-2009, 03:18 PM
LOL@ Phil and Paul --> That is exactly why I am here! (having a good time of it too)

@Leon That document linked is the one I was quoting from.

And for what it's worth, a scheduler in silicon is a nice innovation that has it's merits. No question. I just know it's not my cup of tea.

"The whole system will still be deterministic."

Being able to determine the timing characteristics of the code running isn't the same thing as the predictable instruction execution time, and parallel instruction processing found on the Propeller.

The former requires a scheduler, and the results can only be expressed in terms of not to exceed. (thus your incoming beta timing analysis tool)

The latter does not, and is expressed as a discrete precise quantity, easily obtained from a look at the program code.

Edit: If a thread can run @100MIPS, how come VGA is not written in C?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/12/2009 8:50:38 AM GMT

Leon
01-12-2009, 03:39 PM
I just looked at the code and he seems to have used assembler to get the timings he needed (he actually used nops in places to get exact short delays), although he also used the timer hardware. He came up against a memory limitation, with only 64k available, which limited the resolution. He could have used external memory, of course. Resolution is 320x200 with 64 colours.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 8:50:02 AM GMT

potatohead
01-12-2009, 03:47 PM
Just saw your post!

Yeah, I was looking at it too. Didn't realize the memory was not shared among the cores. Probably has to keep timing precise for max streaming between them to make best use of the display buffer too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Leon
01-12-2009, 03:52 PM
He only used one core. I think the 100 MHz clock was a bit inconvenient.

It's a classic MIMD architecture, like the Inmos transputer that David May also designed. He doesn't like shared memory.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 9:03:07 AM GMT

soshimo
01-12-2009, 03:59 PM
Ah adding nops - that's the tricks you do on PICs and AVRs to get timings almost.

I have to go with the camp and say that the propeller definitely beats anything else in determinacy. Also, multi-threaded, whether pre-emptive or cooperative, is not the same as multi or parallel processing. You are still only executing one context, there are clever mechanisms to save state for each context and to make fetching instructions quicker, but you are still only fetching and executing instructions through one pipeline.

The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?

Leon
01-12-2009, 04:08 PM
XMOS uses true MIMD parallel processing - the four cores are completely independent. Two or more threads might be running on the same core but they behave like separate processors.

I think you are confusing the hardware threads used by XMOS with conventional software threading systems.

[quote]The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?

I don't understand what you mean.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 9:16:42 AM GMT

potatohead
01-12-2009, 04:20 PM
Hmmm...

Seems to me those "video generators" that are not "professional" would have come in damn handy for that task. Kind of nice to just set the PLL, then build pixels off of that, but that's just me! LOL!! Change the clock, and probably that won't run. Change clock on the Prop, and it likely will, given the overall compute speed is still capable of the pixel feed rate.

I switch boards all the time, and just run the same video code I'm focused on, only having to just state what clock I'm actually running. It's really easy.

And he basically used the entire core too. Gotta put the display buffer somewhere, meaning that core is mostly not available to then run threads. (no real program space remaining) Graphical data, existing elsewhere, or on external RAM must then be streamed in to the display buffer, as the other cores cannot write it directly. This has fill rate limits too. If the one core is managing the display and moving data, then the other cores, cannot be used in combination to actually draw the display. One pipe = one fill rate. More pipes then = more threads = non deterministic behavior = more complexity.

My point there is despite having a "proper compiler", it's down and dirty in assembly language for the good tricks anyway, isn't it Leon?

I'll stick with the Prop. Thanks for the XMOS discussion though! Always nice to learn some new stuff about new hardware.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/12/2009 9:28:53 AM GMT

Baggers
01-12-2009, 04:24 PM
Leon, also, iirc it's not single cycle it's 4 per instruction, which is why it runs at 100mips per 4 threads, as 100mips is the maximum it can run a single thread at, which is why it runs up to 4 at 100mips, then the 5th thread disrupts the whole thing and makes it go to 80mips cos it needs 5*4 clocks :D
and thus all threads don't run in parallel, as there's a clock latency on all threads.
Prop is also much nicer to code, and doesn't get RED HOT as soon as you turn the thing on, or at all, I've had PropGFX running full tilt with all cogs blazing and it still doesn't get mildly warm after a couple of days, whereas the XMOS will burn your fingers after a few seconds :(
Prop also has better intercog coms, as each cog has access to ALL available memory, not 4 seperate 64K chunks, ( PropII will have access to ALL 256K with any cog and run at 160mips per cog making it faster, better, stronger, able to leap buildings in a single bound, oh sorry, wrong script lol and that's before you add the 3D textured gouraud shading ability :P )
you can tell which microcontroller I have on my desk, and which is gathering dust in a deep cupboard corner, well, actually I have 7 prop setups on my desk :D

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Ale
01-12-2009, 04:29 PM
To both, let me explain my choices with the VGA drivers:

There are two drivers:

1/4 bpp drivers. These were written in assembler because:

- I wanted exact timing, at 12.5 MHz pixel clock eight instructions are needed. With C (XC) I was not sure if I could squeeze the needed timing because I was using the ports asynchronously. Asynchronicity of the ports is the reason here. (And I wanted to give assembler a go!).

8 bpp driver. This was written in XC because I used synchronous port access (buffered and synchronized to a clock). This way I could afford the uncertainty that C (XC) gives because port access will be delayed till the right time comes. This is an evolution of the other method. I couldn't have done it before because I had not found the Ports document.
This driver still uses an assembler helper (vgabuf_sender) that reads the pixel data from memory. It was done in assembler just to fit it in the tight spot left by a 64000 byte frame buffer.

Now: The 1 bpp driver is going to be merged with a new 1bpp driver based on the 8bpp driver model and the resolution will be cranked up to 640x480. I think I can get 800x600 1bpp (64000 bytes).

The 4bpp driver is going to use a similar technique.

I also developed a text driver. I only got so far as to display chars with foreground colors. Background colors other than black are missing, using similar techniques as the 8bpp and 1bpp (new driver).

I hope it clarifies things.

As ports have many more modes of operation than the propeller, determinism is less of a concern. Threads either 4 or 8 have a total maximum of 100 or 50 MIPS respectively. They cannot get beyond that. No matter what. Waits are measured to the 400 MHz clock so a wait for 1 cycle can happen. That means a thread that was starting at a clock mod 4 = 0 may start at clock %4 = 1 after the delay. That may or may not affect things.

Leon
01-12-2009, 04:32 PM
I'm the other way round, my Propeller boards are gathering dust. 8-)

Ale,

I've been wondering if you were the same Ale who wrote that VGA code for the XMOS. Alles klahr!

It looks like external RAM could be interesting. How about dual-porting it between two cores?

Which do you prefer?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 9:41:34 AM GMT

potatohead
01-12-2009, 04:36 PM
Hi Ale...

Thanks for the extra info. :) No worries here. Looks like you are having a good time of it! I didn't mean to imply anything bad about your project!

Is it that binary? 3 threads = 100 MIPS @ standard clock, 5 threads = 50 MIPS? ...or a smooth degrade as Baggars was saying?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Baggers
01-12-2009, 04:52 PM
Doug, can you go you online?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

simonl
01-12-2009, 05:00 PM
IMHO both chips have their place, but the Propeller appears to me to be MUCH simpler for the hobbyist in many ways (DIP; objects 'slot in'; price; etc.). And just because it's simpler for the hobbyist should be no reason for it not to be suitable for the professional.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
-------------------------------

www.norfolkhelicopterclub.com (http://www.norfolkhelicopterclub.com)

You'll always have as many take-offs as landings, the trick is to be sure you can take-off again http://forums.parallax.com/images/smilies/wink.gif
BTW: I type as I'm thinking, so please don't take any offence at my writing style http://forums.parallax.com/images/smilies/smile.gif

Ale
01-12-2009, 05:05 PM
Potatohead:

For 1 to 4 thread all of them get 100 MIPS each. For 5 to 8 all of them get 50 MIPS each. That is due to pipeline and some clever shared use of resources.

I know you did not mean any detriment for the code http://forums.parallax.com/images/smilies/smile.gif, the 1bpp and 4bpp where not-so-quick-but-quite-dirty approach http://forums.parallax.com/images/smilies/smile.gif. The second one is a proper one using the resources at hand. As I said, that ports document was not available till the end of November of beginning of Dec.

Leon: I'm the same and only Ale here (and there I'm called Ale500). Well, there are some Alex and Alexanders here, too. My real name is Alejandro, the spanish version.

One of the things I find really good is how they crammed in 16 bits opcodes with 3 arguments. As only 12 registers are available for these instructions a 11 bit field is used for all combinations. Some instructions are also in the not used combinations, very clever. I really miss some instructions, like compare and and with immediate, but you cannot have everything. Channel communication, thread creation and join are all in the assembler. That makes it quite fast to boot several threads.
For the time being the XMOS dev boards (XC-1) are slaves of a PC or a Mac. I hope some not-so-enslaved-boards are going to show up soon (Leon, are you there ?) and we can use those XS1s fore more things than testing code and limits.

Post Edited (Ale) : 1/12/2009 10:12:17 AM GMT

Cluso99
01-12-2009, 05:07 PM
I looked at the XMOS assembler instruction set and found it a mess, not regular like the prop. I gave it a miss before I got to the point that it was threads. Glad I didn't bother any further.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Ale
01-12-2009, 05:12 PM
Cluso99: You need to experience more x86 assembler! Then anything else is a joy! After a little while you see the orthogonality of it. It is not like MIPS but it is also shorter.

Leon
01-12-2009, 06:16 PM
Ale said...


One of the things I find really good is how they crammed in 16 bits opcodes with 3 arguments. As only 12 registers are available for these instructions a 11 bit field is used for all combinations. Some instructions are also in the not used combinations, very clever. I really miss some instructions, like compare and and with immediate, but you cannot have everything. Channel communication, thread creation and join are all in the assembler. That makes it quite fast to boot several threads.
For the time being the XMOS dev boards (XC-1) are slaves of a PC or a Mac. I hope some not-so-enslaved-boards are going to show up soon (Leon, are you there ?) and we can use those XS1s fore more things than testing code and limits.


David May did a good job. He's an FRS, BTW, that's the highest scientific qualification in the UK.

I'm waiting for the 144BGA chips, although I could go ahead with one of my 512BGA designs.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 11:21:53 AM GMT

Cluso99
01-12-2009, 06:42 PM
Ale said...
Cluso99: You need to experience more x86 assembler! Then anything else is a joy! After a little while you see the orthogonality of it. It is not like MIPS but it is also shorter.

I have, and no thanks.

In addition to minicomputers, I've coded 6800, 6805, 6502, 6511, 68020, 88100, Z80, Z8681, 8080, 80486 (a complete ICL minicomputer emulation specifically targeting the faster 486 instructions and commercially verified), and now the Prop. Just because the XMOS is better than the x86 doesn't make it easy, and the x86 is arguably the worst instruction set out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Post Edited (Cluso99) : 1/12/2009 11:49:21 AM GMT

Cluso99
01-12-2009, 06:43 PM
Determinism:

I think·determinism is highly overrated. Do I have your attention now ??

For most micros, determinism is impossible unless you disable interrupts.·Previously, it has not been really necessary, as long as you·know that your routines and interrupt routines can co-exist.

The Prop has changed this. Why, you ask. Well because the Prop doesn't have·embedded peripherals like other modern day micros. It has 8 cogs that can control very flexible counters (or whatever you want to call these building blocks). There is only one Prop, not hundreds of variants·like other micros such as the PIC. So, in order to build·internal peripherals, cog(s) are used. For some of these, deterministic code is often required. With interrupts this simply could not be the case. And neither could it be if the cogs were merely threads. For example, if one thread's code was dependant on an external event, and this·thread affected another·threads performance depending on what it was doing, determinism goes out the window - period! Your VGA may suffer jitter. It does not matter how complex a simulator is, it cannot cater for variable external events to simulate timing.

So the Prop has independant cogs that can function as peripherals to the other cogs via shared memory (hub memory). We all build these peripherals. Some of these are in the Object Exchange. Peripherals such as FullDuplexSerial, VGA, SPI, I2C, SDcard, etc. Now we have one chip that is so flexible that it can replace many variants that other chips·require. More of these variants are being discovered daily, by enthusiasts such as yourselves.

Once again, I thank Chip for the courage to create a micro which does not conform to the norm. It is truly a directional change that has yet to be understood by many - for it's simplicity and flexibility. The PropII will be another leap forward.http://forums.parallax.com/images/smilies/cool.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Leon
01-12-2009, 06:52 PM
I did a lot of hand-assembly in the early days with the 6800 and 8086 (I couldn't afford an assembler), and didn't have any problems with the 8086. I wrote and hand-assembled a comprehensive monitor/debugger for it - once I got the basic debugger working I used that to debug the rest of the code. I remember hand-assembling transputer code when I built my first system, it was similar to XMOS assembler in many ways. I usually do some hand-assembly when learning a new chip, and check it against the assembler, it's a good way to learn how it works.

All XMOS peripherals are implemented in software, also, and run on their own thread. There aren't any interrupts, either.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 11:58:08 AM GMT

heater
01-12-2009, 07:40 PM
That 30 million dollars that have been invested in XMOS worries me. Those investors will want a return on their investment and that's a lot of chips to shift. I worry that this will all go the same way as the Transputer. Don't get me wrong I love the XMOS ideas, software as silicon, parallel processing, communication links etc.

Conversely I have confidence that Parallax will still have Props to sell me a long time from now.

As for engineers defending their position with the use of arcane esoteric knowledge, that can work for a while or even a long while. But I have seen it also become career suicide as what ever technology it is you are the "keeper" of suddenly gets blown away very quickly the day that some one high up realises what it's costing them.

Better to keep moving on and share what you know. That way people will always come to you because you "know" and you are always one step ahead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon
01-12-2009, 08:01 PM
The transputer wasn't exactly a failure, the core was used in set top boxes for many years. It didn't survive as a parallel processing chip mainly because the second generation device was just on the limit of what could be achieved at the time. XMOS already has several design wins, although the chip has only been available for a few months. They targeted likely customers by giving away XDKs that sell for $999 each, it seems to have worked. Here are some nice YouTube clips of the XDK in action:

uk.youtube.com/user/theamazingxmoose (http://uk.youtube.com/user/theamazingxmoose)

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

tonyroberts09
01-12-2009, 08:04 PM
And for simple applications you don't have to use interrupts at all or can get by with a round robin scheduler. Mandatory they are not.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
tonyroberts09

heater
01-12-2009, 08:12 PM
Why is that SDK so expensive? A chip and an LCD what else is in there ?

Can't a Prop rotate a star on a screen for one tenth the price ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

simonl
01-12-2009, 08:16 PM
One thing that I find really intriguing about the XMOS chip is its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!) - then the sky's the limit :yay: (Just imagine; 1 x Prop for hi-res colour VGA, fed from another that deals with all the I/O, etc - you get the picture).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
-------------------------------

www.norfolkhelicopterclub.com (http://www.norfolkhelicopterclub.com)

You'll always have as many take-offs as landings, the trick is to be sure you can take-off again http://forums.parallax.com/images/smilies/wink.gif
BTW: I type as I'm thinking, so please don't take any offence at my writing style http://forums.parallax.com/images/smilies/smile.gif

heater
01-12-2009, 08:22 PM
Leon said...
The transputer wasn't exactly a failure,


Perhaps failure is to hard but my point was really where can I get a Transputer now or for the past umpteen years? It was rather a flash in the pan.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon
01-12-2009, 08:29 PM
heater said...
Why is that SDK so expensive? A chip and an LCD what else is in there ?

Can't a Prop rotate a star on a screen for one tenth the price ?


There's much more than that in it, like a codec, Ethernet, etc.

XMOS is running high-end audio applications on it this week at NAMM 2009:

http://forums.parallaxinc.com/www.xmos.com/company/news/22-dec-2008/xmos-demonstrate-complete-suite-audio-reference-designs-namm-2009 (https://www.xmos.com/company/news/22-dec-2008/xmos-demonstrate-complete-suite-audio-reference-designs-namm-2009)

I can't see a Propeller doing that sort of stuff.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2009 1:34:24 PM GMT

Leon
01-12-2009, 08:38 PM
simonl said...
One thing that I find really intriguing about the XMOS chip is its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!) - then the sky's the limit :yay: (Just imagine; 1 x Prop for hi-res colour VGA, fed from another that deals with all the I/O, etc - you get the picture).


The five-wire Xlink gives a 3.2 Gb/s transfer rate (full duplex). It uses 5 wires so that 32 bits can be transferred in one clock. The two-wire Xlinks are a lot slower, of course.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

heater
01-12-2009, 09:12 PM
simonl said...
...its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!)


Yep, I bring this up every time there is a Prop II discussion. There must be a fairly simple way to do this by allowing the video shifters to shift in as well as out plus some synch logic. Just following the Prop philosophy of having relatively simple but adaptable general purpose logic.

Never do get any feed back on this from Parallax but there are already a bunch of multi Prop projects out there that would benefit from high speed links.

Next up is a means to access a pile of external RAM at speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Kye
01-12-2009, 10:31 PM
Okay, for video the propeller really just needs a speed boost. Mainly because you simply can't do all the things you need to do at 20 MIPS.

For example:

With more speed it will be possible to have higher resolutions running on one cog. Right now 640x480 is the absolute limit for one cogs display capabilities.

With more speed it will be possible to use higher resolution character sets and graphics on one cog with a large display. As if the procesor is running a display at 640x480 its minimum amount of pixles per waitvid is 16 which allows the cog just enough time to fetch more.

With more speed it will be possible to do more complex overlays. For example I'm working on a mouse cusor for my vga driver that actually draws on the display by forcing the color lines to certaint states while a waitvid is shifting pixles out in the back ground. My goal is to have the same cog generating video do this.

And with more speed it will possilbe to work with more colors.

External ram and a large video buffer aren't really needed if you adopt the use of tiled bit mapped graphics and simply make the display buffer a buffer full of pointers.

And yes, this was off topic.



·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Phil Pilgrim (PhiPi)
01-13-2009, 12:38 AM
Leon said...
All XMOS peripherals are implemented in software, also, and run on their own thread. There aren't any interrupts, either.

'Odd, then, that there are so many instructions that deal with interrupts. Also, from the manual, XMOS XS1 Instruction Set Architecture (8.7.1) (p. 207):

"4 Exceptions

Exceptions change the normal flow of control on an XS1-G4; they may be caused by interrupts, errors arising during instruction execution and by system calls. On an exception, the processor will save the pc and sr in spc and ssr , disable events and interrupts, and start executing an exception handler. The program counter that is saved normally points to the instruction that raised the exception. Two registers are also set. The exception-data (ed) and exceptiontype (et ) will be set to reflect the cause of the exception. The exception handler can choose how to deal with the exception."

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 1/12/2009 6:06:00 PM GMT

waltc
01-13-2009, 01:10 AM
What I don't understand is why folks are comparing the Prop to the Xmos chip. To me they look to be targeted at different markets. XMOS seems to have target high end embedded stuff and compute farms, etc. The Prop OTOH looks to be marketed as a low cost, multicore embedded micro.

Apples and oranges IMO.

OTOH I do see the ARM variants as the chips to beat if the Prop wants to be a player in either the consumer electronics market or some other field say like medical electronics.

FWIW

SRLM
01-13-2009, 04:20 AM
Not so much apples and oranges, more like Red apples and Granny apples...

ianw
03-12-2009, 06:00 AM
Not to reopen an old can of worms, but how are propeller enthusiasts getting along with this chip now that they have given it some of their time?

I saw this post on the XMOS forums (back in October) regarding several propeller enthusiasts active in these forums, apparently crossing over to XMOS:
www.xlinkers.org/forum/viewtopic.php?f=3&t=93&st=0&sk=t&sd=a (http://www.xlinkers.org/forum/viewtopic.php?f=3&t=93&st=0&sk=t&sd=a)
Although Leon and Ale have developed some code for the XMOS and Leon is probably more active in the XMOS forums now than the propeller forums, several of the other folks (heater coley, timothy, cluso) mentioned in the thread above seem to have not gone much further with the XMOS. Was productivity trickier than the Propeller?
Their is a nice set of code examples accumulating in their obex: www.xlinkers.org/projlist (http://www.xlinkers.org/projlist)
But it is still no where near the level that is in the Propeller Obex

I've been working with two other regular posters to these forums on a multi rotor craft and one recently decided the XMOS was a better solution for his efforts than the Propeller. We debated crossing over to the XMOS with him, but will stick with the propeller temporarily. I think all three of us are curious how the pioneers listed above have found the development experience with the XMOS chips relative to the Propeller though.

In a previous post by Leon he indicated there will a single cog version available in volume at $1. This does seem very interesting. For example I may want to use Propeller code for a task, but only need 1-3 cogs and can't justify a $15 chip, especially if considering volume. But I could not find this statement on their forums, so was not sure how that price was derived - apparently it will be released later this year.

Looking at the underside of the evaluation pcb posted by timothy, it seems there are many more component dependancies for an XMOS setup than Propeller. The other concern is that this requires a 6 to 8 layer pcb, and that takes me outside the realm of free versions of Eagle or Target3001.
www.flickr.com/photos/brilldea/2963394963/sizes/l/ (http://www.flickr.com/photos/brilldea/2963394963/sizes/l/)
You can get a more complete dev kit too, the XDK, but are they serious? $999 - that's not hobbyist friendly

I'd like to ask how the Propeller II will match against this, since I might be less tempted to stray, but I know that's taboo.

Luis Digital
03-12-2009, 08:17 AM
The success of the Propeller is for:
Parallax is recognized globally.
Many years in the business.
Distributors throughout the world.
Propeller is easy to use (Software and Hardware).
Only 13 dollars (if cost more I would not buy it, and I expect that its price descend, since is a mature product).
Propeller Protoboard at 19 dollars http://forums.parallax.com/images/smilies/smilewinkgrin.gif (Now 32.00)
The support of all the community.
The version for Linux/MacOS (Thanks Brad).

But certainly XMOS has something very powerful (http://www.hexus.net/content/item.php?item=17513), and we waiting since years ago the Propeller II, as was promised. http://forums.parallax.com/images/smilies/cry.gif

Peter Jakacki
03-12-2009, 08:34 AM
There are a few applications where the XMOS would be a good choice but I shy away from the power (120ma quiescent) and pcb requirements (BGA multilayer) of a monster chip. A lot of applications can get by with a simple simple 8-bit CPU so Propellers eight 32-bit cores might seem overkill for most applications yet the Prop is in my opinion even easier to use than the 8-bit'rs. As for that magic $1 silicon I will believe it when I see it but I very much doubt that will happen.

Good luck to the XMOS boys and I may hop on that wagon if it's going my way but my love is the Prop chip. It is both a "hobbyist" chip and also a very serious (but fun) commercial chip. Viva la Prop!

Prop II will be here before we know it but a watched kettle never boils, so keep busy with THE Propeller chip.

*Peter*

Cluso99
03-12-2009, 11:14 AM
I am still here, not there... so does that answer the question.

As Peter said, the prop is a joy to use, both software and hardware wise. To save complexity, just add more standalone props and link them together. Take a look at the TriBladeProp. Also the standalone props designed just for a single (but complex) job - the VT100 Terminal on a pcb for use with other micros, this website (becuase I am not sure how much I can reveal) www.propgfx.co.uk and others.

My TriBladeProp uses one prop for I/O expansion - it is a simple and actually cost effective way for a multipurpose, fully programmable, I/O peripheral. Another prop is used for the VT100 (or whatever) standalone peripheral in a single chip. I have provided the prop with extra SRAM should we want better graphics. Once again, this is a cost effective way and reduces the complexity for the programmer. The third prop has SRAMs and microSD for all sorts of powerful code. Once again this is a cost effective way to do this and gives us 8 cogs to do whatever we want. Things like PropDOS for a prop SBC (Single Board Computer), Z80 + CP/M (heaters iCog), and other emulations come to mind.

I have used co-operating microprocessor techniques since the early 80's. As I said above, it is a cost effective way to add functions to the processor and saves the complexity for the programmer. And we are using the same micro so only 1 set of code to learn.

The prop is a very powerful chip and with 8 cogs (real 32 bit processors) and the simple interface, we have a brilliant chip. Add a few together and you have a very simple architecture, easy to maintain, and easy to code.

Hope this says why I am still here having a ball http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Bill Henning
03-12-2009, 11:27 AM
Xmos looks like an interesting chip, but I am staying away from it and concentrating on the Propeller. Why?

- Xmos "on-line" compiler for the inexpensive dev kit. Sending all my source to their web site... I think not.
- $999 "more complete" dev kit / compiler. I think not.
- availability of 40 pin dip propeller. Add a handful of parts, and you have a new board.

If Xmos was available as a dip part, with a free/cheap (off-line) dev kit, I'd look at it, but so far, I *REALLY* like the Prop.


ianw said...
Not to reopen an old can of worms, but how are propeller enthusiasts getting along with this chip now that they have given it some of their time?

I saw this post on the XMOS forums (back in October) regarding several propeller enthusiasts active in these forums, apparently crossing over to XMOS:
www.xlinkers.org/forum/viewtopic.php?f=3&t=93&st=0&sk=t&sd=a (http://www.xlinkers.org/forum/viewtopic.php?f=3&t=93&st=0&sk=t&sd=a)
Although Leon and Ale have developed some code for the XMOS and Leon is probably more active in the XMOS forums now than the propeller forums, several of the other folks (heater coley, timothy, cluso) mentioned in the thread above seem to have not gone much further with the XMOS. Was productivity trickier than the Propeller?
Their is a nice set of code examples accumulating in their obex: www.xlinkers.org/projlist (http://www.xlinkers.org/projlist)
But it is still no where near the level that is in the Propeller Obex

I've been working with two other regular posters to these forums on a multi rotor craft and one recently decided the XMOS was a better solution for his efforts than the Propeller. We debated crossing over to the XMOS with him, but will stick with the propeller temporarily. I think all three of us are curious how the pioneers listed above have found the development experience with the XMOS chips relative to the Propeller though.

In a previous post by Leon he indicated there will a single cog version available in volume at $1. This does seem very interesting. For example I may want to use Propeller code for a task, but only need 1-3 cogs and can't justify a $15 chip, especially if considering volume. But I could not find this statement on their forums, so was not sure how that price was derived - apparently it will be released later this year.

Looking at the underside of the evaluation pcb posted by timothy, it seems there are many more component dependancies for an XMOS setup than Propeller. The other concern is that this requires a 6 to 8 layer pcb, and that takes me outside the realm of free versions of Eagle or Target3001.
www.flickr.com/photos/brilldea/2963394963/sizes/l/ (http://www.flickr.com/photos/brilldea/2963394963/sizes/l/)
You can get a more complete dev kit too, the XDK, but are they serious? $999 - that's not hobbyist friendly

I'd like to ask how the Propeller II will match against this, since I might be less tempted to stray, but I know that's taboo.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

Ken Gracey
03-12-2009, 11:36 AM
For those of us who are citing Propeller prices, I should let you know that they're going to get really better as soon as Lauren lets loose (Qty 1 of any package: $7.99). Right now we're in the mandatory "distributor notification period" and once that's done you'll know about it officially!

As for the XMOS comparison, there's so much more than specifications. If all that people cared about were side-by-side specifications and they migrated to the "most capable" device, the BASIC Stamp would have been dead a long time ago but it's still finding new customers.

Ken Gracey
Parallax, Inc.

BradC
03-12-2009, 11:40 AM
Ken Gracey (Parallax) said...
For those of us who are citing Propeller prices, I should let you know that they're going to get really better as soon as Lauren lets loose (Qty 1 of any package: $7.99). Right now we're in the mandatory "distributor notification period" and once that's done you'll know about it officially!



Now we are cooking with gas! With the way the exchange rate has headed for us antipodeans I was starting to have to balance the ease of use against the price. This sweetens the deal considerably. Now I don't suppose this might follow on to a price drop of the Proto Boards by any chance ?? ;)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

heater
03-12-2009, 12:26 PM
Cluso, You are a genius! You wrote "heaters iCog". I was trying to think up a name for a cut down Intel 8080/5 only version of the ZiCog emulator. "iCog" is obviously it. Or was that a typo;)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Ken Gracey
03-12-2009, 12:29 PM
BradC,

Proto boards are free for you because of your Mac/Linux efforts, so you can consider that a "price drop". Just tell me how many you need!

Ken Gracey

william chan
03-12-2009, 01:35 PM
Is the Propeller price reduction due to an imminent release of Prop II?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

Coley
03-12-2009, 05:13 PM
I did have a brief flirtation with XMOS but I found it's IDE clunky, it's nowhere near as user friendly as the Propeller IDE.
I looked at it for an XMOS derivative of PropGFX but it's video generating capabilities are not as efficient in terms of resource allocation as the Propeller.
I was completely drawn in by the 400 mips with 8 threads on 4 tiles which sounded like a dream but the reality was somewhat different.
I was also shocked by the heat generated from the chip itself, seriously those things can burn!

There is no doubt it is a very capable piece of hardware but it's not for me.

The truth is I just missed my first love the Propeller too much, it's soooo easy to work with.

I'll just be patient and wait for Prop II (hint, hint, Chip!)

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX (http://www.propgfx.co.uk) - The home of the Hybrid Development System and PropGFX Lite

Leon
03-12-2009, 05:16 PM
ianw
-----

The single core XMOS chip will be available in a couple of months (QFN package), and a double sided PCB will be suitable. The eight hardware threads will be ample for many applications, giving a total of 400 MIPS. Having 64 I/Os will make it suitable for lots of interesting applications. The $1 price is for large quantities (like 250,000). A single chip will probably be about the same price as the Propeller.

It is feasible to put the BGA XMOS chips on a four-layer PCB, which isn't too bad.

The hardware works as advertised. The free tools include a debugger and simulator as well as XC and C compilers, and are pretty good. I am beta-testing the new timing analyser, which helps in the development of true deterministic code.

As with the Propeller, functions usually implemented in hardware are implemented in software. High-speed USB and Ethernet as well as the usual SPI, I2C and async comms are available as free downloads, as well as lots of other stuff.

Ale is the most productive Propeller user working with the XMOS chip, having implemented some nice VGA applications. The main limitation is the 64k of memory available on each core, which restricts the resolution. It isn't a limitation with most applications.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 3/12/2009 10:22:17 AM GMT

Erik Friesen
03-12-2009, 07:08 PM
Ken, that is great news. That puts the prop in a good price/value range.

Cluso99
03-12-2009, 07:42 PM
Excellent news Ken. This is a significant reduction 38% http://forums.parallax.com/images/smilies/smile.gif

Makes using props as peripherals to props even better!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Gadgetman
03-12-2009, 08:05 PM
Ken Gracey (Parallax) said...
BradC,

Proto boards are free for you because of your Mac/Linux efforts, so you can consider that a "price drop". Just tell me how many you need!

I think this single post shows more than anything·what the real advantage of the Propeller is.·It's hard to beat this kind of customer service. :-)



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Baggers
03-12-2009, 08:21 PM
You got it in one there Gadgetman, plus this forum, is full of amazingly talented, and helpful people, which is probably why Leon keeps coming back here :D lol
You just can't beat the Propeller for soooooooooooo many reasons, yes, it may not be the fastest chip in town, or have the most memory, but it has SOOOOOOOOOOOO much more to offer than any other micro I've worked on, heck, it's even more enjoyable than any games console I've worked on, and believe me, I've worked on all the mainstream consoles, and enjoyed them all, but nowhere near as much as I've enjoyed working on the propeller.
Thanks guys, and not just the Parallax people, but all on here too. :D

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Ken Gracey
03-12-2009, 08:50 PM
@William. No, there is no relation and these are two mutually exclusive, independent events. As you have asked many times, and we have answered: there is no release date for Prop II. It's not even laid out yet. There is no release date. We don't know the cost or price of it. We will tell our customers when it is available.

Ken Gracey
Parallax, Inc.

Oldbitcollector (Jeff)
03-12-2009, 09:18 PM
I'm not just a Propeller "yes man", I do in fact read everything I can get my hands on regarding micro controllers. Parallax has set the bar very high.

The Propeller is the best bang for the buck and easiest to use for the level of functionality it provides.
The only processor I see that might surpass it will be the Propeller II.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

Rayman
03-12-2009, 10:54 PM
I'm glad I just read Ken's post! I was just about to order 20 chips... Be waiting a bit now...

hippy
03-13-2009, 08:37 AM
I can think of a number of (personally) negatives for the Propeller and tools but if anyone asked me which chips I'd prefer to be working with day-in, day-out it would still be at the top of my list.

It's the best micro I've found for Rapid Application Development and prototyping, and I love the clean, uncomplicated architecture. If nothing else, the less there is, the less you have to learn. The great thing for me is that you can go from throwing something quick and dirty together in Spin to fine-tuning it to high-speed PASM or LMM.

Oldbitcollector (Jeff)
03-13-2009, 09:20 AM
Wow.. Ray somehow I missed Ken's first post. That is awesome news!

@BradC, sounds like you've got Protoboards for your next projects.. :)

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

Cluso99
03-13-2009, 01:11 PM
So Brad, now we need a propeller based pasm/spin compiler... pretty pretty please http://forums.parallax.com/images/smilies/smile.gif http://forums.parallax.com/images/smilies/smile.gif http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), SixBladeProp (http://forums.parallax.com/showthread.php?p=780033), website (Multiple propeller pcbs) (http://bluemagic.biz/cluso.htm)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Ale
03-13-2009, 01:52 PM
The prop is great for loads of reasons, simplicity is one of them, hardware and soft-wise. OK, it is multicore, but if that is a problem for you (not yet multi-core aware brains without latest updates :D), just think of them as interrupt driven and voila, it is as if it were :D.
The XMOS device is something else, tools are gcc/gdb based. That means quite a bit if you are custom to gnu tools (like me). But it has some niceties: a cycle exact simulator! (slow but useful to catch exceptions), and a time analysis tool as Leon said, and the tools work not only on winblows but also on MacOS X and Linux natively. Well, now that we have BST (thanks again Brad!), that is a no issue to me.
The online IDE... I never used it that much, I prefer local tools.
Hardware wise, well you have to do almost everything with software, but the ports are a tad more flexible than the Prop's. It is a different beast. Do not compare them, because they are for different purposes.

Did I said something new ?

sfx
04-26-2009, 04:13 PM
I just received my first Propeller (Demo board), and I'm currently comparing it to other options for low-power 4-channel audio processing for acoustic localisation (I basically need to do a convolution on 4 simultaneous 24-bit audio streams at 96kHz), at lowest possible power consumption and lowest possible complexity and size.
Reading through this discussion was very interesting, as it scratches a few of the things that I'm concerned about.

There's a few things that I found difficult to compare, that came up a couple of times:

MIPS performance: comparing the "speed" is quite difficult, and obviously the XMOS has far more MIPS, at higher power consumption, higher price and higher complexity. So does the ARM7 running at 400Mhz, or the Analog Devices BlackFin Dual Core running at 800Mhz. They are different CPUs for different purposes - nobody would use a BlackFin to build a weather station.
In terms of multi-CPU I'd like to mention the PowerPC MPC series, i.e. MPC5554 and similar processors - it's only single core, but has multiple TPUs (time processor units) which are freely microprogrammable parallel processors, that allow cycle-accurate real time response, and can be linked together. In terms of "programmable peripherals" that gets quite close, but the chips are far more expensive, and board design is more complex. But again, it's a far bigger, more powerful processor for completely different things. But then, it does have support for the Ada language :)
In terms of power consumption I find the Atmel AVR32 comparable, which is also comparable in price, and also has roughly the same speed in MIPS as it seems. It's only single core, so it doesn't answer the original question, but it has heaps of peripherals that can lessen the computational load. See next point.

Hardware peripherals vs. Cogs. I have to apologize if I get some things wrong and please correct me - I obviously don't have much experience with the propeller yet, but have worked on a range of other platforms (mostly AVR, PowerPC and ARM).
As a Propeller newbie, I tried to find out what can be achieved. I know that an 8-bit Atmel can run SPI at 10Mhz using its dedicated hardware, or up to clock rate on the AVR32s. - I checked OBEX and found the SPI drivers, but none specified what speed can be supported. Same goes for other interfaces (i2c, UART, i2s, etc).
Another example is hardware timers. By cleverly linking multiple HW timers, interrupts and output compare units, one can "easily" generate clock cycle accurate signals with zero jitter, while the cpu can go to sleep. Of course I can do that on a cog, but wouldn't the duration of instructions (4 cycles?) limit my timing resolution and accuracy?
My point is, the configurability of the Propeller is great, but needs MIPS - so it makes comparisons harder, and it's not quite clear without trying it out how much performance one can expect. Maybe someone can enlighten me :)

Interrupts and determinism:
I think it's important to distinguish between external and internal interrupts here. It is true that interrupts mostly ruin determinism to some extent (mostly introducing timing jitter, so in the end reducing timing resolution, but sometimes can really upset the system as well). However, it is possible to write code that uses interrupts and yet is 100% deterministic, i.e. if the interrupt is caused by an internal timer that is set appropriately, and the main loop is empty (idle). It does need some analysis to make sure that the interrupts don't interrupt each other. One application I used the timer interrupt to program the HW timer output compare for the next cycle, and was triggered after the next output event. That way the output edge was always 100% accurate and aligned with the system clock. Jitter was not visible, and probably in the low nanosec range.


Having said all that, i think the Propeller is a fantastically exciting processor, and I can see me using it as a much better, faster and more flexible alternative to the ubiquitous ATMegas in my designs.
I think Parallax could make the propeller more appealing to professionals by demonstrating the performance more clearly and showing what can be done at what accuracy and speed and what can't. Especially the performance of emulated peripherals is crucial to me if I want to connect high-speed ADC/DACs or other peripherals. While I can easily check the data sheet of i.e. the AVR32 UC3 or AP7000 to read about SPI clock rates, I2S support etc, I found it difficult to get that information for the propeller.

Post Edited (sfx) : 4/26/2009 9:27:52 AM GMT

Mike Green
04-26-2009, 09:43 PM
Some comments:
"Hardware peripherals vs. Cogs"
By cleverly linking cog timers and cogs, syncing multiple cogs, and/or possibly communicating via otherwise unused I/O pins, one can "easily" do all sorts of very complex signal generation to a resolution of one clock cycle on the Propeller. Yes, the basic instruction time is 4 clock cycles (50ns), but, depending on the particular application, you can get quite clever about doing things faster using more resources. The use of multiple cogs (6) to get 1600 x 1200 pixel VGA output is one example.

"Interrupts and determinism"
The WAITCNT instruction does allow a cog to synchronize itself to a specific clock cycle and the WAITPNE/WAITPEQ instruction allows a cog to synchronize itself to a specific I/O state, both with a granularity of a single clock cycle and complete determinism.

You're correct about the value of lots of application notes and similar documentation. As is usual for small companies, Parallax runs a "tight ship" and people tend to wear many hats and stay very busy. There's simply not enough resources (very talented and experienced people) available for the sort of documentation you're describing to be done in anything other than years of one little side project at a time.

One difficulty about using software to implement functional blocks over functional blocks in hardware is that things are so flexible. Usually there's a constant tradeoff of speed vs. functionality or memory space that doesn't exist with hardware functional blocks. For example, there are now 3 or 4 ways at least of doing buffered asynchronous serial I/O with tradeoffs of code size, maximum Baud, other features like handshaking, etc. There are several ways of doing I2C, several ways of doing SPI, etc. Really high performance applications tend to integrate the I/O functionality into the rest of the code rather than use more general purpose library routines, so general statements in a datasheet may not apply.

pgbpsu
04-27-2009, 01:00 AM
@sfx

Welcome to the prop community. I think you'll find all of what Mike Green said to be true. And if you spend any amount of time on the forums, you'll quickly learn that he really knows his stuff. He was favorably compared to Santa Claus last Christmas because of how much he gives to everyone here. I've often been on the recieving end of Mike's advice.

The project you briefly describe will be challenging, but I believe it can be done in the Prop (with Assembly). I have a device based on the Prop which reads 4 channels of 24-bit data from audio ADCs. These data are read and averaged then dumped to HUB RAM for other cogs to work on. The ACQ and averaging takes 2 cogs for all 4 channels. @96Khz we were just able to get our 24-bits out of the 32-bit output word (we're using the AD1871. What ADC are you using?). The lack of a PASM multiply will makes this a bit more complicated, but there are easy to find mul routines in PASM which will do this. Depending on how many other jobs this Prop has to handle (driving display, data storage, etc) you may have enough resources to do real-time continuous analysis.

When you get your project going, or hit a snag, be sure to post on a new thread so we can see how this project comes along.

Best of luck,
Peter

Leon
04-27-2009, 01:24 AM
I don't think that convolution for acoustic localisation is feasible on 24-bit audio streams at 96 kHz, on the Propeller. There simply isn't enough memory.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 4/26/2009 6:30:55 PM GMT

sfx
04-27-2009, 11:27 AM
Thanks for the quick and detailed responses.
I haven't fully decided on the ADC yet - probably either TI's ADS1274 (has SPI data interface, industrial grade ADC with very good SNR and low drift) or one of the audio CODECs (not 100% sure if I need a dedicated DAC as well).
It's good to know that it seems to be possible to get the data rate into the chip. I assume you were using two chips - was that to be able to use two cogs independently to grab the data? would it be possible to read a single SPI stream with all 4 channels, or is that too much?
In terms of memory, 32 +8x 2kb Kb isn't that much (definitely looking forward to a Propeller 2 with more onboard RAM :) ), but I think it'll do. I expect maybe 10 samples maximum search width (pretty short baseline) and a window size of 256 samples at most. As everything is running in real time there is no need to keep any more data than the last windowsize plus search size (unless I want to use some pre-calc optimisations to speed it up).
The main concern I have though is about the lack of hardware muls. My other choice at the moment is the AVR32 (AT32UC3A1256) which has 64 Kb RAM, 1-cycle instructions, muls, and of course all the peripherals. It's only spec'ed at 90 MIPS (@66Mhz), so it's a bit slower, but given the multiplication issue it might actually be faster for my application...
Maybe I just have to make two test boards, one with Propeller and one with AVR32 and see which one wins :)
Of course a slightly bigger processor might be better suited, but I'm trying to avoid the complexity of external RAM, BGA packages, complicated boot setups, memory map configurations etc. (and I don't want an OS running as I need fairly high sync accuracy).

James Long
04-27-2009, 12:26 PM
I have been a Parallax family member since way before the forum. I like Parallax, and their products.

I do not knock the Xmos products, but I know little about them. I don't think I will either with the price tag they have hung on the header of that board.

I have looked around, and considered many other development systems, but I always return to Parallax. Some of their items are a little pricey, but pound for pound, dollar for dollar, you will not find better customer support, nor an easier product to start with.

I'm sure there are many other systems out there that can do this or that, but the product is not all I look at.

I'm late into this discussion, but I was around way before the Propeller, and will be long after Propeller II.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services (http://www.lil-brother.com)

mctrivia
04-27-2009, 12:35 PM
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 (http://propmodule.com) has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

pgbpsu
04-28-2009, 09:27 PM
@sfx

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 (http://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.

Chris_D
04-29-2009, 03:35 AM
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.·



Chris

Agent420
08-11-2009, 07:05 PM
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.

Post Edited (Agent420) : 8/11/2009 2:13:57 PM GMT

Mike Green
08-11-2009, 09:30 PM
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.

hover1
08-11-2009, 09:52 PM
I would think if the Propeller wasn't doing well, there would be more 40 Pin DIP's in stock.
http://www.parallax.com/Store/Microcontrollers/PropellerChips/tabid/142/CategoryID/18/List/0/SortField/0/Level/a/ProductID/332/Default.aspx
Just an observation.

·· If I had to infer, I'd guess Parallax doesn't think the Prop is doing as well as they hoped

Oldbitcollector (Jeff)
08-11-2009, 09:57 PM
Expo attendance is up... Even with the UPEW expo, which I thought might steal some
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 (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

Agent420
08-11-2009, 10:04 PM
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.



Post Edited (Agent420) : 8/11/2009 3:35:16 PM GMT

BradC
08-11-2009, 10:42 PM
Agent420 said...

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?

HollyMinkowski
08-11-2009, 10:45 PM
@Agent420

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.

SamMishal
08-11-2009, 11:04 PM
Agent420 said...

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.


I've been working with micros since 6502/z80 days, so I feel I have a good understanding of what is going on,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:



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
·

Agent420
08-11-2009, 11:08 PM
BradC said...

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.


@HollyMinkowski (http://forums.parallax.com/member.php?u=56533):

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.

SamMishal
08-11-2009, 11:25 PM
BradC said...
·Debuggers are highly overrated.

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.http://forums.parallax.com/images/smilies/tongue.gif

Sam

heater
08-11-2009, 11:39 PM
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.

Agent420
08-11-2009, 11:43 PM
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 :)

Post Edited (Agent420) : 8/11/2009 8:01:32 PM GMT

jazzed
08-11-2009, 11:45 PM
Fascinating topic as always :) Aside from the expected ranting from certain members ....

If you want to run PASM on all cogs, you can. Linus Akesson (http://www.linusakesson.net) 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 http://forums.parallax.com/images/smilies/wink.gif 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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Agent420
08-11-2009, 11:48 PM
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.

Nick Mueller
08-11-2009, 11:49 PM
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 (http://www.yadro.de)

Agent420
08-11-2009, 11:56 PM
jazzed said...
Fascinating topic as always :) 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 http://forums.parallax.com/images/smilies/wink.gif 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?

jazzed
08-12-2009, 12:02 AM
No bashing interpreted :) ... 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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Nick Mueller
08-12-2009, 12:05 AM
> So a Spin based app really leaves 7 cogs free for user code?

Right!
You might also say, its a waste of resources. http://forums.parallax.com/images/smilies/wink.gif



Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Agent420
08-12-2009, 12:09 AM
jazzed said...
No bashing interpreted :) ... 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 ;-)

heater
08-12-2009, 12:40 AM
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.

heater
08-12-2009, 12:45 AM
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.

Agent420
08-12-2009, 01:08 AM
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.

heater
08-12-2009, 01:23 AM
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.

Cluso99
08-12-2009, 01:24 AM
spin uses a cog, just like pasm. But, you CAN run 8 cogs of spin http://forums.parallax.com/images/smilies/smile.gif 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:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

jazzed
08-12-2009, 01:34 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

heater
08-12-2009, 01:40 AM
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.

jazzed
08-12-2009, 01:52 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Microcontrolled
08-12-2009, 08:59 AM
I think that of all the microcontrollers out there, the Prop is the best for the money. What other chip can just handle video and keyboards without any external drivers?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just call me micro.


If it's not Parallax then don't even bother.
·
I have changed my avatar so that I will no longer be confused with others who use genaric avatars.

Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order.
Cheap·shipping unless specified!··········150 left!!··

hinv
08-12-2009, 11:22 AM
When comparing to other microprocessors, there are things I like about the propeller, but most of all it is the support(and entertainment) of this forum.
Some things I like about others:
The SeaForth processors have Up, Down, Left, Right registers that link their processors together. When you try to read one that hasn't been written yet, the processor stalls(sleeps) until it is provided by the writers side.
This is done in hardware, and will stop an instruction unlike WaitPNE which has to be added to your code. This type of logic could be put in the cogs registers. It would take 4 more of those precious longs, but think of the possibilities!

Another thing I like about others is more IO pins. A year ago, when it was decided to not pursue the P8x32B, for dedicating resources to the prop2, I was disapointed, and still am. The extra IO's would have helped greatly with external memory and such, and because the prop1 is a lower power processor, it will still be used for many applications in the future. Of course, when Prop2 comes out, I reserve my right to change my mind;^) but I think that is too big of a step. The 64io prop would have filled in nicely(and depending on how long it will take for the prop2, it still can)

As for other processors. Notice I am wanting features added to my prop. I don't plan on going anywhere other than to look around. I like the simplicity. I like having no interrupts! I like all of the amazing stuff you guys develop and give away here on the forum. I have listened to the same 5 songs I have in midi about 6 times today because it is so amazing what sounds can come out just 2(left and right) pins! Thanks Ariba!

Just my 10 bits worth,

Doug

heater
08-12-2009, 01:12 PM
hinv: You are so right.
About the forum, about the CPU-CPU communication, about the I/O pins, the lack of interrupts, the simplicity....

The Prop is a strange beast:
Too big to compete with the weeny PICs and AVRs at jobs where they fit.
Too small to compete with the Linux running ARMS and such.
Has the awesome power of 32 bit CPUs (8 of them for god sake) but the terrible confinement of 496 instructions each.
Has the most simple, regular, instruction set/ASM syntax of any processor I've used seriously but is totally not suited to running compiled high level languages.

Maybe Parallax should be called "Paradox".

An aside: I recently had to knock up a device driver for Linux to wiggle some simple I/O pins. The equivalent of "DIRA something" and "OUTA/INA something" for the program that uses it. Very simple in terms of Linux device drivers but still a couple of hundred lines long and a fair bit of Linux device driver research required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Praxis
08-12-2009, 05:10 PM
This thread is always a good read particularly the comments about debuggers.

Sort of like Real Programmers do not use debuggers etc.

That's like saying I have never used a spell checker as only real writers can use a word processor without a typo or a PCB design rule checker for example.

Anyone here remember Bishop Graphics artwork materials for PCB layout?

Although a debugger is a bit overboard for "Hello World" but sometimes complex tasks require complex tools.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Caelum videre iussit, et erectos ad sidera tollere vultus

Certe, toto, sentio nos in kansate non iam adesse

heater
08-12-2009, 05:51 PM
Eye always do a spill chick.

I don't really have a downer on debuggers. But what is a debugger? That oscilloscope I watch the outputs with, the logic analyzer hooked on the bus between CPUs. I've used a telephone ear piece to listen to bugs when no other equipment was available.

I've often heard that some like to single step their way through code to "see that it works" prior to running for real in the live system. That's fine but if you are going to do that why not wrap the module in a test harness that checks a lot more possibilities than you ever will single stepping manulally, can be repeated easily when you modify your code, and takes about as much time and effort as the sigle step in debugger exercise.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

ErNa
08-12-2009, 06:05 PM
just a comment: heater, you are right. An ear is such a perfect instrument. I did the same! And the prop gives you a bitmap on a screen and you see the bits changing in real time. Again just versatility.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_ 5511&partName=htmltext (http://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 http://forums.parallax.com/images/smilies/wink.gif

SamMishal
08-12-2009, 06:56 PM
Praxis said...
This thread is always a good read particularly the comments about debuggers.

Sort of like Real Programmers do not use debuggers etc.

That's like saying I have never used a spell checker as only real writers can use a word processor without a typo or a PCB design rule checker for example.

Anyone here remember Bishop Graphics artwork materials for PCB layout?

Although a debugger is a bit overboard for "Hello World" but sometimes complex tasks require complex tools.

Cheers


Comparing a debugger to a spellchecker is the wrong analogy. A spellchecker is more akin to the compiler
catching your syntax errors. Consider this sentence:
············· These ease a cent en that ill a straits y a spellchecker dos nut work all these time.
············· (this is a sentence that illustrate why a spellchecker ·does not work all the time)

The above will pass a spell checker, but is very obviously in semantic error. Consider this one
················ I want to ensure my car
Can you see the error here? a spell checker did not catch this one either. But its semantic error
is not very obvious. Can you see the problem?? Look again….can you see it now? No….then you
need an English language debugger. If you saw it already then you do not need an English language
debugger.
Here is another one of my favorite subtle English semantic errors
···················· This has a bad affect on the environment.
Neither a spellchecker nor a grammar checker caught this one.
Sam

localroger
08-12-2009, 07:03 PM
When I was first learning to program, on a 2 MHz 8080A with no dev tools other than a hex editor, I used to use an AM radio to listen to the machine's RF pollution. I could easily tell when something crashed the interrupt system because its distinct 60 Hz hash would cease, and other common operations (like scrolling the screen) had easily recognizable signatures.

Agent420
08-12-2009, 07:14 PM
microcontrolled said...
I think that of all the microcontrollers out there, the Prop is the best for the money. What other chip can just handle video and keyboards without any external drivers?

Imo 'Best' relates to what you need to do.· It seems the Prop's video capabilties are fequently tossed around in this context, and I'll agree it's a very cool feature, but not every project requires a video display.· As for keyboards, virtually all the common chips can accomodate ps2 interfaces.


heater said...
The Prop is a strange beast:
Too big to compete with the weeny PICs and AVRs at jobs where they fit.
Too small to compete with the Linux running ARMS and such.
Has the awesome power of 32 bit CPUs (8 of them for god sake) but the terrible confinement of 496 instructions each.
Has the most simple, regular, instruction set/ASM syntax of any processor I've used seriously but is totally not suited to running compiled high level languages.
This is where I'm trying determine how the Prop fits in, I think you've encapsulated it very well here.

·

Nick Mueller
08-12-2009, 07:17 PM
Do you remember those cards that had an DAC on the lower 8-Bit addresses and one on the upper 8 bit addresses, each channel going to X or Y of an scope and the address-latch to the Z-input? http://forums.parallax.com/images/smilies/smile.gif

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Praxis
08-12-2009, 08:59 PM
SamMishal said...

Comparing a debugger to a spellchecker is the wrong analogy.



Perhaps but think of it more as a metaphor in that case.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Caelum videre iussit, et erectos ad sidera tollere vultus

Certe, toto, sentio nos in kansate non iam adesse

ericball
08-12-2009, 11:51 PM
heater said...
The Prop is a strange beast: . . . Maybe Parallax should be called "Paradox".
Too right.· On one hand the Propeller has some serious I/O power - eight 32 bit processors and 32 flexible I/O pins.· On the other hand, those 32 bit processors only have 486 longs of local RAM and 32K of shared RAM and no built-in external memory bus.· For stuff which fits into those limitations, the Propeller has definite advantage.· But if you have dreams of porting Linux or anything which needs more than 32K of RAM, you're in for a nasty surprise.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum (http://forums.parallax.com/showthread.php?p=800114)
NTSC & PAL driver templates: ObEx (http://obex.parallax.com/objects/483/) Forum (http://forums.parallax.com/showthread.php?p=803904)
OnePinTVText driver: ObEx (http://obex.parallax.com/objects/480/) Forum (http://forums.parallax.com/showthread.php?p=822453)

Granz
08-13-2009, 01:25 PM
parts-man73 said...
It confuses me why users of other microcontrollers have such disdain for the Propeller. I mentioned it on another microcontroller forum (which by the way, is not for any specific micro, so it wasn't like I was posting on another company's turf) and I received responses that made it obvious that they didn't want to hear about the Propeller.

I really think that if they got over themselves and tried it, they'd love it. (if they went into it with an open mind)

I do believe there is the right tool for the right job. Just as you wouldn't try to drive a nail with a screwdriver, you don't need a Propeller to drive a HD44780 LCD. I simple $3 PIC will suffice. But the speed in which you can develop a project always impresses me (that coupled with the fact the I have an abundance of Propeller circuit boards around http://forums.parallax.com/images/smilies/smilewinkgrin.gif ) that I use a propeller in most every project nowadays.


I am an Atmel user and I really like their controllers.

That said, though, I also truly like the propeller. I am fairly new to the propeller (although I have been working with computers for nearly 35 years, and according to my mother, been working with electronics since she gave me a battery, wires and a light bulb at age 2) I think that there is a lot of potential with that system (hard to call it just a microcontroller with eight computers on one chip) and I think Parallax really outdid themselves. I originally became acquainted with Parallax through Scott Edwards' Counterfeit Stamp article in Nuts & Volts. I built one of those and really enjoyed the simplicity and versatility of that little circuit. Since then, I played around a bit with Microchip's PIC series, but really got down and dirty with Atmel's AVR line. I wrote the instruction manual for the Chibot (Chicago Area Robotics Group) Table Top Bot from Wright Hobby Robotics which uses an AVR Mega-48 for it's brain, and am in the process of writing an Introduction to Microcontrollers book with a kit for the Tiny 13, an Introduction to Robotics with a $15-$25 bot based on the Tiny 2313 and a more in-depth college-level Microcontroller Course book with a full-featured development kit, based on the Mega 8 and the Tiny 13 (master-slave topics will be introduced, along with other topics). Most of my material is aimed at the student scientist or student engineer (or younger students who have an inclination towards engineering/science). In other words, I also have a large number of microcontrollers around (mostly Atmel, but several TI's, a Renasas, a couple of PICs, several MC6800s, a couple of RCA 1802s and several Z-80s). I can put together a simple project in a very short time with the chips and boards that I have on hand.

Even though I have been involved with computers since 1975 and controllers, specifically since 1994, I did not really notice the propeller other than to think that it looked kinda cool ("...but, I'm really busy with my day job - network engineer for a major insurance company - and my Atmel stuff"). It was the announcement about the UNPENE in Ohio next weekend that got my attention. I really love going to electronics expos, but can't afford to get to the West Coast for theirs. This one was going to be close enough that I thought that I may be able to make it. Well, if I was to be going to an expo on the Propeller, I really thought that I should get to know the "wee beastie" (as my favorite 23rd century engineer puts it). I have ordered and received the parts to put together a simple development system (almost done wiring it up - this Saturday should do it). I plan on having a simple demo for the expo, showing how simple and cheap it can be to get into the field with the Propeller. Already, ideas are starting to form in my head about books and kits that I can write/put together featuring the Propeller. I really do like the Propeller, but this system is not really a microcontroller - kinda like comparing a small office network, with server, workstations, network printers and internet gateway/router to a lone computer.

All of this long-winded essay is just to say that not all "users of other microcontrollers have such disdain for the Propeller." There are a lot of us out there who do not need to have "got over themselves and tried it". Those of us who are in this as a real hobby or a profession are going to be open-minded enough to try it, we just need something to tip the scales and break into our busy schedules (thanks a MILLION for the effort that you have put into this Expo, OBC!)

Art G. Granzeier III, President
Granzeier Consulting