crgwbr said...
I might of read it incorectly; but, did some one same 160 MIPS per Cog and 16 Cogs. If thats true, that would equal a total 2.56 GHz of proccessing power. Thats about double the speed my computer runs at. Add a hard drive and some more ram and you've got yourself a pretty decent desktop computer.
But remember that the PCs have hardware dedicated for example card of video.
crgwbr said...
I might of read it incorectly; but, did some one same 160 MIPS per Cog and 16 Cogs. If thats true, that would equal a total 2.56 GHz of proccessing power. Thats about double the speed my computer runs at. Add a hard drive and some more ram and you've got yourself a pretty decent desktop computer.
But remember that the PCs have hardware dedicated for example card of video.
Hi all, !!! INTERRUPTS !!!! (I said that to get your attention) A few people have posted here suggesting interrupts be added to the next Propeller chip.· I know it may be hard to grasp, but interrupts have been around for a long time only because true multiprocessing has not been.· Interrupts were the only viable solution to employ to certain applications when you only have one processor. The Propeller design·intentionally leaves that methodology behind to provide a much more capable solution; dedicate a cog to each asynchronous event.· Though it may seem very wasteful·it really isn't, because of the way it is implemented. When a cog waits for an event (with one of the WAITxxx commands) it is not executing any other code.· In fact, it is in a low-power mode for that period where its special "wait" hardware is preventing most of the cog's internals from being affected by the system clock.· This equates to very low power consumption. When a cog detects the desired event ("wakes up" from the WAITxxx command), it is immediately able to respond to the event (no context switches are necessary).· This makes applications built with the Propeller much more responsive to asynchronous events (especially multiple, close proximity, asynchronous events) than interrupt-driven single-core devices. And, by far, it makes developing that application much less time consuming.· And, one step further, it makes enhancing that application at a later time much less time consuming because of the likelihood of adding features without needing to worry about domino effects on other tasks. I know it's hard to get used to this idea because it "seems" wasteful (I've caught myself thinking that way too) but that's because we're not used to it yet... the Propeller enables us to think outside the box that previous devices forced us to crawl into. · · Consider the following: · Single-processor devices are like a company with only one worker.· That worker designs new products, builds existing products, ships products, collects money, pays the bills and tries to answer all the phone calls each day. · The Propeller is more like a company with a unique worker·for each of those tasks (allowing things to get done faster and with a quicker response) and, the best part, it encourages each unique worker to sleep every time their task is done, while they are waiting for another.· If money were energy, the Propeller wouldn't be spending much more than his single-worker predecessors (and may even spend less), but would be completing· many more of its duties·faster and with less effort.
Sure, but all that single tasked silicon that is sleeping (which at 160 MIPS I expect to be well over 90% of the time, and that IS wasteful) could be doing a ton of useful work. I fully understand the different approach by supplying independent cogs to mimic what interrupts traditionally do. But with interrupts, multiple tasks in each cog could be time shared deterministically. And if there were interrupts, it does not imply that they MUST be used...... only for those applications where 8 (or later possibly 16) single threaded cogs is not enough. I expect it will be a bear to try to mimic interrupt functionality with a device that has none.
Don't get me wrong, I love the Propeller, and am currently designing it into an industrial Product..... I just wish it also had an interrupt per cog; now that would make my software life a ton simpler.............I thought it would not be too hard to do.
Sorry for the newbie qestion. I just got my Demo Board in today. YIPPIE!
What can a cog WAIT for?
Can you wait for any change in a group of input pins? Say for monitoring 4 different serial ports simultaneiously?
If so, wouldn't that be the equivilent to an interupt except that an interupt routine cannot be interruped.
Mimicing true interrupts can be a bear, however doing multitasking (which to my knowledge is the primary reason you use interrupts) is very possible with the current architecture. Im sure you are aware of FullDuplexSerial's use of JMPRET. It's not multi-tasking implemented in the way you are use to, but it does provide it for those times you feel like you missing potential MIPS.
hinv said...
Sorry for the newbie qestion. I just got my Demo Board in today. YIPPIE!
What can a cog WAIT for?
Can you wait for any change in a group of input pins? Say for monitoring 4 different serial ports simultaneiously?
If so, wouldn't that be the equivilent to an interupt except that an interupt routine cannot be interruped.
Thanks,
Doug
A cog can wait for a specific time (WAITCNT) or a pin state (WAITPE) or a pin non-state (WAITPNE). So to detect a change on 1 of 4 pins,·you'd use the·WAITPNE command, but doing a·multithreaded solution as shown in FullDuplexSerial is the better way to approach the problem.
No the·WAITxx commands aren't·equivalent to·interrupts (although they can be used to produce interrupt-like behavior)·because nothing is iterrupted, hence it cant be called an interrupt.
I'm glad someone mentioned WAITPNE.· I'd planned on using it to creat an object to read servo-pulses from an RC reciever.· i'd use it to wait for incomming pulses on a range of pins and store CNT every time a pin changed.· This should allow high accuracy timing of up to 32 incoming servo-pulses while making NO assumptions about the timing pulse to pulse.· (aka the pulses can come at random times and in random orders)·
pjv & hinv,
Interrupts are really the wrong sort of thing. They're intended to literally interrupt some other piece of code to do something considered a higher priority and resume the lower priority "thread" when the interrupt routine is done. This sort of works when the interrupt function really is minimal and there's no significant state that has to be carried over from one interrupt to another (and the low priority code doesn't depend on deterministic timing). I think what you're looking for most of the time is interleaved multiple threads per cog. This can be done (and is already done) with the current hardware. Some of the video drivers do this to handle complex initialization during multiple vertical retrace intervals. The FullDuplexSerial driver does this to interleave receive and transmit actions. The technique is not really documented for the Propeller and there are no nice, simple examples.
hinv,
You can wait for a group of pins to change from a known state with the WAITPNE instruction or change to a known state with WAITPEQ. You'd need to go through the individual pins to see exactly what's changed and there is the potential for a race condition because you'd have to read the input
register again (because the WAITxxx instruction doesn't tell you what specific bits changed, just that they're different). Practically, that's not an issue. The main difficulty is that you cannot wait for either a pin(s) to change or a time to elapse, whichever happens first, so you end up polling periodically. This still leaves the cog in low power most of the time, but it's not clean. This sort of thing would be used for serial I/O on multiple channels since you'd be looking for asynchronous changes like a new start bit, but you'd also be receiving or transmitting based on a specific time coming (for the next bit time). If you had a spare I/O pin, you could use the built-in counter in a cog to provide a timeout by changing an extra I/O pin which would be part of the group you're waiting for (with WAITPNE).
Given that the FullDuplexSerial object can easily handle 115KB, you should be able to have 4 serial I/O channels at 19.2KB minimum.
And that piece of code being interrupted is the current running task, and the interrupting code is the highest priority and deterministic RTOS that decides what should happen next.
Real tough to keep it deterministic and precisely timed without an interrupt....... that is unless you have only one thread.
The nice thing about the WAITCNT instruction and hub-based system clock is that you can resynchronize any and all cogs to absolute (or relative) times and, without interrupts, can determine timing from those resynchronization points. It's easy with the JMPRET instruction to construct cooperatively time sliced multiple threads. Each thread has to give up control within the slice time (or provisions must be made for threads that "slip" their slice time).
I'm really not trying to be stubborn, but...... WAITCNT is exactly that, it waits while doing no work. So how should a piece of running code know what to set its wait counter to so that another piece of code can run at a time suitable for that ? It's just not practical. Individual threads should be as independent as possible.
Now I know that I'm probably seen as someone who is unwilling to use the Propeller the way it was intended. I'm not. I just wish it had interrupts to make my life easier.
Anyhow, I think I will, or perhaps already have outlived my welcome on this topic if I don't duck below the radar and keep quit on this issue.
Relax. I'm just trying to point out that the Propeller is more flexible without interrupts than you might think. Years ago, I wrote an operating system for a Z-80 based business computer where the OS kernel provided an interrupt-less environment with semaphores and task forking and the ability to wait for an I/O condition (but with a timeout possible). The kernel was small, efficient, and easy to debug. The rest of the OS was very clean, very few bugs, and plenty fast enough for the environment (a word processing and data processing system). Most of the system (other than the kernel) was written in an extended Pascal.
- a complete datasheet for the propeller that includes electrical characteristics,
temperature ranges, power consumption and detailed description of all internal blocks
- More cog RAM
- flash instead of ROM
- interrupts
- integrated analog comparators that can be used for better analog to digital
conversion and a lot of other things
- USB PHY (USB state machine could be done in software)
- 32.768kHz subclock (watch xtal)
- sleep mode with really low power consumption and flexible wakeup options
- did I mention the datasheet?
There are no doubts about Propeller capability, even without interrupts. I'm just starting with it and I'm amazed·about how·well thought everything is. I feel like a·child in·a toy shop with eight fast cogs, integrated video hardware,·powerful counters, so many pins, flexible clock, friendly but revolutionary asm (conditional execution is impressive), nice programming ide, increasing object library. I'm having app ideas almost every day for this little monster. Lot of fun really.
I·also know this is not·open core. Parallax is gently enough as to open a debate about future versions extensions, I'm not aware about other chip makers doing that! And I also know we are way off topic, the debate was about a specific question...not·to post a·wishlist.
Said that, I feel I must apologize about interrupts because they are immensely successful way to do things and...squeeze mips.·It may happen we (at least me) have not fully grasp the current multitask prevision (JMPRET). Even so, I don't really think it can replace interrupts. You always have to wait for something...some events just cant wait·for other routines to finish and give the control. Sure, you can launch a new cog, with 64/128 cogs that wouldn't be a problem but then we have only eight, that barrier soon jumps just in front·your nose by not having a easy way to multiplex. I don't mean a complex interrupt system, just a new counter mode (to reuse the existent harware) and an·interrupt handler address register.·If a counter or pin event happens, execute·a jmpret·with PC+1 and·the·handler register values, leave saving both flags to the programmer. The hardware is almost there, the juice too, just allow us to extract it. It can't hurt anyone
The problem with Interrupts is that you can only reliably service ONE at a time.
Sure, the processor/architecture may have more interrupts defined, but many of them shouldn't be interrupted, or data-loss may occur. (Serial comms is one)
For that reason, some processors had one NMI(Non-Maskable Interrupt), which was reserved for the REALLY time-critical stuff, and allowed the rest to be 'masked away' by setting a flag(usually in the CPU itself).
What happened when that flag was cleared?
Some, at least, kept track of whether or not an IRQ(Interrupt ReQuest) had arrived, and executed it as soon as the flag was cleared, but...
What if several IRQs had arrived?
Which ones are still valid?
That flag was usually set by the arrival of the NMI, but could also be set with an assembly instruction, so that the running program wouldn't be interrupted while doing something time-critical.
Unfortunately, what is or isn't time-critical is up to the programmer...
(I've done Interrupt programming on Z80 and i8051, and frankly, I don't miss it)
Is it annoying to know that whole COGs which could potentially execute code at 20 or 160MIPS is 'wasted' while it waits for an event?
Yes, but with 8 32bits COGs for $12.95(the current one-off price), and the potential of 16 GOGs in the next version, I think I can live with it.
Besides, it's not as if most apps NEED the speed...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 1/12/2007 1:50:00 PM GMT
You're view that ·"supplying independent cogs to mimic what interrupts traditionally do", while historically accurate is really backwards.
INTERRUPTS on other MCU's·are used to mimic what independent cogs "do".· Think of the prop this way. 1 MCU with 7 dedicated, deterministic interrupt routines. Or the future prop, 1 160mips MCU with 15 interrupt routines.
I understand the view that using a cog for one task "IS wasteful", but think of it this way. Unless you app REQUIRES more that the current 8 cogs, with one task per cog,·using a PROP WILL·be wasteful.· The idea of the Prop is to make designs and their software simpler, alot simpler by removing dedicated devices (and the subsequent boat load of MCU SKU's) and removing the 'hack' of using interrupts to simulate multitasking.
After all of the trouble I had understanding so many different interupt mechanisms, (I don't even know if there is two families of processors that have the same mechanism) I look forward to programming without them.
I really look forward to having a 64IO Prop2. What I would really like would be a standard meathod supported in spin to pass messages between objects on different Propellers. If that was fast and easy, I would rather have 8Cog/256KB, because each one would have faster memory access, and I could just add more props if I needed more cogs. Now that would be really cool! Interrupts are not needed at al then. Of course, there would be a cost to run an object on another prop, but there is a cost in memory access for having more than 8 cogs.
When I looked at Paul's memory expansion(http://forums.parallax.com/forums/attach.aspx?a=10636), it seemed like a good idea. But, take this with a grain of salt since I just got my Demo Board yesterday, and haven't had time to play with it.
Pros:
This would eliminate separate 3.3V VDD_IO pins.
No need for a separate 3.3V supply.
Pins would transition much faster for LVDS possibilities.
It would simplify the device architecture.
At 1.8V, video/VGA generation would still work fine, so would direct interfacing to elemental sensors.
Cons:
1.8V would be inadequate for driving LEDs.
Transistors would have to be used to generate 3.3v+ outputs.]
Is it possible, since we are getting another 32 pins of IO to leave the upper 16 pins at 1.8V for faster interprop communication, VGA, memory interfacing, etc?
I would agree that we we need at least 32 pins of 3.3v IO, but 16 or 32pins of 1.8V IO would be great!
Remember that we will continue using 5v, for other devices (including LEDs with resistances). If is used 1.8 more 3.3, then in practice will be 1.8, 3.3 and 5v (three regulators).
The question was whether we'd give up ALL 3.3V on the chip and run the whole thing on 1.8V. If you have any part of the chip running at 3.3V, there's no particular advantage to running only part of the I/O drivers from 3.3V. His question was mostly about eliminating the pin connections for a 3.3V supply
What would be the implications of running at 1.8v and working with 5v TTL or CMOS logic? 1.8v is getting quite near TTL thresholds, below CMOS at 5v. Driving TTL/CMOS sounds more troublesome than receiving from them.
Are there translator ICs for 1.8v to 5v and back? It seems some applications running a PROP at 1.8v will not be easily workable! Am I wrong?
I was hoping this 2nd generation Prop would handle a design (which would need 3 gen 1 Props for I/O and cogs) but looks more and more like it cannot. SIGH!
Please a spin language with enhancement as
- callback
- preprocessor
- macro
- variable of 'bit' type
- classical hardware and software interrupts support can sometime permit to saving cog's usage.
- a globally nicely syntax and more C like language .
If your spin language is few attractive for the BASIC STAMP users, it is repulsive and 'not professional' for the C users .
Globally, the Propeller is wonderful and a great enhancement.
I'm just buy Propeller for testing and it's a very interesting environment. As Parallax can do it's very simple to start. But it's not a good way for 'commercial' uses because the
wastage of resources.
I just read the discussion about the interrupts. As for a religion, it's possible to give interrupt to people witch like it and the other don’t need to use it !
- More cogs means increased access time to main RAM, so if you application ends up not using more than 8 cogs, you're reducing performance for no gain at all. Unless there could be a mechanism in the hub that would connect ONLY the active cogs to main memory, but that would kill timing determinism and I'd rather keep it.
- On the other hand, I can think of a few applications that would require a lot of cogs and wouldn't be penalized too much by increased main RAM latencies
- A chip with more main RAM would be nice but to really take advantage of the additional RAM it would also be important to decrease access time. It's like a 4GB thumbdrive with USB 1.1 : nobody would buy that, it'd be too slow compared to the capacity.
You mention that each cog would run at 160 MIPS. I sure makes my mouth water : can you tell us more ? I assume the chip would have to run at 160 MHz with single-cycle execution of most instructions. What will that mean for the hub timing ?
With the 16 cog / 128k design, each cog will get access to hub memory every 16 cycles... 10M times per second.
The current propeller gets access 5M times per second.
Therefore, in the 16 cog version each cog would get TWICE the memory bandwidth the current cogs get!
In my opinion, that speeds things up [noparse]:)[/noparse]
Also, the cogs would be executing 160M instructions per second, up from the current 20M - an 8x improvement per cog
Personally, I was initially for the 16cog/128k design... then I changed my mind, and preferred the 8cog/256k design... however now I am back in the 16cog/128k design camp [noparse]:)[/noparse] for two reasons:
- twice the processing power of the competing design (8cog/256k)
- with the 64 bits of I/O, it is easy enough to hook up some external memory - as much as we like.
Nefastor said...
I'd say we can use both solutions :
- More cogs means increased access time to main RAM, so if you application ends up not using more than 8 cogs, you're reducing performance for no gain at all. Unless there could be a mechanism in the hub that would connect ONLY the active cogs to main memory, but that would kill timing determinism and I'd rather keep it.
- On the other hand, I can think of a few applications that would require a lot of cogs and wouldn't be penalized too much by increased main RAM latencies
- A chip with more main RAM would be nice but to really take advantage of the additional RAM it would also be important to decrease access time. It's like a 4GB thumbdrive with USB 1.1 : nobody would buy that, it'd be too slow compared to the capacity.
You mention that each cog would run at 160 MIPS. I sure makes my mouth water : can you tell us more ? I assume the chip would have to run at 160 MHz with single-cycle execution of most instructions. What will that mean for the hub timing ?
Jean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
I hope I wouldn't sound too pleading if I mentioned (I believe Bill Henning's) request for some really fast hardware for comms. I believe he mentioned SPI.
Autoincrementing pointer registers seem to be a frequent request.
That would make everything from Ethernet to bulk memory easier.
And I'd very much like to hear from Chip if he believes he will be able to move the interior tracks in such a way as to make the ADC work with adjacent pins but the same or less noise.
Comments
Sure, there are ways around it, but they'll all slow it down significantly.
Also, MIPS doesn't need to equal clock-speed.
Anyway, it'll be interesting to see what happens when it ships to some of the more 'insane' members of this forum...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Post Edited (CJ) : 1/11/2007 6:40:08 PM GMT
But remember that the PCs have hardware dedicated for example card of video.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NerdMaster
For
Life
!!! INTERRUPTS !!!!
(I said that to get your attention)
A few people have posted here suggesting interrupts be added to the next Propeller chip.· I know it may be hard to grasp, but interrupts have been around for a long time only because true multiprocessing has not been.· Interrupts were the only viable solution to employ to certain applications when you only have one processor.
The Propeller design·intentionally leaves that methodology behind to provide a much more capable solution; dedicate a cog to each asynchronous event.· Though it may seem very wasteful·it really isn't, because of the way it is implemented.
When a cog waits for an event (with one of the WAITxxx commands) it is not executing any other code.· In fact, it is in a low-power mode for that period where its special "wait" hardware is preventing most of the cog's internals from being affected by the system clock.· This equates to very low power consumption.
When a cog detects the desired event ("wakes up" from the WAITxxx command), it is immediately able to respond to the event (no context switches are necessary).· This makes applications built with the Propeller much more responsive to asynchronous events (especially multiple, close proximity, asynchronous events) than interrupt-driven single-core devices.
And, by far, it makes developing that application much less time consuming.· And, one step further, it makes enhancing that application at a later time much less time consuming because of the likelihood of adding features without needing to worry about domino effects on other tasks.
I know it's hard to get used to this idea because it "seems" wasteful (I've caught myself thinking that way too) but that's because we're not used to it yet... the Propeller enables us to think outside the box that previous devices forced us to crawl into.
·
·
Consider the following:
·
Single-processor devices are like a company with only one worker.· That worker designs new products, builds existing products, ships products, collects money, pays the bills and tries to answer all the phone calls each day.
·
The Propeller is more like a company with a unique worker·for each of those tasks (allowing things to get done faster and with a quicker response) and, the best part, it encourages each unique worker to sleep every time their task is done, while they are waiting for another.· If money were energy, the Propeller wouldn't be spending much more than his single-worker predecessors (and may even spend less), but would be completing· many more of its duties·faster and with less effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.
Sure, but all that single tasked silicon that is sleeping (which at 160 MIPS I expect to be well over 90% of the time, and that IS wasteful) could be doing a ton of useful work. I fully understand the different approach by supplying independent cogs to mimic what interrupts traditionally do. But with interrupts, multiple tasks in each cog could be time shared deterministically. And if there were interrupts, it does not imply that they MUST be used...... only for those applications where 8 (or later possibly 16) single threaded cogs is not enough. I expect it will be a bear to try to mimic interrupt functionality with a device that has none.
Don't get me wrong, I love the Propeller, and am currently designing it into an industrial Product..... I just wish it also had an interrupt per cog; now that would make my software life a ton simpler.............I thought it would not be too hard to do.
Thanks for letting me whine !
Cheers,
Peter (pjv)
What can a cog WAIT for?
Can you wait for any change in a group of input pins? Say for monitoring 4 different serial ports simultaneiously?
If so, wouldn't that be the equivilent to an interupt except that an interupt routine cannot be interruped.
Thanks,
Doug
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lets see what this does... KA BOOM (note to self do not cross red and black)
No the·WAITxx commands aren't·equivalent to·interrupts (although they can be used to produce interrupt-like behavior)·because nothing is iterrupted, hence it cant be called an interrupt.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Esentially I'd be emulating an "interrupt"
My two cents
marty
Interrupts are really the wrong sort of thing. They're intended to literally interrupt some other piece of code to do something considered a higher priority and resume the lower priority "thread" when the interrupt routine is done. This sort of works when the interrupt function really is minimal and there's no significant state that has to be carried over from one interrupt to another (and the low priority code doesn't depend on deterministic timing). I think what you're looking for most of the time is interleaved multiple threads per cog. This can be done (and is already done) with the current hardware. Some of the video drivers do this to handle complex initialization during multiple vertical retrace intervals. The FullDuplexSerial driver does this to interleave receive and transmit actions. The technique is not really documented for the Propeller and there are no nice, simple examples.
hinv,
You can wait for a group of pins to change from a known state with the WAITPNE instruction or change to a known state with WAITPEQ. You'd need to go through the individual pins to see exactly what's changed and there is the potential for a race condition because you'd have to read the input
register again (because the WAITxxx instruction doesn't tell you what specific bits changed, just that they're different). Practically, that's not an issue. The main difficulty is that you cannot wait for either a pin(s) to change or a time to elapse, whichever happens first, so you end up polling periodically. This still leaves the cog in low power most of the time, but it's not clean. This sort of thing would be used for serial I/O on multiple channels since you'd be looking for asynchronous changes like a new start bit, but you'd also be receiving or transmitting based on a specific time coming (for the next bit time). If you had a spare I/O pin, you could use the built-in counter in a cog to provide a timeout by changing an extra I/O pin which would be part of the group you're waiting for (with WAITPNE).
Given that the FullDuplexSerial object can easily handle 115KB, you should be able to have 4 serial I/O channels at 19.2KB minimum.
Right.
And that piece of code being interrupted is the current running task, and the interrupting code is the highest priority and deterministic RTOS that decides what should happen next.
Real tough to keep it deterministic and precisely timed without an interrupt....... that is unless you have only one thread.
Cheers,
Peter (pjv)
I'm really not trying to be stubborn, but...... WAITCNT is exactly that, it waits while doing no work. So how should a piece of running code know what to set its wait counter to so that another piece of code can run at a time suitable for that ? It's just not practical. Individual threads should be as independent as possible.
Now I know that I'm probably seen as someone who is unwilling to use the Propeller the way it was intended. I'm not. I just wish it had interrupts to make my life easier.
Anyhow, I think I will, or perhaps already have outlived my welcome on this topic if I don't duck below the radar and keep quit on this issue.
Cheers,
Peter (pjv)
- a complete datasheet for the propeller that includes electrical characteristics,
temperature ranges, power consumption and detailed description of all internal blocks
- More cog RAM
- flash instead of ROM
- interrupts
- integrated analog comparators that can be used for better analog to digital
conversion and a lot of other things
- USB PHY (USB state machine could be done in software)
- 32.768kHz subclock (watch xtal)
- sleep mode with really low power consumption and flexible wakeup options
- did I mention the datasheet?
There are no doubts about Propeller capability, even without interrupts. I'm just starting with it and I'm amazed·about how·well thought everything is. I feel like a·child in·a toy shop with eight fast cogs, integrated video hardware,·powerful counters, so many pins, flexible clock, friendly but revolutionary asm (conditional execution is impressive), nice programming ide, increasing object library. I'm having app ideas almost every day for this little monster. Lot of fun really.
I·also know this is not·open core. Parallax is gently enough as to open a debate about future versions extensions, I'm not aware about other chip makers doing that! And I also know we are way off topic, the debate was about a specific question...not·to post a·wishlist.
Said that, I feel I must apologize about interrupts because they are immensely successful way to do things and...squeeze mips.·It may happen we (at least me) have not fully grasp the current multitask prevision (JMPRET). Even so, I don't really think it can replace interrupts. You always have to wait for something...some events just cant wait·for other routines to finish and give the control. Sure, you can launch a new cog, with 64/128 cogs that wouldn't be a problem but then we have only eight, that barrier soon jumps just in front·your nose by not having a easy way to multiplex. I don't mean a complex interrupt system, just a new counter mode (to reuse the existent harware) and an·interrupt handler address register.·If a counter or pin event happens, execute·a jmpret·with PC+1 and·the·handler register values, leave saving both flags to the programmer. The hardware is almost there, the juice too, just allow us to extract it. It can't hurt anyone
Respectfully, Gus
The problem with Interrupts is that you can only reliably service ONE at a time.
Sure, the processor/architecture may have more interrupts defined, but many of them shouldn't be interrupted, or data-loss may occur. (Serial comms is one)
For that reason, some processors had one NMI(Non-Maskable Interrupt), which was reserved for the REALLY time-critical stuff, and allowed the rest to be 'masked away' by setting a flag(usually in the CPU itself).
What happened when that flag was cleared?
Some, at least, kept track of whether or not an IRQ(Interrupt ReQuest) had arrived, and executed it as soon as the flag was cleared, but...
What if several IRQs had arrived?
Which ones are still valid?
That flag was usually set by the arrival of the NMI, but could also be set with an assembly instruction, so that the running program wouldn't be interrupted while doing something time-critical.
Unfortunately, what is or isn't time-critical is up to the programmer...
(I've done Interrupt programming on Z80 and i8051, and frankly, I don't miss it)
Is it annoying to know that whole COGs which could potentially execute code at 20 or 160MIPS is 'wasted' while it waits for an event?
Yes, but with 8 32bits COGs for $12.95(the current one-off price), and the potential of 16 GOGs in the next version, I think I can live with it.
Besides, it's not as if most apps NEED the speed...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 1/12/2007 1:50:00 PM GMT
You're view that ·"supplying independent cogs to mimic what interrupts traditionally do", while historically accurate is really backwards.
INTERRUPTS on other MCU's·are used to mimic what independent cogs "do".· Think of the prop this way. 1 MCU with 7 dedicated, deterministic interrupt routines. Or the future prop, 1 160mips MCU with 15 interrupt routines.
I understand the view that using a cog for one task "IS wasteful", but think of it this way. Unless you app REQUIRES more that the current 8 cogs, with one task per cog,·using a PROP WILL·be wasteful.· The idea of the Prop is to make designs and their software simpler, alot simpler by removing dedicated devices (and the subsequent boat load of MCU SKU's) and removing the 'hack' of using interrupts to simulate multitasking.
Seth
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I really look forward to having a 64IO Prop2. What I would really like would be a standard meathod supported in spin to pass messages between objects on different Propellers. If that was fast and easy, I would rather have 8Cog/256KB, because each one would have faster memory access, and I could just add more props if I needed more cogs. Now that would be really cool! Interrupts are not needed at al then. Of course, there would be a cost to run an object on another prop, but there is a cost in memory access for having more than 8 cogs.
When I looked at Paul's memory expansion(http://forums.parallax.com/forums/attach.aspx?a=10636), it seemed like a good idea. But, take this with a grain of salt since I just got my Demo Board yesterday, and haven't had time to play with it.
Thanks,
Doug
I would agree that we we need at least 32 pins of 3.3v IO, but 16 or 32pins of 1.8V IO would be great!
Doug
Remember that we will continue using 5v, for other devices (including LEDs with resistances). If is used 1.8 more 3.3, then in practice will be 1.8, 3.3 and 5v (three regulators).
Are there translator ICs for 1.8v to 5v and back? It seems some applications running a PROP at 1.8v will not be easily workable! Am I wrong?
I was hoping this 2nd generation Prop would handle a design (which would need 3 gen 1 Props for I/O and cogs) but looks more and more like it cannot. SIGH!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Also :
Please a spin language with enhancement as
- callback
- preprocessor
- macro
- variable of 'bit' type
- classical hardware and software interrupts support can sometime permit to saving cog's usage.
- a globally nicely syntax and more C like language .
If your spin language is few attractive for the BASIC STAMP users, it is repulsive and 'not professional' for the C users .
Globally, the Propeller is wonderful and a great enhancement.
I'm just buy Propeller for testing and it's a very interesting environment. As Parallax can do it's very simple to start. But it's not a good way for 'commercial' uses because the
wastage of resources.
I just read the discussion about the interrupts. As for a religion, it's possible to give interrupt to people witch like it and the other don’t need to use it !
Thank-you for this very good job.
Respectfully,
dro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
Post Edited (inservi) : 1/15/2007 8:02:41 PM GMT
- More cogs means increased access time to main RAM, so if you application ends up not using more than 8 cogs, you're reducing performance for no gain at all. Unless there could be a mechanism in the hub that would connect ONLY the active cogs to main memory, but that would kill timing determinism and I'd rather keep it.
- On the other hand, I can think of a few applications that would require a lot of cogs and wouldn't be penalized too much by increased main RAM latencies
- A chip with more main RAM would be nice but to really take advantage of the additional RAM it would also be important to decrease access time. It's like a 4GB thumbdrive with USB 1.1 : nobody would buy that, it'd be too slow compared to the capacity.
You mention that each cog would run at 160 MIPS. I sure makes my mouth water : can you tell us more ? I assume the chip would have to run at 160 MHz with single-cycle execution of most instructions. What will that mean for the hub timing ?
Jean
The current propeller gets access 5M times per second.
Therefore, in the 16 cog version each cog would get TWICE the memory bandwidth the current cogs get!
In my opinion, that speeds things up [noparse]:)[/noparse]
Also, the cogs would be executing 160M instructions per second, up from the current 20M - an 8x improvement per cog
Personally, I was initially for the 16cog/128k design... then I changed my mind, and preferred the 8cog/256k design... however now I am back in the 16cog/128k design camp [noparse]:)[/noparse] for two reasons:
- twice the processing power of the competing design (8cog/256k)
- with the 64 bits of I/O, it is easy enough to hook up some external memory - as much as we like.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Autoincrementing pointer registers seem to be a frequent request.
That would make everything from Ethernet to bulk memory easier.
And I'd very much like to hear from Chip if he believes he will be able to move the interior tracks in such a way as to make the ADC work with adjacent pins but the same or less noise.
Thank you, Tom Perkins
Post Edited (tperkins) : 1/15/2007 3:20:45 AM GMT