Shop OBEX P1 Docs P2 Docs Learn Events
Why...O...why...in this day and age... - Page 2 — Parallax Forums

Why...O...why...in this day and age...

245678

Comments

  • Interesting to OP did not respond to any comments yet.
  • The creator of ByPic, Jim Meer, says it's "not open source YET". Whatever that means.

    The firmware is free, however and can be loaded on to your own PIC32MX170 using a PICkit 3.

    Interesting benchmark over on thebackshed forum, comparing the various Micromites to '80s PCs. I am "Tinine" over there and decided to run a similar benchmark on the 40MHz ByPic....turned out to be 3 to 6 times quicker than the latest 200MHz "MM Extreme"....LOL
  • jmg wrote: »
    The main hurdle I see for PBASIC -> P1 is not language limitations, but the lack of Wide Vcc on P1.

    A key pivot for doing a 'better PBASIC' platform, will be backward hardware compatibility.

    Neither P1 nor P2 offers 5V IO operation, but BS2p already uses an external-vendor MCU, so a precedent is proven that Parallax can use other vendor's MCUs.

    I used to agree and that is why I attempted to launch my Propeller BSC Module 4 years ago. Even though it was a Propeller based drop-in replacement for a 5 volt BS2 on a BoE-Bot, the interest was lackluster so it died after the first prototypes were built and qualified.

    SpinStamp2_Module_Prototype.jpg

    As for the OP, I would suggest looking at SPIN again, and let the forums help you with any issues. When I migrated from PBASIC to SPIN, I got a Propeller Demo board, loaded up the demo code in the editor, and then poked and prodded to see the results. From then on out, I downloaded sample code from the forums or OBEX and hacked them up until I could understand functionality, nomenclature, structure, and commands. For me, migrating to SPIN seemed way easier than I had originally thought before I had a demo board in my hands. Once I started playing with it, I was very disappointed that I waited so long to migrate from the stamp.

  • Mickster wrote: »
    The creator of ByPic, Jim Meer, says it's "not open source YET". Whatever that means.

    The firmware is free, however and can be loaded on to your own PIC32MX170 using a PICkit 3.

    Interesting benchmark over on thebackshed forum, comparing the various Micromites to '80s PCs. I am "Tinine" over there and decided to run a similar benchmark on the 40MHz ByPic....turned out to be 3 to 6 times quicker than the latest 200MHz "MM Extreme"....LOL
    I asked if it was open source because I thought it might be possible to get the compiled code to run on a Propeller.

  • David Betz wrote: »
    I asked if it was open source because I thought it might be possible to get the compiled code to run on a Propeller.

    I'm impressed with Peter's BASIC/Forth....prolly the closest we're gonna get for P1.

    The ByPic "OS" takes up like 120K of the PIC's 256K flash, leaving just over 130K for the user program. There is also 60K+ of RAM.
  • cgraceycgracey Posts: 14,133
    edited 2017-01-06 05:51
    It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is happening.
  • JasonDorie wrote: »
    If you spend some time with the Propeller and Spin you'll find that there's a learning curve, but it's not hard to use, and there are a lot of examples in the code provided with the Propeller Tool, the Object Exchange, and the forums, in addition to a lot of people here who are happy to help when something stumps you.
    As for the OP, I would suggest looking at SPIN again, and let the forums help you with any issues.

    I second Jason's and Andrew's statements.

    Which tutorials did you use to learn to program in Spin.

    While there are lots of great tutorials, I personally liked the original Propeller Manual's tutorial. I keep a pdf of the version 1.0 manual in my Dropbox to share. A link to this pdf and a bunch of other Propeller related links can be found here.

    The multiple processors in the Propeller makes writing relatively complex programs much easier than programming other microcontrollers. I'm personally a huge fan of the Propeller and Spin. I made a "Fun with Spin" playlist with some of my Propeller projects.

    Once I got used to Spin, it quickly became my favorite programming language. I hope you give Spin another try and ask questions here whenever something doesn't make sense.





  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.

    Yes, but one problem with Spin, is the (extreme) single-source nature.
    It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.

    Yes, but one problem with Spin, is the (extreme) single-source nature.
    It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.


    What is the best way to get enthused about Python?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-01-06 05:58
    Spin was a very easy language to learn, of course we probably all made the same beginner mistakes with indentation where whitespace was important and this is perhaps the only bugbear I had with the language itself. I don't see the advantage though to using less efficient languages simply for portability, that is something that makes sense when going from an ARM to an ARM or to a PIC32 etc, but the Prop is very different. There seems to be far too much reliance these days on libraries to provide a function that could just as easily be written in a few lines of Spin. It seems that although people are becoming much more multi-lingual, the tendency in programming is the opposite, and even if there is a better language for a task but it ain't C then it's just gibberish to many who seem to think that there is only one way of doing things, the way they were taught. That's what's truly sad.




  • JasonDorieJasonDorie Posts: 1,930
    edited 2017-01-06 06:49
    Python is great for "glue" but it lacks the ability to do anything really hardware specific on its own - you'd need native functions to twiddle a port, for example. Python handles this well, but I'd be surprised if it was remotely practical on a micro. Anything that's garbage collected doesn't lend itself well to 32kb.

    Don't get me wrong - I like Python and I use it semi-regularly now. It's fantastic for string-bashing and things like file transforms, but it's not very close to the metal. If you'be never used it, Codecademy has a free online walk-through that's a decent starting point. It's a good learning language too - it supports functions or objects, handles the memory management and types for you, and is pretty readable.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-01-06 07:54
    The Propeller is a unique and wonderful processor. Spin is a unique and wonderful language.

    Some processors, like the AVR, were optimized to work well with C. The Propeller was not -- thankfully.

    Spin was designed to work well with the Propeller, which it does with efficiency and elegance -- again, thankfully.

    So, Chip, please don't bend to the winds of fashion. Make Spin -- or whatever you want to call it -- fit the P2 like a glove, without burdening it with the cruft of convention.

    Thanks,
    -Phil

    P.S. BTW, I've taught both C and Spin at the high-school level, using the ActivityBot as the learning platform for both. The kids took to Spin much more readily than they did to C, and there was much less debugging due to syntactic gingerbread, which is prevalent in C.
  • jmgjmg Posts: 15,140
    ...
    So, Chip, please don't bend to the winds of fashion. Make Spin -- or whatever you want to call it -- fit the P2 like a glove, without burdening it with the cruft of convention...

    Sure, there will naturally be a Spin for P2 - n fact, one already exists in the Spin2cpp thread.
    That covers the P1 users wishing to make use of P2, which is a very small subset of the MCU designers out there.
    There is also C for P1 and P2.

    I mentioned Python as one language target to consider when selecting a Stamp Successor host.
    ( C and Spin are not excluded, as these are all Flash parts, not ROM parts )

    Languages like Python tend to bump the size of the MCU needed ( as also does self-hosting, such as the ByPic example given above by Mickster, which quotes 130k of Code size), but the Cypress part can easily host ByPic on that spec.

    Another slightly more radical HW approach to the Basic Stamp / Spin / Prop continuum, would be to use P1V and something like
    https://opencores.org/project,p16c5x, hosted on a new Lattice iCE40UP5K ( 48-pin QFN).

    This would need 5V level shifters, as the FPGA is not Wide Vcc operation.

    Basic Stamp code would run on the PIC core, and Prop code would run on the P1V core(s), all in the same chip.


  • Cluso99Cluso99 Posts: 18,066
    Spin is an easy language to learn. It takes good bits from a number of languages, and some of its own.

    The biggest problem was, and IMHO still is, where to find the tutorials and info on spin.

    Spin is designed to enlist pasm objects running in other cogs to do certain functions. This permits simple use of the multiple cores (cogs) in the propeller chip. There are a huge number of objects, some in the OBEX and some not. We have multiple serial objects, from single (smart) UART drivers to multiple serial ports in one core/cog.

    Seriously, it is certainly worth a look into spin. The objects are simple because you don't need to understand how they work, just the calls. There are SPI and I2C objects for lots of chip interfaces.

    And just for reference, this past week I downloaded the Arduino IDE to run a robot piece of code. There are nice tutorials, etc. But trying to download the code from github and install it in the Arduino IDE was a nightmare! The instructions for adding all the libraries required to run the program to make the robot walk was almost impossible to figure out. I did it after lots of googling. How a school student or teacher is supposed to get started on this is unbelievable! Once I figured out how to load the libraries, I was able to compile and download the code easy enough. But it didn't work straight off. Fortunately I can modify the base code to get one servo working at a time to figure out what is going wrong.

    There were no such problems when I bought my first prop board. Just plugged it in, compiled and downloaded the led blink program and away it went. Spin with a couple of lines of code. No libraries, etc. Just so simple - took no more than 5 minutes!!! I worked through the 10? examples downloaded with PropTool. I cannot stress how simple this was.
  • TorTor Posts: 2,010
    Agreed - I bought a QuickStart board back when it was $20, plugged it in, ran through the four or five examples of Spin source, then modified each of them to blink the lights in a different sequence, or faster, or counting. Never seen anything with such a low threshold for getting started. Not even close. I used to bring that QS board everywhere in a pocket, with a stub USB cable, and plugging it into a notebook in the cafeteria where I had my lunch. Just to play with.
  • jmg wrote: »
    cgracey wrote: »
    It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.

    Yes, but one problem with Spin, is the (extreme) single-source nature.
    It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.

    I don't know why people frequently compare Spin with Python. Other than that they both use indenting for block structure, they are not even remotely similar.

  • TorTor Posts: 2,010
    David Betz wrote: »
    I don't know why people frequently compare Spin with Python.
    You're not alone in wondering about that.
    Other than that they both use indenting for block structure, they are not even remotely similar.
    100% agreed.

  • I have never used the Propeller. If I make a Spin program that does nothing but toggle a port pin, how much memory does this take? 5-15 bytes? In other words, is Spin a zero runtime overhead language?

    I was reading something a while back about hipster culture. Perhaps there might be an idea for a hipster-like revival of Basic. Just needs some new marketing. For example, the ChickenSpeak rebranding idea mentioned previously on these forums. Or an advertising campaign on programming websites: "Bringing Basic BACK!!!"

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-01-06 12:48
    The_Master wrote: »
    I have never used the Propeller. If I make a Spin program that does nothing but toggle a port pin, how much memory does this take? 5-15 bytes? In other words, is Spin a zero runtime overhead language?

    I was reading something a while back about hipster culture. Perhaps there might be an idea for a hipster-like revival of Basic. Just needs some new marketing. For example, the ChickenSpeak rebranding idea mentioned previously on these forums. Or an advertising campaign on programming websites: "Bringing Basic BACK!!!"
    The interpreter is in ROM although the Spin code generated by the PC Spin tool is very compact but the Spin cog is loaded with the Spin interpreter and the rest of the 32k ROM holds interpreted Spin code that supports all the built-in Spin functions plus room for fonts and tables.

    My Spin is rusty but here is a simple toggle:
    pub toggle
      dira[0]~~
    repeat
      !outa[0]
    
    and the compiled Spin byte codes takes 11 bytes
    Local Parameter DBASE:0000 - Result
    |===========================================================================|
    2                        dira[0]~~
    Addr : 0018:             35  : Constant 1 $00000000
    Addr : 0019:       3D D6 1C  : Register [Bit] op DIRA VAR~~ Post-set
    Addr : 001C: Label0002
    4                        !outa[0]
    Addr : 001C:             35  : Constant 1 $00000000
    Addr : 001D:       3D D4 47  : Register [Bit] op OUTA LongMathop !
    Addr : 0020: Label0003
    Addr : 0020: JMP Label0002
    Addr : 0020:          04 7A  : Jmp 001C -6   
    Addr : 0022: Label0004
    Addr : 0022:             32  : Return
    

    Although my latest version Tachyon uses word code instead of byte code in the previous version and takes 10 bytes and is much faster.
    ( 0001 $2830 ok )   : TOGGLE BEGIN 0 HIGH 0 LOW AGAIN ; 
    ( 0002 $283A ok )   SEE TOGGLE
    
    2830 $0000 (0)
    2832 HIGH
    2834 $0000 (0)
    2836 LOW
    2838 GOTO TOGGLE
    

    As for "hipster", that might be fine for fashion but in engineering we actually have to make things work, not just look fashionable.
  • Heater.Heater. Posts: 21,230
    Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.

    "hipsters" should like Forth if they are into retro. :)

    I'm not sure about a BASIC revival. Damn thing never went away. Also with a :)
  • Heater. wrote: »
    Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.

    "hipsters" should like Forth if they are into retro. :)

    I'm not sure about a BASIC revival. Damn thing never went away. Also with a :)
    To satisfy real hipsters we should bring back LISP!

  • David Betz wrote: »
    Heater. wrote: »
    Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.

    "hipsters" should like Forth if they are into retro. :)

    I'm not sure about a BASIC revival. Damn thing never went away. Also with a :)
    To satisfy real hipsters we should bring back LISP!

    We can always end this conversation real quick. To satisfy real hipsters, we should write our programs with very small magnets and hole punchers.

    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.

    Yes, but one problem with Spin, is the (extreme) single-source nature.
    It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.


    What is the best way to get enthused about Python?

    I would argue that the best way to get about enthused, when you live in the Parallax world, is to look at Micropython. The P2's 512kB will be plenty large enough to fit Micropython, and it's already gaining a respectable following. I really like that right smack dab on the home page are 7 short example snippets. Check them out here: http://micropython.org/ (beneath "Proper Python with hardware-specific modules"). And above that is a "TEST DRIVE A PYBOARD ONLINE" button (but the board is currently offline at the moment... so that's not much fun right now).

    Python is very easy to learn. It can be simple and fully procedural, or you can get as complex as you want with inheritance. The addition of annotations allows one to get some pretty smart type checking by your IDE too. I certainly think that Spin on the P2 via Spin2cpp is the only type of Spin that Parallax should officially support (but I'm a bit biased as someone who doesn't care for Spin). Invest in a good C/C++ compiler and then you'll quickly find yourself with C, C++, Spin, JavaScript, Python, and lots of others probably.
  • SPIN Toggle
    pub toggle
      dira[0]~~
    repeat
      !outa[0]
    

    PropBASIC Toggle (not much good without a delay, mind)
    LED Pin 20 Low
    
    Do
    Toggle LED
    Loop
    


    PropBASIC (PASM) output
    __DO_1                                         'Do
        or            dira,LED                     'Toggle LED
        xor           outa,LED                    
        jmp           #__DO_1                      'Loop
    __LOOP_1
    


  • FredBlaisFredBlais Posts: 370
    edited 2017-01-06 17:08
    I've been a fan of the Propeller since the beginning and really enjoyed working with SPIN and the Propeller IDE. After this, it has been hard for me to get back to C on microcontrollers. Readability of source code is the most important factor for me, I want to be able to go back in my code a couple months later and be able to pick up where I left.

    While I was in EE, I participated in a couple robotic/machine design/electronics competition. The other students learned programming PIC18 in ASM and C. I set-up a small lab to teach SPIN and Propeller stuff to a couple students for an upcoming competition (the University gave me some money so I could buy about 15 Quickstart Board to give away).

    It has been a fun experience but very few students worked with SPIN afterwards. I think it is because they felt they would be locked to the Propeller by learning it and when you write SPIN in your CV, employers just don't know what it is.

    These days, I work a lot with Python. I use it at my workplace and the week-end when I'm fiddling with these myriads of small Linux board. You can tackle almost all programming job in Python, the amount of libraries is huge and it is really easy to install them (pip).

    I could not agree more with DavidZemon about putting efforts in a good C compiler. Projects like MicroPython could be ported and even Javascript engine for IoT like JerryScript (see http://jerryscript.net/ )

    These are projects that are targeted specifically for microcontrollers. Nowadays, people ask a lot for Node.js or Python. I don't really like Arduino, but there is a trend where new boards made by different company implements the Arduino standard library and even use the Arduino IDE.
  • Hmmm,

    Just realized that "Toggle" repeatedly sets the pin as an output...not to worry..

    PropBASIC with inline PASM
    Do
    Asm
        xor           outa,LED                    
    Endasm
    Loop
    

    Output
    __DO_1
         'Do
         '             ASM                       'Asm
        xor         outa,LED                                  
         '             ENDASM                 'Endasm
         jmp        #__DO_1                'Loop
    __LOOP_1
    
  • cgraceycgracey Posts: 14,133
    edited 2017-01-06 18:29
    My only personal desire is to make Spin for the Prop2. It could compile to byte code or straight PASM, or either.

    I recognize the value of snatching those Hipster dollars from cyberspace, but I'm actually pretty limited, in terms of what I have the stomach for and the wil to do. Spin is going to be the first thing I work on.
  • JasonDorieJasonDorie Posts: 1,930
    edited 2017-01-06 18:33
    ...and in C:
    #include <propeller.h>
    
    const int LED = 1;
    
    void main(void)
    {
      DIRA |= LED;
      while(1)
        OUTA ^= LED;
    }
    

    I've always thought these kinds of "look how simple it is!" tests are a bit silly, because the triviality of the example means that it's simple to implement in just about any language.

    Every language makes trade-offs between the efficiency of the code and the efficiency of the programmer, and it's the job of the engineer to pick the one that's appropriate for a given situation. I wouldn't write a rendering engine or video codec in Python, and I wouldn't write a find-in-files with regular expression text replacement function in assembly. Knowing only a single language means you have one tool at your disposal and you get stuck in the "if you only have a hammer, everything looks like a nail" mentality. That said, there's nothing wrong with having a favorite.

    My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
  • cgraceycgracey Posts: 14,133
    JasonDorie wrote: »
    My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.

    If I understand what you mean, we will solve this problem through method pointers in the Prop2 Spin language.

    One thing I've been wanting to do, but haven't because of data-forwarding issues in the pipeline, is to implement instructions which set the DIR bit and modify the OUT bit for individual pins: DRVH, DRVL, DRVC, DRVNC, DRVZ, DRVNZ, DRVN. It's simple to implement these, but we'll just have to have a stated rule that OUTA/OUTB data will be forwarded in these cases, but DIRA/DIRB data will not be. It's a caveat, but not a complex one, and it will enable atomic pin-output operations that will make things simpler and cleaner. All those code examples above can get rid of their DIR assignments and just use DRVN (set the DIR bit and toggle the OUT bit).
  • Toggle, or set H or L depending on the instruction? (I'd expect the latter to be more useful)

    And yes, you probably understand my meaning. When writing the firmware for the Elev8 in Spin, there were cases where I needed more than one of a given type of object in the project, but also wanted to call functions in them from multiple places in the code, that's hard to do in Spin without duplicating code. I needed two serial port objects (USB and XBee) and wanted to send output to them from multiple sub-objects in my code. Much simpler in C/C++.

    I also found the lack of optimization in Spin to be huge. Function level linking, dead code elimination, auto-inlines, and constant folding make a massive difference in code size and performance, and meant that my C/C++ version of the Elev8 code is slightly smaller than the Spin version, and 2x faster, even though the bytecode representation for CMM code is 50% or more larger than Spin for simple benchmarks.
  • cgraceycgracey Posts: 14,133
    JasonDorie wrote: »
    Toggle, or set H or L depending on the instruction? (I'd expect the latter to be more useful)

    And yes, you probably understand my meaning. When writing the firmware for the Elev8 in Spin, there were cases where I needed more than one of a given type of object in the project, but also wanted to call functions in them from multiple places in the code, that's hard to do in Spin without duplicating code. I needed two serial port objects (USB and XBee) and wanted to send output to them from multiple sub-objects in my code. Much simpler in C/C++.

    I also found the lack of optimization in Spin to be huge. Function level linking, dead code elimination, auto-inlines, and constant folding make a massive difference in code size and performance, and meant that my C/C++ version of the Elev8 code is slightly smaller than the Spin version, and 2x faster, even though the bytecode representation for CMM code is 50% or more larger than Spin for simple benchmarks.

    Ultimately, it would be great if we could get optimizing compilation working for Spin. It's a lifetime of development effort to achieve that, it seems. Do you think lessons could be efficiently learned from how CLANG, GNUC, and others work? I imagine there's some degree of abstraction at which it's all the same. I wonder how many KB of compiler source code define those functions.
Sign In or Register to comment.