QuattroRS4 said...
Assuming an 8 cog/256k prop is agreed - with functionality for inter/intra prop cog usage .. How exactly would a proposed multi Prop2 setup work. Assuming the first PropII is a master the second is a slave (purely a cog donor) ..So essentially the scenario is as follows - One eeprom connected to master Prop, 1 master PropII, 1 or more Cog donor propII's,1 clock source.
How does such a system boot with the 'slave' or 'slaves' "knowing" that they are essentially cog donors without having to be programmed? How is the clock Synchronised successfully.How are the slave I/O's addressed.
Regards,
John Twomey
The slaves just get loaded up from the master and start executing. They'd all have some pins tied·across for communication. I think everything would be·a software issue. No special hardware is required to work like this.
In case you haven't seen it, look at the PropellerLoader object. It loads another Propeller, controlling reset and pins 31 and 30. It's pretty understandable.
As far as the clock goes, you'd connect the master's XO to the slave's XI with XINPUT selected on the slave to minimize capacitance.
I look forward to making an 8x8 array of Prop II's which are loaded as a group, with the same program going into each, but also unique ID values assigned for each array member. Each would use his ID as a key to differentiate his own behavior.
Sleazy-G: No slight intended and I've had quite enough experience of such calculations. What I was curious about is why things like a keypad and joystick need to be up dated at anything like 200KHz and in such tight synchronization. The human who is doing the pressing and wiggling is nowhere near that quick.
Still, this is getting a little off topic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
HeHe; like Phil I couldn't keep my eyes open any longer - t'was the early hours here in UK, but I'm finding this thread fascinating.
Re: inter-chip comm's: I've been thinking for a few months about a scheme similar to good-old Token-Ring. This seems to fit with the deterministic nature of the Prop; albeit where the determinism is subject to the number of Prop's in the ring!
Given that PropII's so much faster than PropI, and there'll be hardware (de-)serialisers, am I right in I'm guessing that we'd be able to dedicate one COG to high-speed serial I/O to implement this? And what sort of data rate could we reasonably expect?
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offense at my writing style
Chip Gracey said...
I look forward to making an 8x8 array of Prop II's which are loaded as a group, with the same program going into each, but also unique ID values assigned for each array member. Each would use his ID as a key to differentiate his own behavior.
Well if intra/inter cog and clock sharing is perfectly doable accross multiple PropII's with little overhead I'd have to say 8Cog/256K version is the way to go.I have been convinced !
A multiple PropII board design will require greater attention though !
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
Post Edited (QuattroRS4) : 8/29/2008 9:49:53 AM GMT
I'm with heater on the hyperthreading / cache ideas - seems to me we're moving way too far from the simplicity & determinism that's what attracts so many people (especially hobbiests) to the Propeller. I'm getting the impression that most of this stuff wouldn't be easily available to the SPIN programmer anyway?
I'd vote for simplicity every time, especially if we're getting high-speed comm's assistance
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offense at my writing style
Yes, I feel much better about simplicity, too. I think no cache-line read/write, and no hardware multi-threading is the way to go. It keeps things sane.
Multi-threading LMM code can be done perfectly well by a single-threaded assembly program that round-robins the LMM code. In fact, I think it would be much simpler this way, as there are no context issues surrounding RETs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 8/29/2008 10:08:32 AM GMT
Yup - one of the (many) powerful beauties of your design is that you put that power into our hands in a way that anyone can learn, and I thank you for that. Just as keeping compatibility will most likely be regretted in future, I feel that adding other complexity would be the same.
You've really got me fired-up with enthusiasm again Chip, and I'm spending way too much time watching this thread, but it's great!
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offense at my writing style
I talked to Andre LaMothe (HYDRA) tonight about what he thought could be done to improve the video circuitry.
He thought adding a layer on top of the current video circuitry which would automate the gathering and outputting of color and pixel data would be good. This would mean that rather than doing flurries of WAITVIDs, you could point at the beginning of a stream of color and pixel longs within cog RAM and have the video circuit fetch them automatically when needed by stalling·cog execution periodically for one clock to get access to the cog RAM. So, you would set the begin and end pointers, set VSCL, do a WAITVID, and it would release you as soon as it took your command. After that, it would gather and output all color/pixel long pairs, not accepting another WAITVID until it was done with the series. This means that rather than doing lots of WAITVIDs, you'd be free to compose a whole scan line. During that time, you would lose a cycle here and there, but not otherwise be interrupted.
Also, we talked about the possibility of putting a color lookup RAM into the video circuit which would translate those 8-bit pixels into 16-bit pixels which could be·output as follows:
for composite video: %PPPPPP_TTTTT_BBBBB; where P=phase, T=top level, B=bottom level. This would use a 5-bit R2R DAC.
for vga (possibility): %RRRRR_GGGGG_BBBB_HV; where RGB have 6:6:5 bits, and Horizontal and Vertical are in the LSBs. Each color would use an R2R DAC.
This would make both composite and vga quite high quality.
The lookup table would be loaded 1-color-word-at-a-time by special instructions.
Would·these modifications be beneficial to you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 8/29/2008 10:52:20 AM GMT
Hmmm; video's not really my 'thing', but I'm sure the likes of Coley & Baggers will be drooling!
BTW Chip: Have package size & pin count been firmed-up yet? I seem to remember talk of no DIP version of PropII, but assume that Parallax will provide some sort of breadboard version...
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
simonl said...
...Have package size & pin count been firmed-up yet? I seem to remember talk of no DIP version of PropII, but assume that Parallax will provide some sort of breadboard version...
We're planning on LQFP-100 (14x14mm) and QFN-100 (12x12mm). We will provide breadboard versions, of course.
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
I have to say that the loss of DIP packaging is very sad. As it is I can stroll up the road to my local ELFA store and pick up a DIP Prop for a few beers worth of euros and slap something together with it in a few hours. I can't see breadboard versions being so cheap and cheerful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Soldering 1.0 mm pitch is a cinch as long as the PCB is well made. That's the real issue - having a PCB ready.
Pretinning is all that's required. Just don't expect it to be removable again, so you have to be sure the IC is placed squarely and firmly before heating the pins. And if a bridge occurs then a blob of fresh solder soaks it up nicely - drag the blob to one end while adding fresh solder. I usually do this anyway to catch any tiny splashes I might not have spotted.
Hi Chip Gracey.
On Video conters and funktions it is fine solution.
My only conclusion if there is rom for fast VGA video modes with diferent XTal speed.
For more reliable VGA
and ALL.
On pakage for hobbyist My solution·PLCC pakage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
That would certainly improve things from a colour depth perspective, I've pretty much had the same conversation with Baggers.
Pixel wise we already have 720*576 resolution which is about the most I'd want to do with a TV.
I like the idea of automating the gathering of data for WAITVID, that's pretty much how the AVR manages to generate it's pixel data.
I can see other non video related uses for that, especially if there is a video de-serializer as you have hinted.
The other thing we have discussed is perhaps a mechanism for supporting TMDS for HDMI signalling.
We agreed that it would be great if the Prop II had this feature as it keeps the 'one chip' solution viable.
Is there not LVDS/TMDS support on the Stratix III? It may be worth a look at.
The other option is to feed VGA into a dedicated DAC so it's no big loss if it's not do-able
Over here in the UK analogue TV is in the process of being phased out, within a few years almost everyone will have made the switch to digital, would it not make sense considering the future roadmap of the Propeller and it's variants.
I accept that there will forever be the AV input on most TV's but if you were able to include TMDS it would certainly future proof the design.
You've certainly got us chomping at the bit over here, it's just like the excitement I encountered when I first found out all about Prop I (Thanks simonl!!!)
Kind regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
I talked to Andre LaMothe (HYDRA) tonight about what he thought could be done to improve the video circuitry.
He thought adding a layer on top of the current video circuitry which would automate the gathering and outputting of color and pixel data would be good. This would mean that rather than doing flurries of WAITVIDs, you could point at the beginning of a stream of color and pixel longs within cog RAM and have the video circuit fetch them automatically when needed by stalling cog execution periodically for one clock to get access to the cog RAM. So, you would set the begin and end pointers, set VSCL, do a WAITVID, and it would release you as soon as it took your command. After that, it would gather and output all color/pixel long pairs, not accepting another WAITVID until it was done with the series. This means that rather than doing lots of WAITVIDs, you'd be free to compose a whole scan line. During that time, you would lose a cycle here and there, but not otherwise be interrupted.
Also, we talked about the possibility of putting a color lookup RAM into the video circuit which would translate those 8-bit pixels into 16-bit pixels which could be output as follows:
for composite video: %PPPPPP_TTTTT_BBBBB; where P=phase, T=top level, B=bottom level. This would use a 5-bit R2R DAC.
for vga (possibility): %RRRRR_GGGGG_BBBB_HV; where RGB have 6:6:5 bits, and Horizontal and Vertical are in the LSBs. Each color would use an R2R DAC.
This would make both composite and vga quite high quality.
The lookup table would be loaded 1-color-word-at-a-time by special instructions.
Would these modifications be beneficial to you?
Yeah those modifications would be very useful. [noparse]:)[/noparse]
The big thing that got me with the Prop's video out was the single bit saturation control. (On/Off)
Having a controllable value for both Top and Bottom modulation levels would allow for all types of useful video-out functions.
That color lookup table (CLUT) would be helpful in making good use of the 8bit limit.
So I'm all for this idea.
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
So what is the pin pitch going to be on the Prop II? I find it challenging to solder the original Prop! Good thing we have a microscope in our electronics lab at work! [noparse]:)[/noparse]
Edit:· OK, I read up on it.· For the benefit of anyone else who's wondering, the lead pitch of a 14mm LQFP-100 is 0.5mm.· The current Prop QFP has 0.8mm spacing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
Post Edited (Ken Peterson) : 8/29/2008 12:40:13 PM GMT
I just read some of the posts from the last day. Wow! Multithreading support in cogs? If 16 cogs is not possible, then this is a good alternative! Would SPIN support multithreading?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
Multithreading support in cogs is not alternative.
Read Chips answers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
On the subject of hardware threading in a Cog, aside from determinism, it's going to be wanting more Cog ram as well. I think before pushing for more intra-Cog concurrency the 512 word limit would have to be raised.
If that happens then interrupts are definitely on the table along with stacking and every other modern serialising enhancement to push out the mips even further. Pushing the Hub into a corner.
@Ken: Yeah, Sapieha's right; I think Chip's decided against it because - with PropII being so much faster (Chip indicated that a single PropII COG will be about equivalent to a complete PropI!) - doing our own multi-threading should be OK. Sure that's a 'wet finger in the air' job, but I believe the majority of applications won't need this anyway - right?
I'd personally love to see PropII with 16 COGs, but I Chip's indicated that the cost of the final chip might be prohibitive. Instead, I'm hearing (Chip; please correct me if I'm wrong) that we'll get 8 COGs and hardware serialise / de-serialise (so inter-chip comm's will be a doddle).
Therefore, if 8 COGs is not enough, it should be simple to add another PropII and have the two (or more!) communicate at very high-speed.
That seems to fit with the simplicity that drew me to the Propeller in the first place
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
Ken Peterson said...
OK, I read up on it. For the benefit of anyone else who's wondering, the lead pitch of a 14mm LQFP-100 is 0.5mm. The current Prop QFP has 0.8mm spacing.
Oops, so true. Don't think I've soldered a new one of those packages before. But I've definitely resoldered a few before that had gone dry.
Propeller power is simplicity.
Do not construct monster.
All new adition must have sama simplicity.
I agree 100% with Sapieha here. Frankly this thread is scaring me. In my lifetime I've seen way too many excellent products completely ruined by feature bloat. The PropI is a good chip. Let's stay with the basic concept and simply address the glaring weaknesses that affect the majority of users. Otherwise we're going to end up with a hardware version of Windows Vista.
Seriously though we need to remember that even the PropI is often a challenge to program for those not well versed in Computer Science. Just read through some of the threads in this forum. Do we really want to create a Frankenstein chip that includes everything short of the proverbial kitchen sink but requires a PhD to program it? I urge Parallax and others to revisit the old advertisement which used to appear on the back of "Nuts and Volts" magazine which started off saying "Remember when programming was fun?".
Comments
In case you haven't seen it, look at the PropellerLoader object. It loads another Propeller, controlling reset and pins 31 and 30. It's pretty understandable.
As far as the clock goes, you'd connect the master's XO to the slave's XI with XINPUT selected on the slave to minimize capacitance.
I look forward to making an 8x8 array of Prop II's which are loaded as a group, with the same program going into each, but also unique ID values assigned for each array member. Each would use his ID as a key to differentiate his own behavior.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Still, this is getting a little off topic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Does that mean we are really on for some serial COG to COG communications assistance? And between Props.
If so the need for 16 COGs goes down.
I worry about these cache and hyper-threading ideas, seems they could lead to all kinds of gotchas.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re: inter-chip comm's: I've been thinking for a few months about a scheme similar to good-old Token-Ring. This seems to fit with the deterministic nature of the Prop; albeit where the determinism is subject to the number of Prop's in the ring!
Given that PropII's so much faster than PropI, and there'll be hardware (de-)serialisers, am I right in I'm guessing that we'd be able to dedicate one COG to high-speed serial I/O to implement this? And what sort of data rate could we reasonably expect?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Well if intra/inter cog and clock sharing is perfectly doable accross multiple PropII's with little overhead I'd have to say 8Cog/256K version is the way to go.I have been convinced !
A multiple PropII board design will require greater attention though !
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
Post Edited (QuattroRS4) : 8/29/2008 9:49:53 AM GMT
I'd vote for simplicity every time, especially if we're getting high-speed comm's assistance
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Multi-threading LMM code can be done perfectly well by a single-threaded assembly program that round-robins the LMM code. In fact, I think it would be much simpler this way, as there are no context issues surrounding RETs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 8/29/2008 10:08:32 AM GMT
You've really got me fired-up with enthusiasm again Chip, and I'm spending way too much time watching this thread, but it's great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I talked to Andre LaMothe (HYDRA) tonight about what he thought could be done to improve the video circuitry.
He thought adding a layer on top of the current video circuitry which would automate the gathering and outputting of color and pixel data would be good. This would mean that rather than doing flurries of WAITVIDs, you could point at the beginning of a stream of color and pixel longs within cog RAM and have the video circuit fetch them automatically when needed by stalling·cog execution periodically for one clock to get access to the cog RAM. So, you would set the begin and end pointers, set VSCL, do a WAITVID, and it would release you as soon as it took your command. After that, it would gather and output all color/pixel long pairs, not accepting another WAITVID until it was done with the series. This means that rather than doing lots of WAITVIDs, you'd be free to compose a whole scan line. During that time, you would lose a cycle here and there, but not otherwise be interrupted.
Also, we talked about the possibility of putting a color lookup RAM into the video circuit which would translate those 8-bit pixels into 16-bit pixels which could be·output as follows:
for composite video: %PPPPPP_TTTTT_BBBBB; where P=phase, T=top level, B=bottom level. This would use a 5-bit R2R DAC.
for vga (possibility): %RRRRR_GGGGG_BBBB_HV; where RGB have 6:6:5 bits, and Horizontal and Vertical are in the LSBs. Each color would use an R2R DAC.
This would make both composite and vga quite high quality.
The lookup table would be loaded 1-color-word-at-a-time by special instructions.
Would·these modifications be beneficial to you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 8/29/2008 10:52:20 AM GMT
BTW Chip: Have package size & pin count been firmed-up yet? I seem to remember talk of no DIP version of PropII, but assume that Parallax will provide some sort of breadboard version...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Soldering 1.0 mm pitch is a cinch as long as the PCB is well made. That's the real issue - having a PCB ready.
Pretinning is all that's required. Just don't expect it to be removable again, so you have to be sure the IC is placed squarely and firmly before heating the pins. And if a bridge occurs then a blob of fresh solder soaks it up nicely - drag the blob to one end while adding fresh solder. I usually do this anyway to catch any tiny splashes I might not have spotted.
On Video conters and funktions it is fine solution.
My only conclusion if there is rom for fast VGA video modes with diferent XTal speed.
For more reliable VGA
and ALL.
On pakage for hobbyist My solution·PLCC pakage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 8/29/2008 12:02:14 PM GMT
That would certainly improve things from a colour depth perspective, I've pretty much had the same conversation with Baggers.
Pixel wise we already have 720*576 resolution which is about the most I'd want to do with a TV.
I like the idea of automating the gathering of data for WAITVID, that's pretty much how the AVR manages to generate it's pixel data.
I can see other non video related uses for that, especially if there is a video de-serializer as you have hinted.
The other thing we have discussed is perhaps a mechanism for supporting TMDS for HDMI signalling.
We agreed that it would be great if the Prop II had this feature as it keeps the 'one chip' solution viable.
Is there not LVDS/TMDS support on the Stratix III? It may be worth a look at.
The other option is to feed VGA into a dedicated DAC so it's no big loss if it's not do-able
Over here in the UK analogue TV is in the process of being phased out, within a few years almost everyone will have made the switch to digital, would it not make sense considering the future roadmap of the Propeller and it's variants.
I accept that there will forever be the AV input on most TV's but if you were able to include TMDS it would certainly future proof the design.
You've certainly got us chomping at the bit over here, it's just like the excitement I encountered when I first found out all about Prop I (Thanks simonl!!!)
Kind regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Yeah those modifications would be very useful. [noparse]:)[/noparse]
The big thing that got me with the Prop's video out was the single bit saturation control. (On/Off)
Having a controllable value for both Top and Bottom modulation levels would allow for all types of useful video-out functions.
That color lookup table (CLUT) would be helpful in making good use of the 8bit limit.
So I'm all for this idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
If You incorporate R2R DAC on video is it rom to stop counter and have only DAC funktion on?
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 8/29/2008 12:19:21 PM GMT
So what is the pin pitch going to be on the Prop II? I find it challenging to solder the original Prop! Good thing we have a microscope in our electronics lab at work! [noparse]:)[/noparse]
Edit:· OK, I read up on it.· For the benefit of anyone else who's wondering, the lead pitch of a 14mm LQFP-100 is 0.5mm.· The current Prop QFP has 0.8mm spacing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
Post Edited (Ken Peterson) : 8/29/2008 12:40:13 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
Multithreading support in cogs is not alternative.
Read Chips answers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 9/25/2008 12:24:12 PM GMT
If that happens then interrupts are definitely on the table along with stacking and every other modern serialising enhancement to push out the mips even further. Pushing the Hub into a corner.
Evan
I'd personally love to see PropII with 16 COGs, but I Chip's indicated that the cost of the final chip might be prohibitive. Instead, I'm hearing (Chip; please correct me if I'm wrong) that we'll get 8 COGs and hardware serialise / de-serialise (so inter-chip comm's will be a doddle).
Therefore, if 8 COGs is not enough, it should be simple to add another PropII and have the two (or more!) communicate at very high-speed.
That seems to fit with the simplicity that drew me to the Propeller in the first place
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
If I hear this right, the PropII might be the last chip you'll ever need...
Simply keep stacking them to increase cogs and memory...
(I'm sweating just thinking about this... [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Evan
I agre with You
"" Therefore, if 8 COGs is not enough, it should be simple to add another PropII and have the two (or more!) communicate at very high-speed.
That seems to fit with the simplicity that drew me to the Propeller in the first place ""
And that solution open for fuly Faul Tolerant systems!!
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I agree 100% with Sapieha here. Frankly this thread is scaring me. In my lifetime I've seen way too many excellent products completely ruined by feature bloat. The PropI is a good chip. Let's stay with the basic concept and simply address the glaring weaknesses that affect the majority of users. Otherwise we're going to end up with a hardware version of Windows Vista.
Seriously though we need to remember that even the PropI is often a challenge to program for those not well versed in Computer Science. Just read through some of the threads in this forum. Do we really want to create a Frankenstein chip that includes everything short of the proverbial kitchen sink but requires a PhD to program it? I urge Parallax and others to revisit the old advertisement which used to appear on the back of "Nuts and Volts" magazine which started off saying "Remember when programming was fun?".
Anyway good luck and peace.