Who do you think will buy the Prop2 ?

189101113

Comments

  • msrobots wrote: »
    By that the P2 is done.

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

    Enjoy!

    Mike
    The sources for the P2-Hot version of PropGCC are in the Parallax GitHub account. You can download them and help with a P2 version of GCC. :-)

  • There are already min. 3 ways to program the P2 in C/C++:
    - Dave Heins "Translater" fom P1-PropGCC to P2
    - Erics ZPU Interpreter
    - Erics RISC-V Emulator

    Andy
  • David Betz wrote: »
    msrobots wrote: »
    By that the P2 is done.

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

    Enjoy!

    Mike
    The sources for the P2-Hot version of PropGCC are in the Parallax GitHub account. You can download them and help with a P2 version of GCC. :-)

    Sadly I can't. The longest C program I ever wrote fits for sure on one or two pages if you print it.

    Some COBOL programs I work on, on the other hand might not be printable at all, with printers available to me.

    Over the last decade I got quite fluent in C#, but never had a employment needing me to use C/C++. And just playing around with a Language - hmm- never gets you to understand it even partially. Not like if you are working daily over weeks/month/years/decades with it.

    For me PropGCC will just be a tool to get COBOL programs running on the P2. I think some features of COBOL would fit quite nicely for stuff I am doing on MCs.

    The SCREEN SECTION for example. Nice TUI interfaces, easy defined. Same for the REPORT SECTION. Nice Reports with Groups and all that, easy defined. DB access build into the language if you can live with ISAM or relative/sequential/dynamic files. Sorting, filtering all build in.

    And since GnuCobol translates to C/C++ interfacing C or other languages is not so complicated.

    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.
  • Did we really have PropGCC for the P2-Hot? I don't remember how far we got before we switched to the P1. Did P2-Hot have hub exec at that time? If so, maybe it's just a matter of updating GAS and the linker. For the most part, PropGCC uses a small subset of the P2 instruction set. It's mostly just rdxxxx, wrxxxx, mov and the basic ALU instructions. The code generator probably wouldn't need a lot of changes.

    The library can be copied from the latest P1 PropGCC version. Maybe this is doable by mere mortals. The linker probably needs a lot of work given the variety of instruction formats used by the P2. Someone that understands the ELF format would need to do that work.
  • Gosh @Ariba,

    I forgot about it, YES, eric did already a ZPU emulator, so GCC can already run on a P2.

    Theoretically.

    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.
  • msrobots wrote: »
    ... Theoretically.

    I think it's more in practice than your COBOL plans... :smile:
  • bobjrbobjr Posts: 13
    edited June 24 Vote Up0Vote Down
    I believe the post from Ken that @msrobots was talking about is this one from 2014:
    Ken Gracey wrote: »
    Those customers have asked for:

    - more RAM
    - faster speed
    - code protect
    - A/D

    . . .and those who didn't use it due to language choices would like efficient use of C.

    Ken Gracey

    Elsewhere, more pins was also mentioned as a goal.
  • Ariba wrote: »
    msrobots wrote: »
    ... Theoretically.

    I think it's more in practice than your COBOL plans... :smile:

    @Ariba,
    yes, sadly. I tried with P1 and PropGCC but my C-fu and Linux-fu is underdeveloped.
    The GnuCobol Project is mostly supported by Linux guys, and I have already a hard time to run it on Windows.

    But I am confident to get there. And I am in no hurry, because I do not need it at all, its just for fun.

    @bobjr,

    YES, thank you!

    That was what I was referring to.

    And welcome to the forum.

    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.
  • Ariba wrote: »
    msrobots wrote: »
    ... Theoretically.

    I think it's more in practice than your COBOL plans... :smile:

    And you have to speak 'Theoretically' in that Russian accent, like in the movie.

    Actually someone got a GnuCobol generated C Program running on some Arduino, with some 'Mesa' Build System and replacing XXX.h files and then he lost me in his description.

    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.
  • Dave Hein wrote: »
    Did we really have PropGCC for the P2-Hot? I don't remember how far we got before we switched to the P1. Did P2-Hot have hub exec at that time? If so, maybe it's just a matter of updating GAS and the linker. For the most part, PropGCC uses a small subset of the P2 instruction set. It's mostly just rdxxxx, wrxxxx, mov and the basic ALU instructions. The code generator probably wouldn't need a lot of changes.

    The library can be copied from the latest P1 PropGCC version. Maybe this is doable by mere mortals. The linker probably needs a lot of work given the variety of instruction formats used by the P2. Someone that understands the ELF format would need to do that work.
    We had GCC for P1 before we had it for P2-hot. No, there was no hub exec at the time but we did support LMM code. I don't think I ever did XMM although that's pretty much been deprecated by Parallax even for P1. You're right that a big first step will be updating GAS. I've started on that by creating a program that reads Chip's instruction spreadsheet to create tables that GAS can use to parse P2 instructions. I just haven't had time to go much beyond that because of having several other paying contracts to work on.
  • jmg wrote: »
    cgracey wrote: »
    I have not thought about making the RESn pin an I/O.
    There are already the natural 64 io, so where would this map ?

    It have not to map to anything. It will be useful that by issuing an internal software reset, beside the prop, the external hardware can be reset also. to bring the external peripherals to their default state.
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 21,024
    edited June 24 Vote Up0Vote Down
    It's not often mentioned, but the nRES pin on the Prop1 is an open-drain output, when nBOE is grounded, in addition to being an active-low reset input. So on power-up, it gets pulled down and can be used to reset external devices. It's a good system, and the same could be done on the P2.

    -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
  • dMajodMajo Posts: 717
    edited June 24 Vote Up0Vote Down
    It's not often mentioned, but the nRES pin on the Prop1 is an open-drain output, when nBOE is grounded, in addition to being an active-low reset input. So on power-up, it gets pulled down and can be used to reset external devices. It's a good system, and the same could be done on the P2.

    -Phil

    Yes, I know this, but is not of much help. After power-up nearly every external part is initialized on its default state. Unfortunately this is not true after an internal software reset eg because of the watchdog timeout.
    ... and enabling BOE enables its mechanism which resets the prop under certain voltage level which is some times not desirable eg on battery powered devices that can run the application below the voltage threshold.
    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • Beau SchwabeBeau Schwabe Posts: 6,268
    edited June 25 Vote Up0Vote Down
    Hi Chip,

    Would a Charge pump approach work if the Charge pump itself were integrated into the programmer?

    See Schematic link below:
    bscircuitdesigns.com/Misc/Propeller_2_Fuse_Programmer_Charge_Pump_Approach.pdf

    T7 would need to handle the normal current load of the Propeller with an appropriate gain.



    Beau Schwabe -- Metallurgical Machine Design and Development Engineer
    ෴My Message෴www.Kit-Start.com - bschwabe@Kit-Start.com ෴෴ www.BScircuitDesigns.com - icbeau@bscircuitdesigns.com ෴෴

    "I've said it before ... If you follow the directions for apple pie and then expect it to taste like cherry pie then your absolutely insane"
  • Hi Chip,

    Would a Charge pump approach work if the Charge pump itself were integrated into the programmer?

    See Schematic link below:
    bscircuitdesigns.com/Misc/Propeller_2_Fuse_Programmer_Charge_Pump_Approach.pdf

    T7 would need to handle the normal current load of the Propeller with an appropriate gain.

    That's quite an approach! I never thought of dropping GND. I think it would mess up ADC and DAC performance, though, even if you did have a jumper to apply for normal use. For brief instances during normal operations, multiple amps might flow through GND. That would cause voltage shifts on GND and make the analog noisy. I thought about just scaling the 1.44um fuse length by 3.3V/5V (width = 0.18um) to make the impedance lower, so that 3.3V would have the same effect as 5V, but all these fuses in different technologies seem to keep an 8:1 length:width ratio. There must be some need for that. At least, it's deemed most reliable.
  • bobjr wrote: »
    I believe the post from Ken that @msrobots was talking about is this one from 2014:
    Ken Gracey wrote: »
    Those customers have asked for:

    - more RAM
    - faster speed
    - code protect
    - A/D

    . . .and those who didn't use it due to language choices would like efficient use of C.

    Ken Gracey

    Elsewhere, more pins was also mentioned as a goal.

    That's correct. Additional I/O is also a common request.
  • It should be. The P1 could make effective use of 64 pins all day long.
    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>
  • I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.

    Second most important requirement is then more RAM.

    Third being more performance. In terms of clock rate, cores and execute from HUB.

    All else is just fluff.

    Whilst I'm here. I consider the fuses to be an anti-feature. Years ago I ended up with a pile of AVR's that I could no longer use as their fuses had been set wrong [1]. In frustration I looked for something else. And that's how I found the Propeller.

    [1] Yeah I know. Mostly my fault for insisting on using my own home made programmer hardware and opensource programming tools on Linux. But still.

  • jmgjmg Posts: 10,208
    Heater. wrote: »
    I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.

    Another approach to 'more IO pins' would be for Parallax to offer an IO Expander, along with a Library for P1.
    Choices could be a modest MCU, or a small CPLD.

    Cheapest 44 pin MCU I can find is AT89LP51-20MU, 62c/100 for under 2c/io, that can link using SPI to a COG.

    For more pins, or faster links, the LAMXO256C-3TN100E (TQFP100) shows as being $1.75/100 with 78 I/O, or just over 2c/io
    The LAMXO256C-3TN100E price shows at many Disti, and on Lattice website, but other family members are more $, - perhaps that's the preferred item, tho not stocks are huge ?
    LCMXO256C-3TN100C shows at $2.20/1k, and LCMXO2-256HC-4SG48C is $2.75/1k
  • I meant more pins as more than the 32 on the P1. Especially as the P1 was all set to get 64 pins in some future version which never happened.

    I/O expanders are great and all. But then you lose the tight coupling between processor and I/O which is one of the Propellers unique selling points. I have certainly wanted to bit bang more than 32 pins with the speed and ease that that the Propeller can do.
  • jmg wrote: »
    Heater. wrote: »
    I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.

    Another approach to 'more IO pins' would be for Parallax to offer an IO Expander, along with a Library for P1.
    Choices could be a modest MCU, or a small CPLD.

    Cheapest 44 pin MCU I can find is AT89LP51-20MU, 62c/100 for under 2c/io, that can link using SPI to a COG.

    For more pins, or faster links, the LAMXO256C-3TN100E (TQFP100) shows as being $1.75/100 with 78 I/O, or just over 2c/io
    The LAMXO256C-3TN100E price shows at many Disti, and on Lattice website, but other family members are more $, - perhaps that's the preferred item, tho not stocks are huge ?
    LCMXO256C-3TN100C shows at $2.20/1k, and LCMXO2-256HC-4SG48C is $2.75/1k

    That was considered some years ago on this forum and went nowhere. Lots of talk then silence.

    The problem is if you scaled up the CPLD/FPGA just a bit, the P1 was no longer necessary. Since all the FPGA vendors provide their own soft MCU cores that range from 8 to 32bits with real time options - all you had to do is roll in a couple of those cores into your VHDL or Verilog code and you have your own homebrew P1 alternative and don't have to worry if the P2 never gets made. which may be the case now,

    The other issue was, if the P1 needed that much help, maybe it's time to consider another more modern MCU that has the I/O lines.
  • jmgjmg Posts: 10,208
    Heater. wrote: »
    I meant more pins as more than the 32 on the P1. Especially as the P1 was all set to get 64 pins in some future version which never happened.

    I/O expanders are great and all. But then you lose the tight coupling between processor and I/O which is one of the Propellers unique selling points. I have certainly wanted to bit bang more than 32 pins with the speed and ease that that the Propeller can do.
    Of course, there is no free lunch, there is some speed penalty for IO.

    A quick napkin test, suggests AT89LP51-20MU can do a 32b Read and Write in just under 20us, clocked from P2 5MHz, consumes 3 SPI pins to do so.
    Plenty of IO tasks are fine with 20us R&W, (keyboards, LEDs, relays, Power control etc) and those that do need highest speed you map on the P1, not the IO expander.
  • We currently buy around a 100 propeller chips a year, and if the learning curve is not too difficult and the advantages manifest, we would begin to switch over to propeller 2. In a few years we would like to be buying 1000's.
  • XMOS aquired setem http://www.eedesignnewseurope.com/news/xmos-acquires-setem-technologies-further-develops-voice-hmi-focus
    I just read an article on beam forming to follow speakers in a crowd. P2 with all the analog input capabilities could be the base for such a solution that can detect signal sources due to the fact, that more mikes can be attached and the phase relations between different signals could be determined by the parallel working cogs.
  • I noticed that the "Firsties" (FIRST Robotic Competitors) don't always use their sponsors products.

    Perhaps it is time for some of that business to come back to Parallax.
  • I noticed that the "Firsties" (FIRST Robotic Competitors) don't always use their sponsors products.

    Perhaps it is time for some of that business to come back to Parallax.

    Thank you for the recognition. Truthfully, I think there are valid reasons for many to switch over to Parallax. Organized travel and competition isn't really one of them (which is a strength of FIRST) but the following reasons are:

    - parallel Blockly/C tutorials means every student has something of interest
    - Propeller Multicore support with a focus on electronics, sensors and programming
    - free tutorials and assessment material for elementary through high school
    - a one robot per student model at less than $200/kit (with ActivityBot); every student gets experience
    - plenty of add-ons (ultrasonic scanning sensors, line followers) for in-class competitions
    - the most complete (and free) Blockly system
    - Chromebook support
    - a product line with depth, allowing students forward progression to product development

    We're currently noticing an increase in our business. Professional development courses around the country are filled; we're out of ActivityBots; new customers are asking many questions and switching over from other platforms. We haven't seen this kind of activity in years so it's encouraging.

    But I work at Parallax, so it's best heard from an educator https://www.parallax.com/news/2017-07-13/customers-applaud-blocklyprop-fall-semester-promises-be-most-exciting-ever-our

    Thank you again for the plug.

    Ken Gracey

  • Ken Gracey wrote: »
    We're currently noticing an increase in our business. Professional development courses around the country are filled; we're out of ActivityBots; new customers are asking many questions and switching over from other platforms. We haven't seen this kind of activity in years so it's encouraging.
    Wow! That's great news. Congratulations! Finally people seem to be seeing the value of your excellent products and support.

  • Coming back to the original question of this thread, asking for Prop II applications:

    We are using the Prop 1 in small quantities as main processor in a measurement instrument for several years now.
    It works fine and is reliable, software maintenance is easy (Spin + ASM).

    For the Prop II (which I hope, will come into my hands before my retirement) I see the best application as very, very intelligent I/O processor
    as realtime slave of an ARM XXX running with Linux or similar. We have such project/board in our drawer for years, realized with the Prop I as prototype,
    but still waiting for the Prop II. By the way: will the Prop II also be produced in Austria?
    Regards
    Markus

  • jmgjmg Posts: 10,208
    MGreim wrote: »
    By the way: will the Prop II also be produced in Austria?
    Prop 2 is being fab'd by OnSemi.

  • I raised the same question earlier, but I'm at a loss to trace where that idea came from. It does seem that AMS was mentioned at one time as a possible fab, though.

    -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
Sign In or Register to comment.