I submitted the scheduler kernel as my entry to this year's Propeller contest. If you go to that section on the Parallax site, you will find the writeup with an explanation and sample code.
Someday (soon?) I hope to get some time and do a more user oriented write up and post it in the OBEX.
Yes, I'd missed it as well. A good way to make the most of each cog - some drivers that are allocated their own cog are in fact quite small, and it seems a shame that you can't use the rest of the cog space for something else - your method shows a fairly simple way to do just that.
Did you ever implement the version that preserves the C & Z flags? That would greatly simplify the process of converting an existing driver to use your scheduler.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Whoaaa, DRAMA. I would have to agree with Leon about some things. I don't think that the miniprop would be much of a market success. There is just to many other chips to compete with. The Propeller is a unique chip, because of its cogs/ Video capability/ Ease of use/ price..... I think downsizing the Prop would be a bad idea. I also agree with the others about the focusing on the Prop 2, which will expand upon the great chip's legacy. And about Leon. He has helped me before when i had questions and i think "Banishing" him is kinda harsh. As Phil said, we need to have a thicker skin. Perhaps Parallax should create a general discussion area. A place where you can talk with your fellow geeks about anything, ranging from XMOS's to vacation spots and from computers to Jessica Alba....... I like that last one a lot, hehe
All you need for ARM development on the cheap is a $29.95 NXP LPCXpresso kit which comes with either an LPC1114 Cortex-M0 or the LPC1343 Cortex-M3. Free software (the Eclipse IDE and gcc) is available for it. The more expensive ($59) mbed board sold by ARM (LPC1768 Cortex-M3) is fun, as well, and uses web-based (Keil) tools. I've got both.
In large quantities an NXP ARM Cortex-M0 chip costs 65c!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
@ Dave Hein;
The smaller process used for the Prop2 is far too leaky for an SX replacement. The Prop1 process allows us to get down to 4 to 6 uA of current, whereas (IIRC) we are told the Prop2 will leak about 1 mA. That just doesn't cut it for me for battery applications.
@ Leon;
(Shouting) I DON'T WANT TO LEARN YET ANOTHER PROCESSOR... I'm comfortable and happy where I am with Parallax in assembler, and I hope to keep it that way, even if that might not be the "BEST" solution. I'm doing my darndest to coax Parallax into a price reduced 2 cog Propeller that can (mostly) replace the SX. Then they will have control over the IP and not have some silly third party management dictate (SX EOL) the direction of their business.
I LIKE the way Parallax runs their business, and I'm going to support it even if it might cost some extra.
Dave: Apart from the power constraints, I just don't think you can reduce the die geometry like that. It requires a new layout, not a photo reduction. Perhaps someone can confirm my belief?? It's a pitty because it could be a good solution to a cost reduced Prop, and allow for a smaller DIP option too, even if it draws more power.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I would like a smaller version of the prop, for small projects.
In my case the advantage would be to use a known chip, for few items.
I think the multischeduler, the spinlmm, propbasic, catalina and so on offer a lot of possible use of a reduced chip, still offering a lot of speed.
Question is: will ROM and Ram be reduced? If a graphic slave with a 2 COG propeller is feasible, for sure you cannot strip ROM fonts, nor RAM for the double buffer.
I use the sine table, so I would miss it.
Excluding the double buffer a smaller RAM could be ok (and maybe ROM fonts?), as long as it brings to a price reduction.
A die shrink like that doesn't need a new layout; I think it can only be used with the older processes, though. I can't see going from 90 nm to 45 nm being feasible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
The die shrink would produce a lower cost chip that could fit in a smaller package while still maintaining 8 cogs.· It would require a minimum amount of redesign, but I do acknowledge that not all of the parts will be able to shrink as much.· The I/O and power pads will probably have to remain about the same size in area.
The argument about having more leakage current is just plain silly without backing it up with numbers.· If a·Prop I can't be shrunk because of the leakage current then the Prop II·will is not feasible for the same reason.· Somebody please provide a number for the leakage current!· Also, as I mentioned before leakage current is not an issue for a lot of applications.
If the Prop I is redesigned for 2 or 4 cogs the idea of using the 180 nm process is even more exciting.· Just think how much smaller the die would be for those cases.· If only some of the I/O pins are brought out, versions of these chips could be·put in a 28 or 18 pin package.
Dave
Edit: I re-read Peter's post, and saw that he did give a leakage current figure of 1 mA for the Prop II.· This would scale to about 250 uA or less for the die shrunk Prop I.· That works for me.· Proportionately sliced 4-cog and 2-cog versions would have leakage currents of 125 uA and 63 uA.· In my applications there are other peripheral chips that consume power, so my circuits are either on at full speed or turned off.· Leakage current is not a major issue for applications like that.
Dave Hein : "The argument about having more leakage current is just plain silly..."
Not silly at all. This is a well documented problem. As feature sizes go down leakage current seems to be going up exponentially. Hence the push toward lower core voltages.
Google will turn up many articles about this. For example:
How this applies to shrinking a Propeller I have no idea, but it seems certain to be an issue. And has already been discussed here from time to time re: the Prop II. It is commonly accepted that the Prop II will be using a lot more power in proportion to it's memory and performance increases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Dave Hein : "The argument about having more leakage current is just plain silly..."
"...· without backing it up with numbers."
heater, you modified my statement by deleting the last part of the sentence.· The issue of leakage current is not silly, but discussing it without hard numbers is.· I think a version of the Prop I with lower cost, but a higher leakage current would be a viable product.· If your application requires a low standby current then you could continue to use the current Prop I, or maybe Leon would have suggestions for other viable solutions.
Dave
Dave: You cannot just scale leakage current either. So a Prop 1 built in 180nm will draw more than currently. How much? No idea. It may not be able to use 3V3 either - I just don't know. Can the chip be scaled smaller? I don't think so without some reasonable redesign - a resource which Parallax do not have spare. Chip already suggested a smaller die at the same geometry with less cogs might be able to be done with minimal work.
However, your idea has merrit if it can be done without interrupting Chip on Prop II. It would be preferable to have a full Prop 1 using more current and smaller die meaning cheaper cost and perhaps smaller packages too. But they didn't go to smaller geometry for the Prop 1.5 layout when they did it, so I presume there was a reason for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dave : Sorry, I did not mean to mis-represent you. I put the quote and dot, dot, dot there to more as a link to what I'm replying to. I'll be more careful in future. Anyway, point taken about the trade offs you are prepared to live with.
All this poses a question. We see that performance can go up as feature sizes go down and that power consumption goes up dramatically as feature size goes down. So is there a sweet spot on the power consumption / performance graph with todays available technology? That is to say if you wanted the post performance per watt then what feature size would you choose?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The comment above that essentially boils down to "vote with your feet" is a good one. Honestly, it's often that one gets exactly what they pay for, so there is some merit to that. I regularly buy local, or US where I can, because we don't make as much as we used to, and that's getting to be a problem. A quick look at the national politics in the US quickly shows the kinds of things we end up dealing with when dollars are the only concern.
Again, I point to margin instead of share. If one large order paid for the setup tasks, leaving perhaps some of that order as profit, and or ongoing chips as some small profit, isn't that a net gain overall?
Just for fun, I took a look at some catalogs. Good grief there are a lot of variations on core designs. You just know a whole batch of those are not seeing the volume they would like, but the run is paid for --or maybe not for the bigger players, who offer them just for completeness. If the chips pay in the end, and are not costing anything to exist, why not?
IMHO, a significant fraction of this discussion ignores those things, operating under the assumption that the offering would pay solely on how it competes with others in the niche. If one substantial order gets the nut cracked, so to speak, doesn't that make follow on sales gravy, particularly, if part of that big order is an additional amount for inventory to be sold over time / and or used for promotional purposes?
Re: Graphics slave. That's an interesting take. Of course with just two COGs, the more advanced video capabilities we've seen are off the table. However, one COG doing comms, mixed with some graphics primitives and or software sprite capabilities, and the other doing a nice video signal, you've got a good frame buffer / tile driver, with some "hardware assist" for not a lot of dollars. If the fill rate needed to maintain the display were not too high, the comms COG probably could do that.
Would this prop have fewer pins? Can't remember, and I don't know that I'm going to re-read the thread. If so, it's cake to use the ones not brought out to the package extremities to form that perfect cog to cog comms port we all want in Prop II. [noparse]:)[/noparse]
I believe the main point of this thread is to discuss ways that the Prop I could be cost reduced.· The original suggestion was to create a 2-cog version of the Prop.· Personally, I think 2 cogs is too limiting for a lot of applications.· If the 32K RAM and 32K ROM are retained then removing 6 cogs eliminates less than 38% of the chip area.· I don't think this is aggressive enough to get a significant cost reduction.
I do think a 4-cog chip would be useful.· 8 cogs is even better if the cost could be reduced.· I believe that a newer process could achieve that cost reduction.· It could potentially reduce the die size to about one-fourth of the current size.· Leakage current seems to be one of the main issues.· A die-shrunk Prop I would have to run at a lower voltage to minimize this.
Clearly we wouldn't want the development of a low-cost Prop to impact the schedule and resources being used for the Prop 1.5 and Prop 2.· I know virtually nothing about chip developement, but it seems like a respin of the current Prop I with a new process would require the smallest effort.· One advantage of this approach is that it would provide design experience that could be leveraged for the Prop 2.
With all that being said, the real question is whether there is a business case for even pursuing a cost reduced Prop I.· That's the toughest question to answer.
@Ross & Leon: I admit I'm mixing apples and oranges. My current employer designs medical devices. We are bound by Misra-C rules. A 'free' gcc compiler isn't going to wash even if I wanted to fuss with getting one built, which I don't. And while an LPC1114 board may cost $23, an ADuc7026 board doesn't. The chip alone is $15, qty 1. The cheapest proto board I've found is nearly $200.
At home, it's all about having fun, which means that things like nested interrupts and you-are-on-your-own (it-was-hard-to-make-so-it-ought-to-be-hard-to-use) compilers are out the window. The ARM may be a great chip to host a Forth kernel. But it would take something like that before the ARM would be my go-to chip for the next application. It's just not very much fun from either a hardware or a software perspective.
The SX and the Prop really don't even need proto boards. And their IDE's, in addition to being free, are labours of love.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The early bird gets the worm but the second mouse gets the cheese.
@Jazzed..... Uh, i must not have been there for that one, haha. But seriously, i wish Parallax would create a general discussion area other than the sandbox. I am sure i am not the only one who would greatly appreciate it. I agree with some who say that an extra increase in the leakage current would not be that bad, unless you were designing a ultra- low current battery powered device. And the prop 2 will most likely need more current than the prop 1.
Part of the difficulty with this sort of discussion is that, in order to come up with realistic numbers (like chip area and power consumption at idle), you have to do a significant amount of design work up front. You can make very good estimates based on the current Prop I design that apply to the same process and same feature size, essentially by leaving out known blocks. If you change the process or feature size, you're talking about a partial redesign. You can't just take the current design and shrink it. The internal voltages are different. The clock distribution system is different. I/O pins have to be built differently. It's not like a complete redesign, but it's not trivial.
Regarding the leakage current ... For a lot of applications it wouldn't matter. For many applications, it would be important. Parallax would have to chime in with percentages, but I see a lot of products using batteries and there may be periods of significant battery drain, but most of the time is spent waiting for time to pass or some kind of sensor activation. With a high leakage current, you can't just idle the processor, you have to shut it down and have some kind of separate processor looking for specific sensor inputs and switching the power back on.
If anyone were ever the exception to the excessively broad generality I made, it would be you! In fact the single best reason to use Catalina is that you are approachable. This entire forum is singular in that regard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Let's not bicker and argue about who killed who."
Peter, your RTOS code is brilliant. I have found it to
be a useful addition to my PASM knowledge. Anyone
that plays with PASM should look at your contest entry.
I have an updated version that enhances the features yet somewhat, but have not published it. Because the nuances of how it works and how to use it most effectively are far from obvious, I need to write some good explanations and presently I have no time for that.
Oh, yes, I like scopes too.... they are an absolute necessity for embedded work. I think that particular one is a Tektronix DPO 4000 series, 4 channel 500MHz. I now use a more current unit; a Tektronix mixed signal MSO 4000 series 16 digital, and 4 analog at 1GHz bandwidth (I also do RF work), 5 Giga samples/sec. The nice thing on this one is each channel has a 10Meg sample memory. It lets me store samples for a long time, and later go look at what happened.
Lots of fun.
P.S. My mistake, the one in the picture·IS the MSO scope. It was the one I used for the UPEW demos.
Comments
I submitted the scheduler kernel as my entry to this year's Propeller contest. If you go to that section on the Parallax site, you will find the writeup with an explanation and sample code.
Someday (soon?) I hope to get some time and do a more user oriented write up and post it in the OBEX.
Cheers,
Peter (pjv)
Bill
Yes, I'd missed it as well. A good way to make the most of each cog - some drivers that are allocated their own cog are in fact quite small, and it seems a shame that you can't use the rest of the cog space for something else - your method shows a fairly simple way to do just that.
Did you ever implement the version that preserves the C & Z flags? That would greatly simplify the process of converting an existing driver to use your scheduler.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Picaxe = Romeo & Juliet
In large quantities an NXP ARM Cortex-M0 chip costs 65c!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/7/2010 4:22:52 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
The smaller process used for the Prop2 is far too leaky for an SX replacement. The Prop1 process allows us to get down to 4 to 6 uA of current, whereas (IIRC) we are told the Prop2 will leak about 1 mA. That just doesn't cut it for me for battery applications.
@ Leon;
(Shouting) I DON'T WANT TO LEARN YET ANOTHER PROCESSOR... I'm comfortable and happy where I am with Parallax in assembler, and I hope to keep it that way, even if that might not be the "BEST" solution. I'm doing my darndest to coax Parallax into a price reduced 2 cog Propeller that can (mostly) replace the SX. Then they will have control over the IP and not have some silly third party management dictate (SX EOL) the direction of their business.
I LIKE the way Parallax runs their business, and I'm going to support it even if it might cost some extra.
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
In my case the advantage would be to use a known chip, for few items.
I think the multischeduler, the spinlmm, propbasic, catalina and so on offer a lot of possible use of a reduced chip, still offering a lot of speed.
Question is: will ROM and Ram be reduced? If a graphic slave with a 2 COG propeller is feasible, for sure you cannot strip ROM fonts, nor RAM for the double buffer.
I use the sine table, so I would miss it.
Excluding the double buffer a smaller RAM could be ok (and maybe ROM fonts?), as long as it brings to a price reduction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/7/2010 10:00:27 AM GMT
The argument about having more leakage current is just plain silly without backing it up with numbers.· If a·Prop I can't be shrunk because of the leakage current then the Prop II·will is not feasible for the same reason.· Somebody please provide a number for the leakage current!· Also, as I mentioned before leakage current is not an issue for a lot of applications.
If the Prop I is redesigned for 2 or 4 cogs the idea of using the 180 nm process is even more exciting.· Just think how much smaller the die would be for those cases.· If only some of the I/O pins are brought out, versions of these chips could be·put in a 28 or 18 pin package.
Dave
Edit: I re-read Peter's post, and saw that he did give a leakage current figure of 1 mA for the Prop II.· This would scale to about 250 uA or less for the die shrunk Prop I.· That works for me.· Proportionately sliced 4-cog and 2-cog versions would have leakage currents of 125 uA and 63 uA.· In my applications there are other peripheral chips that consume power, so my circuits are either on at full speed or turned off.· Leakage current is not a major issue for applications like that.
Post Edited (Dave Hein) : 7/7/2010 1:20:49 PM GMT
Not silly at all. This is a well documented problem. As feature sizes go down leakage current seems to be going up exponentially. Hence the push toward lower core voltages.
Google will turn up many articles about this. For example:
www.design-reuse.com/articles/4860/keeping-leakage-current-under-control.html
How this applies to shrinking a Propeller I have no idea, but it seems certain to be an issue. And has already been discussed here from time to time re: the Prop II. It is commonly accepted that the Prop II will be using a lot more power in proportion to it's memory and performance increases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater, you modified my statement by deleting the last part of the sentence.· The issue of leakage current is not silly, but discussing it without hard numbers is.· I think a version of the Prop I with lower cost, but a higher leakage current would be a viable product.· If your application requires a low standby current then you could continue to use the current Prop I, or maybe Leon would have suggestions for other viable solutions.
Dave
However, your idea has merrit if it can be done without interrupting Chip on Prop II. It would be preferable to have a full Prop 1 using more current and smaller die meaning cheaper cost and perhaps smaller packages too. But they didn't go to smaller geometry for the Prop 1.5 layout when they did it, so I presume there was a reason for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
All this poses a question. We see that performance can go up as feature sizes go down and that power consumption goes up dramatically as feature size goes down. So is there a sweet spot on the power consumption / performance graph with todays available technology? That is to say if you wanted the post performance per watt then what feature size would you choose?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Again, I point to margin instead of share. If one large order paid for the setup tasks, leaving perhaps some of that order as profit, and or ongoing chips as some small profit, isn't that a net gain overall?
Just for fun, I took a look at some catalogs. Good grief there are a lot of variations on core designs. You just know a whole batch of those are not seeing the volume they would like, but the run is paid for --or maybe not for the bigger players, who offer them just for completeness. If the chips pay in the end, and are not costing anything to exist, why not?
IMHO, a significant fraction of this discussion ignores those things, operating under the assumption that the offering would pay solely on how it competes with others in the niche. If one substantial order gets the nut cracked, so to speak, doesn't that make follow on sales gravy, particularly, if part of that big order is an additional amount for inventory to be sold over time / and or used for promotional purposes?
Re: Graphics slave. That's an interesting take. Of course with just two COGs, the more advanced video capabilities we've seen are off the table. However, one COG doing comms, mixed with some graphics primitives and or software sprite capabilities, and the other doing a nice video signal, you've got a good frame buffer / tile driver, with some "hardware assist" for not a lot of dollars. If the fill rate needed to maintain the display were not too high, the comms COG probably could do that.
Would this prop have fewer pins? Can't remember, and I don't know that I'm going to re-read the thread. If so, it's cake to use the ones not brought out to the package extremities to form that perfect cog to cog comms port we all want in Prop II. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
I do think a 4-cog chip would be useful.· 8 cogs is even better if the cost could be reduced.· I believe that a newer process could achieve that cost reduction.· It could potentially reduce the die size to about one-fourth of the current size.· Leakage current seems to be one of the main issues.· A die-shrunk Prop I would have to run at a lower voltage to minimize this.
Clearly we wouldn't want the development of a low-cost Prop to impact the schedule and resources being used for the Prop 1.5 and Prop 2.· I know virtually nothing about chip developement, but it seems like a respin of the current Prop I with a new process would require the smallest effort.· One advantage of this approach is that it would provide design experience that could be leveraged for the Prop 2.
With all that being said, the real question is whether there is a business case for even pursuing a cost reduced Prop I.· That's the toughest question to answer.
At home, it's all about having fun, which means that things like nested interrupts and you-are-on-your-own (it-was-hard-to-make-so-it-ought-to-be-hard-to-use) compilers are out the window. The ARM may be a great chip to host a Forth kernel. But it would take something like that before the ARM would be my go-to chip for the next application. It's just not very much fun from either a hardware or a software perspective.
The SX and the Prop really don't even need proto boards. And their IDE's, in addition to being free, are labours of love.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The early bird gets the worm but the second mouse gets the cheese.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Picaxe = Romeo & Juliet
Regarding the leakage current ... For a lot of applications it wouldn't matter. For many applications, it would be important. Parallax would have to chime in with percentages, but I see a lot of products using batteries and there may be periods of significant battery drain, but most of the time is spent waiting for time to pass or some kind of sensor activation. With a high leakage current, you can't just idle the processor, you have to shut it down and have some kind of separate processor looking for specific sensor inputs and switching the power back on.
I like it! I think I'll make this Catalina's official support policy
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Let's not bicker and argue about who killed who."
Peter, your RTOS code is brilliant. I have found it to
be a useful addition to my PASM knowledge. Anyone
that plays with PASM should look at your contest entry.
here is a direct link to the entry.
www.parallax.com/PropRTOS/tabid/852/Default.aspx
That looks like a nice scope in the picture of you at your workbench.
What is that? (I love scopes, they are my fav tools)
I have an updated version that enhances the features yet somewhat, but have not published it. Because the nuances of how it works and how to use it most effectively are far from obvious, I need to write some good explanations and presently I have no time for that.
Oh, yes, I like scopes too.... they are an absolute necessity for embedded work. I think that particular one is a Tektronix DPO 4000 series, 4 channel 500MHz. I now use a more current unit; a Tektronix mixed signal MSO 4000 series 16 digital, and 4 analog at 1GHz bandwidth (I also do RF work), 5 Giga samples/sec. The nice thing on this one is each channel has a 10Meg sample memory. It lets me store samples for a long time, and later go look at what happened.
Lots of fun.
P.S. My mistake, the one in the picture·IS the MSO scope. It was the one I used for the UPEW demos.
Cheers,
Peter (pjv)