Propeller 2 Specs
tryit
Posts: 72
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
* 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
Comments
I am hoping that PropBASIC will support the P2, also.
Also, is P2 for sure going to have Spin? Gonna, gonna?
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.
I would expect PropBASIC, Spin, & C to all be ported to P2 fairly quickly.
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.
Chip would need to comment on a Smart-Pin-cell being able to map to three pins ?
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.
"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:
Ha! I didn't get that error, but then my user number is 1000 after all.
The Prop2 will handle C far more readily with a cool 16x HubRAM increase over the Prop1.
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++.
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.
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.
Thanks to all of who who have kindly replied
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
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.
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.
http://forums.parallax.com/discussion/163221/getting-started-with-p1-and-how-to-code
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.
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?
BUT, you need a 10 ton truck to transport the documentation, and a lifetime to read and understand it
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.
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.