Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Datasheet — Parallax Forums

Propeller Datasheet

NateNate Posts: 154
edited 2006-02-26 21:28 in Propeller 1
I'm not posting a datasheet, I'm asking for one.

Really, this is the most assbackward product launch I have ever seen.· Parallax has developed a new product, but instead of giving out a basic spec sheet we must all play 20 questions?· Looking at that last thread, I could not believe that people are trying to learn the new Spin language or Assembly one command at a time in an entirely random order!·

Why not publish a basic datasheet with what you DO have nailed down, and attach a 'all is subject to change.'· ·If people complain about small changes as the·final product comes out, well, though luck for them.

This sounds like a great product, and if Parallax is smart they will sell it for a ridiculusly low price, establishing a market dominance that no one will ever overcome.·

I actually started this thread to congradulate Parallax, and be the first non-Parallax employee to start a thread in the Propeller forum.· I WIN!!!

Nate·
«1

Comments

  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-02-20 23:02
    What we are willing to put into print (web format) can be found at: http://www.parallax.com/propeller.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2006-02-20 23:06
    I'm sure the release wasn't meant in this fashion or order, but the documentation is still undergoing final revisions.

    Chip, Jeff and many other staff at Parallax are working non-stop to ensure all in order for it's very soon release.

    Jeff has been good enough to try an answer Q's here, but I'm sure it's really distracting him from getting it done, though I'm sure he's feeling like a proud parent right now.

    So, hang loose if you can? I know it's hard, and many of us have waited a long time for something to compete against the stampalikes.
    -Martin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel

    Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
    Southern Illinois University Carbondale -Electronic Systems Technologies
    Personal Links with plenty of BASIC Stamp info
    and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
  • ElectronegativityElectronegativity Posts: 311
    edited 2006-02-20 23:06
    The link is broken.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I wonder if this wire is hot...
  • ElectronegativityElectronegativity Posts: 311
    edited 2006-02-20 23:07
    Sorry, it's only broken if you copy the period at the end.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I wonder if this wire is hot...
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2006-02-20 23:25
    PS: Those who may not be familiar with Parallax internal workings, they have 2 people who did all this. Chip Gracey, the creator of the BASIC Stamp (which, if you think way back, was revolutionary - a controller you could program directly in a simple language!), and Jeff Martin, software guru. The two of them have been responsible for the IC design, layout, IDE and all the documentation for it. I had a glimps to come about 7 years ago when visiting Parallax for the 1st time and Chip explained a vague idea of what he wanted to do. My last visit 2 years ago it was near design completion and going off to fabrication. So for some of us, this has been a LONG time coming while the rest of Parallax's employees thrilled us with more gizmos, innovative products, educational materials and the SX. But this truly is the start and heart of Parallax - Having Chip Gracey going where none have gone before.

    So, these two are very busy trying to pull everything together, and you won't be dissapointed.
    -Martin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel

    Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
    Southern Illinois University Carbondale -Electronic Systems Technologies
    Personal Links with plenty of BASIC Stamp info
    and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
  • NateNate Posts: 154
    edited 2006-02-20 23:38
    "So, these two are very busy trying to pull everything together, and you won't be dissapointed."

    I sure we won't.· Perhaps someday we can tell our children "Yep, I was one of the first to see the Propeller come out - the chip that toppled the market dominance of Intel".....





    ......then we'll have to run for cover as the autonomus drones of the SkyNet come sweeping over, with their AI systems that run on hoped up Propeller chips, sweeping the earth with a pryrotechnic laser show of death and destruction.....
    ·
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-02-20 23:41
    We have no interest in dominating anything except our own desire to do things in the most efficient way -- we like microcontrollers and Chip wanted (and has) to create one that would let us do really cool things without jumping through a lot of unnecessary hoops.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • NateNate Posts: 154
    edited 2006-02-20 23:58
    That's what SkyNet said too.



    That was just before it decided we were a danger to ourselves and needed 'guidence'······

    ··· [noparse]:)[/noparse]
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-21 00:47
    It maybe backwards from the prospective of the industry, but its the correct order to do things. By not publishing docs, Chip and Jeff are free to change things as they progress. This affords them the most flexibility and permits them to choose the best course and not tie thier hands by releasing preliminary documents. If we did release the docs availible now, you would be disappointed. Many commands only have a brief description of thier purpose and very few examples of use are provided. That was what the seminar was for, to provide us examples and supply information on the fly in specific areas that needed explanation. Since neither the chip nor the IDE is availible to the public, releasing the documents would serve no utility, you wouldn't be able to write programs or start developing any projects. The only thing it would accomplish would to be generate hundreds of questions asking for further explanation, and this would distract Jeff from actually finishing up what needs to be done before it's release. So by releasing the docs you would be delaying the Propeller's release, is this what you want?
    Nate said...
    I'm not posting a datasheet, I'm asking for one.

    Really, this is the most assbackward product launch I have ever seen.· Parallax has developed a new product, but instead of giving out a basic spec sheet we must all play 20 questions?· Looking at that last thread, I could not believe that people are trying to learn the new Spin language or Assembly one command at a time in an entirely random order!·

    Why not publish a basic datasheet with what you DO have nailed down, and attach a 'all is subject to change.'· ·If people complain about small changes as the·final product comes out, well, though luck for them.
    The reason the industry does things in the reverse order is that they are publicly traded companies, and as such the marketing department releases preliminary datasheets to generate market buzz and to appease the shareholders. This tactic is actually not in the best interest of the company and time and time again leads to the product availibility to be delayed substatially. Parallax is a privately held company and as such does not have to play the dumb game that other leading compaines play to prop up thier standing on Wall Street.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10

    Post Edited (Paul Baker) : 2/21/2006 3:49:56 AM GMT
  • Jeff MartinJeff Martin Posts: 751
    edited 2006-02-21 02:44
    Paul Baker said...
    It maybe backwards from the prospective of the industry...
    Thank you, Paul.· Very well said.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Jeff Martin

    · Sr. Software Engineer
    · Parallax, Inc.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2006-02-21 08:06
    The 2006 Catalogue still has better information. [noparse][[/noparse]The picture is clearer, more text].

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

    ······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
  • bobledouxbobledoux Posts: 187
    edited 2006-02-21 13:43
    I'm flabergasted that this complex product development is only staffed by two people.

    I'm amazed there is a realm of microcontroller technology where you could spend seven years on the concept and still be at the technology forefront when the product is released.

    I'd like to have your crystal ball.
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-02-21 13:55
    I bet that the ONLY part of the design that has staid on since the beginning is the fact that it has more than one core...

    That it has wider instructions that 8bit isn't surprising as many microcontrollers do that, including PICs.
    What IS surprising is the width(32bit) and that it allows 'self-modifying code' which means that PROGRAM and DATA spaces must be able to overlap. (Something NOT found on most microcontrollers)

    This thing has me more excited than the two weeks I spent waiting for my iBook to arrive...
    And almost as excited as while waiting for my Psion S5...

    It's probably a good thing that the datasheets aren't available, yet, as I wouldn't be able to get anything done at the office...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • steve_bsteve_b Posts: 1,563
    edited 2006-02-21 14:04
    I am totally ecstatic to see new products from Parallax....
    I've had a great time with the stamps and have recently gotten setup with an SX kit (wow, the potential, too bad I got inebriated one too many times in the ice hut....I'll learn it though).
    In the past Parallax has taken shots from people about product teases.· Some people got VERY up in arms about a product that was supposed to be out at 'this' date and wasn't.·
    Parallax stopped giving out hints as to what was to come....granted, this is much larger, but I hope everyone keeps it in context and doesn't razz Parallax so much that once again we get our hands slapped.· Of course, one has to expect a little craziness in the hive when a somethings dropped in it, so don't be too mad at us, Parallax, for wanting to know more.·
    The can o'worms has been opened!

    Look forward to the docs when they're published!
    Paul Baker said...
    It maybe backwards from the prospective of the industry, but its the correct order to do things. By not publishing docs, Chip and Jeff are free to change things as they progress. This affords them the most flexibility and permits them to choose the best course and not tie thier hands by releasing preliminary documents. If we did release the docs availible now, you would be disappointed. Many commands only have a brief description of thier purpose and very few examples of use are provided. That was what the seminar was for, to provide us examples and supply information on the fly in specific areas that needed explanation. Since neither the chip nor the IDE is availible to the public, releasing the documents would serve no utility, you wouldn't be able to write programs or start developing any projects. The only thing it would accomplish would to be generate hundreds of questions asking for further explanation, and this would distract Jeff from actually finishing up what needs to be done before it's release. So by releasing the docs you would be delaying the Propeller's release, is this what you want?
    Nate said...
    I'm not posting a datasheet, I'm asking for one.

    Really, this is the most assbackward product launch I have ever seen.· Parallax has developed a new product, but instead of giving out a basic spec sheet we must all play 20 questions?· Looking at that last thread, I could not believe that people are trying to learn the new Spin language or Assembly one command at a time in an entirely random order!·

    Why not publish a basic datasheet with what you DO have nailed down, and attach a 'all is subject to change.'· ·If people complain about small changes as the·final product comes out, well, though luck for them.

    The reason the industry does things in the reverse order is that they are publicly traded companies, and as such the marketing department releases preliminary datasheets to generate market buzz and to appease the shareholders. This tactic is actually not in the best interest of the company and time and time again leads to the product availibility to be delayed substatially. Parallax is a privately held company and as such does not have to play the dumb game that other leading compaines play to prop up thier standing on Wall Street.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2006-02-21 15:19
    I feel like an 8 bit baby that is about to be weaned - cold turkey. It has been very comfortable to avoid even thinking about 16 bits.
    I guess I will just have to buy some wide-angle eyeglasses and accept the challenge. At least hexadecimal is more readable.

    I keep wondering about those 8 video processor boxes in the COGS.
    To date, I haven't really thought much of what a video processor can be, what it looks like, or how to program it. I can only imagine that with 8, you have some sort of animation ability - like having sprites in a video graphics card maybe. [noparse][[/noparse]Again there seems to be another portion of technology that I have been ignoring].

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

    ······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-21 16:19
    LOL... I had a dream about working with this...
    Gosh, it befoggles the mind what someone with some imagination can dream up with something like this...
    I can't wait....
    SHMBO has been softly informed,I found myself saying, and I quote myself here, "I will forgo the new 30" tires and 4 inch lift, in exchange for the this...."
    She gave me the "dear in the headlights look", "ok dear... if you want... I guess..."
    Now all I have to do is wait...

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

    Just tossing my two bits worth into the bit bucket
    KK
    ·
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2006-02-21 16:27
    Kramer said...
    I keep wondering about those 8 video processor boxes in the COGS.
    To date, I haven't really thought much of what a video processor can be, what it looks like, or how to program it. I can only imagine that with 8, you have some sort of animation ability - like having sprites in a video graphics card maybe. [noparse][[/noparse]Again there seems to be another portion of technology that I have been ignoring].

    What's extremely cool about the video is that the output to video is nothing more than a 4 resistor R-2R ladder to give the 'analog' levels needed.· I too hadn't really explored video principles much, but I'm learning a lot quickly now.

    Speaking of forgo-ing, you don't how much I spent in airlines, hotels and car rentals to be there and be able to get the hardware as a guest [noparse]:)[/noparse]· But it was WELL worth it, if only to see the Parallax gang once again.

    -Martin


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel

    Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
    Southern Illinois University Carbondale -Electronic Systems Technologies
    Personal Links with plenty of BASIC Stamp info
    and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
  • ElectronegativityElectronegativity Posts: 311
    edited 2006-02-21 19:30
    You might want to change the name of this thread before a thousand more people click on it in an attempt to find the propeller data sheet.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I wonder if this wire is hot...
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2006-02-22 06:15
    Repeat -- the best data is posted in the 2006 Catalogue. The other image is somewhat unclear.
    Is that still available or did Parallax remove it for some reason?




    We now have an excellent PDF that prints out as 8 /12 x 11".· Thanks



    I started a Video thread if you want to continue posting to that.
    There is an SPI thread too.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

    ······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

    Post Edited (Kramer) : 2/22/2006 6:45:01 AM GMT
  • Dan RogantiDan Roganti Posts: 11
    edited 2006-02-25 04:27
    Hi,
    I was wondering about the availability of a datasheet too. I took a look at the block diagram pdf on here. But I couldn't distinguish where on this processor is there an Interrupt pin. I do hope this was just overlooked when preparing the block diagram. I don't see how one can expect to create an embedded design without such a rudimentary but critical function for a processor.

    thanks,
    Dan
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-02-25 04:33
    Dan Roganti said...(trimmed)
    But I couldn't distinguish where on this processor is there an Interrupt pin.
    Dan,

    ·· There are 32 of them.· This is one of those times when you have to break away from conventional microcontroller designs...Instead of ISR or multi-tasking you have multi-processing, which means concurrent processes...8 of them.· Any one of those can monitor a pin and take action without affecting the others in any way.· Or it can affect the others.· Again, this is something completely different.· Time for a new way of thinking.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Dan RogantiDan Roganti Posts: 11
    edited 2006-02-25 05:17
    Chris,

    Yes, I'm familiar with Multi-processing, as I've designed with this in the past as multi-processors is already a conventional item. From what you're saying, it appears this uses software polling to emulate an Interrupt. You tend to waste precious CPU cycles polling an i/o pin for an event. Although this processor may run faster than the common 8bit MCU's, even the fastest processor justify the need for an interrupt input(even parallel processors). This might be fine if you want to wait for a switch to close. But in the real world an event is always unpredictable. This also factors into whether you can design a real-time system (including Parallel processing). A basic concept in computer architecture, you don't design a processor to wait for an event(ie. software polling an i/o pin), it supposed to react to an event(ie. interrupt the process).
    I've seen the pitfalls in some of the biggest companies, namely Motorola and IBM while I was working at Lucent, in designing their new processor chips. Some of the most basic functions such an NMI(let alone some of the more elaborate functions in the Cache) were mishandled on their newest generation processors. One of the important items these companies had was a relationship to garner feedback from their clients during the design phase of a processor chip. I hope this issue is not obscured here and suffers any pitfalls.

    thanks,
    Dan
  • Martin HebelMartin Hebel Posts: 1,239
    edited 2006-02-25 05:25
    Dan,
    Even when using typical interrupts though, it requires clock cycles to place return addresses on the stack, going into the ISR there may be multiple pushes to hold important data before the ISR code is ever executed, not to mention disabling of interrupts during critical main processor code, and having to deal with interrupt priorities or multiple interrupts.

    A cog has a hardware-wait which will cease execution until a pin, or a pin configuration, occurs, at which time the code will continue and is immediately executed. Besides tying up a multiple cogs possibly for different interrupt needs, I don't see much of a downside to this new way of approaching this problem.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Martin Hebel

    Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
    Southern Illinois University Carbondale -Electronic Systems Technologies
    Personal Links with plenty of BASIC Stamp info
    and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-02-25 06:10
    Dan Roganti said...(trimmed)
    Chris,
    Yes, I'm familiar with Multi-processing, as I've designed with this in the past as multi-processors is already a conventional item. From what you're saying, it appears this uses software polling to emulate an Interrupt. You tend to waste precious CPU cycles polling an i/o pin for an event. Although this processor may run faster than the common 8bit MCU's, even the fastest processor justify the need for an interrupt input(even parallel processors). This might be
    Interesting...I guess you will just have to wait until it comes out and see what I mean.· I am still trying to understand where precious CPU cycles are being wasted.· Interrupts are not being emulated in any way.· The tasks happen concurrently and thus are not an "interrupted" process.· Perhaps we are on different subjects.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • danieldaniel Posts: 231
    edited 2006-02-25 06:15
    According to the prelim docs, a COG can WAITxxx for pins to match a certain pattern or for a time to elapse.· The WAITPEQ/WAITPNE seems to get to the more interrupt functions of other processors where pin edges/levels trigger an ISR.· In this case, the COG is the ISR waiting for the pin(s) edge/level.

    However, the prelim doc state that the WAITPxx, once the pin pattern is matched, finishes the WAITPxx instruction and executes the next.· This could be imply that there is at a one-cycle·latency (as I seem to recall hearing elsewhere) before the instruction after the WAITPxx.· It could also imply a four or five cycle latency.·

    In addition, there is apparently a·5 cycle preparatory period while the WAITPxx configures the COG for the interrupt, but this seems to be part of the period of time that the COG would be in an "interrupt disabled" state, and not thus really part of the question following.·

    Assume WAITPNE #0, #000F, meaning (I think)·wait until any of the first eight pins are non-zero.· Regardless of the length of the time from interrupt-to-next-instruction, how can the COG know which of pins were were actually non-zero if the signal duration is less than this time period?· In other words, can an "interrupt" be triggered that leaves the COG senseless of which pins triggered it (I do realise that the "pattern" is known)?

    I have in mind mimicing the persistant interrupt mask of some processors, allowing the ISR to poll the combination of interrupts currently active, and manage them, before clearing that mask and returning to its waiting-for-interrupt state.

    Daniel
  • Dan RogantiDan Roganti Posts: 11
    edited 2006-02-25 06:28
    Martin,

    The cpu cycles used for the ISR is typical and is usually effective in how a system would perform in real-time. If you look at existing multi-processor systems, this concept still continues. Way back, I would build a quad Motorola G4 with 2MB of L2 cache in a CPCI system and the software guys would have a heyday trying to make it the cpu load max out.

    A Hardware Wait ?, ouch, now I see the Mips performance starting to decrease. This might be fine to dedicate as a coprocessor or slave processor. One thing that you learn in computer architecture is to make sure the cpu is executing as often as possible. Never let a cpu idle, which is why they have pipelines.

    A good example of why interrupts are used is communication interfaces. I realize this new processor is a big number cruncher. But eventually you want to connect peripherals to this, besides rs-232, usb, firewire, even wifi in your project. After connecting a slew of peripherals to this (those typically found in bigger MCU's) you tend to be forced to multi-task. I suppose with 8 processors, you can dedicate each cpu to a specific interface. But I find it difficult to propose a parallel RTOS for this, where you usually like to have interrupt events prioritized.

    Hey, I'm not trying to play hardball here, but just like to be able to convey some thoughts on what I experienced. I really appreciate the investment you guys are making with this development.

    thanks,
    Dan
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-02-25 09:25
    Dan, please do us a favour...

    Forget EVERYTHING you know about designing big computers.

    The Propeller isn't meant to compete with a G4(at least I don't want the Propeller inside my iBook) or other 'large' CPU.

    Ignore the 32bit classification of it, it doesn't matter(except in a few datamove and add/subtracts) and focus on the fact that this is a microcontroller.

    It's a microcontroller which can dynamically change its speed from 20KHz to 80MHz, start and shut down any of its 8 cores and can generate 8(! Bl**dy H!) video signals at one time.
    In low speed it draws microAmps, but can speed up to 80MHz in moments, whenever something happens, so that it can run almost forever on a small battery-pack. (I was planning to use a BS2P as the brains of a central locking system in my car, but that would mean wasting milliAmps all the time while waiting, and I tend to leave my car alone for weeks... Now I can get down to microAmps, and still get a fast response, have lots of excess processing-power to do all kinds of nifty things...)

    If you need to compare it to anything, it would be the CELL processor that Sony is using in their mythical PS3, except that it can't generate video directly, and also, at least 2 of their cores are dedicated, so it's not as flexible.

    In fact, forget anything you know about designing ANY computer. Parallax just threw the book out the window...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • Dan RogantiDan Roganti Posts: 11
    edited 2006-02-25 13:53
    Gadgetman,

    "I'm afraid I can't do that, Dave"
    If you want to design a processor, you have to be mindful of the critique.(goes with the territory)
    I feel a good application for this would be image recognition. Where each of the processors could be dedicated to a specific function for image analysis. I would interface a OV6620 image sensor(AVR Cam) to this and see how much faster I could get it to track objects. I noticed the thread on FFT, this could also be useful for recognizing images. I'm sure it would offer a significant performance boost.

    thanks,
    Dan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    .~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
    [noparse][[/noparse]My Corner of Cyberspace http://ragooman.home.comcast.net/ ]
    [noparse][[/noparse]Pittsburgh Robotics Society Got Robot? http://www.pghrobotics.org/ ]
    [noparse][[/noparse]Pittsburgh Vintage Comp.Society http://groups.yahoo.com/group/pghvintagecomp/ ]
    .~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2006-02-25 16:03
    Dan,
    I wouldn't look on this as a math processor, in the conventional sense of the word, due to the lack of hardware multply and extensive fast memory resources. But "conventional" is the watchword there. It does have those features Gadgetman mentioned, combined with a very interesting asm instruction set that is well suited to fast integer algorithms. It is first and formost a microcontroller, and I think you are quite right in thinking that it can make a superb peripheral controller for your mainframe (relatively speaking).

    Daniel,
    It is true the inputs are not latched on this machine. I wonder, the kind of interrupt handling you talk about could (IMHO) to be implemented as a state machine. The minimum pulse width for single events could be one clock cycle plus 4 more to read the input state of the pins, so that would be 12.5 nanoseconds at 80mhz clock and 50 microseconds with a 20 khz clock. In much of the environmental monitoring I do, where the inputs are rain gages and annemometers and keyboards, even 50 microseconds is a lifetime. And 12.5 nanoseconds isn't too shabby. The story would be more difficult with repeating asychronous events, if you are using the WAITpin mechanisms in order to achieve the minimum single event latency. There would be time for propeller to process the state (which would only take a few clock cycles), and then do something with it, like put it in a queue in main memory, and that could eat up quite a few cycles. But let's say the whole process takes 80 clock cycles, including a maximum of 23 for hub rotation. That is still one microsecond overall latency, to define the minimum spacing between asynchronous events with 80 mhz clock, using one cog for the single purpose of "interrupt" queueing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-02-25 19:00
    I've been playing around a little bit with the assembly commands, and one test I have is very simple...

    The program sets up 3 loops, 255, 255 and 48, inside each other, then counts them down to 0.
    no RET command, no consideration for interrupts or anything, just a paper exercise.

    I got this test from someone on a C64 forum, where he wanted to prove the superiority of the 6502 processor over the Z80, so no, the 48 is not my idea...

    A Z80 doing this ends up with a program that uses 31.433.108 clock pulses. (about 7.5 seconds run-time at 4MHz)
    (After that the C64 user went back to tests of the Basic languages, which I must admit he won... with good margins... )

    Writing the same program for a single COG I got this:
                  MOV $000,#48
    LOOP3:   MOV $001, #255
    LOOP2:   MOV $002, #255
    LOOP1:   DJNZ $002, #LOOP1
                  DJNZ $001, #LOOP2
                  DJNZ $000, #LOOP3
    
    



    As I found that the MOV instruction takes 4 cycles, and the DJNZ takes 4 or 8 depending on whether or not it reaches 0, I got these numbers:
    (Each line corresponds to the same line of code)

          4      4                                             4
          4      48 x 4                                   192
          4      48 x 255 x 4                     48.960
       4/8      (254x4 + 8) x255x48  12.533.760
       4/8      (254x4 + 8) x 48              49.152    
       4/8      (47x4 + 8)                            196
    
    



    Or a total of 12.632.264 clock cycles.
    At 20KHz, this takes slightly over 631seconds, or just above 10m31s
    At 4MHz, this takes 3.158 seconds...
    At 80MHz, this takes 0.157seconds...

    Can anyone verify these numbers?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
Sign In or Register to comment.