Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 Costs - Page 3 — Parallax Forums

Prop2 Costs

13»

Comments

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Ramon wrote: »
    ...I actually can't imagine the P2 penetrating any market. And I really wish to be wrong on this...

    Might it open up a new, perhaps unanticipated, market?

    Of course :) - there is quite a lot of fertile area between MCU and custom FPGA design :)
    The smart pins make it very well suited to Instrumentation and Test & Measuring markets, as well as many uart based industrial networking uses.

    Quite a lot of Bridge type uses out there.

    The lack of HS-USB is a slight drawback, but there are low cost HS-USB parts like FT4222H that can give middle-ground speed boosts, and it should slave well to a Rasp-Pi host, or even any WiFi device via a wifi module.

    If you have examples of T&M instruments, with source, that's immediately useful in a great many labs and education, right there.

    Motor and Position control is another fertile area, and the Eve series Display processors from FTDI also show another large sector.

    Some of these markets will need a supply lifetime guarantee.
    Did you ask OnSemi about that aspect of their 180nm FAB lines ?
    - ie how many customers do they have active now ?

  • jmgjmg Posts: 15,140
    Mike Green wrote: »
    Heater, As I understand it, reliable fuse programming requires a higher than normal voltage. This either can't be done "in-circuit" or would require prohibitively expensive switching circuitry to pull off "in-circuit". Once Chip gets test chips, fuse blowing can be tested and characterized as the need (potential customers) arises. If no one wants it initially, there are higher priority tasks

    If it is not 'out of the box standard', it probably should not be in the main data sheet, but off in an appnote, or even under a * Contact Factory line in the data sheet ?

    Many vendors offer factory programming, for associated MOQ and unit prices, and Parallax may have to set that up, if user-fuse is too unusual or strange.

    I would still like to see Calibrate and Serial info factory stored, in all parts, if the yield is proven good enough to do that.



  • cgraceycgracey Posts: 14,133
    The problem is that our fuses are known to have in 1-in-400 failure rate on programming. So, some kind of redundancy is required.
  • Heater.Heater. Posts: 21,230
    That's a bit tough Ramon. I'd buy some P2. I'm a market. Just need a few hundred thousand more like me! Also I don't see that having the chip ASAP does anything but help P2 sales. On the contrary, delay is no sales now and less chance of sales in the future.

    Chip, I feel that you are right. There is no way the P2 will get used where traditional micro-controllers/processors are used. It has to demonstrate it's unique capabilities and seek out people who need them. My rationale goes like this:

    a) At the low end of things the P2 clearly won't get a look in by those that use little PIC, AVR and the like. Too big, too power hungry too expensive, etc. Besides entrenched players have that market segment stitched up already.

    b) At the high end the P2 won't displace devices that need Linux in embedded systems. Think ARM SoCs by Broadcom, ATMEL and so on. It just can't do that.

    c) That leaves somewhere in the middle. Where is that somewhere?

    My answer to that is that the P2 covers a lot of ground where a micro-controller user might be forced to use an FPGA. Places where a lot of I/O and lots of fast(ish), timing determinate, custom logic, bit banging, is required. Not to mention analog capability.

    As far as I can tell those that need such capability have traditionally bolted an FPGA onto their system as a go faster logic, "coprocessor", Which of course is a hugely complex and expensive thing to have to do.

    Now a days FPGAs are big enough that you can incorporate that processor core into the FPGA itself. That is still a hugely complex thing to do. And having to design with Verilog and the FPGA tools get's you far away from the ease of development and comfort of a software system on a micro-controller.

    Enter the P2. It has everything required to run a software solution like a micro-controller but it has a ton more real-time logic and I/O capability. That should be enough to meet a lot of cases where a designer would otherwise be forced into the FPGA route.

    That then is the market. That thin strata of applications that require more than a micro-controller but less than an FPGA solution.

    How to find that "unanticipated, market", those people who find themselves in that thin strata? I have a plan....

    On P2 launch day the P2 comes on a dev board that is Raspberry Pi HAT compatible. Out of the box all the tools needed to use it work on the Raspberry Pi, prop-gcc, OpenSpin, loaders, SimpleIDE, Propeller IDE etc. They are all packaged up ready to go, easy to install. Of course to go with that is a ton of useful code, starting from UART drivers, LED string drivers, VGA drivers and up. Especially stuff that is hard to do on a Raspberry Pi. And a ton of documentation and tutorials. All P2 pins will be broken out.

    I'm not suggesting such a dev board be dependent on the Pi, it should be usable standalone as usual. But there will be 20 million Pi out there by the time the P2 arrives. That's a lot of tinkers and hackers who like to explore things.

    Anecdotally.... In my travels from Scandinavia to Britain to California I have come across people building robots and other gadgets that have hit the wall with what they have got. Be it the Arduino users that run out of space, speed and general I/O. Or the Pi users who find real-time I/O tweaking is not what Linux and the Raspi is good at. They need the P2!

    A typical case, like the high school robot building team I meet in San Jose, ends up trying to solve their problems by lashing Arduinos to the Raspberry Pi and getting into a complicated mess.

    BUT, be warned. Time is of the essence. In recent times FPGA solutions have been getting smaller, cheaper and far easier. With the Lattice parts price and size are right down. And with the recent development of Free and Open Source tool chains they are becoming drop dead easy to use. We can now synthesize a Verilog design for Lattice as easily as writing a sketch for an Arduino. With new HDL's like Chisel and SpinalHDL designing for them is more like the ease of writing Python than the pain of Verilog or VHDL. Things are not quite there yet but I can imagine super simple FPGA development is on the horizon. It just needs someone to package up what is already available into something as easy to install and get started with as the Arduino IDE.

    Such developments in the FPGA world could render the P2 obsolete in the near future. They are not there just yet.

    Err... sorry for the essay. Hope it made a bit of sense.

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    The problem is that our fuses are known to have in 1-in-400 failure rate on programming. So, some kind of redundancy is required.

    I guess a better yield data will come from the upcoming test parts.
    What is the software overhead, to add such redundancy ? ( ie see 64 bits at 1/400 is a ~15% yield hit, uncorrected )

  • jmgjmg Posts: 15,140
    edited 2017-10-01 09:26
    Heater. wrote: »
    ...
    Enter the P2. It has everything required to run a software solution like a micro-controller but it has a ton more real-time logic and I/O capability. That should be enough to meet a lot of cases where a designer would otherwise be forced into the FPGA route.

    That then is the market. That thin strata of applications that require more than a micro-controller but less than an FPGA solution.

    Yup, mostly I agree, that a P2 fits where a generic MCU is not enough, but that's not quite what I'd call 'thin strata'...
    There are many users wanting MORE uarts, or MORE SPI, or MORE quad counters on their MCUs, and some become somewhat reluctant FPGA customers, whilst others combine many MCUs to get what they ultimately need.
    Heater. wrote: »
    How to find that "unanticipated, market", those people who find themselves in that thin strata? I have a plan....

    On P2 launch day the P2 comes on a dev board that is Raspberry Pi HAT compatible. Out of the box all the tools needed to use it work on the Raspberry Pi, prop-gcc, OpenSpin, loaders, SimpleIDE, Propeller IDE etc. They are all packaged up ready to go, easy to install. Of course to go with that is a ton of useful code, starting from UART drivers, LED string drivers, VGA drivers and up. Especially stuff that is hard to do on a Raspberry Pi. And a ton of documentation and tutorials. All P2 pins will be broken out.

    I'm not suggesting such a dev board be dependent on the Pi, it should be usable standalone as usual. But there will be 20 million Pi out there by the time the P2 arrives. That's a lot of tinkers and hackers who like to explore things.

    Yup, sounds a good idea, and it would be also nice if Ultibo (Bare metal Pi) examples could be included too ! ;)

    That shows what performance users can really get out of Pi, with the right sort of assistance.

    My own focus would be less on VGA, and more on 'What Pi lacks', so examples that answer FAQ questions like...
    * How many UARTS can you add to Pi ?
    * How many Quad+Stepper Motor channels can you add to Pi ?
    * How many Servo channels can you add to Pi ?
    * How many Quad+Servo Motor channels can you add to Pi ?
    * How many LED String Drivers can be added to Pi ?
    * LCD extension, using USB to LCD bridge via P2 ?

    and to really push a Pi along, some pioneer work would be needed, as this thread shows'
    https://www.raspberrypi.org/forums/viewtopic.php?t=192447

    Suggests even 250k baud has challenges in a Linux instance, and that 15.625MBd may be configurable, but hard to support within Linux.
    Maybe Ultibo can prove if a P2-Pi link can run at 15.625MBd ?

    SPI seems to be higher, likely IO pin limited ? 31MHz ? 41.667MHz ? 62.5MHz ?
    This thread mentions
    "ili9341 boards seem to gracefully handle 31.25Mhz as their max speed (the next increment is 62.5Mhz and it doesn't work)."


    I think a 80MHz P2 could test 31.25MHz SPI links OK ? - Would the 41.667MHz next step (250MHz/2N) be ok, or does that need > 83.33MHz P2 ?
  • Heater.Heater. Posts: 21,230
    jmg,

    Of course we can debate how "thin" that strata may be. It's certainly wide :)

    If Ultibo developers want to support an attached P2 then go ahead. The more the merrier. The plan here is not promote a particular niche programming language (We already have that in Spin :) ) or even a more niche operating system. (Yeah, yeah, I know, Ultibo is not an OS. Works just like MS-DOS but it's not an OS right?)

    The plan is to leverage the millions of Linux using Raspi owners. Users that will be using Python, Java, C#, C, C++,Javascript etc, etc, etc.

    No doubt Parallax will be supporting their tools on Linux anyway, a lot of that exists already, so the Pi is only a small step away. Better to invest their resources in that direction. Cross-platform support is the sensible way to go to reach a wide audience.

    You certainly have a good list of problem areas that Pi users run into. Just those areas where a P2 would help them. I'm sure there are many more.

    I suspect the speed of communication between Pi and P2 is more than fast enough for the majority.

  • cgraceycgracey Posts: 14,133
    edited 2017-10-01 10:27
    Heater. wrote: »
    ...BUT, be warned. Time is of the essence. In recent times FPGA solutions have been getting smaller, cheaper and far easier...

    ...Such developments in the FPGA world could render the P2 obsolete in the near future. They are not there just yet...

    There is something else the P2 will have going for it: Near-instantaneous turn-around for code changes.

    Waiting minutes for tools, even 30 seconds, causes a huge slow-down in development. If your turn-around is less than a second or two, you can develop MUCH more rapidly. You can get ahead just by making mistakes faster and finding your way quicker. This is something that FPGA's will (maybe) never have going for them, as good fabric utilization requires huge compilation efforts. And, often times, you can adjust your problem to better fit your viable solution. We won't have raw FPGA flexibility, but we have macro functions that can be quickly brought into play via a few instructions. That means better impedance match to the programmer's brain. If he can tweak his problem to allow the P2 to effectively address it, he's way ahead of the guy mired in tedium.

    I think there is a HUGE potential for an awakening towards this kind of efficiency - impedance matching the brain. There is no programmable system, that I know of, that addresses this.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    The problem is that our fuses are known to have in 1-in-400 failure rate on programming. So, some kind of redundancy is required.

    I guess a better yield data will come from the upcoming test parts.
    What is the software overhead, to add such redundancy ? ( ie see 64 bits at 1/400 is a ~15% yield hit, uncorrected )

    It's no big deal, firmware wise.
  • Chip, It might be. I hope so.

    Fast hardware development cycle is certainly a key feature.

    FPGA manufacturers try their best to include soft/hard CPU and all the required software tools to do as much as possible in the software domain for faster development and code reuse. Other MCU manufacturers (like Cypress PSoC) even provides a graphical configuration tool. But I don't think that to be enough.

    I don't know how wide or narrow is that land in between MCU and FPGA. Nowadays MCUs and low-medium sized FPGAs has both mixed digital and analog features at any price/package combination. But in no way anyone can be happy with their development tools or encyclopedic-sized datasheets.

    The dual purpose P2 breakout board and Raspberry Pi Hat board (with complete development tools ready at time of launch) is certainly a great sales idea. I really like it. It would make analog hardware scripting possible. And it may overcome a lack of connectivity with highly regarded components with which the P2 doesn't have any easy way to talk: big-huge-and-cheap primary storage (DDR), big-huge-and-cheap secondary storage (SD Card), and fast-deterministic-and-OS-Independent connectivity (Ethernet).

    Not only that, also leveraging the millions of Linux using Raspi owners can be another source for NRE cost funding for a second P2 variant. This idea can be elaborated later ... a Raspberry Pi Hat board PCB prototype can be done next year using one of the first IC samples. But don't know if parallax is willing to try a crowdfounded P2 variant (as a side note to the marketing deparment: crowdfunding projects can be a really effective way to get free media coverage, so it might be worth to try even if the crowdfunding project is not successfully funded).
  • I feel about the same way, though there is an existing market of small to mid sized product design using P1 chips. Expansion in that one is likely.

  • If you concede that a small FPGA and a small Micro is a lower cost solution than a P2, but the issue is tools, why not focus on the tools. As it stands the P2 is also lacking in tool support today.

    In the 12 years since the P1 the industry has moved quite a distance, with true single chip micros, including on chip power supplies, high accuracy oscillators, large on chip Flash, eeprom ... Not to mention built in peripherals a P2 will never have like ethernet, high performance QSPI, SDcard, USB ... On the hobbyist side you have the range of Arduino to RasPi and everything in between. In addition competition of knock offs from China.

    So in the commercial world of as little as 10K units, a $5 saving provides for a lot of engineering time. As has been stated before the target audience is the 1K volume market. To reach 500K units/year you need 500 of those customers. What I have seen of that type of customer it takes them years to get to that kind of volume. So the P2 won't be able to get there quickly.

    The problems the P2 have include

    die size - 8.5 x 8.5 is yuge, those kind of sizes are usually seen in PCs, tablets and cell phones. But the P2 has no where near that kind of capability.
    video - yeah its there but a relatively low resolution, kind of late 80s in screen size/ color space
    analog - big unknown, but I doubt it will be able to do better than 10 bit with all those noisy COGs running on the same die
    debug capabilities - yes 1 COG could be dedicated to looking at Hub RAM, but that doesn't tell you what the other COGs are doing
    off chip support - still requiring multiple supplies, Flash and crystals
    power - still pretty power hungry in comparison to what is available.
    timing - it is still over a year away and the rest of the industry is not standing still

    I get back to the issue of fast or easy development of a micro/FPGA, fix that issue.
  • Gosh! Sure glad you caught this in time! Guess we should just pack it in.

    :D

  • ErNaErNa Posts: 1,738
    Brucee, your doubt seems to be a very good omen ...
  • Heater.Heater. Posts: 21,230
    brucee,

    We know all that. We have known it for years. It is often said that the Propeller 2 should not even try to compete against the huge plethora of devices the likes of which you allude to. You can't beat the big boys at that game.

    Rather, with it's 16 cores, plentiful and flexible IO, deterministic timing and so on the Propeller can do things that those other common or garden parts cannot.

    That is the "thin strata" of applicability I talk about above.

    I'm sure that developing with the P2 will be as drop dead easy and fast as it is for the P1. That is to say perhaps the most easy going development environment in the industry. After the Arduino perhaps but far more capable.





  • And, it does not have to be about beating the big boys. That takes very significant capitalization, among many other things.

    What it is about is a sustainable business that meets expectations. P2 holds a very strong potential there.

  • ErNaErNa Posts: 1,738
    edited 2017-10-01 18:10
    just looking to find an appropriate avatar: https://www.br-spielwaren.de/unsere-rubriken/teddybaeren-und-stofftiere/fantasie-stofftiere/yoohoo-brucee?id=000000000104655001

    Or should I better say: ...Save your energy Rex, we'll do what has to be done!
  • cgracey wrote: »
    At the moment, our fuses are in there, still, but they need elevated VIO voltages to blow.

    Frankly, my plate is overflowing with what I've already got on it. I don't want to add more by trying to incorporate that EE block that will need new hookups and firmware to go with it. I'm just DONE making changes. If anything, I may pull the existing fuses out. I want something that I can be very sure about and simulate without caveats. This makes the chip more reliable, but it will have no code protection.

    If you leave the fuses in then customers would have the option of using them but they would have to consider yield. Leaving the fuses in doesn't make the chip less reliable, does it?

    Sandy
  • cgraceycgracey Posts: 14,133
    edited 2017-10-01 19:23
    cgracey wrote: »
    At the moment, our fuses are in there, still, but they need elevated VIO voltages to blow.

    Frankly, my plate is overflowing with what I've already got on it. I don't want to add more by trying to incorporate that EE block that will need new hookups and firmware to go with it. I'm just DONE making changes. If anything, I may pull the existing fuses out. I want something that I can be very sure about and simulate without caveats. This makes the chip more reliable, but it will have no code protection.

    If you leave the fuses in then customers would have the option of using them but they would have to consider yield. Leaving the fuses in doesn't make the chip less reliable, does it?

    Sandy

    No. The presence of the fuses is not detrimental.
  • Cluso99Cluso99 Posts: 18,066
    P2 with 16x 32bit 160+MHz cores, 0.5MB SRAM, and 64 SmartPins with ADC/DAC, Goertzal, Multiply/Divide, Mac and other maths assistance, makes this P2 a very different micro than any other out there.

    The 16 cores should pique the interest of the media to get publicity.
  • Cluso99Cluso99 Posts: 18,066
    Chip,
    How long before the ROM contents need to be frozen, or have they already?
  • cgraceycgracey Posts: 14,133
    edited 2017-10-01 23:24
    Cluso99 wrote: »
    Chip,
    How long before the ROM contents need to be frozen, or have they already?

    I just have to add some code to randomize the PRNG seed and handle some redundancy issue with the fuses.

    This will need to be wrapped up in less than three months.
  • rjo__rjo__ Posts: 2,114
    edited 2017-10-02 04:06
    brucee,

    I'm with Heater. Go where the competition isn't. Grow your own market. Word of mouth is the best form of advertising. There should plenty word of mouth about the P2:)

    Sometimes, I get the feeling that I am the only true amateur here... which makes me feel obligated to say things that everyone probably knows but don't need to say, because everyone probably already knows it.

    What caused me to choose the P1...knowing absolutely nothing about controllers and very little about programming... was that it seemed to have a very high ceiling and a very low entrance. It was clear that there were some very fine engineers on the forum and that they tirelessly supported new users. What a bargain... what an amazing thing.

    It was dog simple to get into Spin and I knew from the forum that all I had to do was get my toes wet and everything would be fine. I loved the materials... it was clear that if I were an engineer... appropriate materials were available. But being an amateur there were welcoming materials directed squarely at me.

    So long as this ecosystem remains healthy, success of the P2 should be expected.

    You guys worry too much.



  • cgraceycgracey Posts: 14,133
    rjo__ wrote: »
    brucee,

    I'm with Heater. Go where the competition isn't...

    Yes, and never wait in lines!
  • rjo__rjo__ Posts: 2,114
    yep:)
  • cgracey wrote: »
    Ken Gracey wrote: »
    evanh wrote: »
    I'm all for open discussion but financials might be taking it a bit far.

    That said, I will point out, yet again, that Parallax has never been your typical volume producer. They aren't really competing with Microchip or Arm. I'm pretty certain that changes the economic numbers. I suspect it's difficult for them to justify a large markup for low volume educational sales. Lots of customers with limited budgets.

    Which in-turn means no large discounts on higher volumes - unless that high volume customer can singly order enough to lower the per unit fab costs.

    I agree with you - it's really not an appropriate topic to "open source" with customers. Transparency can be taken a bit too far. I can imagine this $5 discussion getting trolled along for a while in the future. These costs are simply a materials cost; they don't reflect R&D, testing, managing, marketing (no matter how minimal it will be), documentation, software, etc.

    Ken Gracey

    Well, I'd be interested to know if I was a customer, just because I like to know how things work. Everyone knows there needs to be markup, and in the west it must be significant. Now, why is bottled water that costs $0.000001 to source more expensive than gasoline?

    Yay, I get to solve a code problem for Chip:

    Read Evian backwards ;)

  • Cluso99Cluso99 Posts: 18,066
    Mickster wrote: »
    cgracey wrote: »
    Ken Gracey wrote: »
    evanh wrote: »
    I'm all for open discussion but financials might be taking it a bit far.

    That said, I will point out, yet again, that Parallax has never been your typical volume producer. They aren't really competing with Microchip or Arm. I'm pretty certain that changes the economic numbers. I suspect it's difficult for them to justify a large markup for low volume educational sales. Lots of customers with limited budgets.

    Which in-turn means no large discounts on higher volumes - unless that high volume customer can singly order enough to lower the per unit fab costs.

    I agree with you - it's really not an appropriate topic to "open source" with customers. Transparency can be taken a bit too far. I can imagine this $5 discussion getting trolled along for a while in the future. These costs are simply a materials cost; they don't reflect R&D, testing, managing, marketing (no matter how minimal it will be), documentation, software, etc.

    Ken Gracey

    Well, I'd be interested to know if I was a customer, just because I like to know how things work. Everyone knows there needs to be markup, and in the west it must be significant. Now, why is bottled water that costs $0.000001 to source more expensive than gasoline?

    Yay, I get to solve a code problem for Chip:

    Read Evian backwards ;)

    LOL. Never knew that!
  • "Yaw Dasani Evian" backwards...
Sign In or Register to comment.