That's neat, Peter. About the same outline as the inner square on the Prop Proto boards. If you swapped the VDD and VSS over at the top right, it would be compatible i think
Chip's recent comment about up to 2 watts (600mA) makes me think the Vdd traces might need to be as thick as we dare, we well as heatsinking on the back where possible.
That's neat, Peter. About the same outline as the inner square on the Prop Proto boards. If you swapped the VDD and VSS over at the top right, it would be compatible i think
Chip's recent comment about up to 2 watts (600mA) makes me think the Vdd traces might need to be as thick as we dare, we well as heatsinking on the back where possible.
I will take a look at the Prop proto to see if I can make it more compatible with it. As I said the adaptor is incomplete in that I just want to see how it can connect and absolutely for sure the ground and power copper will be beefed up considerably. It might even mean having to take the power and ground to the inner pads rather than trying to snake through to the edge and I could even decide to just push in between the I/O on each side so that the power and ground are centered. All this while I try to keep it double-sided only.
BTW, I can never find matrix protoboards that tick all the boxes, most of them think it's a good idea to run tracks along the pads so that you have to cut them when it is so much easier just to join up the ones you want in the first place. Then they might even be plated through but not have pads on the other side or they run power rails that limit where you can place components. So my matrix board addresses all this by having uncommitted plated through 38mil holes that take pin headers with ease and while power rails are useful they also get in the way. What I did was run power traces in between the pads with 25mil vias at the intersections so I can have quick and easy connection to rails without then getting in the way.
I had to look for a while onto your image until it hit me. This is a very cool idea. Are the rails on the interconnection also thru hole or how I would solder to them?
Or is the idea to just drag the solder blob to the interconnection to supply VDD or VSS on the pad?
I had to look for a while onto your image until it hit me. This is a very cool idea. Are the rails on the interconnection also thru hole or how I would solder to them?
Or is the idea to just drag the solder blob to the interconnection to supply VDD or VSS on the pad?
The vias have 25mil holes so they will take components leads and wires of course.
So my matrix board addresses all this by having uncommitted plated through 38mil holes that take pin headers with ease and while power rails are useful they also get in the way. What I did was run power traces in between the pads with 25mil vias at the intersections so I can have quick and easy connection to rails without then getting in the way.
That all makes sense, until you look at the 2nd (wayward?) via down, from top right.
... All this while I try to keep it double-sided only.
It's a good idea to check how 2 layers route, but for a protoboard that can end up driving cables, and more C than a final PCB, the incremental cost of 4 layer is quite low on a board of such small area.
Plus, I like to 'approach from above', where some over-design initially can be checked later - on a P2, that would mean top and bottom side under-chip decoupling, and poured inner planes, maybe in thicker copper too.
Someone is always going to want to overclock these too
That all makes sense, until you look at the 2nd (wayward?) via down, from top right.
It's a good idea to check how 2 layers route, but for a protoboard that can end up driving cables, and more C than a final PCB, the incremental cost of 4 layer is quite low on a board of such small area.
Plus, I like to 'approach from above', where some over-design initially can be checked later - on a P2, that would mean top and bottom side under-chip decoupling, and poured inner planes, maybe in thicker copper too.
Someone is always going to want to overclock these too
Don't look too close at the screenshot, it's only a sample as I am changing things around every time I look at it and in this section I quickly wanted to see how it would look if I removed every second via so that I could run horizontally as well as vertically. But the final one will be clean obviously!
The P2 adaptor may indeed end up multilayed if need be and it is possible that I will allow for decoupling on top of the board as well as an oscillator but the bottom has to be unpopulated so that if desired the adaptor can be soldered directly to the matrix. Some may choose to put connectors on it but if the chip is blown it's blown, just cut the pins, swipe off with a wet iron, and redo it.
I did up the P2 for Protel schematic and PCB a while ago and have it designed into a pcb that I just haven't had time to finish. The PCB will be using a BeMicroCV-A9 to emulate the P2 until one day hopefully the chip is ever ever available (there's ALWAYS some little thing being added). I also have a special proto board that fits a particular case I use and to facilitate prototyping with SMD I have a whole range of adaptors that are designed to just sit on top of the matrix board and be soldered through, no pins.
Anyway, here is a screen shot of the P2 footprint that I did alongside the 80-pin MEC connector from the CVA9. There's also an incomplete P2 prototyping adaptor as well.
It is a nice solution there Peter. If the P2 is only offered in a 0.5mm pitch, that would be a nice solution for an industrial setup, once the chip is heavily potted.
I agree that neither the P2 or the P1 would ever compete with some of the single chip microcontrollers on a price basis. It's my ignorance of the chip design process that has me asking some of the silly questions I'm asking.
My introduction to Parallax came many years ago when I was working with the Scenix SX chips. They were a great little processor for many applications. This particular application was a controller for a marking system. Only a few thousand machines were sold, but a few thousand chips here and there embedded into consumer products might go a long way for the bottom line of some companies.
A single (32bit) cog of the P1 with on-chip flash memory and in-system programming might have been a nice next-step-up replacement for the SX. I know that there are designs I WOULD have done with it had it been available.
The P2 with 16 cogs is going to be an incredible high performance rocket for applications needing that kind of horsepower, but many, many of the day to day embedded designs for consumer products like toasters and toys ( where often tens or hundreds of thousands of chips go) can't justify ANY extra cost when the saving of a single dollar can represents a hundred thousand dollars in profit or loss.
When the P1 first came out, I desperately tried to design it into a controller for a company making screen printers for T-shirts. At $6.00 per chip in quantity ( I think at the time) + the support chips, my bid for the board was about $5.00 more expensive than the PIC board I lost the design to. The SX didn't have QUITE the horsepower I needed, the P1 just didn't fit, but one or two cogs of the P1 with on chip memory would have done the job nicely. This is the reason there are so many variations of the PIC, TI430 and other such processors: those little "Niche" applications.
Chip's time is RIGHTLY being invested in developing a wonderfully capable NEW design, but if my very limited understanding of the design process is anywhere near correct... the CODE that compiles into a P2 cog is like a software subroutine that becomes a "tool" in a toolkit that COULD be reused for other designs many years into the future. I'm not smart enough to use 16 cogs in a design. I've never even used all 8 of the P1's cogs. I have used up to six, but the norm is more like two or three. My WISH is for two to four of those wonderfully capable P2 cogs in a small, inexpensive package that I CAN justify embedding into new designs.
Working for Hamilton Avenet back in the dark ages, I introduced many companies to the 8051 microcontroller. 36 years later, there are HUNDREDS of variants of this original chip currently in production still making money for the companies producing them.
Once the P2 is a functional part, Chip's time will again ( probably, and rightfully) be invested in a P3 ( if he should be so inclined...) but from a company stand-point, if it was possible to have another designer take his code and "Cut and paste" a cog or two and a few smart-pins ( and some on-chip boot memory ) into something for the lower end embedded market... I believe that Parallax could amortize some of the incredible time/dollar investment behind the P2 into some "workhorse" chips that might still be making money 20 or 30 years from now.
The FACT that the P1 had software provisions for an additional 32 bit port led me (over ten years ago) to believe (however foolishly) that there would be (much needed) variants of the Prop that would have it. I assumed ( yes... I know ) that the serial start-up nature of the P1 would be followed by some single chip version with on-board boot memory for applications where price, footprint, and rapid startup was critical. BECAUSE IT MADE SO MUCH SENSE THAT THESE WOULD BE THE NEXT STEPS!
Chip is the genius behind the company and his time should be invested wherever he "darn-well" feels like it... but I hope that the BUSINESS pros there at Parallax will consider that there are old-farts like me out here who appreciate your ethics and openness with the community of loyal followers and would in turn love to be "Loyal" to parallax but CAN'T because of technical needs that seem likely could have been introduced into the P1 "Family" of processors sometime over the last ten years.
Many of the "Propeller Superstars" out there want and need the adrenaline rush capability of the latest, greatest things that can be stuffed into the newest bleeding edge processor. I may WANT some of these things from the sheer joy for a wonderful new toy, but most of my ACTUAL engineering needs are more for low cost, reliability and long term product life.
Long term product life for nearly every other successful microprocessor has come from offshoots that fill those niches that the original chip didn't quite fit.
The fact that there is no "Family" of Propeller chips is my biggest concern about and for the future of Parallax. We're ten years down the road and still waiting for the first offshoot.
Build the P2 and make it WONDERFUL! I can hardly wait! ... but please, have some pity on some of us dimmer bulbs out here in the Parallax sky... and consider some of our more prosaic but real needs over the future years.
The Prop1'A' with 64 I/O would have happened but for a problem with ageing tool compatibility I think it was. Chip decided to move on to the Prop2 instead.
Prop2 is using fully up-to-date tools so when the time is right there shouldn't be any compatibility issues with rolling out another model variation of the Prop2. Or an up-spec'd Prop3 for that matter.
Pricing is always a chicken or egg problem. Luckily, Parallax isn't competing head-to-head with Microchip.
Working for Hamilton Avenet back in the dark ages, I introduced many companies to the 8051 microcontroller. 36 years later, there are HUNDREDS of variants of this original chip currently in production still making money for the companies producing them.
Indeed, and not only is the 8051 still in use, it is still seeing active development.
The 8 bit MCU market is doing better than all those jumping on the 32b bandwagon hope, yes, it is seeing some rationalise as the fringe 8b cores decline, but ST recently claimed their second billion of STM8, with strong sales in China.
STM8 is not 8051, (but has roots almost as far back), but plenty of Asian vendors have 8051 parts, and some have core-redesigns being done to process opcodes in a wider fashion (24b opcodes).
The new SiLabs EFM8 series target STM8 prices, with more variants (Speed to 72MHz, ADC to 14b).
.. but from a company stand-point, if it was possible to have another designer take his code and "Cut and paste" a cog or two and a few smart-pins ( and some on-chip boot memory ) into something for the lower end embedded market... I believe that Parallax could amortize some of the incredible time/dollar investment behind the P2 into some "workhorse" chips that might still be making money 20 or 30 years from now.
Interesting point, and certainly possible when P2 is out of FAB, and proven.
On-chip code memory is a difficult one.
P2 already has a boot ROM, & then loads CODE from SPI Flash.
On Chip flash sounds nice, but brings some baggage - it bumps the processing cost and layers, and it (severely) limits speed.
One key feature of P2 is very fast, deterministic cores, and it does that by running from RAM.
Possible ways around this, are to follow Nuvoton, and include a SPI die in package, or follow new FTDI (FT51,FT9xx) and have some CODE memory storage that is loaded into RAM.
"lower end embedded market" can mean many things, but I doubt P2 variants will ever be in the sub $1 or even sub $2 sandpits.
It does not need to be, P2 provides the real time side of control, and will often be used alongside some larger device running an Operating System.
For the more grain of rice end, like sensor gathering, P2 will talk to those sub $1 MCUs, often hidden inside sensors.
The new USB feature means P2 will see good use as 'smart hub', where it can collect a series of cheap USB peripherals, in a smarter way, for an upstream PC/OS-end host.
On-chip code memory is a difficult one.
P2 already has a boot ROM, & then loads CODE from SPI Flash.
On Chip flash sounds nice, but brings some baggage - it bumps the processing cost and layers, and it (severely) limits speed.
One key feature of P2 is very fast, deterministic cores, and it does that by running from RAM.
Indeed, and to add, Flash has also the problem of write cycles limitation. That would mean that an on die Flash would not be replaceable and, ultimately, the Propeller chip would have to be replaced in case of a Flash failure. With an external Flash or EEPROM memory, I can easily replace that failing part without tossing away an otherwise functional micro-controller. Also, I can always opt between Flash or EEPROM, as I do prefer the latter for its endurance.
I don't know enough about the manufacturing technologies to know what options would or wouldn't make sense. However... theP2 will already have a boot Rom. Not in the FIRST chip... but perhaps a second version might be done with enough unused rom space that custom code could easily be embedded there. It might make sense to "Keep it in mind" in case something could easily be reserved in the design or memory space that might not be so easy to "Undo" later.
None of MY applications will ever have high enough volume to justify paying for a custom chip run, however, many companies do.
My largest customer established policies against paying for software that could be developed internally. They purchased a software development group in Sweden to rewrite the control code for the machines they sold that had software requiring royalty payments. This cut me out of a considerable ongoing revenue stream.
However... I was a valuable, albeit external, part of their design team. The company had no policies against paying for custom hardware and the machines I designed used an SX chip as part of the control package, so... BECAUSE OF INTERNAL POLITICS, they worked a deal with me where I supplied them a VERY expensive, but pre-programmed SX microcontroller for each machine sold.
As stupid as this may sound, I suspect this sort of thing is reasonably common and giving engineers THE ABILITY TO ADD VALUE TO THE HARDWARE can affect which processor does or doesn't get designed into new products NO MATTER WHAT TECHNICAL CAPABILITY a processor may have.
The "Hooks" in the code to easily jump into (future) additional internal OTP rom might lead to more high volume sales.
As far as flash memory goes, yes, due to the limited life-cycles, you would never want to use it as part of the operational memory, but as a tool for development and booting an operational program, it works pretty well. One of my manufacturing machines has a Prop on it that I have been using for about 7 years. I turn it off and on several times a day. I make minor program changes every once in a while. I've probably programmed the EPROM a thousand times or more... and it still seems to be going strong.
In THIS particular application, a couple of seconds in start-up isn't a big deal, however... I used to work in flight test, and I GUARANTEE you, in some instances, you want your electronics to "Get-to-gettin" ASAP! The incredible speed of a processor can be almost irrelevant if the time it takes to "Start thinking about stuff" takes too long. You't be amazed at how long three seconds in uncontrolled flight can seem.
We are used to waiting for our laptops to take a while to boot... but we are NOT used to our cars "thinking about it for a while" before the engine starts. THESES REAL-WORLD-CONTROL APPLICATIONS ARE EXACTLY WHAT THE PROP(S) EXCEL AT! However, the longer and more complex programs become, the less viable serial loading is going to be for many embedded control applications.
If the POSSIBILITY of future versions of the P2 ( or even the P1) having rapid start up (i.e. internal boot memory) is there, it should be planned for because there are thousands of applications where it is an essential part of a design and not being there will cost both Parallax and loyal engineers many lost designs.
These are only MY two cents worth... and probably not worth what you are paying for them... however as someone who loves MOST of the P1 and appreciates Parallax and this community of people out here, I would feel remiss not to have said some of these things if they MIGHT have made a difference down the road. I don't want to delay the introduction of the P2 by as long as it might take Chip to read my ramblings, but if any of it makes sense, I hope that SOMEONE there at Parallax will keep these things in mind when it's time to consider long-term planning.
I don't know enough about the manufacturing technologies to know what options would or wouldn't make sense. However... theP2 will already have a boot Rom. Not in the FIRST chip... but perhaps a second version might be done with enough unused rom space that custom code could easily be embedded there. It might make sense to "Keep it in mind" in case something could easily be reserved in the design or memory space that might not be so easy to "Undo" later.
None of MY applications will ever have high enough volume to justify paying for a custom chip run, however, many companies do.
My largest customer established policies against paying for software that could be developed internally. They purchased a software development group in Sweden to rewrite the control code for the machines they sold that had software requiring royalty payments. This cut me out of a considerable ongoing revenue stream.
However... I was a valuable, albeit external, part of their design team. The company had no policies against paying for custom hardware and the machines I designed used an SX chip as part of the control package, so... BECAUSE OF INTERNAL POLITICS, they worked a deal with me where I supplied them a VERY expensive, but pre-programmed SX microcontroller for each machine sold.
As stupid as this may sound, I suspect this sort of thing is reasonably common and giving engineers THE ABILITY TO ADD VALUE TO THE HARDWARE can affect which processor does or doesn't get designed into new products NO MATTER WHAT TECHNICAL CAPABILITY a processor may have.
The "Hooks" in the code to easily jump into (future) additional internal OTP rom might lead to more high volume sales.
As far as flash memory goes, yes, due to the limited life-cycles, you would never want to use it as part of the operational memory, but as a tool for development and booting an operational program, it works pretty well. One of my manufacturing machines has a Prop on it that I have been using for about 7 years. I turn it off and on several times a day. I make minor program changes every once in a while. I've probably programmed the EPROM a thousand times or more... and it still seems to be going strong.
In THIS particular application, a couple of seconds in start-up isn't a big deal, however... I used to work in flight test, and I GUARANTEE you, in some instances, you want your electronics to "Get-to-gettin" ASAP! The incredible speed of a processor can be almost irrelevant if the time it takes to "Start thinking about stuff" takes too long. You't be amazed at how long three seconds in uncontrolled flight can seem.
We are used to waiting for our laptops to take a while to boot... but we are NOT used to our cars "thinking about it for a while" before the engine starts. THESES REAL-WORLD-CONTROL APPLICATIONS ARE EXACTLY WHAT THE PROP(S) EXCEL AT! However, the longer and more complex programs become, the less viable serial loading is going to be for many embedded control applications.
If the POSSIBILITY of future versions of the P2 ( or even the P1) having rapid start up (i.e. internal boot memory) is there, it should be planned for because there are thousands of applications where it is an essential part of a design and not being there will cost both Parallax and loyal engineers many lost designs.
These are only MY two cents worth... and probably not worth what you are paying for them... however as someone who loves MOST of the P1 and appreciates Parallax and this community of people out here, I would feel remiss not to have said some of these things if they MIGHT have made a difference down the road. I don't want to delay the introduction of the P2 by as long as it might take Chip to read my ramblings, but if any of it makes sense, I hope that SOMEONE there at Parallax will keep these things in mind when it's time to consider long-term planning.
KB
KB, thanks for your comments. I have been thinking, too, that rapid start up is something we really need in the Prop 2. Between SPI flash chips, synchronous serial smart pins, and variable length loading, we should be able to start within a second of power-on.
You't be amazed at how long three seconds in uncontrolled flight can seem.
What flight systems are you talking about?
My experience, with such things as the Boeing 777, is that there are at least three compute nodes flying the plane. If any one of them fails or reboots nobody notices. Apart from a red light coming on some place. If they all fail in flight you have a much bigger problem than the boot time.
I'm not saying that a fast start up is not desirable though.
... I have been thinking, too, that rapid start up is something we really need in the Prop 2. Between SPI flash chips, synchronous serial smart pins, and variable length loading, we should be able to start within a second of power-on.
The variable length loading should allow much less than one second of power on ?
Maybe a spec for TTL1 (Time to load/launch one COG) would be useful here.
Some MCUs have a pin to enable/disable UART boot, which speeds the decision tree.
QuadSPI memory, streaming at say 48MHz in a second stage boot, can stream 24MB/s, which is ~10ms to load a 50% memory image, or just over 1ms to load 16 Full COGS contents.
However... theP2 will already have a boot Rom. Not in the FIRST chip... but perhaps a second version might be done with enough unused rom space that custom code could easily be embedded there.
I think your terminology is a little off here.
The first P2 certainly will have a BOOT ROM, otherwise it can never start. The FPGA images already have that, otherwise they can never load code normally.
The "Hooks" in the code to easily jump into (future) additional internal OTP rom might lead to more high volume sales.
Now you have made two leaps, to user ROM and also OTP
Even with present P2 mask ROM, user ROM is possible, in theory, but would need a manufacturing flow change, so MOQs on that come with a lot of zeros.
OTP is interesting middle ground, cheaper than flash, and is more of a process question for OnSemi.
Quite a few parts use OTP, (or something less than Full Flash), and in some forms that does have low added fabrication costs.
That comes down to the IP.
There are still plans, I think, for Fuses & Security in P2, unclear what form / size those are now, but those could share OTP flows, with the added caveat they need normal Vcc operation.
OTP would make user-ROM designs much more feasible, but including that is a Parallax-OnSemi discussion.
Some MCUs have a pin to enable/disable UART boot, which speeds the decision tree.
Since the P2 is not a single core processor, one cog can start loading immediately and the other can wait for UART boot. If the UART cog detects a computer wanting to program the chip, it will kill the loading cog, load the new program, and then start the main program in cog 0 (and then stop itself). If the UART cog detects no computer after some timeout, it will signal the loading cog that it's OK to start running the loaded code and then it will stop itself.
Since the P2 is not a single core processor, one cog can start loading immediately and the other can wait for UART boot. If the UART cog detects a computer wanting to program the chip, it will kill the loading cog, load the new program, and then start the main program in cog 0 (and then stop itself).
Interesting idea, tho I think not how the present boot works ?
If the UART cog detects no computer after some timeout, it will signal the loading cog that it's OK to start running the loaded code and then it will stop itself.
That seems to be the problem unsolved, as you still wait until after that timeout, before you 'start run'.
For other ideas to shorten decision trees, I think tying the RxD low was one mentioned.
Boot then assumes some min baud, and if LOW exceeds that char time, it can quickly skip UART. (eg >= 78us at 115200, plus margins)
No extra pins, but does need a HW jumper.
This should give sub 250us TTL1 load times ?
And/Or, you can have Host stream chars at around the USB turn around rate (no point going faster) and when host sees a Boot-echo, it starts the real download preamble.
Bootloader knows it should have data with small max char spaces, so can make 'no data' decision earlier.
This needs margins for USB + OS, so maybe sub 20ms? sub 5ms? is possible ?
I used to work in the autopilot STC ( Supplemental Type Certificate) group at King Radio ( Now Bendix King). Part of my job was to insert failures into the autopilot to simulate the worst failure it was possible for the autopilot to experience ( a servo drive motor shorted full on ). We had to let the airplane do whatever it was going to do (hands off) for 3 seconds before attempting recovery to simulate the possible delay time before a pilot might notice the failure. Roll failures weren't all that big a deal, but elevator failures could get really interesting, particularly since testing had to be done throughout the entire flight envelope. The worst "Failure" was a DOWN failure at maximum altitude, Vmax ( top speed) and maximum, full aft loading. ( One flight in particular comes to mind...)
There were no "Little red lights"... in a small plane with a single autopilot, when it fails, it often notifies you in very exciting ways. Our job was to make sure that the excitement for "Joe Average Pilot" was kept to a minimum... but OUR failures were sometimes right out there on the edge.
It was a fun job... but roller coasters were never quite the same after that.
Oh no! Worse than Flash is OTP ROM. If you mess up the fuses, that means that the chip goes to trash. Why the security fuses? Why the need to obfuscate the code? Isn't the P2 mainly targeted for open hardware projects?
But what happens if one happen to use it mistakenly? It it possible to overwrite? I think the fuses should only limit read access for that purpose. Once you would write new code, that "fuse" was reset.
Oh no! Worse than Flash is OTP ROM. If you mess up the fuses, that means that the chip goes to trash. Why the security fuses? Why the need to obfuscate the code? Isn't the P2 mainly targeted for open hardware projects?
So don't mess up the fuses. In any case, it's not that easy to mess them up by accident IIRC.
Oh no! Worse than Flash is OTP ROM. If you mess up the fuses, that means that the chip goes to trash. Why the security fuses? Why the need to obfuscate the code? Isn't the P2 mainly targeted for open hardware projects?
So don't mess up the fuses. In any case, it's not that easy to mess them up by accident IIRC.
I wouldn't. However, it seems that adding OTP is a condition of possible failure, IMHO. And to add, your code is still unprotected if it is stored in an external Flash or EEPROM (since internal EEPROM seems not to be an option at the moment). One could easily desolder your EEPROM and read it.
Oh no! Worse than Flash is OTP ROM. If you mess up the fuses, that means that the chip goes to trash. Why the security fuses? Why the need to obfuscate the code? Isn't the P2 mainly targeted for open hardware projects?
So don't mess up the fuses. In any case, it's not that easy to mess them up by accident IIRC.
I wouldn't. However, it seems that adding OTP is a condition of possible failure, IMHO. And to add, your code is still unprotected if it is stored in an external Flash or EEPROM (since internal EEPROM seems not to be an option at the moment). One could easily desolder your EEPROM and read it.
The fuses can be used to establish a 128-bit key for SHA-256 loader signing, so that the EEPROM's data would only boot that Prop2 chip. Also, the main program can be encypted using the key.
Can there be a special value that the fuses can be set to (supposing they haven't been written yet) that permanently disables the fuses, so that it's not possible to accidentaly set the fuses on a development board?
Can there be a special value that the fuses can be set to (supposing they haven't been written yet) that permanently disables the fuses, so that it's not possible to accidentaly set the fuses on a development board?
That would be a good one to add. If the door has to swing, let it swing both ways. I would disable them if I could, if I were to develop a dev board with the P2.
From what I understand, you will need to use a special program to blow the fuses. There will be no accidental fuse blowing like can happen on other micros. Just don't use them and there will not be any problems.
Therefore no corrections will be required. They are there for special use and encryption of code for commercial users who want to protect their code investment.
Comments
Chip's recent comment about up to 2 watts (600mA) makes me think the Vdd traces might need to be as thick as we dare, we well as heatsinking on the back where possible.
I will take a look at the Prop proto to see if I can make it more compatible with it. As I said the adaptor is incomplete in that I just want to see how it can connect and absolutely for sure the ground and power copper will be beefed up considerably. It might even mean having to take the power and ground to the inner pads rather than trying to snake through to the edge and I could even decide to just push in between the I/O on each side so that the power and ground are centered. All this while I try to keep it double-sided only.
BTW, I can never find matrix protoboards that tick all the boxes, most of them think it's a good idea to run tracks along the pads so that you have to cut them when it is so much easier just to join up the ones you want in the first place. Then they might even be plated through but not have pads on the other side or they run power rails that limit where you can place components. So my matrix board addresses all this by having uncommitted plated through 38mil holes that take pin headers with ease and while power rails are useful they also get in the way. What I did was run power traces in between the pads with 25mil vias at the intersections so I can have quick and easy connection to rails without then getting in the way.
I had to look for a while onto your image until it hit me. This is a very cool idea. Are the rails on the interconnection also thru hole or how I would solder to them?
Or is the idea to just drag the solder blob to the interconnection to supply VDD or VSS on the pad?
confused again.
Mike
The vias have 25mil holes so they will take components leads and wires of course.
That all makes sense, until you look at the 2nd (wayward?) via down, from top right.
It's a good idea to check how 2 layers route, but for a protoboard that can end up driving cables, and more C than a final PCB, the incremental cost of 4 layer is quite low on a board of such small area.
Plus, I like to 'approach from above', where some over-design initially can be checked later - on a P2, that would mean top and bottom side under-chip decoupling, and poured inner planes, maybe in thicker copper too.
Someone is always going to want to overclock these too
Don't look too close at the screenshot, it's only a sample as I am changing things around every time I look at it and in this section I quickly wanted to see how it would look if I removed every second via so that I could run horizontally as well as vertically. But the final one will be clean obviously!
The P2 adaptor may indeed end up multilayed if need be and it is possible that I will allow for decoupling on top of the board as well as an oscillator but the bottom has to be unpopulated so that if desired the adaptor can be soldered directly to the matrix. Some may choose to put connectors on it but if the chip is blown it's blown, just cut the pins, swipe off with a wet iron, and redo it.
I agree that neither the P2 or the P1 would ever compete with some of the single chip microcontrollers on a price basis. It's my ignorance of the chip design process that has me asking some of the silly questions I'm asking.
My introduction to Parallax came many years ago when I was working with the Scenix SX chips. They were a great little processor for many applications. This particular application was a controller for a marking system. Only a few thousand machines were sold, but a few thousand chips here and there embedded into consumer products might go a long way for the bottom line of some companies.
A single (32bit) cog of the P1 with on-chip flash memory and in-system programming might have been a nice next-step-up replacement for the SX. I know that there are designs I WOULD have done with it had it been available.
The P2 with 16 cogs is going to be an incredible high performance rocket for applications needing that kind of horsepower, but many, many of the day to day embedded designs for consumer products like toasters and toys ( where often tens or hundreds of thousands of chips go) can't justify ANY extra cost when the saving of a single dollar can represents a hundred thousand dollars in profit or loss.
When the P1 first came out, I desperately tried to design it into a controller for a company making screen printers for T-shirts. At $6.00 per chip in quantity ( I think at the time) + the support chips, my bid for the board was about $5.00 more expensive than the PIC board I lost the design to. The SX didn't have QUITE the horsepower I needed, the P1 just didn't fit, but one or two cogs of the P1 with on chip memory would have done the job nicely. This is the reason there are so many variations of the PIC, TI430 and other such processors: those little "Niche" applications.
Chip's time is RIGHTLY being invested in developing a wonderfully capable NEW design, but if my very limited understanding of the design process is anywhere near correct... the CODE that compiles into a P2 cog is like a software subroutine that becomes a "tool" in a toolkit that COULD be reused for other designs many years into the future. I'm not smart enough to use 16 cogs in a design. I've never even used all 8 of the P1's cogs. I have used up to six, but the norm is more like two or three. My WISH is for two to four of those wonderfully capable P2 cogs in a small, inexpensive package that I CAN justify embedding into new designs.
Working for Hamilton Avenet back in the dark ages, I introduced many companies to the 8051 microcontroller. 36 years later, there are HUNDREDS of variants of this original chip currently in production still making money for the companies producing them.
Once the P2 is a functional part, Chip's time will again ( probably, and rightfully) be invested in a P3 ( if he should be so inclined...) but from a company stand-point, if it was possible to have another designer take his code and "Cut and paste" a cog or two and a few smart-pins ( and some on-chip boot memory ) into something for the lower end embedded market... I believe that Parallax could amortize some of the incredible time/dollar investment behind the P2 into some "workhorse" chips that might still be making money 20 or 30 years from now.
The FACT that the P1 had software provisions for an additional 32 bit port led me (over ten years ago) to believe (however foolishly) that there would be (much needed) variants of the Prop that would have it. I assumed ( yes... I know ) that the serial start-up nature of the P1 would be followed by some single chip version with on-board boot memory for applications where price, footprint, and rapid startup was critical. BECAUSE IT MADE SO MUCH SENSE THAT THESE WOULD BE THE NEXT STEPS!
Chip is the genius behind the company and his time should be invested wherever he "darn-well" feels like it... but I hope that the BUSINESS pros there at Parallax will consider that there are old-farts like me out here who appreciate your ethics and openness with the community of loyal followers and would in turn love to be "Loyal" to parallax but CAN'T because of technical needs that seem likely could have been introduced into the P1 "Family" of processors sometime over the last ten years.
Many of the "Propeller Superstars" out there want and need the adrenaline rush capability of the latest, greatest things that can be stuffed into the newest bleeding edge processor. I may WANT some of these things from the sheer joy for a wonderful new toy, but most of my ACTUAL engineering needs are more for low cost, reliability and long term product life.
Long term product life for nearly every other successful microprocessor has come from offshoots that fill those niches that the original chip didn't quite fit.
The fact that there is no "Family" of Propeller chips is my biggest concern about and for the future of Parallax. We're ten years down the road and still waiting for the first offshoot.
Build the P2 and make it WONDERFUL! I can hardly wait! ... but please, have some pity on some of us dimmer bulbs out here in the Parallax sky... and consider some of our more prosaic but real needs over the future years.
KB
Prop2 is using fully up-to-date tools so when the time is right there shouldn't be any compatibility issues with rolling out another model variation of the Prop2. Or an up-spec'd Prop3 for that matter.
Pricing is always a chicken or egg problem. Luckily, Parallax isn't competing head-to-head with Microchip.
Indeed, and not only is the 8051 still in use, it is still seeing active development.
The 8 bit MCU market is doing better than all those jumping on the 32b bandwagon hope, yes, it is seeing some rationalise as the fringe 8b cores decline, but ST recently claimed their second billion of STM8, with strong sales in China.
STM8 is not 8051, (but has roots almost as far back), but plenty of Asian vendors have 8051 parts, and some have core-redesigns being done to process opcodes in a wider fashion (24b opcodes).
The new SiLabs EFM8 series target STM8 prices, with more variants (Speed to 72MHz, ADC to 14b).
Interesting point, and certainly possible when P2 is out of FAB, and proven.
On-chip code memory is a difficult one.
P2 already has a boot ROM, & then loads CODE from SPI Flash.
On Chip flash sounds nice, but brings some baggage - it bumps the processing cost and layers, and it (severely) limits speed.
One key feature of P2 is very fast, deterministic cores, and it does that by running from RAM.
Possible ways around this, are to follow Nuvoton, and include a SPI die in package, or follow new FTDI (FT51,FT9xx) and have some CODE memory storage that is loaded into RAM.
"lower end embedded market" can mean many things, but I doubt P2 variants will ever be in the sub $1 or even sub $2 sandpits.
It does not need to be, P2 provides the real time side of control, and will often be used alongside some larger device running an Operating System.
For the more grain of rice end, like sensor gathering, P2 will talk to those sub $1 MCUs, often hidden inside sensors.
The new USB feature means P2 will see good use as 'smart hub', where it can collect a series of cheap USB peripherals, in a smarter way, for an upstream PC/OS-end host.
Indeed, and to add, Flash has also the problem of write cycles limitation. That would mean that an on die Flash would not be replaceable and, ultimately, the Propeller chip would have to be replaced in case of a Flash failure. With an external Flash or EEPROM memory, I can easily replace that failing part without tossing away an otherwise functional micro-controller. Also, I can always opt between Flash or EEPROM, as I do prefer the latter for its endurance.
None of MY applications will ever have high enough volume to justify paying for a custom chip run, however, many companies do.
My largest customer established policies against paying for software that could be developed internally. They purchased a software development group in Sweden to rewrite the control code for the machines they sold that had software requiring royalty payments. This cut me out of a considerable ongoing revenue stream.
However... I was a valuable, albeit external, part of their design team. The company had no policies against paying for custom hardware and the machines I designed used an SX chip as part of the control package, so... BECAUSE OF INTERNAL POLITICS, they worked a deal with me where I supplied them a VERY expensive, but pre-programmed SX microcontroller for each machine sold.
As stupid as this may sound, I suspect this sort of thing is reasonably common and giving engineers THE ABILITY TO ADD VALUE TO THE HARDWARE can affect which processor does or doesn't get designed into new products NO MATTER WHAT TECHNICAL CAPABILITY a processor may have.
The "Hooks" in the code to easily jump into (future) additional internal OTP rom might lead to more high volume sales.
As far as flash memory goes, yes, due to the limited life-cycles, you would never want to use it as part of the operational memory, but as a tool for development and booting an operational program, it works pretty well. One of my manufacturing machines has a Prop on it that I have been using for about 7 years. I turn it off and on several times a day. I make minor program changes every once in a while. I've probably programmed the EPROM a thousand times or more... and it still seems to be going strong.
In THIS particular application, a couple of seconds in start-up isn't a big deal, however... I used to work in flight test, and I GUARANTEE you, in some instances, you want your electronics to "Get-to-gettin" ASAP! The incredible speed of a processor can be almost irrelevant if the time it takes to "Start thinking about stuff" takes too long. You't be amazed at how long three seconds in uncontrolled flight can seem.
We are used to waiting for our laptops to take a while to boot... but we are NOT used to our cars "thinking about it for a while" before the engine starts. THESES REAL-WORLD-CONTROL APPLICATIONS ARE EXACTLY WHAT THE PROP(S) EXCEL AT! However, the longer and more complex programs become, the less viable serial loading is going to be for many embedded control applications.
If the POSSIBILITY of future versions of the P2 ( or even the P1) having rapid start up (i.e. internal boot memory) is there, it should be planned for because there are thousands of applications where it is an essential part of a design and not being there will cost both Parallax and loyal engineers many lost designs.
These are only MY two cents worth... and probably not worth what you are paying for them... however as someone who loves MOST of the P1 and appreciates Parallax and this community of people out here, I would feel remiss not to have said some of these things if they MIGHT have made a difference down the road. I don't want to delay the introduction of the P2 by as long as it might take Chip to read my ramblings, but if any of it makes sense, I hope that SOMEONE there at Parallax will keep these things in mind when it's time to consider long-term planning.
KB
KB, thanks for your comments. I have been thinking, too, that rapid start up is something we really need in the Prop 2. Between SPI flash chips, synchronous serial smart pins, and variable length loading, we should be able to start within a second of power-on.
My experience, with such things as the Boeing 777, is that there are at least three compute nodes flying the plane. If any one of them fails or reboots nobody notices. Apart from a red light coming on some place. If they all fail in flight you have a much bigger problem than the boot time.
I'm not saying that a fast start up is not desirable though.
Maybe a spec for TTL1 (Time to load/launch one COG) would be useful here.
Some MCUs have a pin to enable/disable UART boot, which speeds the decision tree.
QuadSPI memory, streaming at say 48MHz in a second stage boot, can stream 24MB/s, which is ~10ms to load a 50% memory image, or just over 1ms to load 16 Full COGS contents.
The first P2 certainly will have a BOOT ROM, otherwise it can never start. The FPGA images already have that, otherwise they can never load code normally.
Now you have made two leaps, to user ROM and also OTP
Even with present P2 mask ROM, user ROM is possible, in theory, but would need a manufacturing flow change, so MOQs on that come with a lot of zeros.
OTP is interesting middle ground, cheaper than flash, and is more of a process question for OnSemi.
Quite a few parts use OTP, (or something less than Full Flash), and in some forms that does have low added fabrication costs.
That comes down to the IP.
There are still plans, I think, for Fuses & Security in P2, unclear what form / size those are now, but those could share OTP flows, with the added caveat they need normal Vcc operation.
OTP would make user-ROM designs much more feasible, but including that is a Parallax-OnSemi discussion.
Since the P2 is not a single core processor, one cog can start loading immediately and the other can wait for UART boot. If the UART cog detects a computer wanting to program the chip, it will kill the loading cog, load the new program, and then start the main program in cog 0 (and then stop itself). If the UART cog detects no computer after some timeout, it will signal the loading cog that it's OK to start running the loaded code and then it will stop itself.
Interesting idea, tho I think not how the present boot works ?
That seems to be the problem unsolved, as you still wait until after that timeout, before you 'start run'.
For other ideas to shorten decision trees, I think tying the RxD low was one mentioned.
Boot then assumes some min baud, and if LOW exceeds that char time, it can quickly skip UART. (eg >= 78us at 115200, plus margins)
No extra pins, but does need a HW jumper.
This should give sub 250us TTL1 load times ?
And/Or, you can have Host stream chars at around the USB turn around rate (no point going faster) and when host sees a Boot-echo, it starts the real download preamble.
Bootloader knows it should have data with small max char spaces, so can make 'no data' decision earlier.
This needs margins for USB + OS, so maybe sub 20ms? sub 5ms? is possible ?
I used to work in the autopilot STC ( Supplemental Type Certificate) group at King Radio ( Now Bendix King). Part of my job was to insert failures into the autopilot to simulate the worst failure it was possible for the autopilot to experience ( a servo drive motor shorted full on ). We had to let the airplane do whatever it was going to do (hands off) for 3 seconds before attempting recovery to simulate the possible delay time before a pilot might notice the failure. Roll failures weren't all that big a deal, but elevator failures could get really interesting, particularly since testing had to be done throughout the entire flight envelope. The worst "Failure" was a DOWN failure at maximum altitude, Vmax ( top speed) and maximum, full aft loading. ( One flight in particular comes to mind...)
There were no "Little red lights"... in a small plane with a single autopilot, when it fails, it often notifies you in very exciting ways. Our job was to make sure that the excitement for "Joe Average Pilot" was kept to a minimum... but OUR failures were sometimes right out there on the edge.
It was a fun job... but roller coasters were never quite the same after that.
KB
So don't mess up the fuses. In any case, it's not that easy to mess them up by accident IIRC.
The fuses can be used to establish a 128-bit key for SHA-256 loader signing, so that the EEPROM's data would only boot that Prop2 chip. Also, the main program can be encypted using the key.
Therefore no corrections will be required. They are there for special use and encryption of code for commercial users who want to protect their code investment.