Shop OBEX P1 Docs P2 Docs Learn Events
Parallax Propeller your COGS ruined me! — Parallax Forums

Parallax Propeller your COGS ruined me!

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2014-09-03 05:54 in General Discussion
I've been working to get that new Micromite Companion project up and running, (a combination of Propeller and PIC32 running BASIC) so naturally I've started working on programming examples in BASIC. I start by writing a simple program to read the I2C Wii Nunchuck controller. (Around 10 lines of code, so simple!), then I thought it would be cool to jump out of the loop on the press of a button and start an LED flashing at a contrable rate. Heck, in spin I'd just assign this job to another COG, set and forget it. Except... PIC32's don't have 7 more cogs to play with..

I did manage to get it working fine, but my simple 10 line program turned into ten more lines to do the job... Parallax, I've become ruined and spoiled by having so many cogs!! What have you done to me? :)

I have however gained a new respect for the magic that people seem to acomplish with that "other" single cog micro. :)

Jeff

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2014-08-31 09:34
    Oldbitcollector (Jeff) wrote: »
    I've been working to get that new Micromite Companion project up and running, (a combination of Propeller and PIC32 running BASIC) so naturally I've started working on programming examples in BASIC. I start by writing a simple program to read the I2C Wii Nunchuck controller. (Around 10 lines of code, so simple!), then I thought it would be cool to jump out of the loop on the press of a button and start an LED flashing at a contrable rate. Heck, in spin I'd just assign this job to another COG, set and forget it. Except... PIC32's don't have 7 more cogs to play with..

    I did manage to get it working fine, but my simple 10 line program turned into ten more lines to do the job... Parallax, I've become ruined and spoiled by having so many cogs!! What have you done to me? :)

    I have however gained a new respect for the magic that people seem to acomplish with that "other" single cog micro. :)

    Jeff
    Are you sure you don't want to use my embedded Basic for the Propeller in place of MMBasic? :-)
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2014-08-31 09:46
    Nah! Learning how to actually *think* again is probably good for me. :)
  • David BetzDavid Betz Posts: 14,516
    edited 2014-08-31 09:48
    Oldbitcollector (Jeff) wrote: »
    Nah! Learning how to actually *think* again is probably good for me. :)
    So I guess the Propeller is for non-thinkers? :-)
  • jazzedjazzed Posts: 11,803
    edited 2014-08-31 10:01
    This is yet another great opportunity to compare and contrast the Propeller against other MCUs.

    Propeller is for everyone, but they just don't know it yet.
  • Heater.Heater. Posts: 21,230
    edited 2014-08-31 10:02
    David,

    So I guess the Propeller is for non-thinkers?
    Yes. I love it.
  • photomankcphotomankc Posts: 943
    edited 2014-08-31 11:25
    David Betz wrote: »
    So I guess the Propeller is for non-thinkers? :-)


    Yes..... thinking leads to complex hacks to simulate multi-tasking, which leads to code that resembles a pyramid standing on it's point. Something that is miraculous in that it works all and something that tinkering with even a little can push the whole thing over. ;)


    Blinking an LED should be simple and having a cog available to do it keeps it simple.
  • JonnyMacJonnyMac Posts: 9,105
    edited 2014-08-31 11:58
    Yesterday I had a conversation with a guy who does electronics for big movies. He's dabbled with the Propeller, but his current setup is a PIC -- and he's connecting three of them to control big props. I said, "See, you're already using multiple processors -- it's better to have them on the same slab of silicon." In the end we agreed that our clients do not care about the technology, only the artistic results. After our conversation he is now open to exploring the Propeller as I described several situations where the multi-cog approach let's us think more about the art than how to make code jump through its own backside to make things work.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-08-31 12:08
    JonnyMac wrote: »
    Yesterday I had a conversation with a guy who does electronics for big movies. He's dabbled with the Propeller, but his current setup is a PIC -- and he's connecting three of them to control big props. I said, "See, you're already using multiple processors -- it's better to have them on the same slab of silicon." In the end we agreed that our clients do not care about the technology, only the artistic results. After our conversation he is now open to exploring the Propeller as I described several situations where the multi-cog approach let's us think more about the art than how to make code jump through its own backside to make things work.
    That's a great story! Maybe Parallax can use that in its marketing materials. It seems that many people see the advantage of multiple concurrent processors when they've taken the time to try the Propeller. Certainly all of us here do.
  • pjvpjv Posts: 1,903
    edited 2014-08-31 13:42
    photomankc wrote: »
    Yes..... thinking leads to complex hacks to simulate multi-tasking, which leads to code that resembles a pyramid standing on it's point. Something that is miraculous in that it works all and something that tinkering with even a little can push the whole thing over. ;)


    Blinking an LED should be simple and having a cog available to do it keeps it simple.

    But of course if you need to blink more than 8 LEDs at different rates, you again need to visit that hack that simulates mult-tasking.

    I say get familiar with multitasking, understand it, and use it when appropriate or when you're out of cogs.

    Cheers,

    Peter (pjv)
  • GenetixGenetix Posts: 1,754
    edited 2014-08-31 16:18
    OBC, to me "throw it in a Cog" seems to be lazy programming. In the old days programmers would use every clock cycle available to do something useful. How often are Cogs idle or running just a few lines of code? If you are programming like that then even a Super Propeller with hundreds of Cogs will never be enough because the lazy programming will continue. Parallel processing has it's place but not if you are doing wrong. The problem isn't the Propeller but lazy programming.
  • varnonvarnon Posts: 184
    edited 2014-08-31 17:19
    Dedicating a cog to a task is kind of lazy programming, but that is why I find the Propeller to be so useful. Sometimes it is actually time-efficient to do things the lazy way. I use one microcontroller for many different applications. Sometimes it is a very simple task, sometimes it is a rather complex task. For complex tasks I do need to be clever, but for simple tasks having extra processors to use really speeds up development. After working with the Propeller for a while, I really have come to prefer the multicore approach for microcontrollers.
  • photomankcphotomankc Posts: 943
    edited 2014-08-31 17:43
    pjv wrote: »
    But of course if you need to blink more than 8 LEDs at different rates, you again need to visit that hack that simulates mult-tasking.

    I say get familiar with multitasking, understand it, and use it when appropriate or when you're out of cogs.

    Cheers,

    Peter (pjv)


    NOBODY needs to blink more than 8 LEDs! NOBODY! :)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-08-31 17:51
    Genetix wrote:
    OBC, to me "throw it in a Cog" seems to be lazy programming.

    "Laziness is a virtue." -Linus Torvalds

    -Phil
  • Duane DegnDuane Degn Posts: 10,588
    edited 2014-08-31 18:15
    Phil Pilgrim (PhiPi) wrote: »
    "Laziness is a virtue." -Linus Torvalds

    -Phil

    Absolutely. The microcontroller is there to make our lives easier including easier to program. I don't care if it's "lazy programming", The Propeller is there to get a job done and the less time it takes to get the job done the better.
  • TtailspinTtailspin Posts: 1,326
    edited 2014-08-31 20:30
    I don't care if it's "lazy programming", The Propeller is there to get a job done and the less time it takes to get the job done the better.
    Always give the hardest job, to the laziest person, They will always find the easiest way to do it..:lol:


    I tried coding with Picaxe, the Basic Stamp, and the BS2, I just don't get it.. I too, have been ruined spoiled by the COG...:smile:
  • evanhevanh Posts: 15,923
    edited 2014-09-02 04:57
    The Prop is only the start of a good thing in terms of helping think mechanically. The problem with most introductory programming is it stops at batch processing. And educational kits offer little support beyond that point. Personally, I feel everyone should start out with a good dose of Ladder Logic training to help them get perspective on computing.
  • photomankcphotomankc Posts: 943
    edited 2014-09-02 08:15
    There will always be problems that force you to push every ounce of performance from a design and when you encounter this you will engineer to the challenge or fail. But, I also listen to my Father-In-Law rail on against the need for RAM in today's programs when he got by with 64K and the 'lazy programming' mantra rings similar. There is much done now that wouldn't be possible in that 64K. We also need to do much less trickery and 'neat' stuff just to cram things into tiny space. The result is easier to follow code that may use more RAM than absolutely required but is easier to work on, maintain, and update. Same with cogs doing small jobs. Sure, we could make something that did UART/SPI/I2C/Blink/LCD all in one cog using all number of tricks to keep the plates spinning but in the vast majority of cases that is not required and a simple 1 Cog, 1 job, model makes it simpler to use, maintain, and adapt.

    The unique aspect of the Propeller has always been that it kept multi-processing simple-ish, and therefore solved the most common issues you have to dance around in other micros. I need to constantly do B and C right on time while I occasionally need to do lengthy process A. Prop makes this a simple thing to deal with and I don't program like it's a brain teaser or to exercise.... I just want to get something working.
  • Heater.Heater. Posts: 21,230
    edited 2014-09-02 08:45
    All this talk of "lazy programmers" is mostly misguided.

    1) We have processors that are millions of times faster, have millions of times more memory and are millions of times cheaper than they were when I first ever wrote a program. And somebody is going to tell me that my program is 10 times too big or 10 times to slow. That I'm lazy. That I should spend hours optimizing every instruction sequence and reusing every possible RAM location. Really? I'm not listening. I'm already working on the next project.

    2) Often being lazy involves a lot of work. For example:

    You have written a program that has to do a lot of searching for stuff. The smallest simplest code to do that might just be a loop that traverses an array looking for what you want. Fine, it works. If it's a bit slow, because the array is a bit long. You can spend as much time as you like rewriting that in assembler and optimizing every instruction. It may get you a speed up of two or four times, big deal. Or you can be lazy, keep your code in a HLL, use more code and perhaps more memory, but take the time to implement a better algorithm, say a binary search or a hash table. BOOM! Your "lazy" code is now taking time proportional to log N or N (Where N is the size of the data set). That can speed things up by tens or thousands of times compared to you micro-optimization hard work. After that tweaking around with assembler instructions seems rather pointless.

    As a concrete example: I wrote an FFT for the Propeller. It is hundreds of times faster than doing spectral analysis the naive way. Turns out the PASM version of it is not much faster than the C version! As a bonus the C version can be simply recompiled compiled to use 2 or 4 COGS for a bit of a boost.

    I'm not saying "be lazy" really. I'm not saying dropping to assembler or tweaking around with it is never required. I'm not saying one should not keep an eye out for inefficiency and bloat. It's just that I often hear this talk of "lazy programmers" and "bloated software" from people who think that all that micro-optimizing is the only way to go.
  • ratronicratronic Posts: 1,451
    edited 2014-09-02 09:08
    I am a lazy programmer in that the Propeller makes it easier for me! I do not miss dealing with interupts.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2014-09-02 10:26
    @Heater, I'm not sure this is lazy or not..

    I tend to think my code while I'm writing. I should probably sit down beforehand and create a "master plan". Then once I have the concept working, then I go back through the code to adjust, refine, and write smarter, faster code.

    Lazy? Not sure. There's probably another word for it. :)

    Jeff
  • photomankcphotomankc Posts: 943
    edited 2014-09-02 10:55
    Oldbitcollector (Jeff) wrote: »
    @Heater, I'm not sure this is lazy or not..

    I tend to think my code while I'm writing. I should probably sit down beforehand and create a "master plan". Then once I have the concept working, then I go back through the code to adjust, refine, and write smarter, faster code.

    Lazy? Not sure. There's probably another word for it. :)

    Jeff



    I'd never write a program otherwise. I used to fail miserably in college when required to present a design up-front (which is partly why I don't code for a living). I never see the whole picture until I'm into the details. So most often I end up with something much different than I thought I would have when I started.
  • mklrobomklrobo Posts: 420
    edited 2014-09-02 13:06
    :nerd: I have been experimenting with the languages and limits of the propeller, and it is totally, completely,
    addictive! I can not stop programming! The multiple Cogs are a great!
    I am wondering, though, abou the DEO - nano cyclone FPGA.(?) Could that be programmed to have
    multiple MPUs? If so, that would open up an infinity power of programming! Have not had a chance to dive
    into it yet................:lol:
  • jazzedjazzed Posts: 11,803
    edited 2014-09-02 13:14
    Actually it takes a lot of work to become a lazy programmer.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-09-02 18:56
    jazzed wrote:
    Actually it takes a lot of work to become a lazy programmer.
    True, and I can think of a perfect example: multiple conditional cases. The non-lazy-but-brain-dead programmer will just chug ahead blindly, using if/elseif/else or select/case/switch constructs to enumerate all the cases. That involves a lot of typing and inefficient code. The lazy programmer, who hates typing and endless multiple choices, will attempt to parametrize the cases and roll them into one expression. That can require a lot of work before the typing even starts -- but just think of the time savings! :)

    -Phil
  • David BetzDavid Betz Posts: 14,516
    edited 2014-09-02 19:17
    Phil Pilgrim (PhiPi) wrote: »
    True, and I can think of a perfect example: multiple conditional cases. The non-lazy-but-brain-dead programmer will just chug ahead blindly, using if/elseif/else or select/case/switch constructs to enumerate all the cases. That involves a lot of typing and inefficient code. The lazy programmer, who hates typing and endless multiple choices, will attempt to parametrize the cases and roll them into one expression. That can require a lot of work before the typing even starts -- but just think of the time savings! :)

    -Phil
    I guess I'm a brain-dead programmer then. I prefer the options to be clearly defined rather than implicit in a convoluted expression.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-09-02 19:38
    What brought this to mind was a sequence of code I just wrote to synthesize left and right wheel speeds in a differential robot drive from "rudder" and "aeleron" RC receiver inputs. There were eight sets of four simultaneous equations to solve, one for each polar octet. I refused to create eight separate cases when there was such an obvious emergent pattern from the equation solutions. Laziness kicked in, and I was able to express the solution in a few lines of Spin, rather than writing out all of the cases.

    I felt so dang virtuous due to my laziness that I just had to share! :)

    -Phil
  • JonnyMacJonnyMac Posts: 9,105
    edited 2014-09-02 21:21
    NOBODY needs to blink more than 8 LEDs! NOBODY!

    We had a few more than eight (channels) in this dude!

    10547014_10152292366191937_1152670575253717571_o.jpg
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2014-09-02 22:44
    JonnyMac wrote: »
    We had a few more than eight (channels) in this dude!

    It's getting some well deserved Reddit love today too..
    http://www.reddit.com/r/gaming/comments/2f9w8g/not_a_huge_lol_fan_but_this_statue_from_pax_prime/
  • photomankcphotomankc Posts: 943
    edited 2014-09-03 05:54
    JonnyMac wrote: »
    We had a few more than eight (channels) in this dude!


    (Looks down and kicks pebbles)..... shut up.







    :)

    That's impressive!
Sign In or Register to comment.