The original idea behind programmable computer processors was that·they could be easily programmed to do a variety of tasks.
(The very first computers had to be physically rewired to change the programming.)
So make it more flexible for whatever anyone wanted to use it for.
Then microprocessors came along and this was available on the desktop.
Then microcontrollers and the whole works in your hand.
Now a fast multiprocessor microcontroller.·Even more·flexible for whatever anyone wants to use it for. Does not matter if it is used for something simple or something more complex, it can do more things is the idea (including the same old things).
However they have gone way beyond just making a multiprocessor microcontroller, they have made it easy to program, provided excellent documentation, sample code, and wonderful support via this forum. So if someone just wanted a quick and easy processor to implement and just needed one cog, I should think the Propeller would be a good choice for that. ·
IMHO unless you have either...
1. Very high volume
2. Lots of code aleady
then if a prop fits the bill, use it. The extra chip cost, unless either 1 or 2 is true, will be recovered in simplicity of the software. Common inventory is another factor in favour of the prop.
The other area where a huge advance was made was in the FPGA which Xilinx pioneered. However, these are quite complex to program too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
As a fan of the PSoC, one word sums up why I use the propeller: "learnability"
If you have tried to sit down on your own and learn PSoC designer with the help and available tools online, you will get frustrated really quick. On the other hand, I created a project that utilized a GPS, uOLED display, and a servo without needed anything more than what was available in the manual, OBEX, or old forum posts. I still play with the PSoC and even have a new product coming out in a few months that uses one, but if I could do the same with a propeller, it would already be in customers' hands........
This thread has some great stuff for Parallax to use.
I think we have seen many reasons why a hobbyist would use the prop. So let's look at it from a professionals point of view.
A Professionals' Point of View I have been out of the design arena for 10 years, but I designed a lot of micro based interfaces using many micros from 1976 (MC6800 onwards). Here is my take on it...
A professional will...
already understand micros (and more than one family)
already have designed many micro pcbs
know how complex the register set of micros are
know the value in re-use of tried code blocks
know the cost of changing from a current family of micros
A reason to change micros...
Need a more powerful micro, ram or code space
Need some peripheral not available in current micro family
Some available software feature (code block done)
Lower parts count
Lower cost
To change to a Propeller based solution...
Pros...
More powerful micro (8 * 80MHz CPUs, mostly 20MHz per instruction)
Large SRAM space (yes 32KB + 8*2KB shared with code space) and good code space
Easy learning curve
no complex register set to learn
simple RISC assembler (PASM)
simple high level language (SPIN)
Multiple processor cores which can
Add standard and special hardware blocks (UARTs, I2C, SPI, VGA, PS2, etc)
Add extra software functionality to those blocks
Extra parallel programming of desired function code blocks
8 * 32bit RISC CPUs
No interupts with full code determinability (may not be seen as an advantage but believe me it is!)
A single·micro (propeller chip)·can replace a whole family of micros (less inventory)
32 I/O pins which are totally flexible (special hardware blocks can use any pins)
The counters are seperate for each CPU and are extremely powerful (new uses being found almost daily)
Very low power
Lots of objects done with source code and free to use (MITS License)
Fantastic support on this forum
Cons...
Some consider it an expensive chip (<$8)
Depends what you are comparing it to
Requires an EEPROM to store code ($1.50)
Have to learn a new architecture
Have to lean a new programming language
IMHO unless you are going to be using >10,000 chips per annum, if you have to change micros, then additional chip cost will be saved by a simpler architecture and easier code.
I may have missed some features and some cons, but it's a start. I hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Sometimes I think Parallax could change their marketing of the Prop for the mainstream professional audience. Here is my suggested new Propeller Product Brief: Parallax P8X32A Configurable System On A Chip (PCSOC)
The P8X32A PCSOC features:
A 32 bit RISC CPU programmable in C, BASIC or Spin or...
32 KBytes RAM
32 General Purpose I/O pins (GPIO)
7 General Purpose Peripheral Blocks (GPPB)
16 Counter Timers
A high resolution system clock
8 video generators
A ROM containing Trig tables etc.
The P8X32A Peripheral Blocks provide:
UART
I2C
SPI
VGA
PS2
dot, dot, dot ad infinitum
The General Purpose Peripheral Blocks (GPPB) are configured with firmware (available on request from Parallax) to perform any of the listed functions. Users can also define their own peripheral functions with custom firmware of their own creation or freely available on the net.
Any of the 32 General Purpose I/O (GPIO) pins may be freely used by any of the General Purpose Peripheral Blocks (GPPB)
Peripheral functions are accessed via memory mapped special purpose registers (SPF).
Notice that in my description of the Prop:
There is no use of strange words like "Propeller", "HUB" or "COG". Relate everything to concepts "professionals" expect to see when they are checking such things.
There is no mention of parallelism.
Those much sort after peripherals are accessed via "registers", professionals like to see lots of registers. In fact Parallax would provide a 5000+ page manual describing in minute detail the layout and function of all registers of all the peripheral blocks that they supply off the shelf "firmware" for.
Of course "registers" are simply what folks around here call "mailboxes" or "rendezvous", just memory locations that COGS communicate through. The entire content of OBEX would be modified to use "register" blocks and hence be easily accessible from C or whatever language but more importantly pad out that 5000+ page user manual and be "firmware".
OK, as usual I'm a little flippant here but I'm sure there is a grain of truth in all this.
Edit: "entire content of OBEX" means all the low level drivers from OBEX that can be converted for use with a "register" interface and operated with no Spin wrappers. Like real firmware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just a side aspect:
I like to use prebuilt project boards. I have found, that the propeller project board gives very good price-power relation. There are cheaper mcus but, if you want to buy boards with them, this advantage shrinks very much.
Christof ·
heater: I would still add the fact that there are 8 32bit RISC processors on chip. If not for this fact, I would not have bothered further with the prop - that's what got my attention first.
Sad, but there is quite a bit of truth in what you say.
We have to somehow get the message across that the onboard peripherals are extremely powerful and flexible and have software running in the seperate cpus to support them for a higher level interface. Maybe we need a new block diagram that shows each set of registers (counters) as fully programmable I/O controllers (systems). Maybe also we need a list of I/O blocks (UARTs, etc) with an "*" note that they are all software configurable systems.
In your Peripheral Blocks, you need to state multiples of each block is/are possible. USB with limited functions are now also possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso: "I would still add the fact that there are 8 32bit RISC processors on chip. If not for this fact, I would not have bothered further with the prop - that's what got my attention first."
No, no, no, You are talking about the Parallax Propeller. I am talking about a different product the Parallax Configurable System On a Chip (PCSOC) [noparse]:)[/noparse]
What do you mean it's the same chip? No matter, my post was aimed marketing and perception.
By the way the PCSOC 2 has two 32 bit CPUs and 6 GPPBs, the PCSOC 3 has three 32 bit CPUs and 5 GPPBs...[noparse]:)[/noparse]
Professionals love to spend hours selecting which device they will use next. I'm not exactly joking here. My company was just presented with a quote for 3000 Euros from a design house to do exactly such a component selection task.
I like the idea of adding the counters to the block diagram more noticeably.
Yes, the possibility of duplicate peripheral blocks should be in the PCSOC product brief.
Sadly the PCSOC does not exist as a product yet, if it ever will, but it looks like Bill Henning and others are working on it.
What's missing is all the firmware binary blobs with register interfaces and the 5000+ page manual to go with them.
USB is a useful addition to the peripheral list but the firmware blob for it would only be the low level bit banging code that goes into COG...err..sorry peripheral block. The rest is example code in an app. note.
I'm kind of pushing the point light heartedly with my PCSOC idea but the basic problem is how to present the Propeller in such a way that people even recognize it as a useful micro-controller.
That probably means using language that is the linqua franca of the target audience. None of this weird "cog" and "hub" and "Spin" stuff.
Having a check list of features to line up against the competition would be useful. It has to be such a check list that it even can be lined up against the competition. Where in any Propeller Product brief does it even mention UARTS, SPI, I2C SD card etc all those things people are used to looking for nowadays?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: I like your idea. A whole family of Props, all using the same chip, hey hey!
heater said...
Having a check list of features to line up against the competition would be useful. It has to be such a check list that it even can be lined up against the competition. Where in any Propeller Product brief does it even mention UARTS, SPI, I2C SD card etc all those things people are used to looking for nowadays?
Yes, I think this is important these days. Consider this...
The PCSOC·can have·a subset of the following possible super-intelligent configurable blocks...
14 UARTs
7·I2Cs
7·SPIs (includes SD)
7·PS2s
16 32 bit timers
3 VGAs
7 Composite video (NTSC/PAL TV)
16 PWMs
2 USB semi-compatible (non compliant) for serial, bluetooth and similar simple interfaces
7 Complex sound generators
x Analog inputs
14 Input configurable counter/timers
Other blocks can also be constructioned, limited by the users imagination
All peripherals/blocks have a simple pseudo-register/memory interface with user configerable·depth FIFOs
I/O pins·for the above blocks can be routed to any of the 32 I/O pins
I/O pins can be dynamically shared between blocks
Configurable blocks can be dynamically reconfigured
I have missed most of what the counters can do as I haven't used them much at all, so maybe some others could add to this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
USB with limited functions are now also possible.
Don't go there. Really. You could say something like "USB compatible serial bus" or other watered down phrase, but if you use USB you really risk the wrath of the USB org. It is not, and never will be USB compliant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Cluso99 said...
Brad: Is this phrase better??? 2 USB semi-compatible (non compliant) for serial, bluetooth and similar simple interfaces
Something along those lines might be acceptable. The USB org has a good history of zapping people who loosely throw the term USB around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
I'd like to add a comment here as an EE professional working with embedded processors since the Intel 8008.
Please don't get me wrong, I really like the propeller, but I'm amazed that no one has mentioned as a negative the ugly method of indirect memory access. So far all my programming is in assembler (have not learned SPIN yet) and am able to get it to do a good bunch of stuff, but the work-arounds you have to do for indirect memory access is absolutely rediculous.
All that said, I will continue to use the PROP.... it has some very good features; for me it's very low power when 'idling' is very important.
But alas, it is still missing an interrupt! I know most everyone is happy with that, but there are some things I could do better if one was available.
I we worked much with systems with interrupts - And Say NO to them. BUT I'm missing instruction that can restart COG without reload --- And that is only one thing.
On Prop I some missing fast INPUT I/O system - BUT that we will have on Prop II.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
pjv. - ...as a negative the ugly method of indirect memory access"
Perhaps the little awkwardness with indirect addressing in PASM is the price we have to pay for having such a simple, regular and easy to use instruction set with the least surprises and exceptions and the same timing on pretty much every instruction. I'm happy to live with that. Unless you can think of a way to work indexing etc into the architecture without breaking the current "orthogonality".
So far I have yet to feel the need for interrupts and have regarded the absence of interrupts a "good thing". An interrupt in PASM would require some sort of interrupt vector which eats a precious log in COG. It would require somewhere to put a return address, eats along. Nested interrupts would require a stack, eats more longs. It require some means to enable/disable it and assign a pin to it which requires other instructions or eats longs for a control reg.
All in all a lot of extra baggage.
I'd be interested to hear an example of a situation where you have felt the need for an interrupt on the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
While being a fan of the propeller chip, I must say that most of the applications people have posted about really do not need or utilize the multi-core capabilities.· Look at the contest winners, how many of those projects really required multi-tasking at the level the propeller (8 cores)?· Most, if not all of them could have been handled by any micro controller.·
Many people think that you need to update an LCD display at the same instance data is calculated etc.· In reality, most tasks can be handled easily in a serial manor.·
The Propeller does excel at some really great features that do not exist on other micros - for me primarily the video output capabilities.· However, serial communications does not require a multi-core chip, on the propeller we use it because there is not a hardware UART to handle the heavy work.
In my experiences, the propeller does excel greatly where its multi-core technology is applied correctly.· In my case that is motion control systems.
One COG is generating the output step and direction signals for a motor drive - at high velocities, there isn't any time left over to handle any of the other calculations or tasks.· In such cases, I would then assign another task to a new COG.· For example...
Output step and direction signals to the axis drives
Read 4 encoders
Calculate velocity with active Acc/Dec
Communicate with another micro
A VERY fast micro might be able to do all of that in a serial fashion however, I have not found one that could (that I could also program easily).· So, while you can look at the COGs as spin-your-own-peripherals for various pins, that is not a good way to compare it to another micro (single core).· Rather, look at what tasks MUST be done concurrently that cannot be done in "left over" time on a single core micro.·
Sorry if this is bit "wandering", I had to type it between meetings here at work
Chris_D: "Many people think that you need to update an LCD display at the same instance data is calculated etc. In reality, most tasks can be handled easily in a serial manor. "
That is true but dropping an LCD object, a UART an SD card a KALMAN filter or whatever into a Prop project is much easier than integrating those things into the common or garden interrupt based sytems. The simplicity of the Prop approach should not be overlooked.
Chris_D: "So, while you can look at the COGs as spin-your-own-peripherals for various pins, that is not a good way to compare it to another micro (single core)."
Also partially true but given that one Prop can have an infinite variety of peripherals it saves having to compare hundreds of different versions of the same single core architecture to find the one that fits your application. And it saves your bacon when you change your mind about what peripherals you need to use.
In general I agree, the ideal Prop application is one where the Prop is used to juggle multiple concurrent and fast external events.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I like the propeller because I have never seen anything like obex before. I can do really powerful things by leveraging the expertise of others that I simply do not have. I likea. plug and play sd reader, tv/vga or whatever. Most of my programs are simple 1 to 2 cog controller loops using premade virtual peripherals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
Just as a curiosity, for those not used to sweating over
interrupt code, here is a very simple complete AVR program
that has an interrupt that hits every 20,000th of a second.
All this does is wiggle an output pin on portB.
The code that you put inside the ISR(TIMER1_COMPA_vect) block
runs whenever the Timer1 interrupt hits. On a prop you would
run the code contained in this interrupt routine in a new cog. On an AVR
or ARM you have to do it like this....and you have to worry that
your code might take too long inside this routine and exceed its
available time of <1/20,000th of a second. In this simplified
example the main code is simply an endless do nothing loop.
In a real world example lots would be going on inside main and
other interrupts would also be firing. This demo should run in the
AVR Studio4 simulator, for just about any AVR with a 16bit Timer1
...as long as I made no typos. This demo is just to show you propeller
only geeks what fun you are missing not using interrupts..LoL
//Timer1 demo
//H.A.Minkowski Jun 18, 2010
#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdlib.h>
int main (void)
{
DDRB |= (1 << 0); // Set pin as output
TCCR1B |= (1 << WGM12); // Setup timer1 for CTC mode
TIMSK1 |= (1 << OCIE1A); // Engage CTC interrupt
sei(); // Allow global interrupts
OCR1A = 400; // Set CTC compare value to 8,000,000/some val at 8mhz clock
// so, 8,000,000/400 = 20,0000 interrupts/second
TCCR1B |= (1 << CS10); // Start timer at same freq as main clock (8mhz rc timer)
for (;;)
{
}
}
ISR(TIMER1_COMPA_vect)
{
PORTB ^= (1 << 0); // Toggle the output pin
}
Personally, I'd configure one of a timers in a cog to do this - no need to tie up a whole cog [noparse]:)[/noparse]
HollyMinkowski said...
Just as a curiosity, for those not used to sweating over
interrupt code, here is a very simple complete AVR program
that has an interrupt that hits every 20,000th of a second.
All this does is wiggle an output pin on portB.
The code that you put inside the ISR(TIMER1_COMPA_vect) block
runs whenever the Timer1 interrupt hits. On a prop you would
run the code contained in this interrupt routine in a new cog. On an AVR
or ARM you have to do it like this....and you have to worry that
your code might take too long inside this routine and exceed its
available time of <1/20,000th of a second. In this simplified
example the main code is simply an endless do nothing loop.
In a real world example lots would be going on inside main and
other interrupts would also be firing. This demo should run in the
AVR Studio4 simulator, for just about any AVR with a 16bit Timer1
...as long as I made no typos. This demo is just to show you propeller
only geeks what fun you are missing not using interrupts..LoL
//Timer1 demo
//H.A.Minkowski Jun 18, 2010
#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdlib.h>
int main (void)
{
DDRB |= (1 << 0); // Set pin as output
TCCR1B |= (1 << WGM12); // Setup timer1 for CTC mode
TIMSK1 |= (1 << OCIE1A); // Engage CTC interrupt
sei(); // Allow global interrupts
OCR1A = 400; // Set CTC compare value to 8,000,000/some val at 8mhz clock
// so, 8,000,000/400 = 20,0000 interrupts/second
TCCR1B |= (1 << CS10); // Start timer at same freq as main clock (8mhz rc timer)
for (;;)
{
}
}
ISR(TIMER1_COMPA_vect)
{
PORTB ^= (1 << 0); // Toggle the output pin
}
The indirect addressing case is interesting to me.
On most processors, indexing and indirection takes extra cycles. Does it matter what form those extra cycles take, over a simple, direct, or absolute instruction?
On a prop, we do an add. On another CPU, we specify a register to be incremented, or do an add. Worst case we do an add, and a mov(sd). On that other CPU, we do a load, add, etc...
IMHO, this is mostly perception. The instruction set is clean, and is a memory to memory one, lacking things like index registers and such. Well, on those other CPUs, that do not use a memory to memory design, the registers are a limited resource, and indirection happens easily enough, but register shuffling occurs. On a prop, we have to do the indirection, but there is little to no register contention.
The self-modify part is a concern, but really is it? On a Prop, we have the COG / HUB address spaces, and a non-associative load of the COG, optionally preserving the program state, if the programmer needs it. On other CPUs, there is one address space (generally speaking), interrupts and all the other stuff necessary to deal with code that, once written is just changed. One can choose to simply not worry about that on a prop, if they want to.
Holly: LOL. I am glad to be rid of that style of code. I recall having to do a 2400 baud UART (there is none on a MC68705P3S) via interrupts while driving modem chips and handling the AT cammand set, all in 1.7KB. The prop makes this so simple.
Indirection is actually simple, it just takes a couple of instructions and at the prop speed this is fine.
What is the most interesting in the prop is the fact that you can add a complex peripheral and also include some other functions to make it a really smart peripheral. Since it resides in a cog, it is basically a seperate object that is easy to debug. So what have we done - we used a processor to accompish two things...
* Implement a block of hardware (say a UART)
* Implement some parallel code to make it a much smarter block (smart UART) that may handle a protocol
Now we have 8 of these, so in the normal realm of coding, we have 1 processor doing the controlling, and we have up to 7 to implement smart peripheral blocks (in parallel) or some other parallel function, like the Kalman filtering.
IMHO we have not yet seen full use of the parallelism that the prop can achieve, nor have we seen really complex hardware blocks that the Prop is capable of. These are just starting to be understood and exploited and soon (Ok still a way out) we will have an even more powerful Prop II to play with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
(The very first computers had to be physically rewired to change the programming.)
So make it more flexible for whatever anyone wanted to use it for.
Then microprocessors came along and this was available on the desktop.
Then microcontrollers and the whole works in your hand.
Now a fast multiprocessor microcontroller.·Even more·flexible for whatever anyone wants to use it for. Does not matter if it is used for something simple or something more complex, it can do more things is the idea (including the same old things).
However they have gone way beyond just making a multiprocessor microcontroller, they have made it easy to program, provided excellent documentation, sample code, and wonderful support via this forum. So if someone just wanted a quick and easy processor to implement and just needed one cog, I should think the Propeller would be a good choice for that.
·
1. Very high volume
2. Lots of code aleady
then if a prop fits the bill, use it. The extra chip cost, unless either 1 or 2 is true, will be recovered in simplicity of the software. Common inventory is another factor in favour of the prop.
The other area where a huge advance was made was in the FPGA which Xilinx pioneered. However, these are quite complex to program too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
If you have tried to sit down on your own and learn PSoC designer with the help and available tools online, you will get frustrated really quick. On the other hand, I created a project that utilized a GPS, uOLED display, and a servo without needed anything more than what was available in the manual, OBEX, or old forum posts. I still play with the PSoC and even have a new product coming out in a few months that uses one, but if I could do the same with a propeller, it would already be in customers' hands........
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
WBA-TH1M Sensirion SHT11 Module
My Prop projects: Reverse Geo-Cache Box, Custom Metronome, Micro Plunge Logger
I think we have seen many reasons why a hobbyist would use the prop. So let's look at it from a professionals point of view.
A Professionals' Point of View
I have been out of the design arena for 10 years, but I designed a lot of micro based interfaces using many micros from 1976 (MC6800 onwards). Here is my take on it...
A professional will...
A reason to change micros...
To change to a Propeller based solution...
Pros...
Cons...
IMHO unless you are going to be using >10,000 chips per annum, if you have to change micros, then additional chip cost will be saved by a simpler architecture and easier code.
I may have missed some features and some cons, but it's a start. I hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Sometimes I think Parallax could change their marketing of the Prop for the mainstream professional audience. Here is my suggested new Propeller Product Brief:
Parallax P8X32A Configurable System On A Chip (PCSOC)
The P8X32A PCSOC features:
The P8X32A Peripheral Blocks provide:
The General Purpose Peripheral Blocks (GPPB) are configured with firmware (available on request from Parallax) to perform any of the listed functions. Users can also define their own peripheral functions with custom firmware of their own creation or freely available on the net.
Any of the 32 General Purpose I/O (GPIO) pins may be freely used by any of the General Purpose Peripheral Blocks (GPPB)
Peripheral functions are accessed via memory mapped special purpose registers (SPF).
Notice that in my description of the Prop:
There is no use of strange words like "Propeller", "HUB" or "COG". Relate everything to concepts "professionals" expect to see when they are checking such things.
There is no mention of parallelism.
Those much sort after peripherals are accessed via "registers", professionals like to see lots of registers. In fact Parallax would provide a 5000+ page manual describing in minute detail the layout and function of all registers of all the peripheral blocks that they supply off the shelf "firmware" for.
Of course "registers" are simply what folks around here call "mailboxes" or "rendezvous", just memory locations that COGS communicate through. The entire content of OBEX would be modified to use "register" blocks and hence be easily accessible from C or whatever language but more importantly pad out that 5000+ page user manual and be "firmware".
OK, as usual I'm a little flippant here but I'm sure there is a grain of truth in all this.
Edit: "entire content of OBEX" means all the low level drivers from OBEX that can be converted for use with a "register" interface and operated with no Spin wrappers. Like real firmware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/17/2010 8:35:20 AM GMT
I like to use prebuilt project boards. I have found, that the propeller project board gives very good price-power relation. There are cheaper mcus but, if you want to buy boards with them, this advantage shrinks very much.
Christof
·
Sad, but there is quite a bit of truth in what you say.
We have to somehow get the message across that the onboard peripherals are extremely powerful and flexible and have software running in the seperate cpus to support them for a higher level interface. Maybe we need a new block diagram that shows each set of registers (counters) as fully programmable I/O controllers (systems). Maybe also we need a list of I/O blocks (UARTs, etc) with an "*" note that they are all software configurable systems.
In your Peripheral Blocks, you need to state multiples of each block is/are possible. USB with limited functions are now also possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
No, no, no, You are talking about the Parallax Propeller. I am talking about a different product the Parallax Configurable System On a Chip (PCSOC) [noparse]:)[/noparse]
What do you mean it's the same chip? No matter, my post was aimed marketing and perception.
By the way the PCSOC 2 has two 32 bit CPUs and 6 GPPBs, the PCSOC 3 has three 32 bit CPUs and 5 GPPBs...[noparse]:)[/noparse]
Professionals love to spend hours selecting which device they will use next. I'm not exactly joking here. My company was just presented with a quote for 3000 Euros from a design house to do exactly such a component selection task.
I like the idea of adding the counters to the block diagram more noticeably.
Yes, the possibility of duplicate peripheral blocks should be in the PCSOC product brief.
Sadly the PCSOC does not exist as a product yet, if it ever will, but it looks like Bill Henning and others are working on it.
What's missing is all the firmware binary blobs with register interfaces and the 5000+ page manual to go with them.
USB is a useful addition to the peripheral list but the firmware blob for it would only be the low level bit banging code that goes into COG...err..sorry peripheral block. The rest is example code in an app. note.
I'm kind of pushing the point light heartedly with my PCSOC idea but the basic problem is how to present the Propeller in such a way that people even recognize it as a useful micro-controller.
That probably means using language that is the linqua franca of the target audience. None of this weird "cog" and "hub" and "Spin" stuff.
Having a check list of features to line up against the competition would be useful. It has to be such a check list that it even can be lined up against the competition. Where in any Propeller Product brief does it even mention UARTS, SPI, I2C SD card etc all those things people are used to looking for nowadays?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I think this is important these days. Consider this...
I have missed most of what the counters can do as I haven't used them much at all, so maybe some others could add to this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 6/17/2010 2:23:05 PM GMT
Don't go there. Really. You could say something like "USB compatible serial bus" or other watered down phrase, but if you use USB you really risk the wrath of the USB org. It is not, and never will be USB compliant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Something along those lines might be acceptable. The USB org has a good history of zapping people who loosely throw the term USB around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
I'd like to add a comment here as an EE professional working with embedded processors since the Intel 8008.
Please don't get me wrong, I really like the propeller, but I'm amazed that no one has mentioned as a negative the ugly method of indirect memory access. So far all my programming is in assembler (have not learned SPIN yet) and am able to get it to do a good bunch of stuff, but the work-arounds you have to do for indirect memory access is absolutely rediculous.
All that said, I will continue to use the PROP.... it has some very good features; for me it's very low power when 'idling' is very important.
But alas, it is still missing an interrupt! I know most everyone is happy with that, but there are some things I could do better if one was available.
Cheers,
Peter (pjv)
I we worked much with systems with interrupts - And Say NO to them. BUT I'm missing instruction that can restart COG without reload --- And that is only one thing.
On Prop I some missing fast INPUT I/O system - BUT that we will have on Prop II.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Perhaps the little awkwardness with indirect addressing in PASM is the price we have to pay for having such a simple, regular and easy to use instruction set with the least surprises and exceptions and the same timing on pretty much every instruction. I'm happy to live with that. Unless you can think of a way to work indexing etc into the architecture without breaking the current "orthogonality".
So far I have yet to feel the need for interrupts and have regarded the absence of interrupts a "good thing". An interrupt in PASM would require some sort of interrupt vector which eats a precious log in COG. It would require somewhere to put a return address, eats along. Nested interrupts would require a stack, eats more longs. It require some means to enable/disable it and assign a pin to it which requires other instructions or eats longs for a control reg.
All in all a lot of extra baggage.
I'd be interested to hear an example of a situation where you have felt the need for an interrupt on the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Many people think that you need to update an LCD display at the same instance data is calculated etc.· In reality, most tasks can be handled easily in a serial manor.·
The Propeller does excel at some really great features that do not exist on other micros - for me primarily the video output capabilities.· However, serial communications does not require a multi-core chip, on the propeller we use it because there is not a hardware UART to handle the heavy work.
In my experiences, the propeller does excel greatly where its multi-core technology is applied correctly.· In my case that is motion control systems.
One COG is generating the output step and direction signals for a motor drive - at high velocities, there isn't any time left over to handle any of the other calculations or tasks.· In such cases, I would then assign another task to a new COG.· For example...
Output step and direction signals to the axis drives
Read 4 encoders
Calculate velocity with active Acc/Dec
Communicate with another micro
A VERY fast micro might be able to do all of that in a serial fashion however, I have not found one that could (that I could also program easily).· So, while you can look at the COGs as spin-your-own-peripherals for various pins, that is not a good way to compare it to another micro (single core).· Rather, look at what tasks MUST be done concurrently that cannot be done in "left over" time on a single core micro.·
Sorry if this is bit "wandering", I had to type it between meetings here at work
Chris
·
That is true but dropping an LCD object, a UART an SD card a KALMAN filter or whatever into a Prop project is much easier than integrating those things into the common or garden interrupt based sytems. The simplicity of the Prop approach should not be overlooked.
Chris_D: "So, while you can look at the COGs as spin-your-own-peripherals for various pins, that is not a good way to compare it to another micro (single core)."
Also partially true but given that one Prop can have an infinite variety of peripherals it saves having to compare hundreds of different versions of the same single core architecture to find the one that fits your application. And it saves your bacon when you change your mind about what peripherals you need to use.
In general I agree, the ideal Prop application is one where the Prop is used to juggle multiple concurrent and fast external events.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
interrupt code, here is a very simple complete AVR program
that has an interrupt that hits every 20,000th of a second.
All this does is wiggle an output pin on portB.
The code that you put inside the ISR(TIMER1_COMPA_vect) block
runs whenever the Timer1 interrupt hits. On a prop you would
run the code contained in this interrupt routine in a new cog. On an AVR
or ARM you have to do it like this....and you have to worry that
your code might take too long inside this routine and exceed its
available time of <1/20,000th of a second. In this simplified
example the main code is simply an endless do nothing loop.
In a real world example lots would be going on inside main and
other interrupts would also be firing. This demo should run in the
AVR Studio4 simulator, for just about any AVR with a 16bit Timer1
...as long as I made no typos. This demo is just to show you propeller
only geeks what fun you are missing not using interrupts..LoL
//Timer1 demo //H.A.Minkowski Jun 18, 2010 #include <avr/interrupt.h> #include <avr/io.h> #include <stdlib.h> int main (void) { DDRB |= (1 << 0); // Set pin as output TCCR1B |= (1 << WGM12); // Setup timer1 for CTC mode TIMSK1 |= (1 << OCIE1A); // Engage CTC interrupt sei(); // Allow global interrupts OCR1A = 400; // Set CTC compare value to 8,000,000/some val at 8mhz clock // so, 8,000,000/400 = 20,0000 interrupts/second TCCR1B |= (1 << CS10); // Start timer at same freq as main clock (8mhz rc timer) for (;;) { } } ISR(TIMER1_COMPA_vect) { PORTB ^= (1 << 0); // Toggle the output pin }▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
On most processors, indexing and indirection takes extra cycles. Does it matter what form those extra cycles take, over a simple, direct, or absolute instruction?
On a prop, we do an add. On another CPU, we specify a register to be incremented, or do an add. Worst case we do an add, and a mov(sd). On that other CPU, we do a load, add, etc...
IMHO, this is mostly perception. The instruction set is clean, and is a memory to memory one, lacking things like index registers and such. Well, on those other CPUs, that do not use a memory to memory design, the registers are a limited resource, and indirection happens easily enough, but register shuffling occurs. On a prop, we have to do the indirection, but there is little to no register contention.
The self-modify part is a concern, but really is it? On a Prop, we have the COG / HUB address spaces, and a non-associative load of the COG, optionally preserving the program state, if the programmer needs it. On other CPUs, there is one address space (generally speaking), interrupts and all the other stuff necessary to deal with code that, once written is just changed. One can choose to simply not worry about that on a prop, if they want to.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 6/18/2010 5:30:03 AM GMT
Indirection is actually simple, it just takes a couple of instructions and at the prop speed this is fine.
What is the most interesting in the prop is the fact that you can add a complex peripheral and also include some other functions to make it a really smart peripheral. Since it resides in a cog, it is basically a seperate object that is easy to debug. So what have we done - we used a processor to accompish two things...
* Implement a block of hardware (say a UART)
* Implement some parallel code to make it a much smarter block (smart UART) that may handle a protocol
Now we have 8 of these, so in the normal realm of coding, we have 1 processor doing the controlling, and we have up to 7 to implement smart peripheral blocks (in parallel) or some other parallel function, like the Kalman filtering.
IMHO we have not yet seen full use of the parallelism that the prop can achieve, nor have we seen really complex hardware blocks that the Prop is capable of. These are just starting to be understood and exploited and soon (Ok still a way out) we will have an even more powerful Prop II to play with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz