Prop2 Feature List
MacGeek117
Posts: 747
in Propeller 2
Hello all!
Did some cursory searching, and all of the lists I've found seem to be upwards of a couple of years old, is there a list anywhere of the current feature set?
Did some cursory searching, and all of the lists I've found seem to be upwards of a couple of years old, is there a list anywhere of the current feature set?
Comments
There you should find everything.
Thanks!
David, thanks for going over the doc and making suggestions/edits. I'll get in there soon and process them all.
That might be a somewhat optimistic interpretation of memory spaces. Data accesses are still the same as the Prop1. Only the instruction pointer has that contiguous mapping arrangement. Also, to keep addressing consistent between data and code, there is no address translation on instruction fetches from HubRAM so it means the first 2kB/4kB (Is LUTRAM mapped in? I'm not sure.) (There is a slight word size trick that inherently reduces the address range. And yes, since it's 1024 addresses, LUTRAM is mapped.) 1kB of HubRAM is not executable space.
SmartPins are indeed crazy powerful. It's gonna be decades of new uses in those.
They remain separate memory spaces. This is important because it allows for the COGS to operate independently, like P1 does. So we get that object benefit we find useful and easy.
Interrupts, memory, the streamer, etc... are all local to a given COG. This means we can build more powerful objects and still use them together easily like we do in P1. Polling, non interrupt P1 style methods are there too. Not having this all be global avoids the need for an OS and the complex interrupt kernel type code associated often needed in other systems.
The HUB memory and Cordic math is global as are the pins.
A COG may run code in its local RAM, P1 style, or can run code from other memory, such as its look up table (LUT) RAM, or the HUB.
In that case, instructions come from that RAM, making the COG RAM a big pile of registers!
LMM, from the P1, is replaced by this ability, called HUBEXEC.
Multiple COGS can run the same code from HUB directly, or copy it to their local RAM P1 style.
This gives us big program capability with native hardware support. Instructions and addressing have been extended for this to all make sense.
Man, there is a whole lot more. This chip is gonna rock!
I'm about to return to P2 land. Probably will on the next FPGA update. Want to try shared LUT and see if all my sprite and pixel code works. Also video. Think I have a good solution for color shimmer on composite.
We are all gonna see increasingly good times from here.
First, for putting up with me. Second, all this chatter, games, language, programming, circuit fun really sunk in! When I started this Propeller adventure, I set IRIX aside, kept my retro computers and returned to embedded after 20 some years away.
My P1 project is complex, driving inductive loads and requires a lot of timing and I2C.
...and the Spud is getting it done. Work project, not hobby. Several have been amazed at small SPIN and PASM code bits doing stuff that normally takes a lot more overall.
Now I always have been convinced this P2 adventure is worth it, but it's nice to have some basic confirmation.
Wish I had P2, just because, but I don't need it at all.
Can't share, but I will when I can.
Kind regards, Samuel Lourenço
There is an 8 bit analog DAC for every pin. The LSB of this DAC gets PWMed with an 8bit value so that the resolution increases to 16bit (but at a lower frequency).
You just write a 16bit value and the higher 7 bits go to the DAC and the lower 9 bits go to a PWM modulator that modulates the LSB.
The PWM is either just 512 steps in PWM mode, or the PWM is modulated with a Noise signal in dithered mode, so that the 1/512 PWM frequency gets blurred. This may be better for Audio or for high sample frequencies, not synced to the PWM frequency.
Andy
If so, this could majorly cut down on the part requirements for one of my upcoming projects.
USB code is still being tested, but P2 can (in theory) do Host and Device, on a one-per-COG basis.
Whether you can call that a HUB, may depend on the details - Google suggests HUB should not delay by more than 36 bit times.
I would expect 1 Device & 4 Hosts should be possible, using 5 COGs.
Many thanks, Andy.
What a spectacular spec :-)
Certainly No High Speed USB (480M), which is part of USB 2.0
There are other USB 2.0 details, that could be supported by P2
https://en.wikipedia.org/wiki/USB#USB_2.0
Sorry, yes, on P2 it uses hubexec. The LMM is on P1.
It does have interrupts? So then a memory protection/management unit is possible?
Nope. Not a true, hardware-enforced one, anyhow.
Can you explain the difference between a hardware-enforced interrupt and what the Prop 2 has? I've never heard of such a distinction before.
Prop2 has hardware interrupts. I think he means true hardware memory protection/management. That requires generating an interrupt when a program tries to access an address outside the assigned memory bounds.
Okay. Makes more sense.