Shop OBEX P1 Docs P2 Docs Learn Events
Propeller 2 Specs — Parallax Forums

Propeller 2 Specs

tryittryit Posts: 72
edited 2017-01-26 00:14 in Propeller 2
As of today (12/24/2015), are these still the propeller 2 specs:

* 32-bit Multi-Processor (16 Core) Module
* HD 1080p Video
* Programmable in: GCC, Spin, other?
* 200 Mhz Clock Speed
* 512 KB RAM
* TBD KB RAM for Program Storage
* 64 I/O Pins
* Up to 64 ADC (13-bit Resolution)
* Peripherals implemented software: USART, PWM, I2C, SPI
* Chip Price: TBD
* Chip and Breakout Board: TBD
* Board Form Factor: TBD

Edited 1/25/2017: Latest news and specs can be found in the first entry of this thread by @cgracey:
http://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-3-november-2016-version-13/p1
«134

Comments

  • I don't know much about the P2 but apparently, it will have quadrature decode capability as well.

    I am hoping that PropBASIC will support the P2, also.
  • I'm really curious as to whether a breakout board has been specified yet, and if so, what will it be.

    Also, is P2 for sure going to have Spin? Gonna, gonna?
  • I'm really curious as to whether a breakout board has been specified yet, and if so, what will it be.

    Also, is P2 for sure going to have Spin? Gonna, gonna?
    I don't think there is any chance that Parallax would release P2 without Spin!

  • Gonna. That part of it should begin soon. Once the Smart Pins are done, it's going to be time to sort out the ROM, how it boots, code protect, etc... SPIN begins in there somewhere.
  • jmgjmg Posts: 15,140
    Mickster wrote: »
    I don't know much about the P2 but apparently, it will have quadrature decode capability as well.

    Certainly Quad Counters are planned.
    Not sure about details like index-pulse reset, or capture, in Quad mode.

    If you have specific QuadCounter sub-features, now would be a good time to detail them.

    Mickster wrote: »
    I am hoping that PropBASIC will support the P2, also.

    I would expect PropBASIC, Spin, & C to all be ported to P2 fairly quickly.

  • jmg wrote: »

    Certainly Quad Counters are planned.
    Not sure about details like index-pulse reset, or capture, in Quad mode.

    If you have specific QuadCounter sub-features, now would be a good time to detail them.

    Index pulse capture would be useful for verifying count integrity.

    My only other (unrelated) thought regarding the P2 is the possibility of a BiSS-C master/slave object.
  • jmgjmg Posts: 15,140
    Mickster wrote: »
    Index pulse capture would be useful for verifying count integrity.
    Capture and even compare will be there in the counter cell, so this is more a pin-mapping probem

    Chip would need to comment on a Smart-Pin-cell being able to map to three pins ?
    Mickster wrote: »
    My only other (unrelated) thought regarding the P2 is the possibility of a BiSS-C master/slave object.

    This BiSS-C probably needs a separate thread.

    That's certainly very interesting, and explains one puzzle I had over the Infineon XMC1000 series.

    There, they have a very nicely flexible 1..63 bits of length in UART and SPI modes. I thought it was quite forward thinking of a chip vendor to make such a change, but I see it was likely driven by this BiSS.


    Quick Issues Scan :
    * IIRC Prop 2 was already planing to have flexible bit counts, at least to 32b, maybe that needs to push to 64b (or more ?) ?
    Given parts like Infineon XMC1xx already have 64b serial modes, this seems a natural step.

    * Some aspects of BiSS slave could be handled with an async-receiver, but it is not clear if features like stretch-ack for busy, adds to the Rx bit count ?

    To support such features, and not push up the Rx Bit count, may need a special Async Start-bit BiSS state engine ? Not complex, but needs an enable/disable bit.

    * The spec mentions cable delay measure.
    Async mode tolerates delays, but gives no information.

    If that information was needed/important, to SysCLK levels, then extra hardware would be needed

    With timers already in the Smart-Pin, this could be as simple as MA _/= to SLOn =\_ Armed one-shot capture.

    100 MBit/s may be a push, but 10 MBit/s should be doable, even 20-40MBit/s.

    Using SyncRX would allow higher bauds, but that needs sample-point adjust with cable delay, which is still SysCLK period (or maybe SysCLK period/2 ?) granular.

    HyperBUS manages this sample-point issue with a feed-back copy of the clock-out.
    Rx phase is then stable & error free, but does now have an any-phase relationship with SysCLK.



  • What is the projected release date for the Prop 2?
  • Release date remains the same:

    "When it is ready."
  • cybersackcybersack Posts: 10
    edited 2016-01-05 06:38
    Release date remains the same:"When it is ready."

    I am completely new here and not yet sure whether I am sinking or swimming in this electronics world, but as a software engineer I was heartened by the very realistic response :)

    Question: Do I program in C or Spin for P1 ? And for P2 ?
    Ubuntu Trusty (14.04) security was not happy for to install simple-ide_1-0-1-rc1_amd64.deb with the warning:
    The package is of bad quality

    The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath.

    E: simpleide: wrong-file-owner-uid-or-gid opt/parallax/Workspace/Learn/Examples/ 1000/1000
    ...
  • evanhevanh Posts: 15,126
    cybersack wrote: »
    Ubuntu Trusty (14.04) security was not happy for to install simple-ide_1-0-1-rc1_amd64.deb with the warning:
    The package is of bad quality
    ...
    E: simpleide: wrong-file-owner-uid-or-gid opt/parallax/Workspace/Learn/Examples/ 1000/1000
    ...

    Ha! I didn't get that error, but then my user number is 1000 after all.
  • evanhevanh Posts: 15,126
    My feeling on the Prop1 is Spin+Pasm is the way to go. RAM space is too precious for C's standard libs.
    The Prop2 will handle C far more readily with a cool 16x HubRAM increase over the Prop1.
  • evanh wrote: »
    My feeling on the Prop1 is Spin+Pasm is the way to go. RAM space is too precious for C's standard libs.
    The Prop2 will handle C far more readily with a cool 16x HubRAM increase over the Prop1.
    Two points:

    1) Parallax has provided "Simple Libraries" that are supposedly more space efficient than the standard C libraries

    2) The CMM memory model is nearly as compact as Spin bytecodes and usually much faster

    So I don't think C is unusable on the P1.

  • David Betz wrote: »
    evanh wrote: »
    My feeling on the Prop1 is Spin+Pasm is the way to go. RAM space is too precious for C's standard libs.
    The Prop2 will handle C far more readily with a cool 16x HubRAM increase over the Prop1.
    Two points:

    1) Parallax has provided "Simple Libraries" that are supposedly more space efficient than the standard C libraries

    2) The CMM memory model is nearly as compact as Spin bytecodes and usually much faster

    So I don't think C is unusable on the P1.

    Yikes... This dead horse has been kicked too many times.
    <10 minutes later..........>
    I actually couldn't find any good threads from the last year on this. I know they've happened... dunno where they went.
    I think David Betz's first point deserves expanding. The fact that Parallax put time/money into creating a suite of libraries and is still pushing it to educational customers should show you that C is a perfectly valid option. Parallax wouldn't push it if it wasn't.

    On top of the above points though, there is also PropWare and libpropeller which are just as efficient (and more so in many cases) as the Simple libraries but written in C++.
    cybersack wrote: »
    Release date remains the same:"When it is ready."

    I am completely new here and not yet sure whether I am sinking or swimming in this electronics world, but as a software engineer I was heartened by the very realistic response :)

    Question: Do I program in C or Spin for P1 ? And for P2 ?
    Ubuntu Trusty (14.04) security was not happy for to install simple-ide_1-0-1-rc1_amd64.deb with the warning:
    The package is of bad quality

    The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath.

    E: simpleide: wrong-file-owner-uid-or-gid opt/parallax/Workspace/Learn/Examples/ 1000/1000
    ...

    As a professional software engineer, you may well appreciate PropWare. Aside from the C++ classes available, the standard installation provides you with a CMake build system for use with the Propeller and PropGCC. You then have the ability to use your favorite IDE/editor instead of being forced into SimpleIDE or hand-written Makefiles.
  • potatoheadpotatohead Posts: 10,253
    edited 2016-01-05 16:13
    Question: Do I program in C or Spin for P1 ? And for P2 ?

    On P1, there are users seeing success with both. I suggest you look it all over and give things a try.

    On P2, it's PASM, FORTH and C at present. All are in development. P1 Spin can be ran on the P2. Several of us are just using PASM. That's true for me, though I plan to use C some time around the next compilier update.





  • cybersackcybersack Posts: 10
    edited 2016-01-05 20:03
    As suggested by David, post moved to http://forums.parallax.com/discussion/163221/getting-started-with-p1-and-how-to-code.

    Thanks to all of who who have kindly replied :)
  • cybersack wrote: »
    Thanks for some really informative replies.
    Please let me know if I am posting in the wrong place and I will move the topic accordingly.

    These are definitely loaded questions that would be better in another thread. I'd recommend copying you entire post (it's well worded, just in the wrong place) into a separate thread in the P1 sub-forum. Once the new thread is created, remove this post and then linking to the other thread might help keep this thread more on-topic
  • David BetzDavid Betz Posts: 14,511
    edited 2016-01-05 19:31
    cybersack wrote: »
    Questions I have:
    * Is Spin a language that you people feel has led you to obtain better results (quality/productivity) ?
    * Is Spin a language that will be offered on the P2 ?
    Many people here will say yes to your first question. It mostly depends on whether you want to take the time to learn a new language. You will certainly find more support among the forum members for programming in Spin. However, you will get good support from Parallax for both Spin and C.

    In answer to your second question, Spin will certainly be offered on the P2. In fact, there is already an effort in progress to allow P1 Spin programs to be run on the P2. In addition, I'm certain that Parallax will offer a version of Spin tailored to the P2.

  • Cluso99Cluso99 Posts: 18,066
    cybersack,

    PASM on the P1 prop is quite easy provided you stick to the mainstream instructions. Print out the two summary sheets and you are almost good to go.

    The base instructions (and/or/...) plus jmpret (jmp/call/ret/jmpret) (don't forget the # is normally required to prefix the address) should get you on your way. And you will need to use the PAR register to get the hub address for parameters passed from spin.

    Go on over to the Propeller 1 thread and we'll help get you going on pasm there.

    I cannot stress how simple the basic pasm instructions are. It's the best assembler instructions of any micro I have ever used, and I have used heaps of them.
  • cybersackcybersack Posts: 10
    edited 2016-01-05 20:04
    ok...moving my post over to the P1 sub-forum .... please follow this thread over there ...
    http://forums.parallax.com/discussion/163221/getting-started-with-p1-and-how-to-code
  • Back to the original thread topic, at the rate of progress of the prop 2, can we expect a finished product by end of 2016? 2017? If you wait too long, can it become obsolete at the current rate of technology?
  • cgraceycgracey Posts: 14,133
    edited 2016-01-07 01:40
    tryit wrote: »
    Back to the original thread topic, at the rate of progress of the prop 2, can we expect a finished product by end of 2016? 2017? If you wait too long, can it become obsolete at the current rate of technology?

    I think 2016 is quite certain.

    In some ways it will be obsolete ten years ago, but in others it will be cutting edge ten years from now. It's a paradox.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2016-01-07 02:07
    cgracey wrote: »
    In some ways it will be obsolete ten years ago, but in others it will be cutting edge ten years from now. It's a paradox.

    Interesting that you say that. I feel the same way about the P1. What 32 bit chip doesn't have a multiply or divide command???? But at the same time.... how many octacore processors are there for $8? :D
  • And that are reasonably easy?
  • Cluso99Cluso99 Posts: 18,066
    Well there are some cheap 8 core ARM chips out there now.

    BUT, you need a 10 ton truck to transport the documentation, and a lifetime to read and understand it ;)
  • Personally, I like the idea of bit banging every protocol. It feels like I have a lot more control of every little thing happening all the time. Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?
  • jmgjmg Posts: 15,140
    gis667en11 wrote: »
    Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?

    You prefer a pedal car to a Porche ?
    Hardware will always get there (much) faster, which is the point you missed.
  • I like hardware, or a good hardware assist. Those frequently present as solved problems, freeing me to solve more specific problems.
  • cgraceycgracey Posts: 14,133
    edited 2016-01-07 05:56
    jmg wrote: »
    gis667en11 wrote: »
    Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?

    You prefer a pedal car to a Porche ?
    Hardware will always get there (much) faster, which is the point you missed.

    Pedal a car and it will go from A to B. Teach a car to pedal and it can loop from A to Z.
  • cgraceycgracey Posts: 14,133
    edited 2016-01-07 06:06
    gis667en11 wrote: »
    Personally, I like the idea of bit banging every protocol. It feels like I have a lot more control of every little thing happening all the time. Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?

    It's good to have the option to bit-bang what you want.

    In Windows programming, I found that nothing beyond a button and a scrollbar was trustworthy. I built every other control myself. That was for the SX-Key software, which was an assembler, programmer, and in-circuit debugger.

    For these smart pins, only the most fundamental functions are being implemented - things that have been and will be useful, indefinitely.
Sign In or Register to comment.