Has parallax considered hiring someone to work alongside Chip, so he's not the only designer of your flagship product?
Chip has developed the Propeller 2 primarily on his own, with input from customers and forum members. The Propeller 2 has two pieces, as you know: (1) the Verilog code which will be synthesized into the production design and (2) the I/O pin which includes the A/D. For both of these parts we have a consulting firm skilled with ASICs and our chosen foundry. They have a team of a half-dozen on the project, usually with 2-3 of them working full time with us. It's not common to have these skills inside of a small company like Parallax because of their special expertise, infrequent needs for these skills, and very big software licensing costs [which are typically renewed yearly, not for six-week chunks like we need the tools].
You ask many other questions that I would also like to answer but I can't right now (Sunday evening, need to get to Parallax in the morning). But yes, the project has had some failures along the way which are all part of our risk. You also asked about how "open" it is when it's not 100% visible, too. It's probably best that the development team stay productive on the project instead of supporting code releases, at least for now.
..
It's getting hard to find PS/2 keyboards too, and even though most consumer USB keyboards still support PS/2 with the passive adapter, a lot of them and especially the industrial ones don't. The Propeller can only barely do HID USB, when overclocked and devoting three cogs to the project.
Do you mean HID USB as a host, talking to the USB keyboards ?
I would also rather see if the boot Flash/Eeprom could be integrated in the new P2 (surely OnSemi have the technology to do this) ....
It's a rather bigger jump, but this recent news shows where Automotive qualified Flash is up to...
["today announced the full qualification and availability of SSTs 55nm embedded SuperFlash® non-volatile memory (NVM) on GLOBALFOUNDRIES 55nm Low Power Extended (LPx)/ RF enabled platform. .... This process technology also met the requirements of AEC-Q100 Grade 1 qualification with an ambient temperature range of -40°C to 125°C, and demonstrated endurance of 100K program/erase cycles with more than 20 years of data retention at 150°C. "]
.... The Propeller 2 has two pieces, as you know: (1) the Verilog code which will be synthesized into the production design and (2) the I/O pin which includes the A/D. For both of these parts we have a consulting firm skilled with ASICs and our chosen foundry. They have a team of a half-dozen on the project, usually with 2-3 of them working full time with us.
Has Parallax run any silicon tests on the Custom cell design areas yet ?
Do you still use the in-house fuse approach, or has that moved to an OnSemi FAB OTP/MTP fuse ?
Since it seems to be a point, I'll say why I need P2....
This post nicely illustrates why it's important projects don't take too long. You end up designing something which is already outdated when you eventually get around to releasing it.
A couple of years ago, when the P2 spec was drawn up, VGA monitors and PS/2 keyboards were still easily available as they were what the consumer market was using. Within a short time-frame they've now become harder to find. In a years time, when P2 silicon is available, they'll be effectively obsolete. Within the next year I'll wager someone will release a commodity uC with built-in HDMI.
I don't think that's quite right. AFAIK, HDMI will/should work with a clock rate between 25MHz and 165MHz. At the bottom end of that range that's something around a 800x600x24-bitx60Hz display needing 1.5MBytes of memory which is not exactly large these days. Whether you can get display that work fown to that resolution is another matter.
Given HDMI needs significant memory support, I'd say there are already commodity chips with HDMI built-in - look no further than the RaspPi series.
I agree.
The rapid price drop of chips like those used in the RaspPi and similar systems is turning things upside down. In many cases it makes more sense to use a RaspPi as the interface between the keyboard/mouse/monitor and the microcontroller that runs the actual machinery.
RaspPi shield for a QuickStart/Project Board anyone?
The rapid price drop of chips like those used in the RaspPi and similar systems is turning things upside down. In many cases it makes more sense to use a RaspPi as the interface between the keyboard/mouse/monitor and the microcontroller that runs the actual machinery.
RaspPi shield for a QuickStart/Project Board anyone?
I seem to recall that as long ago as two years people were already saying VGA support was a waste of time.
As it stands my Raspberry Pi and other boards make very good "Prop Plugs", for not much more money than an actual Prop-Plug around here. With the bonus that they run the Propeller dev tools and drive HDMI screens, networking, USB, SD card. I have no need for video out on the Prop or Prop II.
Personally I will be quite happy with 24 bit parallel output with dot clock, hsync, and vsync along with analog VGA (6/9/12/15 bit parallel output options to save pins where needed would also be very nice).
The parallel output can easily be used to feed an HDMI chip
Personally I will be quite happy with 24 bit parallel output with dot clock, hsync, and vsync along with analog VGA (6/9/12/15 bit parallel output options to save pins where needed would also be very nice).
The parallel output can easily be used to feed an HDMI chip
I think Chip does plan parallel LCD, so all of the above should be possible - within the memory constraints of P2.
That is the approach FTDI used on their EVE - focus on LCD and forget HDMI.
The EVE was seeding a market for P2 quite well, .... until FTDI announced a bigger-screen EVE...
Maybe someone like Solomon Systech will do a HDMI output version of their Graphics Chips ?
- an HDMI display handler chip, with QuadSPI and/or HyperBUS would get good market takeup.
C'mon, Heater, that's yesterday's news -- no longer relevant. Move along, 'nothing to see here...
Yes, the FTDI scandal seems like only yesterday.
If you are happy with companies screwing with you then by all means ignore what I say. As a good friend of mine is fond of saying "You get what you order".
Clearly you were not around for the months (years?) that the development was discussed here in quite some detail. With feature suggestions from forum members being adopted into the design on what seemed like a daily basis. That resulted in a design that was too complex and power hungry and ultimately scrapped.
You're right heater, I was not around for the months/years that the devfelopment was discussed. 99% of the P2's potential user base hasn't either. So I guess my viewpoint is that of an outsider, and take it as you will.
Also Ken: Looking back, I apologize if my post was too acidic. I don't mean to imply Chip is at fault. He certainly is brilliant, but I guess my point is that since this is Parallax's first public multi-year project problems were inevitable. That's all.
Personally I will be quite happy with 24 bit parallel output with dot clock, hsync, and vsync along with analog VGA (6/9/12/15 bit parallel output options to save pins where needed would also be very nice).
The parallel output can easily be used to feed an HDMI chip
A parallel output option along those lines would make more sense than obsolete video standards like VGA or NTSC/PAL, particularly if it was made a bit more flexible like allowing the hsync, and vsync to be used for handshaking.
Also Ken: Looking back, I apologize if my post was too acidic. I don't mean to imply Chip is at fault. He certainly is brilliant, but I guess my point is that since this is Parallax's first public multi-year project problems were inevitable. That's all.
Not at all a problem at all - being so close to this project all of you could rest assured that I've experienced more frustration than all of you combined at times. However, I shared a laugh with Chip this morning and in some way I realized that ultimately this P2 project had better be fun and productive.
A parallel output option along those lines would make more sense than obsolete video standards like VGA or NTSC/PAL, particularly if it was made a bit more flexible like allowing the hsync, and vsync to be used for handshaking.
I wonder how the DACs are running up in simulation on the OnSemi process ? and how much die-cost there is in having a Video-spec DAC on every pin ?
How many displays is a P2 likely to ever drive at the same time ?
Of course, there are niche Test Equipment and Instrument uses for lots of DACs, and it does give P2 a point of difference.
Imagine, for example, if half the video-spec DAC's, were traded for some USB support silicon ?
Despite the seemingly infinite amount of highly-integrated uCs on the market, it's so frustrating that the "perfect" device is often non-existent, so you either have to settle for something that's overkill, or you need additional components to meet all functionality requirements. The original Propeller design was a great way to make a single part as far reaching as possible by the use of soft peripherals. This obviously makes great sense when it's not economical for a company to have a huge portfolio of devices, but it doesn't solve any problems for the engineer if it too is almost perfect, even more so if it isn't cost competetive. For certain applications, it's great when a company is dedicated to long-term support of their IC, but an issue arises when an engineer has to rely on another specialized part to enable certain functionality which might not have that same long-term availability. Where's the benefit of having access to one chip for a few decades if the engineer has to completely redesign a product because another key component has reached EoL with no suitable replacement available? These are reasons why being behind the curve even before your LTS product hits the market is a bad idea. Even worse is if the things it's lacking have long been widely adopted technologies, while intentionally supporting outdated ones.
To be more direct, I strongly advise the P2 dev team to take a serious look at how other industry players make due with a lack of certain on-chip functionality. Using HDMI and MIPI DSI as an example, even many higher-end SoCs don't have full on-chip support, but they do support common interface standards shared with the necessary driver chips. I don't think it should require much persuasion to see why doing this would be a good idea, especially if something like video capability is a stated goal of the P2. And another thing I'm just going to go ahead and say: lacking USB support, especially on a fairly expensive chip, is a BAD IDEA. Without it, Parallax is basically shutting itself out from the P2 ever being used in some high-volume consumer/prosumer device. "But why not just use some kind of USB host/device chip?" you say. Because they're Smile and a kludge, and make using your chip a worse proposition than a competitor's chip. USB has been around for something like 20 years now, and is so ubiquitous that it is effectively The Standard wired interface between computing devices and peripherals. It's so important that chip makers find it necessary to even include it their upper low-end products. Yes, everything I'm saying is obvious, but I'm concerned that Parallax might be making a few huge oversights.
Is that actually true? Is there any reason you couldn't "race the beam" and generate the HDMI bitstream on the fly? Granted, HDMI has error-correcting, 8b/10b, differential signalling, etc. so there's more to it than just getting out 24bits of color per pixel clock. But, AFAICT, you don't need the whole framebuffer any more than you need a whole framebuffer for producing video on a Prop1. Do you even need a single raster?
Is that actually true? Is there any reason you couldn't "race the beam" and generate the HDMI bitstream on the fly? Granted, HDMI has error-correcting, 8b/10b, differential signalling, etc. so there's more to it than just getting out 24bits of color per pixel clock. But, AFAICT, you don't need the whole framebuffer any more than you need a whole framebuffer for producing video on a Prop1. Do you even need a single raster?
Sure., if you are OK with a small subset of HDMI usage.
Simple Character only display you might be able to do, as "race the beam", but that is a long way short of a RaspPi and others.
Even the EVE devices have background-image display abilities.
After all the water that's gone over the dam, under the bridge, and out to sea for the P2, I can't help returning to this simple mantra:
This is the vision that propelled the P1 and should be the vision that does the same for the P2. Programming and microcontrollers are supposed to be FUN! Why have we become such adults (and I do mean that in its pejorative sense) in our expectations of what the P2 should provide? The P1 is fun! Spin and PASM are fun! Show me how the P2 is going to be more fun than the P1, and I'll climb aboard. But, doggone it, the P1 hasn't lost its magic yet!
I agree with that! My fondest wish would be a design shrink of the P1 so that it would fit in the same package sizes and types that the SX did, and sell for somewhere around $2.50.
BTW, one of my kids just completed a BSEE a few days ago. After four years of having ARM crammed down his throat he was pretty sick of it. For his Senior Project I floated the suggestion he use the Propeller. I even emailed him some sample code showing how easily ΣΔ converters can be implemented and how easily PST can be used for debugging. Darned if he didn't take my recommendation. (I guess there has to be a first for everything. )
He reports that the programming came together very quickly. From the first line of Spin he ever wrote to the completion of the coding on several cogs took only a morning. He was amazed at that. To have done everything with timers and interrupts on a std processor would have been a nightmare to design and debug. The prospects of that had filled him with dread.
Now if I could just sell him on the joys of PASM...
With all the bad implementations of USB, I would expect that a foolproof implementation in hardware for the P2 would be a minefield.
At least with just some minimal support USB FS will be doable, most likely with 2 cogs. This will mostly be a software peripheral, so any bugs will be software fixes.
This is where the P1 shines - software peripherals. So will the P2, and if the final spec is still 16 cogs, all the better.
There's always the option to *gasp*.... license USB IP so that Parallax doesn't have to take all the associated risks of developing it in-house. I wouldn't be surprised if Treehouse and/or ON Semi have such IP. At the very least Parallax could implement a bare minimal ULPI interface (for use with USB phy chips) in hardware, ideally with a CRC engine. This would only require minimal die realestate and be far less risky to implement. The drawback would be the amount of pins it would need (~12), but the benefit would be Hi-Speed support which could come in handy considering the amount of bandwidth the P2 will have. Such hardware might even be useful for software implementations of low/full-speed USB in software where lower bandwidth is sufficient with the added benefit of reduction in pin usage.
Single use hw is the wrong direction. Just the basic pieces to get decent speed is all that should be included. Software can do the rest.
And I'm all for having HDMI capabilities but the above goes for any HDMI assistance also. Any serialiser that can be used for HDMI must be a generic serialiser that can be re-purposed.
Comments
Chip has developed the Propeller 2 primarily on his own, with input from customers and forum members. The Propeller 2 has two pieces, as you know: (1) the Verilog code which will be synthesized into the production design and (2) the I/O pin which includes the A/D. For both of these parts we have a consulting firm skilled with ASICs and our chosen foundry. They have a team of a half-dozen on the project, usually with 2-3 of them working full time with us. It's not common to have these skills inside of a small company like Parallax because of their special expertise, infrequent needs for these skills, and very big software licensing costs [which are typically renewed yearly, not for six-week chunks like we need the tools].
You ask many other questions that I would also like to answer but I can't right now (Sunday evening, need to get to Parallax in the morning). But yes, the project has had some failures along the way which are all part of our risk. You also asked about how "open" it is when it's not 100% visible, too. It's probably best that the development team stay productive on the project instead of supporting code releases, at least for now.
Ken Gracey
["today announced the full qualification and availability of SSTs 55nm embedded SuperFlash® non-volatile memory (NVM) on GLOBALFOUNDRIES 55nm Low Power Extended (LPx)/ RF enabled platform. .... This process technology also met the requirements of AEC-Q100 Grade 1 qualification with an ambient temperature range of -40°C to 125°C, and demonstrated endurance of 100K program/erase cycles with more than 20 years of data retention at 150°C. "]
Do you still use the in-house fuse approach, or has that moved to an OnSemi FAB OTP/MTP fuse ?
This post nicely illustrates why it's important projects don't take too long. You end up designing something which is already outdated when you eventually get around to releasing it.
A couple of years ago, when the P2 spec was drawn up, VGA monitors and PS/2 keyboards were still easily available as they were what the consumer market was using. Within a short time-frame they've now become harder to find. In a years time, when P2 silicon is available, they'll be effectively obsolete. Within the next year I'll wager someone will release a commodity uC with built-in HDMI.
Maybe 'commodity' wasn't quite the right word. What I was meaning was chips which can be bought in relatively small quantities.
I don't think that's quite right. AFAIK, HDMI will/should work with a clock rate between 25MHz and 165MHz. At the bottom end of that range that's something around a 800x600x24-bitx60Hz display needing 1.5MBytes of memory which is not exactly large these days. Whether you can get display that work fown to that resolution is another matter.
I agree.
The rapid price drop of chips like those used in the RaspPi and similar systems is turning things upside down. In many cases it makes more sense to use a RaspPi as the interface between the keyboard/mouse/monitor and the microcontroller that runs the actual machinery.
RaspPi shield for a QuickStart/Project Board anyone?
And Gadgetoid made a nice propeller+breadboard hat for the Pi that can be used for experimenting with the prop.
In both cases, SimpleIDE / PropellerIDE can run a full development system on the Pi.
I've also successfully run SimpleIDE on the Banana Pi, Banana Pro, and ODROID-C1 (in addition to Raspberry Pi's)
(Gives me something to do while I patiently wait for the P2)
As it stands my Raspberry Pi and other boards make very good "Prop Plugs", for not much more money than an actual Prop-Plug around here. With the bonus that they run the Propeller dev tools and drive HDMI screens, networking, USB, SD card. I have no need for video out on the Prop or Prop II.
The Propeller 2 doesn't have built-in support for HDMI, so we would be relying on chips designed for that purpose.
Ken Gracey
The parallel output can easily be used to feed an HDMI chip
That is the approach FTDI used on their EVE - focus on LCD and forget HDMI.
The EVE was seeding a market for P2 quite well, .... until FTDI announced a bigger-screen EVE...
Maybe someone like Solomon Systech will do a HDMI output version of their Graphics Chips ?
- an HDMI display handler chip, with QuadSPI and/or HyperBUS would get good market takeup.
If you are happy with companies screwing with you then by all means ignore what I say. As a good friend of mine is fond of saying "You get what you order".
You're right heater, I was not around for the months/years that the devfelopment was discussed. 99% of the P2's potential user base hasn't either. So I guess my viewpoint is that of an outsider, and take it as you will.
Also Ken: Looking back, I apologize if my post was too acidic. I don't mean to imply Chip is at fault. He certainly is brilliant, but I guess my point is that since this is Parallax's first public multi-year project problems were inevitable. That's all.
A parallel output option along those lines would make more sense than obsolete video standards like VGA or NTSC/PAL, particularly if it was made a bit more flexible like allowing the hsync, and vsync to be used for handshaking.
Not at all a problem at all - being so close to this project all of you could rest assured that I've experienced more frustration than all of you combined at times. However, I shared a laugh with Chip this morning and in some way I realized that ultimately this P2 project had better be fun and productive.
Ken Gracey
How many displays is a P2 likely to ever drive at the same time ?
Of course, there are niche Test Equipment and Instrument uses for lots of DACs, and it does give P2 a point of difference.
Imagine, for example, if half the video-spec DAC's, were traded for some USB support silicon ?
To be more direct, I strongly advise the P2 dev team to take a serious look at how other industry players make due with a lack of certain on-chip functionality. Using HDMI and MIPI DSI as an example, even many higher-end SoCs don't have full on-chip support, but they do support common interface standards shared with the necessary driver chips. I don't think it should require much persuasion to see why doing this would be a good idea, especially if something like video capability is a stated goal of the P2. And another thing I'm just going to go ahead and say: lacking USB support, especially on a fairly expensive chip, is a BAD IDEA. Without it, Parallax is basically shutting itself out from the P2 ever being used in some high-volume consumer/prosumer device. "But why not just use some kind of USB host/device chip?" you say. Because they're Smile and a kludge, and make using your chip a worse proposition than a competitor's chip. USB has been around for something like 20 years now, and is so ubiquitous that it is effectively The Standard wired interface between computing devices and peripherals. It's so important that chip makers find it necessary to even include it their upper low-end products. Yes, everything I'm saying is obvious, but I'm concerned that Parallax might be making a few huge oversights.
Is that actually true? Is there any reason you couldn't "race the beam" and generate the HDMI bitstream on the fly? Granted, HDMI has error-correcting, 8b/10b, differential signalling, etc. so there's more to it than just getting out 24bits of color per pixel clock. But, AFAICT, you don't need the whole framebuffer any more than you need a whole framebuffer for producing video on a Prop1. Do you even need a single raster?
The only video in spec is VGA now. If it does that, all tricks and formats are on the table.
HDMI, without enough for a frame buffer, ideally two won't be anywhere as capable as simple analog displays will be.
Simple Character only display you might be able to do, as "race the beam", but that is a long way short of a RaspPi and others.
Even the EVE devices have background-image display abilities.
This is the vision that propelled the P1 and should be the vision that does the same for the P2. Programming and microcontrollers are supposed to be FUN! Why have we become such adults (and I do mean that in its pejorative sense) in our expectations of what the P2 should provide? The P1 is fun! Spin and PASM are fun! Show me how the P2 is going to be more fun than the P1, and I'll climb aboard. But, doggone it, the P1 hasn't lost its magic yet!
-Phil
Totally.
FWIW, Chip wants the fun. It will happen. I'm really not worried.
I agree with that! My fondest wish would be a design shrink of the P1 so that it would fit in the same package sizes and types that the SX did, and sell for somewhere around $2.50.
BTW, one of my kids just completed a BSEE a few days ago. After four years of having ARM crammed down his throat he was pretty sick of it. For his Senior Project I floated the suggestion he use the Propeller. I even emailed him some sample code showing how easily ΣΔ converters can be implemented and how easily PST can be used for debugging. Darned if he didn't take my recommendation. (I guess there has to be a first for everything.
He reports that the programming came together very quickly. From the first line of Spin he ever wrote to the completion of the coding on several cogs took only a morning. He was amazed at that. To have done everything with timers and interrupts on a std processor would have been a nightmare to design and debug. The prospects of that had filled him with dread.
Now if I could just sell him on the joys of PASM...
At least with just some minimal support USB FS will be doable, most likely with 2 cogs. This will mostly be a software peripheral, so any bugs will be software fixes.
This is where the P1 shines - software peripherals. So will the P2, and if the final spec is still 16 cogs, all the better.
And I'm all for having HDMI capabilities but the above goes for any HDMI assistance also. Any serialiser that can be used for HDMI must be a generic serialiser that can be re-purposed.