Much as I drool (not a pretty sight!) at the though of the Prop II, I agree with you completely - many of the projects being built around the Prop I right now would benefit enormously from a PortB Prop. Some of the emulation and XMM projects would benefit even if Parallax just implemented Port B internally but did not make all the pins accessible externally. Imagine what we could do with superfast cog-to-cog parallel comms that did not consume any I/O pins!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
PropII is shaping up now to have 64 I/O's, not the 96+ as previously stated. The reason has to do with packaging constraints. We met with our packager in Taiwan a few weeks ago about this matter, and what we wanted to do was, in simplistic terms, "very difficult". The problem was not so much technical as it was economic. We would need a special lead-frame·and maybe even·new injection molds to accommodate them. The tooling costs would be quite high to get that going. Even if we paid the tooling costs, I sensed they were somewhat loathe to run it because it would mean changing tooling out on their molding machine when they'd run our stuff, as opposed to leaving the standard tooling in place, and not worrying about QC problems due to switchovers. They strongly recommended that we fall back to one of their standard packages, so we cut down the lead count down·to 100 and went with a larger pitch. This will make things a little easier for some customers and keep us from becoming a pain in·our packager's·neck. They are very volume-oriented and have always given us excellent pricing, even though we are a peon among their other customers.
Also, the I/O pin circuits have become so large that fitting much more than 16 per die edge would have made the die huge. Now, Beau is rearranging the I/O pin layout so that it is wider than it is tall. This will let us squish them out sideways so that interior core area is freed up. This means more room for RAM.
While 96+ I/O's would have been quite rich, I feel we are on a better completion path with just 64. I'm getting kind of punch drunk and need to see some light at the end of the tunnel, anyway. Currently, things are feeling quite "right", as opposed to overwhelming.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/8/2010 6:54:49 AM GMT
Re: Multi-thread determinism: If a processor has a set of registers for two or more threads. And if each instruction takes the same amount of time, say four clocks. And if that processor executes an instruction from each thread before returning to the first, round robin style. Then the execution of the whole system of thread is as deterministic as having 4 processors running off the same clock at half the speed, or quarter speed or whatever.
There are two reasons why the XMOS threads fail to be as deterministic as the Propeller COGs.
1) Adding a second thread to a one thread set up halves the speed of the first thread. Has too. Same if you add a thread to two thread system. So unlike the Prop adding another object into your system can change the timing of the existing parts of the system.
2) Turns out XMOS divide instructions take longer to execute than other instructions. This means that if one thread suddenly decides to do a divide it will bugger up the timing of any other threads running.
I had a little debate about determinism with David May the CTO of XMOS over the Christmas break where he had to admit: "So - there is potential interference between divide instructions in different threads"
So that's it for determinism on XMOS. You cannot do it by simple cycle counting of instructions.
What you are supposed to do is make proper use of the various timing features of the device. Use the clocked I/O itc.
In this way multiple threads can exist with totally deterministic timing in a single core.
It is somewhat harder than just throwing objects at COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Chip: Thanks for the update. We can of course live with 64 I/Os. 100 pin package with greater pin spacing is good. Are you still implementing a ground plane connection on the underside of the IC?
More RAM · I presume this is hub Ram.
Are you still implementing the extra port(s)·internally so we could do·32bit cog to cog mailbox/comms or whatever?
Is the design now frozen? Can you release any other info pls?
Do you have a timeframe estimate to first silicon yet?
@hinv: Like many others, I see that the choice of not asking for the Prop IB was a mistake. At the time, although many recognised that we wanted more ram, so much development has occurred since then making a lot more programs require more pins & external SRAM.
Anyway, I guess it's too late now, although I do see that it would still have it's own market, particularly from a power standpoint. It could be incorporated back into the 40/44 pin packages so that we could access the extra port internally. Unfortunately, we have ignored the Port B access method, so some software would now break with the implementation of Port B.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Roy Eltham said...
TonyD,
Sorry for my mistake. It was really hard to tell with the low quality video, and I was going by the text in the blog that just said something like "I had the DAC hooked up backwards" which led me to believe it was a DAC chip. In any case the video shows what looks like a lot more than 8 resisters and a VGA port hooked up to the xmos board (which I looked up on their site as being $149, and the cheapest one they had was $99).
No problem. Yvo (who wrote the video driver) wired the port signals back to front, so the colours came out all wrong
The DAC was a 15-bit R-2R so used 30 resistors and gave us 32K colours. The board we used was the Ethernet enabled board which cost $150, there are cheaper boards out there Sparkfun have one at $50 but you need a JTAG interface which costs $50.
Getting back to the thread. As Cluso99 said, if we only getting 64-pins will we still have the ground pad/paddle under the chip? I hope we lose it as it will make hand soldering a lot easier.
I am 100% with Cluso99.
There are many ways IO can be expanded, is better to have more ram.
The internal-use-only extra port will be fantastic !!! This will allow inter-cog comunications without hub access and thus faster, but what is more important without loosing (gained) sync with external environment.
@TonyD: I've not done it, but from what I have watched on a youtube video somewhere as long as you have 2 holes under the big ground pad, is not a big deal. You would need one hole to stick your wet solder iron in, and another one to add some solder.
@dMajo, Chip, Beau: I didn't see them commit to the internal portC, but I sure would like to see it. It go a long way to appeasing those who wanted more bandwidth to certain cogs.
Oh, and while you're at it. I would like to see P0 on a corner and exactly 16 I/Os per side(if 64I/Os total), and cheap stickers offered with each and every prop (on the same web oder page for like $.10).
That's how I solder the pad on a QFN. I only use one large via, though. I only do that for prototypes, of course; production boards are done properly and need a gridded stencil to prevent the chip floating when it is reflowed.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Here is the current 100 pin package outline ... as far as your internal PortC question since there are 64 I/O's technically there are external Ports A,B,C, and D. The internal Port assignment I'll leave for Chip to answer, but I'm almost sure this will be implemented.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Nice footprint to PropII but that give P31, P32 bad place that can be big problems for XI, XO if P31, P32 is used in high frequncy modes.
In that case can give Xi, XO posibilites to transcients from P31, P32.
Look on my reedited picture it is placements of pins I see more reliable for high reliablity for XI, XO.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
"this means more room for ram" - I am officially drooling. You were already going to have 384KB... 512KB would be insanely great [noparse]:)[/noparse]
A few questions...
- On 100 pin TQFP, a lot more than 64 I/O's would be possible... are you considering perhaps 2x32 pin ports, and a 1x16 bit port for SPI, I2C etc?
- If it is 2x32 and 1x16 (which makes sense on a TQFP-100) could the other 16 bits be implemented internally? It would be great for cog-cog flags
- If there will only be 64 I/O's on the silicon, could you please look into a PLCC84 package? It would make prototyping MUCH easier, and through-hole PLCC84 sockets are readily available, allowing for through-hole designs
- If there are only 64 I/O's, I'd strongly prefer going back to the existing PORTA / PORTB mapping in Cog memory, as it would not require switching a port index to update ports, speeding up external memory solutions
Chip Gracey (Parallax) said...
PropII is shaping up now to have 64 I/O's, not the 96+ as previously stated. The reason has to do with packaging constraints. We met with our packager in Taiwan a few weeks ago about this matter, and what we wanted to do was, in simplistic terms, "very difficult". The problem was not so much technical as it was economic. We would need a special lead-frame and maybe even new injection molds to accommodate them. The tooling costs would be quite high to get that going. Even if we paid the tooling costs, I sensed they were somewhat loathe to run it because it would mean changing tooling out on their molding machine when they'd run our stuff, as opposed to leaving the standard tooling in place, and not worrying about QC problems due to switchovers. They strongly recommended that we fall back to one of their standard packages, so we cut down the lead count down to 100 and went with a larger pitch. This will make things a little easier for some customers and keep us from becoming a pain in our packager's neck. They are very volume-oriented and have always given us excellent pricing, even though we are a peon among their other customers.
Also, the I/O pin circuits have become so large that fitting much more than 16 per die edge would have made the die huge. Now, Beau is rearranging the I/O pin layout so that it is wider than it is tall. This will let us squish them out sideways so that interior core area is freed up. This means more room for RAM.
While 96+ I/O's would have been quite rich, I feel we are on a better completion path with just 64. I'm getting kind of punch drunk and need to see some light at the end of the tunnel, anyway. Currently, things are feeling quite "right", as opposed to overwhelming.
I'm creating a PCB part for it (Pulsonix). I've got a spreadsheet with the signals and pin numbers that I can just paste into the part editor. I'll make it available if anyone else wants it.
Roy: I am presuming that the VP0-7 and GP0-7 are the power and grounds to each bank of I/O pins (a bank is 8 pins) as per chips previous info that each group of I/Os will have seperate power so they can have different voltages.
Bill: There are 16 power & ground pins and 16 I/O power & ground pins = 32, 2 xtal + reset + BOE = 4, 64 I/O = 64, totalling 100 pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Roy: I am presuming that the VP0-7 and GP0-7 are the power and grounds to each bank of I/O pins (a bank is 8 pins) as per chips previous info that each group of I/Os will have seperate power so they can have different voltages.
Bill: There are 16 power & ground pins and 16 I/O power & ground pins = 32, 2 xtal + reset + BOE = 4, 64 I/O = 64, totalling 100 pins.
Cluso99,
Ah, thanks. That makes sense now, as I recall from earlier postings, the I/Os run at 3.3v and the chip itself runs at 1.8v. So, they need separate power/ground for the I/Os.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Actually, the I/Os can run at 1.8V, 3.3V, or anything in-between, if I understand correctly. Can someone clarify this? I would, but my search capability went away.
Anybody that has done chip development want to throw out a guess as to when the TurboProp could go into production considering they layout they are doing now? Maybe I will hold off my purchase of an IGEPv2.
For the power, that is correct. As for the naming, I've learned not to question some of the names that Chip gives to the layout blocks. And to your other question "Anybody that has done chip development want to throw out a guess as to when the TurboProp could go into production..." ... sorry to be so vague, but anyone who has done chip development would know better than to answer this question. The development process is always in constant flux with many implementations coming from suggestions here in the forum. We do listen very carefully to ALL of your needs and suggestions and try to accommodate to the best of our ability what will physically "fit" into the design as well as the level of complexity that will "fit" into the design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
@Chip: Thanks for the update. We can of course live with 64 I/Os. 100 pin package with greater pin spacing is good. Are you still implementing a ground plane connection on the underside of the IC?
Instead of one nice big, fat ground plate, we'll bring out all the separate grounds and you can tie them together at the PCB level.·If we lumped all the grounds together·ON the die (higher-Z), instead of using·lower-Z off-die connections (bottom plate or discrete ground pins), analog performance would be compromised.
More RAM · I presume this is hub Ram.
Yes. It's going to be a matter of how much can fit. I'm hoping for 384KB. The cogs are more complicated this time around, though, so they are going to take up some space, too.
Are you still implementing the extra port(s)·internally so we could do·32bit cog to cog mailbox/comms or whatever?
That is easy to do, but it feels like kind of a kludge.
Is the design now frozen? Can you release any other info pls?
After a multi-month detour to finalize the I/O pins, I'm back on FPGA stuff now. There are several small things that need some finalizing before the final schematic can be made. Then, Beau will have a giant Lego project to work on. All the building blocks are designed and laid out already. We've just got to put them all together.
Do you have a timeframe estimate to first silicon yet?
No.
@hinv: Like many others, I see that the choice of not asking for the Prop IB was a mistake. At the time, although many recognised that we wanted more ram, so much development has occurred since then making a lot more programs require more pins & external SRAM.
Anyway, I guess it's too late now, although I do see that it would still have it's own market, particularly from a power standpoint. It could be incorporated back into the 40/44 pin packages so that we could access the extra port internally. Unfortunately, we have ignored the Port B access method, so some software would now break with the implementation of Port B.
- On 100 pin TQFP, a lot more than 64 I/O's would be possible... are you considering perhaps 2x32 pin ports, and a 1x16 bit port for SPI, I2C etc?
Because of power and ground pin needs, not to mention die real estate, I think 64 I/Os is going to fill things up. S we're heading for 2x32-bit I/O ports with 2x32-bit internal ports.
- If it is 2x32 and 1x16 (which makes sense on a TQFP-100) could the other 16 bits be implemented internally? It would be great for cog-cog flags
- If there will only be 64 I/O's on the silicon, could you please look into a PLCC84 package? It would make prototyping MUCH easier, and through-hole PLCC84 sockets are readily available, allowing for through-hole designs
I don't see where we can give up 16 pins in a way that spreads around the die.
- If there are only 64 I/O's, I'd strongly prefer going back to the existing PORTA / PORTB mapping in Cog memory, as it would not require switching a port index to update ports, speeding up external memory solutions
I see your point, but it would, on the other hand, force you into self-modifying code for pin parameters, whereas with the current scheme, you just select a port number from bits 6,5 of a variable, while bits 4..0 can provide the bit number. This keeps things simple, though I understand your rationale for wanting discrete port addresses.
Cluso said...
Are you still implementing the extra port(s)·internally so we could do·32bit cog to cog mailbox/comms or whatever? Chip replied... That is easy to do, but it feels like kind of a kludge. and... Because of power and ground pin needs, not to mention die real estate, I think 64 I/Os is going to fill things up. S we're heading for 2x32-bit I/O ports with 2x32-bit internal ports.
·Internal ports·is what I meant, so that will be fantastic ·· You can bet we will find lots of uses for these
Ale: my understanding was that each group of 8 pins was to be seperately powered and this would fit the layout.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Internal ports is what I meant, so that will be fantastic You can bet we will find lots of uses for these
Could someone explain about the internal I/O ports (I'm a bit confused)? Would these be spare ports ready to bring out if a bigger IC package is used? or have some other use I've missed?
TonyD: They are just extra I/O ports which do not have the pad circuitry in the chip. We could use them for communication, indication, etc, between cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
May I suggest to swap the XO/XI with RESn/BOEn pins?
This would make the layout for the PropPlug connector much easier (Res, P31, P30 near to each other).
On Prop1 I always have problems to route the reset line around half the Print, because it is in the opposite side from the P31/P30 pins.
Comments
Much as I drool (not a pretty sight!) at the though of the Prop II, I agree with you completely - many of the projects being built around the Prop I right now would benefit enormously from a PortB Prop. Some of the emulation and XMM projects would benefit even if Parallax just implemented Port B internally but did not make all the pins accessible externally. Imagine what we could do with superfast cog-to-cog parallel comms that did not consume any I/O pins!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Also, the I/O pin circuits have become so large that fitting much more than 16 per die edge would have made the die huge. Now, Beau is rearranging the I/O pin layout so that it is wider than it is tall. This will let us squish them out sideways so that interior core area is freed up. This means more room for RAM.
While 96+ I/O's would have been quite rich, I feel we are on a better completion path with just 64. I'm getting kind of punch drunk and need to see some light at the end of the tunnel, anyway. Currently, things are feeling quite "right", as opposed to overwhelming.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/8/2010 6:54:49 AM GMT
There are two reasons why the XMOS threads fail to be as deterministic as the Propeller COGs.
1) Adding a second thread to a one thread set up halves the speed of the first thread. Has too. Same if you add a thread to two thread system. So unlike the Prop adding another object into your system can change the timing of the existing parts of the system.
2) Turns out XMOS divide instructions take longer to execute than other instructions. This means that if one thread suddenly decides to do a divide it will bugger up the timing of any other threads running.
I had a little debate about determinism with David May the CTO of XMOS over the Christmas break where he had to admit: "So - there is potential interference between divide instructions in different threads"
So that's it for determinism on XMOS. You cannot do it by simple cycle counting of instructions.
What you are supposed to do is make proper use of the various timing features of the device. Use the clocked I/O itc.
In this way multiple threads can exist with totally deterministic timing in a single core.
It is somewhat harder than just throwing objects at COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
More RAM
Are you still implementing the extra port(s)·internally so we could do·32bit cog to cog mailbox/comms or whatever?
Is the design now frozen? Can you release any other info pls?
Do you have a timeframe estimate to first silicon yet?
@hinv: Like many others, I see that the choice of not asking for the Prop IB was a mistake. At the time, although many recognised that we wanted more ram, so much development has occurred since then making a lot more programs require more pins & external SRAM.
Anyway, I guess it's too late now, although I do see that it would still have it's own market, particularly from a power standpoint. It could be incorporated back into the 40/44 pin packages so that we could access the extra port internally. Unfortunately, we have ignored the Port B access method, so some software would now break with the implementation of Port B.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The DAC was a 15-bit R-2R so used 30 resistors and gave us 32K colours. The board we used was the Ethernet enabled board which cost $150, there are cheaper boards out there Sparkfun have one at $50 but you need a JTAG interface which costs $50.
Getting back to the thread. As Cluso99 said, if we only getting 64-pins will we still have the ground pad/paddle under the chip? I hope we lose it as it will make hand soldering a lot easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
Post Edited (TonyD) : 2/8/2010 11:18:32 AM GMT
There are many ways IO can be expanded, is better to have more ram.
The internal-use-only extra port will be fantastic !!! This will allow inter-cog comunications without hub access and thus faster, but what is more important without loosing (gained) sync with external environment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
@dMajo, Chip, Beau: I didn't see them commit to the internal portC, but I sure would like to see it. It go a long way to appeasing those who wanted more bandwidth to certain cogs.
Oh, and while you're at it. I would like to see P0 on a corner and exactly 16 I/Os per side(if 64I/Os total), and cheap stickers offered with each and every prop (on the same web oder page for like $.10).
Post Edited (hinv) : 2/8/2010 4:05:43 PM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Here is the current 100 pin package outline ... as far as your internal PortC question since there are 64 I/O's technically there are external Ports A,B,C, and D. The internal Port assignment I'll leave for Chip to answer, but I'm almost sure this will be implemented.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Nice footprint to PropII but that give P31, P32 bad place that can be big problems for XI, XO if P31, P32 is used in high frequncy modes.
In that case can give Xi, XO posibilites to transcients from P31, P32.
Look on my reedited picture it is placements of pins I see more reliable for high reliablity for XI, XO.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
What are VP0-7 and GP0-7?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
One observation:
"this means more room for ram" - I am officially drooling. You were already going to have 384KB... 512KB would be insanely great [noparse]:)[/noparse]
A few questions...
- On 100 pin TQFP, a lot more than 64 I/O's would be possible... are you considering perhaps 2x32 pin ports, and a 1x16 bit port for SPI, I2C etc?
- If it is 2x32 and 1x16 (which makes sense on a TQFP-100) could the other 16 bits be implemented internally? It would be great for cog-cog flags
- If there will only be 64 I/O's on the silicon, could you please look into a PLCC84 package? It would make prototyping MUCH easier, and through-hole PLCC84 sockets are readily available, allowing for through-hole designs
- If there are only 64 I/O's, I'd strongly prefer going back to the existing PORTA / PORTB mapping in Cog memory, as it would not require switching a port index to update ports, speeding up external memory solutions
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
[noparse][[/noparse]edit]
Here it is: www.leonheller.com/Propeller/Propeller%20II%20pinout.xls
Please let me know if you see any mistakes.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/8/2010 6:01:44 PM GMT
So is TurboProp the official name, or has "marketing" not decided yet?
Bill: There are 16 power & ground pins and 16 I/O power & ground pins = 32, 2 xtal + reset + BOE = 4, 64 I/O = 64, totalling 100 pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Ah, thanks. That makes sense now, as I recall from earlier postings, the I/Os run at 3.3v and the chip itself runs at 1.8v. So, they need separate power/ground for the I/Os.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Anybody that has done chip development want to throw out a guess as to when the TurboProp could go into production considering they layout they are doing now? Maybe I will hold off my purchase of an IGEPv2.
Thanks,
Doug
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
work with and has been around for awhile.
Is there still a DAC & ADC on each I/O pin, this seems like kinda a waste of space to me.
Russ
For the power, that is correct. As for the naming, I've learned not to question some of the names that Chip gives to the layout blocks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
www.leonheller.com/Propeller/Propeller%20II.pdf
I've used several gates for the part instead of a single square symbol. It took longer to create it, but it will make schematics easier to follow.
All I need now is a chip or two.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/8/2010 9:52:44 PM GMT
Chip Gracey
Parallax, Inc.
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Ale: my understanding was that each group of 8 pins was to be seperately powered and this would fit the layout.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Could someone explain about the internal I/O ports (I'm a bit confused)? Would these be spare ports ready to bring out if a bigger IC package is used? or have some other use I've missed?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
This would make the layout for the PropPlug connector much easier (Res, P31, P30 near to each other).
On Prop1 I always have problems to route the reset line around half the Print, because it is in the opposite side from the P31/P30 pins.
Andy