Who do you think will buy the Prop2 ?

11012141516

Comments

  • cgracey wrote: »
    Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown.

    How wonderfully last century. I don't think I've used a chip that needed a special voltage to program it since the days of the 2764.
  • cgracey wrote: »
    A bunch of resistors were resized to become their proper values. They all got shortened.
    ...
    I have not thought about making the RESn pin an I/O.

    All the padframe layout changes are done and we are waiting for a shuttle.

    Hi Chip

    Thanks for answering my post.

    More on the fuses's subject, later...

    @Chip, @jmg et. al.

    In the subject of making the Reset pin an I/O, sorry by not being as clear as I needed to be, due to differing mother's language barriers, but I didn't intended for Reset to be a part of the 64 bit I/O block.

    I've been thinking in something closer to JMG's latter post, perhaps with the addition of a new instruction that could control the setup of two variables; one to set the minimum External Reset pulse width that is to be allowed to pass in, before it can be even sensed as a valid one, thus effectivelly reseting the P2, and the other, controlling how long will last the internally generated Reset pulse, driving the Reset pin, to properly initialize any externally connected devices.

    The same instruction, with perhaps zero as the minimum acceptable External Reset pulse lenght, can fire an internally generated Reset pulse, whose lenght will be controlled by the second field.

    And finally, by defining a non-zero value for the minimum acceptable external reset pulse, and simultaneously, a zero lenght for the internally generated one, could be used to "mute" the output capability of the Reset pin, letting it with almost the same functions as it initialy has been designed.

    Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures, thus defining the first internally generated Reset pulse period, if any, and enabling the P2 to be the solelly one to drive any board or system Reset line, during and perhaps just after each power cycle.

    This way, by inspecting the lenght of the first internally generated Reset pulse, available at the Reset pin during and shortly after (register-contents defined) each power cycle, one can be assured that P2 has completed its internal reset procedures.

    Henrique
  • Yanomani wrote: »
    ...., one can be assured that P2 has completed its internal reset procedures.

    Henrique

    Surely users code could set an IO pin state to achieve that, without requiring this special reset function?

  • Seairth wrote: »
    cgracey wrote: »
    I have not thought about making the RESn pin an I/O.

    Good. Keep on not thinking about it. :)
    +1E6

    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • YanomaniYanomani Posts: 380
    edited June 22 Vote Up0Vote Down
    Hi Chip

    ... about fuses.
    cgracey wrote: »
    I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.

    None crazy sounding, yet... :o

    In fact, perhaps we are closer to have some nice wookey frying pans, to blow fuses, inside...

    I believe you've talked about each fuse's blowing circuit having a large PMOS device to deal with the needed (and now known to be 5V @ 35mA, lasting under 1mS) power.

    If ONC18: G/MS is the target proccess and accordingly to the following OnSemi document, page 3, they can have 3.3V Gate / 15V Drain PLDMOS with Rsp = 34.5 mOHMs*mm2 devices.

    https://onsemi.com/pub/Collateral/ONC18GMS-D.PDF

    Such a low on resistance would minimize losses due to the 35mA programming current, preventing much lower than the intended 5V programming voltages to finally hit the target fuse to be blown.

    Also, on page 6 of the same document, they show several options for the 3.3V I/O circuits as being 5V tolerant, but with modest current limits of 24 or even 16mA.

    Any way, and this should be noted, rated at design dimensions that are well under the ones settled at the current pad frame you have specified, then, IMHO, we are at the safe side area on this subject.

    Also at the same document, on page 4, they show the availability of OTP (Sidense Oxide Rupture OTP IP) in two flavours (page 7); 1 kbit and 256 kbit instances!!!

    To the extent of my readings, no increased mask count for any of the above, but I can say nothing about the cost of using Sidense IP, if anything will be charged or not.

    Hope it helps a bit (or a bunch of fuses). :D

    Henrique

  • jmgjmg Posts: 10,343
    Yanomani wrote: »
    @Chip, @jmg et. al.

    In the subject of making the Reset pin an I/O, sorry by not being as clear as I needed to be, due to differing mother's language barriers, but I didn't intended for Reset to be a part of the 64 bit I/O block.

    I've been thinking in something closer to JMG's latter post, perhaps with the addition of a new instruction that could control the setup of two variables; one to set the minimum External Reset pulse width that is to be allowed to pass in, before it can be even sensed as a valid one, thus effectivelly reseting the P2, and the other, controlling how long will last the internally generated Reset pulse, driving the Reset pin, to properly initialize any externally connected devices.

    The same instruction, with perhaps zero as the minimum acceptable External Reset pulse lenght, can fire an internally generated Reset pulse, whose lenght will be controlled by the second field.

    And finally, by defining a non-zero value for the minimum acceptable external reset pulse, and simultaneously, a zero lenght for the internally generated one, could be used to "mute" the output capability of the Reset pin, letting it with almost the same functions as it initialy has been designed.

    Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures, thus defining the first internally generated Reset pulse period, if any, and enabling the P2 to be the solelly one to drive any board or system Reset line, during and perhaps just after each power cycle.

    This way, by inspecting the lenght of the first internally generated Reset pulse, available at the Reset pin during and shortly after (register-contents defined) each power cycle, one can be assured that P2 has completed its internal reset procedures.
    a) the problem, with any register-params around reset, is they are not known at power up, so you cannot do "Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures"
    Instead, some special ROM/Fuse based defaults must be forced, to at least get reset to a working point.

    b) I'm still unclear, but I think you are now talking about a BIDIRECTIONAL RESET pin, allowing "one can be assured that P2 has completed its internal reset procedures"

    Yes, that operation is a more common - some MCUs do have a N_FET on their Reset pin, and this allows them to reset other devices, on a WDOG or SW-reset.
    It can also be used to pulse stretch a narrow reset, and you could use it to signal across many P2's that the slowest one is (close to) ready.
    This does not need fancy pulse width window registers, just a N_FET.

    Making a reset pin Open-Drain is lower risk, than 'trying to make it too clever'.
  • Ken GraceyKen Gracey Posts: 6,011
    edited June 23 Vote Up0Vote Down
    My only concern with Blockly is that Parallax is trusting Google to continue supporting it. But that trust may be misplaced, given Google's track record. More than once they've pulled the rug out from under developers who relied upon their tools.

    I developed some great apps for my robotics class that relied upon the Google Earth API. Well, guess what? They deprecated it without a viable alternative, and all the work I did is now for naught.

    I'd really hate to see that happen to Parallax, since they've put so much energy and capital into Blockly.

    -Phil

    I appreciate the honest concern about our well-being. This particular reliance is not a concern and I don't want people to get the idea that we'll be pulling the rug out from under them because Google decides "Blockly is OVER!". We took a copy of the Google Javascript engine and libraries and we build around it. It's open source license, and it doesn't matter what Google does with the project. In fact, they've already moved on to work with MIT on Scratch Blocks.

    Now, a Blockly port lives on our servers and we don't need anything from them, unless they release some new components in Blockly we wish to add to our system. Even without them, we're adding graphing and other neat tools.

    If you have concerns about viability of any program's hardware, software, company or vision, I could give you a long list that are of higher priority (component obsolescence is a big one, for starters!).

    Ken Gracey



  • jmg wrote: »
    Blocky seems to tolerate white spaces in function names, and the quotes suggest there may be leading and trailing spaces too ?
    That's probably not the best idea for moving to any other language ?

    Sure, an improvement could be made in this regard with some "Blockly syntax rules".
  • jmg wrote: »
    Ken has said they are open to the idea of crowd funding.
    Sounds ok to me, and my feeling is they need something tangible they can deliver as milestones, hence FPGA is logical.

    I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.

    Ken Gracey
  • jmgjmg Posts: 10,343
    Ken Gracey wrote: »
    jmg wrote: »
    Blocky seems to tolerate white spaces in function names, and the quotes suggest there may be leading and trailing spaces too ?
    That's probably not the best idea for moving to any other language ?

    Sure, an improvement could be made in this regard with some "Blockly syntax rules".

    Sounds worthwhile.
    One detail that helps in any language tool chain, is being able to search/find the outermost source labels, in the mid-level files, be they reports,MAP files, List Files, or intermediate generated source files.
  • Ken Gracey wrote:
    It's not a concern and I don't want people to get the idea that we'll be pulling the rug out from under them. We took a copy of the Google Javascript engine and libraries and we build around it. It's open source license, and it doesn't matter what Google does with the project. Now it lives on our servers and we don't need anything from them, unless they release some new components in Blockly we wish to add to our system.
    Ken, it's good to know that Parallax has total control over Blockly. Given Google's track record, I'm sure that was a priority, but I just wanted to make sure.

    BTW, I'm not sure how you extrapolated from Google pulling the rug out from under you to Parallax doing that to their customers. You and your customers would both have been the victims in such a scenario, and Parallax would have been blameless. Thankfully, neither will come to pass.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • YanomaniYanomani Posts: 380
    edited June 23 Vote Up0Vote Down
    Hi jmg
    jmg wrote: »
    a) the problem, with any register-params around reset, is they are not known at power up, so you cannot do "Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures"
    Instead, some special ROM/Fuse based defaults must be forced, to at least get reset to a working point.

    b) I'm still unclear, but I think you are now talking about a BIDIRECTIONAL RESET pin, allowing "one can be assured that P2 has completed its internal reset procedures"

    Yes, that operation is a more common - some MCUs do have a N_FET on their Reset pin, and this allows them to reset other devices, on a WDOG or SW-reset.
    It can also be used to pulse stretch a narrow reset, and you could use it to signal across many P2's that the slowest one is (close to) ready.
    This does not need fancy pulse width window registers, just a N_FET.

    Making a reset pin Open-Drain is lower risk, than 'trying to make it too clever'.

    Thanks to you by clarifying this subject. I was wrong, because I've understood that a procedure very similar to the one adopted making the boot process accessible just after the reset period, could be used to pre-load the reset pin behavior control registers I've imagined, during the power-on reset cycle.

    This could provide some means to extend its duration (valid reset pulse), to ensure every connected device can timely complete its internal reset procedures.

    And yes, you are right again; in my mind (interpretation), an I/O pin and a bidiretional pin are the same thing. Now I know that this is not the right interpretation of their behavior.

    This also clarifies my view of P2 pins; internally, they are bidiretional in nature. Externally, their behavior depends on many factors, including any override provided by programming then into any smart mode that controls the output state.

    Henrique
  • David BetzDavid Betz Posts: 11,420
    edited June 23 Vote Up0Vote Down
    Ken Gracey wrote: »
    jmg wrote: »
    Ken has said they are open to the idea of crowd funding.
    Sounds ok to me, and my feeling is they need something tangible they can deliver as milestones, hence FPGA is logical.

    I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.

    Ken Gracey
    Parallella still seems to be around. You can buy a board from them with their chip on it for $99.

    https://www.parallella.org
  • jmgjmg Posts: 10,343
    Yanomani wrote: »
    This could provide some means to extend its duration (valid reset pulse), to ensure every connected device can timely complete its internal reset procedures.
    If that is the purpose, the Open Drain reset pin allows that, and more (eg SW & WDOG can do a system wide reset).
    Problem is, I don't think Chip has allowed for an Open Drain Reset Pin so such 'system usefulness' discussions are moot.

  • jmgjmg Posts: 10,343
    edited June 23 Vote Up0Vote Down
    Ken Gracey wrote: »
    jmg wrote: »
    Ken has said they are open to the idea of crowd funding.
    Sounds ok to me, and my feeling is they need something tangible they can deliver as milestones, hence FPGA is logical.

    I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.
    Yes, my point was really to make final P2 silicon a stretch goal, there are other more practical milestones that can be delivered via a module, that can keep interest levels up.
    On present FPGA price curves, it looks like a full P1V, and (or) some useful subset of P2, could be done.

    Along the way, the whole P2 software eco system is a vital, but less tangible deliverable.

    The intel example shows that doing the opposite - as in having silicon, before your software and docs are viable, is not a key to success.

  • Seriously... after 11 years, they are wondering if they should finish it? If nothing else, to update the original line and compete in the same areas where others have advanced. I, however, noted in my now DELETED post about my dismay over how long this has taken. I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide... THOUSANDS of chip sales for this.. but with so many delays and the hardware portable portion is all that is left, I had to pull the trigger yesterday and start looking at other options. Love the prop, and I'll play with the prop2 if it comes out before I die...

    So to answer your question, I WOULD have 10's of 100's personally...
  • veluxllc wrote: »
    Seriously... after 11 years, they are wondering if they should finish it? If nothing else, to update the original line and compete in the same areas where others have advanced. I, however, noted in my now DELETED post about my dismay over how long this has taken. I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide... THOUSANDS of chip sales for this.. but with so many delays and the hardware portable portion is all that is left, I had to pull the trigger yesterday and start looking at other options. Love the prop, and I'll play with the prop2 if it comes out before I die...

    So to answer your question, I WOULD have 10's of 100's personally...

    I don't know who deleted your post, but I wanted to respond to it.

    I'm not sure what to say.

    I understand your frustration. You should figure that it sucks to be me, too. There is a mountain of effort into this project that is not yet realized as anything we can sell. The world keeps changing, meanwhile. Even the culture surrounding technology has morphed greatly. I'm doing my best to bring this to completion. And, yes, there's been a ton of tinkering along the way.

    Hopefully, this gets done soon and we can all enjoy some benefit from it.
  • Post has been restored.
    Infernal Machine
  • veluxllc,
    I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide...
    I'm curious. What is it about the requirements for this system that would call for the real-time capabilities of the P2 ? Why has it's development been waiting for the P2 when there are millions of devices out there for ages now that could do it?
  • Chip

    Please do not let the bull get to you, especially to the point of explaining your grief to an inactive member. It is very difficult to design and develop stuff, especially when you have a specific vision for your creation, but the funds are limited.

    Just keep your nose to the grindstone, and if that wears down to nothing, then choose an ear :)

    Seriously, I look forward to seeing the efforts of your labor, as well as all the support from the forum that has gone into this chip. As they say, you cannot rush success. Just have a well established plan ready for distribution, once the chip actually goes into production.

    Wishing you and Parallax all the best.


    Novel Solutions - http://www.novelsolutionsonline.com/ - Machinery Design • - • Product Development
    "Necessity is the mother of invention." - Author unknown.

  • idbruce wrote: »
    Just keep your nose to the grindstone, and if that wears down to nothing, then choose an ear :)

    Good one Bruce!



  • I don't know why Blocky needs the P2, wouldn't the money be better spent on software tools?

    I don't see a large market for the P2, it is just too slow to bit bang most of the modern serial/semi parallel interfaces and it is too power hungry for battery operations. Can you really make it with a handful of 1K/year customers? Maybe when you get to the P5, it might be fast enough to be competitive.

    But how do you afford the mask charges for a 40-60 nm process? I would suggest going with MOSIS multi-project die to build a small number of modern chips. If it really would be a player, better to have some samples for potential large customers and seed the forum base with parts to do demos. Yes you would have to abandon the analog, or do a big redesign (analog does not scale like digital). Other than that the P2 won't expand the current Propeller market much.
  • Education wants it and they pay. Simple enough.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Education wants it and they pay. Simple enough.

    What do they really want? More speed, more memory, more ???
  • potatoheadpotatohead Posts: 8,812
    edited June 23 Vote Up0Vote Down
    Lots of things. Props make really good learning platforms there's a number of reasons for this how the cogs work being able to bit bang clean Assembly Language in the P2 they'll be lots of spiffy functions on the chip...
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • jmgjmg Posts: 10,343
    brucee wrote: »
    I don't know why Blocky needs the P2, wouldn't the money be better spent on software tools?
    I don't see anyone saying Blocky needs P2, indeed the fact Blocky is shipping right now on P1, rather proves that point.
    brucee wrote: »
    I don't see a large market for the P2, it is just too slow to bit bang most of the modern serial/semi parallel interfaces ...
    Almost any chip is too slow to bit bang most of the modern serial/semi parallel interfaces, so that point means little.
    The 'Modern Serial Interfaces' cover a huge dynamic range - newest ones are GBit in speed, and clearly need custom silicon support.
    P2 was never going to play in that sand pit anyway.

    More important to P2, and the mid-level, highest volume serial interfaces like QuadSPI, HyperBUS and USB.
    So far, P2 look to have those reasonably well covered (tho I'm not sure on latest USB-Build-phase?)
    Certainly, the streamer design has the bulk transport covered, it may be some pin-level tweaks are needed to get best performance & control.
    brucee wrote: »
    ... and it is too power hungry for battery operations.
    That rather depends on the size of the battery... ;)
    Quadcopters are battery operated, and they certainly are not 'mA paranoid', but the P2 is not even in the right package to chase the smallest, most portable coin-cell designs.

    Chip has been improving the Time to (Re)Start, which is one place P2 system design can do something to expand the market.
  • msrobotsmsrobots Posts: 1,639
    edited June 23 Vote Up0Vote Down
    brucee wrote: »
    Education wants it and they pay. Simple enough.

    What do they really want? More speed, more memory, more ???

    Actually @Ken provided that info some years ago. I can't find the post, so just my memory. (not sure about order and completeness).

    1. C support.
    2. more memory.
    3. more pins.
    4. analog pins.
    5. higher speed (more commercial customers then educational ones)
    6. Debug capability
    7. native LMM support (for C) - not sure about that, @Bill Henning might remember, it is almost a decade ago.
    8. more COGs

    that was, as far as I remember, the primary list of stuff needed.

    Enjoy!

    Mike


    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • By that the P2 is done.

    Except full fleshed out C/C++ support. But I will keep nagging there.

    Enjoy!

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 12,737
    edited June 24 Vote Up0Vote Down
    IIRC the points were

    Faster
    More HUB RAM
    Security
    More I/O

    I am sure there was a fifth point. Pretty sure it was not analog.

    Basically it was a P1+

    Could have been done years ago. Could be done for the next shuttle too and an extremely high chance of success except for the fuses.

    P2 will require another pass. Goodbye 2017.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • yeah, I forgot security. That was a main point.

    not sure about analog either, but C support and Debug where in there, if I am not senile yet.

    @Publison, our God of Archive's, do you maybe can find that post of @Ken about what the customers wanted in 200x?

    Enjoy!

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.