As for ADC, yes I am disappointed too. But hey, we can enlist another cheap AVR for this. Don't get locked in to thinking only 1 chip is the total solution.
I can virtually guarantee that when the Prop II arrives, there will be a short dip in Prop I sales as we all concentrate on the Prop II. However, the Prop II release will generate a huge amount of press interest and that will also mention (if done correctly, which I think it will be) the Prop I. I think that will be when the engineers will discover they have a baby and a big brother, so to speak. Then I think we shall see both chips taking off, because both have their place. The Prop II will therefore also fuel Prop I sales. Just MHO. And we all realise there is a place for Prop I too!
I consider the Prop great for small scientific instruments. It has all the timing, i/o, user interface capabilities, data storage, etc etc. that typically come up in a small self-contained instrument
I feel the same way, I have used it to make small diagnostic tools for analyzing data
coming from various systems. It is really a perfect fit for many such tasks. In one instance
we put a small uc inside a device and had it analyze some internal data and transfer it to the
power on LED on the front of the device. The LED pulsed the data at a rate that was fast
enough that you could not tell it was winking on/off at all. This saved us having to alter the
case of the device by adding a data jack of some sort....it was important that the device remain
exactly as it was because it was water and dust proof. The prop along with a small lcd screen
was the perfect uc for the external data reader for this setup. Data flow was 2 way as the LED
also served as a mediocre but usable light sensor.
I third that, It is nice to be able to use a protoboard when others are spending 1000's on labview and the associated hardware. They are not directly equivalent but often people are cracking nuts with the national instruments sledgehammer.
As for ADC, yes I am disappointed too. But hey, we can enlist another cheap AVR for this. Don't get locked in to thinking only 1 chip is the total solution.
A very pertinent point in a thread on the commercial success and future of the Prop. Try selling that argument to someone who is comparing against a single chip offering with ADC on-chip which can do the same job when they need ADC.
It's a fair point for anyone considering a micro ( any micro ) to ask why they should choose a Prop which needs external ADC, external Eeprom, external Crystal, all the extra costs, extra board space, against a single chip which has all that on-board. Not to mention comes with a much narrower operating voltage range, and likely a higher price.
I know that some will be convinced by what a Propeller does offer to make those necessities and extras worthwhile but I suspect most won't. The idea that people will just put up with it, accept it as a minor inconvenience, isn't so true beyond this forum and those already using Props.
The Prop is a niche product ( those willing to accept what a Prop is ). If one wants more one goes to XMOS or high-end ARM, otherwise one goes to PICmicro, AVR or lower-end ARM etc. I'm therefore intrigued to know what all these potential commercial users will be moving from in choosing to use the Prop.
The Prop I does do ADC and DAC with external passive components (a resistor and one or two capacitors). These functions are not as good as can be done with external ADCs or DACs, but on-chip devices generally are not as good.
I know that some will be convinced by what a Propeller does offer to make those necessities and extras worthwhile but I suspect most won't. The idea that people will just put up with it, accept it as a minor inconvenience, isn't so true beyond this forum and those already using Props.
Very well said. From my earliest days, I've been a fan of wiring chips together. I enjoyed picking among the various commercial offerings for the particular building blocks I wanted. Sadly, I've not met an employer yet who likes that approach. They always push to have everything possible on one chip and then hire whoever they have to to make that chip work. It's about minimizing warehousing, tracking, production, packaging, and rework costs. It may also have to do with RFI and ESD concerns. Point is, that's how commercial manufacturers roll.
Very well said. From my earliest days, I've been a fan of wiring chips together. I enjoyed picking among the various commercial offerings for the particular building blocks I wanted. Sadly, I've not met an employer yet who likes that approach. They always push to have everything possible on one chip and then hire whoever they have to to make that chip work. It's about minimizing warehousing, tracking, production, packaging, and rework costs. It may also have to do with RFI and ESD concerns. Point is, that's how commercial manufacturers roll.
Actually, the "virtual peripheral" approach of the Propeller should help with minimizing warehousing since the Propeller can present different sets of virtual peripherals as required. The same MCU can be used for a project that needs four UARTs an another that needs 3 SPI ports. No need to warehouse different MCUs with different complements of features.
The Prop I does do ADC and DAC with external passive components (a resistor and one or two capacitors). These functions are not as good as can be done with external ADCs or DACs, but on-chip devices generally are not as good.
On-chip ADCs and DACs are adequate for most applications. I've used six 10-bit ADC channels on an ARM chip (two ADCs) without any problems to get data from a four-quadrant silicon detector, and a couple of temperature sensors, without any problems. I don't think that six ADC channels on a Propeller using sigma-delta is feasible, if several other functions are needed as well.
I don't think that six ADC channels on a Propeller using sigma-delta is feasible, if several other functions are needed as well.
If you have the pins available, it can be done with one counter, round-robin fashion. The S2 uses sigma-delta ADC on 16 channels, but with the help of a couple analog multiplexers. It's seldom necessary to acquire multiple ADC inputs simultaneously.
True. RossH, you hit the nail on head. I am a young engineer! I agree with what you said.
Propeller, in my opinion, is neat for quickie (such as putting together what's needed to be done quickly by wire-wrapping), and it's of course, cheaper.
The more complex the microcontroller can tackle the problem, it's true - but the more importantly... Parallelism will usually take care of the problems.
It's what Propeller was designed for. When I heard of it, I quickly attracted toward Propeller like a moth toward Neon sign.
And, SPIN is also neat for people who have not been programming things for so long times, as well as some newbies (who's determined to get their hands dirty).
Dr Mario: Spin is also useful for us oldies that prefer pasm but have a background in lots of languages. My higher level area is in VB3-6. I have done a little in C. My preference has always been in assembler, even on the mini-computers of old. This was because I could make it do things others could not do in higher level languages, or could not do at the speed. I bypassed the OS on the mini for a 30x gain in speed which was critical in a huge database scan. I have designed and programmed lots of commercial projects with micros (microcontroller chips) including some for Apple.
The Prop is by far the simplest of all the micros I have used, the quickest to get running, and requiring the least amount of programming to get the first program running.
For the record...I have used 6800/01/02/05/705P3S/705U3S/701, 6502, Z80, Z8 (Z8681), 68332 (IIRC), 6511. I have also coded 80486 in assembler specifically targetting the '486 fast instructions (for an ICL mini-computer emulation). I have often used multiple micros in my designs to minimise the interrupt issues, and FPGA's to minimise hardware interfacing to the mini-computer internal bus, etc. I have softcoded Uarts in the 68705 family (because there are none in this single chip micro) for modem controllers, etc.
I was just about to get into the PIC when I accidentally discovered the prop. My PIC gear is still in the box! I looked at Xmos and decided the asm instruction set was horrific. (IMHO Leon encourages people to look from here, and as I have said many times, it is just plain rude) BTW a thread <> core.
I understand that Parallax certainly doesn't want to make their IP publicly available, notably to prevent cheap clones, however having the Propeller be the first open-source ASIC would make a first in history, I'd say
The Propeller isn't really an ASIC (Application Specific Integrated Circuit). It's a microcontroller. It's not an ASIC until a specific program is loaded into it.
Anyway, Parallax is not likely to make their core IP publicly available. It will be making a lot of their other products available as Open Source though.
True. And, XMOS XS1 is only good for more serious computational jobs. True, ASM on XS1 is a bit difficult, but I will just hack away (and get away with it). I am still planning on using both Propeller II and XS1-G4 - all together. Leon said my hybrid supercomputer is just silly - I would disagree here because when you look at the HD video cards, you will notice there may be up to 11 different CPU cores on the same GPU die, assigned to different jobs (IT REALLY PROVES that the old saw, "Two brains are better than one" is actually true!) so I just decided to really take advantage of it.
Propeller is still neat, I gotta say- I got instantly hooked on it as it got eight CPU (COG) cores - on the cheap!
I have yet to purchase the XMOS XS1 chip (was really tempted in asking for a XS1 programming platform that the others won't need/want as it would really benefit in programming experience - I am planning in using two inter-system processor in my supercomputing project - but if anyone don't mind, just PM me.)
However, I am only serious with what I work on, not just blandishing around and yell "Propeller suck!" Propeller is a serious hardware, and I have desire in working with it, as well as picking its brains totally clean, in advantage of sharing some of my work with the others. I would do the same with XS1, however. I believe in Open Source Computing, so when Dendou Oni starts up for the first time, I would be giving out my detailed works for the benefits of the others- even sharing some computing power to whoever requested for it via Internet.
Somewhat new here to the propeller, so maybe these have been considered. One thing that might be useful is to consider in a new Propeller is the introduction of a bank of rams in each COG and a set of instructions to flip between these. This way the spin interperter can loaded once for each cog, into a bank, and also, byte code could be page loaded up into the local COG ram. The speed improvements with this simple change (Ok, its not so simple) would be huge I think. Each COG would have as a minimum, COG ram for PASM and sping and second COG ram for the spin interperter. The other thing that would be a great improvement would be a compiler that could compile 'some' of the spin code to PASM directly and also allow it to run 'inline' with spin byte code up directly in each COG. This would have to be done with the paged memory as first described to get real speed ups. With this type of memory design the time to switch between PASM and SPIN should be reduced to a few clock cycles, local to each COG. And, it would reduce or improve the access to main memory. If this banking is carried further, then longer PASM or multiple PASM/local spin code could be really increased in size. Also, local variables could be increased in number this way.
If the main memory were not being accessed, by a COG, the time slot should be made availble to a different COG. A techniqe of giving a seperate COG the time slot to main memory could go a long way to improving performance also. For example if the hub counter were set to loop around based on the number of COGS being used this would improve performance. For example if the program only needs 2 COGS, then the hub should just bounce between those two addresses and accesses should be limited to these, increasing availble access times by a factor of 4.
Hopefully the newer version will have some standard DSP features... Butterfly indexing, Hardware Multiplies, and a large number of bits for an accumulator and multiplier, (I'm thinking FIR filters, FFTs, etc. here)
Just a few ideas... maybe they have been considered. So far, this is a very interesting chip to mess around with.
With the propeller, the ability to scrap the use of LCDs and just drive a cheap old VGA or TV for debugging or a display is fantastic, and you only need a few resistors! Some sort of larger video memory would be great, so you could put up a life like picture!
Great chip Chip. Look forward to seeing what you are coming up with.
No, no, no. bank switching. We all hate bank switching, we've all done it many times before. Since the 8 bit days and with the Intel segmented architecture of the 286 and with the PICs etc. It's horrible.
I'll leave it to others to expand on why.
Butterfly indexing - Do yo mean that funky bit reversal thing that goes on with an FFT. The Prop already has a REV instruction that makes short work of that.
Hardware multiply - yes. it's coming I believe.
Larger number of bits - Yes I'd like a 48 bit Prop, see above linked post.
You are right, these ideas have been debated extensively this last year or so. Parallax is such a great company that they do listen to these things and I believe user input here will show up in the
Prop II.
If I have a processor that is 8 times faster than each of the 8 separate cores.
If I arrange for that processor to execute one instruction of each thread at a time, cycling around at a constant rate. i.e. inactive threads effectively have nops to execute.
If all instructions execute in the same number of clocks.
If all pin inputs are sampled at the beginning of a cycle and clocked out at the end of a cycle.
And so on...
Then there would be no way to tell if your program is executed by 8 cores or 8 threads on one core.
A few weeks back I tried to pitch the Prop to one of my professors. Afraid of the reaction that "Propeller" might get I referred to it as the P8X32A, or the P8 when we talked. My idea was to write a paper examining and comparing the P8 and the XMOS architectures from a parallel perspective. I'm taking a class with this professor called "Concurrent Programming and Parallel Systems". I thought it would be fun to learn and analyze the details of the various architectures, especially when so much of what we are taught in the classroom is interrupt based.
The professor didn't like it though. He thought that there would not be enough in depth documentation available for either chip, and that they were irrelevant anyway and would be obsolete very shortly. He even went so far as to say that I was wasting my time, and implied that my career would go downhill if I pursued the project. He then suggested that I learn about the Android, because that is the way of the future... I told him no and dropped the project.
@Heater
A thread executes concurrently, a core (processor) executes in parallel. Say this theoretical architecture had a hardware test and set instruction (useful for programming locks) then some set of threads could each execute the instruction leading to one thread having "priority" over another. In a parallel architecture it could be done differently, which leads to a way to tell which style the thread is being executed on.
Edit: I have been doing some AVR stuff recently since my embedded systems class uses an ATMega32 as the lab microcontroller. I started having problems as soon as I got going, one of which was missing a compiler flag. I started a thread over at AVR freaks (here) and had to laugh how much like these forums a thread can wander.
In any case, for my lab I have implemented the Propeller as a peripheral to the AVR: I use the prop to provide a debugging via a simple 8 bit parallel interface. I could hardly believe that the AVRs don't have a easy to use serial port for USB communication (at least not without linking in libraries and all that...). I'm also not really enjoying the interrupts thing. When I realized that I couldn't wait on the system clock to make a synchronous state machine I wanted to just ditch the whole thing. It seems inelegant to set a timer to interrupt on overflow, then have to count the number of interrupts and calculate based on the clock frequency the required period... Maybe it becomes more clear with experience.
As for cross platform, well, AVRs don't seem to have a built in Linux IDE (like BST). They use command line tools for code compiling and loading.
If I have a processor that is 8 times faster than each of the 8 separate cores.
If I arrange for that processor to execute one instruction of each thread at a time, cycling around at a constant rate. i.e. inactive threads effectively have nops to execute.
If all instructions execute in the same number of clocks.
If all pin inputs are sampled at the beginning of a cycle and clocked out at the end of a cycle.
And so on...
Then there would be no way to tell if your program is executed by 8 cores or 8 threads on one core.
Easy - try toggling 8 pins synchronized in time - one from each thread or cog. I'll bet it would be easy to tell which processor was using cogs and which was using threads.
Good grief your professor is way off base. What on earth has Android got to do with "Concurrent Programming and Parallel Systems". Well underneath it is Linux which can handle processes and threads and multi-core processors. I don't see the Android layer as being a sensible way to explore any of that. Better just use your PC.
A thread executes concurrently, a core (processor) executes in parallel.
Indeed. But my thesis is that a sufficiently fast processor can do the work of 8 slow ones in parallel and deliver the results at exactly the expected times. Therefore from outside the box you cannot tell the difference.
Say this theoretical architecture had a hardware test and set instruction (useful for programming locks) then some set of threads could each execute the instruction leading to one thread having "priority" over another. In a parallel architecture it could be done differently, which leads to a way to tell which style the thread is being executed on.
I don't believe this.
If one of my thread sees a lock set it cannot proceed, same as a parallel executing task, so it hangs there until the lock is clear. Don't forget in my mythical architecture all inputs are sampled at the beginning of a cycle that will perform the work of the 8 tasks and all results are clocked out at the end of that cycle. In this way any interaction with pins or timers or locks or whatever is the same as if there were 8 processors.
This must be true else it would be impossible to write a cycle accurate simulation of a Propeller on a single core PC.
RossH,
Easy - try toggling 8 pins synchronized in time - one from each thread or cog. I'll bet it would be easy to tell which processor was using cogs and which was using threads.
No, for the same reason as above.
Do we have a cycle accurate simulation of a Prop that runs on a single core PC?
If so I invite contributions of code that would allow one to tell if the code is running on a single Intel core or 8 real COGS. Speed differences aside of course. I maintain that if the real pins and simulated pins are not moving at the same points in the clock cycles, simulated or real, the simulation is not accurate enough.
No-one would design a chip that deliberately slowed down its ability to interact with the real world by a factor of 8 just to prove that a thread was the same as a cog.
On second thoughts, I take it back - this is precisely what the Cortex chip does - it artifcially slows down its own interrupt processing so that it can claim to have "deterministic interrupts". Moronic.
Only by a few clocks, which is negligible at 100 MHz. Anyway, you don't necessarily need deterministic interrupts, which can then then run at minimal latency.
Only by a few clocks, which is negligible at 100 MHz. Anyway, you don't necessarily need deterministic interrupts, which can then then run at minimal latency.
But "Deterministic Interrupts" is one of their big selling features! Now you're telling me it's uneccessary?
Actually, I agree with you - it is both unnecessary and moronic. Or perhaps it is just their customers who are moronic?
It is unnecessary in a lot of applications. People have been using ARM7s for yonks without that feature, without any problems.
What have you got against ARM, it's currently the most successful 32-bit architecture on the planet. An ARM will comfortably outperform a Propeller in most applications, at a fraction of the cost! It's also designed for running programs written in C very efficiently, the same cannot be said of the Propeller.
No-one would design a chip that deliberately slowed down its ability to interact with the real world by a factor of 8 just to prove that a thread was the same as a cog.
I might:)
Actually by clocking the I/O as I suggest one does not necessarily slow down the interaction with the real world. For example, if each thread was just toggling an output bit it could only do it at the 1/8th speed. All we are doing is making sure that when all threads are toggling a bit then all the edges are synchronized on the output as they would be for 8 slower processors.
Can someone describe what weird thing these Cortex chips do with interrupts, I don't get it yet.
The whole idea of "deterministic interrupts" seems odd to me. I mean, the whole idea of interrupts is that events are coming in from an external source at random unsynchronized times at which point all fine grain determinism in my system is lost. Is that LED I'm toggling in the background going to stay on a bit longer or off a bit longer?
It is unnecessary in a lot of applications. People have been using ARM7s for yonks without that feature, without any problems.
What have you got against ARM, it's currently the most successful 32-bit architecture on the planet. An ARM will comfortably outperform most Propeller applications, at a fraction of the cost!
And I would also happily use one - for any application that did not require deterministic behaviour.
Actually by clocking the I/O as I suggest one does not necessarily slow down the interaction with the real world. For example, if each thread was just toggling an output bit it could only do it at the 1/8th speed. All we are doing is making sure that when all threads are toggling a bit then all the edges are synchronized on the output as they would be for 8 slower processors.
So as I said - you have a fast processor, artificially slowed in it's ability to interact with the real world!
Can someone describe what weird thing these Cortex chips do with interrupts, I don't get it yet.
Since not all instructions take the same amount of time, they offer the ability to artificially stretch the interrupt handling time to match the longest possible instruction time - so it doesn't matter what instruction was being executed at the time of the interrupt. But since multiple interrups make the whole thing non-deterministic anyway, there seems very little point to it - which is why I suppose they make it "optional". I'll be that option is never enabled.
The whole idea of "deterministic interrupts" seems odd to me. I mean, the whole idea of interrupts is that events are coming in from an external source at random unsynchronized times at which point all fine grain determinism in my system is lost. Is that LED I'm toggling in the background going to stay on a bit longer or off a bit longer?
So what is this Cortex thing trying to achieve?
It's just marketing babble. It allows them to say "deterministic" in their tech specs. Which I gues just goes to show you that for some applications, determinsm is important - and if it is, you wouldn't use a Cortex processor.
Comments
I can virtually guarantee that when the Prop II arrives, there will be a short dip in Prop I sales as we all concentrate on the Prop II. However, the Prop II release will generate a huge amount of press interest and that will also mention (if done correctly, which I think it will be) the Prop I. I think that will be when the engineers will discover they have a baby and a big brother, so to speak. Then I think we shall see both chips taking off, because both have their place. The Prop II will therefore also fuel Prop I sales. Just MHO. And we all realise there is a place for Prop I too!
I feel the same way, I have used it to make small diagnostic tools for analyzing data
coming from various systems. It is really a perfect fit for many such tasks. In one instance
we put a small uc inside a device and had it analyze some internal data and transfer it to the
power on LED on the front of the device. The LED pulsed the data at a rate that was fast
enough that you could not tell it was winking on/off at all. This saved us having to alter the
case of the device by adding a data jack of some sort....it was important that the device remain
exactly as it was because it was water and dust proof. The prop along with a small lcd screen
was the perfect uc for the external data reader for this setup. Data flow was 2 way as the LED
also served as a mediocre but usable light sensor.
Graham
A very pertinent point in a thread on the commercial success and future of the Prop. Try selling that argument to someone who is comparing against a single chip offering with ADC on-chip which can do the same job when they need ADC.
It's a fair point for anyone considering a micro ( any micro ) to ask why they should choose a Prop which needs external ADC, external Eeprom, external Crystal, all the extra costs, extra board space, against a single chip which has all that on-board. Not to mention comes with a much narrower operating voltage range, and likely a higher price.
I know that some will be convinced by what a Propeller does offer to make those necessities and extras worthwhile but I suspect most won't. The idea that people will just put up with it, accept it as a minor inconvenience, isn't so true beyond this forum and those already using Props.
The Prop is a niche product ( those willing to accept what a Prop is ). If one wants more one goes to XMOS or high-end ARM, otherwise one goes to PICmicro, AVR or lower-end ARM etc. I'm therefore intrigued to know what all these potential commercial users will be moving from in choosing to use the Prop.
Very well said. From my earliest days, I've been a fan of wiring chips together. I enjoyed picking among the various commercial offerings for the particular building blocks I wanted. Sadly, I've not met an employer yet who likes that approach. They always push to have everything possible on one chip and then hire whoever they have to to make that chip work. It's about minimizing warehousing, tracking, production, packaging, and rework costs. It may also have to do with RFI and ESD concerns. Point is, that's how commercial manufacturers roll.
On-chip ADCs and DACs are adequate for most applications. I've used six 10-bit ADC channels on an ARM chip (two ADCs) without any problems to get data from a four-quadrant silicon detector, and a couple of temperature sensors, without any problems. I don't think that six ADC channels on a Propeller using sigma-delta is feasible, if several other functions are needed as well.
-Phil
Propeller, in my opinion, is neat for quickie (such as putting together what's needed to be done quickly by wire-wrapping), and it's of course, cheaper.
The more complex the microcontroller can tackle the problem, it's true - but the more importantly... Parallelism will usually take care of the problems.
It's what Propeller was designed for. When I heard of it, I quickly attracted toward Propeller like a moth toward Neon sign.
And, SPIN is also neat for people who have not been programming things for so long times, as well as some newbies (who's determined to get their hands dirty).
The Prop is by far the simplest of all the micros I have used, the quickest to get running, and requiring the least amount of programming to get the first program running.
For the record...I have used 6800/01/02/05/705P3S/705U3S/701, 6502, Z80, Z8 (Z8681), 68332 (IIRC), 6511. I have also coded 80486 in assembler specifically targetting the '486 fast instructions (for an ICL mini-computer emulation). I have often used multiple micros in my designs to minimise the interrupt issues, and FPGA's to minimise hardware interfacing to the mini-computer internal bus, etc. I have softcoded Uarts in the 68705 family (because there are none in this single chip micro) for modem controllers, etc.
I was just about to get into the PIC when I accidentally discovered the prop. My PIC gear is still in the box! I looked at Xmos and decided the asm instruction set was horrific. (IMHO Leon encourages people to look from here, and as I have said many times, it is just plain rude) BTW a thread <> core.
I understand that Parallax certainly doesn't want to make their IP publicly available, notably to prevent cheap clones, however having the Propeller be the first open-source ASIC would make a first in history, I'd say
Anyway, Parallax is not likely to make their core IP publicly available. It will be making a lot of their other products available as Open Source though.
Propeller is still neat, I gotta say- I got instantly hooked on it as it got eight CPU (COG) cores - on the cheap!
I have yet to purchase the XMOS XS1 chip (was really tempted in asking for a XS1 programming platform that the others won't need/want as it would really benefit in programming experience - I am planning in using two inter-system processor in my supercomputing project - but if anyone don't mind, just PM me.)
However, I am only serious with what I work on, not just blandishing around and yell "Propeller suck!" Propeller is a serious hardware, and I have desire in working with it, as well as picking its brains totally clean, in advantage of sharing some of my work with the others. I would do the same with XS1, however. I believe in Open Source Computing, so when Dendou Oni starts up for the first time, I would be giving out my detailed works for the benefits of the others- even sharing some computing power to whoever requested for it via Internet.
Somewhat new here to the propeller, so maybe these have been considered. One thing that might be useful is to consider in a new Propeller is the introduction of a bank of rams in each COG and a set of instructions to flip between these. This way the spin interperter can loaded once for each cog, into a bank, and also, byte code could be page loaded up into the local COG ram. The speed improvements with this simple change (Ok, its not so simple) would be huge I think. Each COG would have as a minimum, COG ram for PASM and sping and second COG ram for the spin interperter. The other thing that would be a great improvement would be a compiler that could compile 'some' of the spin code to PASM directly and also allow it to run 'inline' with spin byte code up directly in each COG. This would have to be done with the paged memory as first described to get real speed ups. With this type of memory design the time to switch between PASM and SPIN should be reduced to a few clock cycles, local to each COG. And, it would reduce or improve the access to main memory. If this banking is carried further, then longer PASM or multiple PASM/local spin code could be really increased in size. Also, local variables could be increased in number this way.
If the main memory were not being accessed, by a COG, the time slot should be made availble to a different COG. A techniqe of giving a seperate COG the time slot to main memory could go a long way to improving performance also. For example if the hub counter were set to loop around based on the number of COGS being used this would improve performance. For example if the program only needs 2 COGS, then the hub should just bounce between those two addresses and accesses should be limited to these, increasing availble access times by a factor of 4.
Hopefully the newer version will have some standard DSP features... Butterfly indexing, Hardware Multiplies, and a large number of bits for an accumulator and multiplier, (I'm thinking FIR filters, FFTs, etc. here)
Just a few ideas... maybe they have been considered. So far, this is a very interesting chip to mess around with.
With the propeller, the ability to scrap the use of LCDs and just drive a cheap old VGA or TV for debugging or a display is fantastic, and you only need a few resistors! Some sort of larger video memory would be great, so you could put up a life like picture!
Great chip Chip. Look forward to seeing what you are coming up with.
Regards, Walt
No, no, no. bank switching. We all hate bank switching, we've all done it many times before. Since the 8 bit days and with the Intel segmented architecture of the 286 and with the PICs etc. It's horrible.
I'll leave it to others to expand on why.
No, no, no, tweaking of the HUB allocation slots depending on what's running. It ruins timing determinism. See my arguments against it here:
http://forums.parallax.com/showthread.php?129490-Propeller-chip-what-if&p=976003&viewfull=1#post976003
DSP features - Yes.
Butterfly indexing - Do yo mean that funky bit reversal thing that goes on with an FFT. The Prop already has a REV instruction that makes short work of that.
Hardware multiply - yes. it's coming I believe.
Larger number of bits - Yes I'd like a 48 bit Prop, see above linked post.
You are right, these ideas have been debated extensively this last year or so. Parallax is such a great company that they do listen to these things and I believe user input here will show up in the
Prop II.
Why do you say so?
If I have a processor that is 8 times faster than each of the 8 separate cores.
If I arrange for that processor to execute one instruction of each thread at a time, cycling around at a constant rate. i.e. inactive threads effectively have nops to execute.
If all instructions execute in the same number of clocks.
If all pin inputs are sampled at the beginning of a cycle and clocked out at the end of a cycle.
And so on...
Then there would be no way to tell if your program is executed by 8 cores or 8 threads on one core.
The professor didn't like it though. He thought that there would not be enough in depth documentation available for either chip, and that they were irrelevant anyway and would be obsolete very shortly. He even went so far as to say that I was wasting my time, and implied that my career would go downhill if I pursued the project. He then suggested that I learn about the Android, because that is the way of the future... I told him no and dropped the project.
@Heater
A thread executes concurrently, a core (processor) executes in parallel. Say this theoretical architecture had a hardware test and set instruction (useful for programming locks) then some set of threads could each execute the instruction leading to one thread having "priority" over another. In a parallel architecture it could be done differently, which leads to a way to tell which style the thread is being executed on.
Edit: I have been doing some AVR stuff recently since my embedded systems class uses an ATMega32 as the lab microcontroller. I started having problems as soon as I got going, one of which was missing a compiler flag. I started a thread over at AVR freaks (here) and had to laugh how much like these forums a thread can wander.
In any case, for my lab I have implemented the Propeller as a peripheral to the AVR: I use the prop to provide a debugging via a simple 8 bit parallel interface. I could hardly believe that the AVRs don't have a easy to use serial port for USB communication (at least not without linking in libraries and all that...). I'm also not really enjoying the interrupts thing. When I realized that I couldn't wait on the system clock to make a synchronous state machine I wanted to just ditch the whole thing. It seems inelegant to set a timer to interrupt on overflow, then have to count the number of interrupts and calculate based on the clock frequency the required period... Maybe it becomes more clear with experience.
As for cross platform, well, AVRs don't seem to have a built in Linux IDE (like BST). They use command line tools for code compiling and loading.
Easy - try toggling 8 pins synchronized in time - one from each thread or cog. I'll bet it would be easy to tell which processor was using cogs and which was using threads.
Ross.
Yes they do - Code::Blocks is a cross platform IDE which supports every C compiler known to man (including AVR).
Ross.
Good grief your professor is way off base. What on earth has Android got to do with "Concurrent Programming and Parallel Systems". Well underneath it is Linux which can handle processes and threads and multi-core processors. I don't see the Android layer as being a sensible way to explore any of that. Better just use your PC.
Indeed. But my thesis is that a sufficiently fast processor can do the work of 8 slow ones in parallel and deliver the results at exactly the expected times. Therefore from outside the box you cannot tell the difference.
I don't believe this.
If one of my thread sees a lock set it cannot proceed, same as a parallel executing task, so it hangs there until the lock is clear. Don't forget in my mythical architecture all inputs are sampled at the beginning of a cycle that will perform the work of the 8 tasks and all results are clocked out at the end of that cycle. In this way any interaction with pins or timers or locks or whatever is the same as if there were 8 processors.
This must be true else it would be impossible to write a cycle accurate simulation of a Propeller on a single core PC.
RossH,
No, for the same reason as above.
Do we have a cycle accurate simulation of a Prop that runs on a single core PC?
If so I invite contributions of code that would allow one to tell if the code is running on a single Intel core or 8 real COGS. Speed differences aside of course. I maintain that if the real pins and simulated pins are not moving at the same points in the clock cycles, simulated or real, the simulation is not accurate enough.
No-one would design a chip that deliberately slowed down its ability to interact with the real world by a factor of 8 just to prove that a thread was the same as a cog.
On second thoughts, I take it back - this is precisely what the Cortex chip does - it artifcially slows down its own interrupt processing so that it can claim to have "deterministic interrupts". Moronic.
Ross.
But "Deterministic Interrupts" is one of their big selling features! Now you're telling me it's uneccessary?
Actually, I agree with you - it is both unnecessary and moronic. Or perhaps it is just their customers who are moronic?
Ross.
What have you got against ARM, it's currently the most successful 32-bit architecture on the planet. An ARM will comfortably outperform a Propeller in most applications, at a fraction of the cost! It's also designed for running programs written in C very efficiently, the same cannot be said of the Propeller.
I might:)
Actually by clocking the I/O as I suggest one does not necessarily slow down the interaction with the real world. For example, if each thread was just toggling an output bit it could only do it at the 1/8th speed. All we are doing is making sure that when all threads are toggling a bit then all the edges are synchronized on the output as they would be for 8 slower processors.
Can someone describe what weird thing these Cortex chips do with interrupts, I don't get it yet.
The whole idea of "deterministic interrupts" seems odd to me. I mean, the whole idea of interrupts is that events are coming in from an external source at random unsynchronized times at which point all fine grain determinism in my system is lost. Is that LED I'm toggling in the background going to stay on a bit longer or off a bit longer?
So what is this Cortex thing trying to achieve?
And I would also happily use one - for any application that did not require deterministic behaviour.
Ross.
It's deterministic interrupt latency that can be useful, and is an option on the Cortex devices, but very few applications actually need it.
It's just marketing babble. It allows them to say "deterministic" in their tech specs. Which I gues just goes to show you that for some applications, determinsm is important - and if it is, you wouldn't use a Cortex processor.
Ross.