It's been so quiet around here.

2

Comments

  • I'm a little concerned about the current incoherence surrounding language implementations for the P2. I believe that there should be one C, one C++, one BASIC, and one Spin to which Parallax gives its blessing and internal customer support. (TAQOZ, of course, is in a world of its own and deserves its own category. :) ) Better yet, would be to have library objects interoperable among the several languages to avoid splintering that support even further. Otherwise, Parallax's customers are going to be confused by a plethora of options, which will ultimately be a turn-off to the P2 in general. I think it's up to Parallax to maintain a coherent message about development options and to give its imprimatur to the best of those options being developed independently or in-house and to bring its tech people up to a level that they can support each of those options intelligently.

    -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
  • jmgjmg Posts: 13,522
    I'm a little concerned about the current incoherence surrounding language implementations for the P2. I believe that there should be one C, one C++, one BASIC, and one Spin to which Parallax gives its blessing and internal customer support.
    Did you mean 'at least one' ?
    With the community doing their own development, it is impossible to hope to regulate a single winner. Even within a language there are multiple approaches, and none is a silver bullet.
    Do you want native PASM code generate, or Byte Code, or some VM emulation ? Do you want a compiler, or an interpreter ? Or even a mix, within a single project ?

    Looking at what other chip vendors do, they support multiple versions of C, but they do drive a preferred Debug file format, and offer Eval Boards, with inbuilt Debug bridges.

    I think Parallax would be better focusing on that debug side, so that users are able to Step/Break/Watch in any language they might choose, from whoever.


  • I'm a little concerned about the current incoherence surrounding language implementations for the P2. I believe that there should be one C, one C++, one BASIC, and one Spin to which Parallax gives its blessing and internal customer support. (TAQOZ, of course, is in a world of its own and deserves its own category. :) ) Better yet, would be to have library objects interoperable among the several languages to avoid splintering that support even further. Otherwise, Parallax's customers are going to be confused by a plethora of options, which will ultimately be a turn-off to the P2 in general. I think it's up to Parallax to maintain a coherent message about development options and to give its imprimatur to the best of those options being developed independently or in-house and to bring its tech people up to a level that they can support each of those options intelligently.

    -Phil

    Well FastSpin does exactly that, you can use objects written in one language from any other and vice versa. You have a serial driver in Spin but like to program in C and use it - works perfect.

    Following your concern Parallax should hire @ersmith and send Chip into some well deserved Vacation.

    One BASIC one C one SPIN, all the same libraries (or at least compatible) one compiler.

    As one would say in German "Die eierlegende Woll-Milch-Sau" -> "The egg laying Wool-Milk-Hog"

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    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.
  • jmg,

    You have to remember who Parallax's customers are. Many of them are not the same ones who will be buying chips from IC vendors and designing their own systems, but rather educators and less experienced users who want a coherent presentation and the support behind it. I'm sure things will eventually come together for these people, but the language stuff seems quite scattered right now. 'Part of the disadvantage of seeing the sausage made, I suppose. :)

    -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
  • It's quiet because we are all in shock at the realisation you are 'writing spin in 0x86 assembler'

    If you want community support - you are better off to write in a language the community can understand and contribute to.

    It's bad form to put out an 0x86 assembler tool and then expect someone else (Roy?) to convert it to c++ or something else others can understand before anything can happen.

    Chip, do us all a favour, Stop right now on the x86 assembler, spend a few days ( what's a few days in 12 years ) to learn c++ or even better c# and put out at least the core tools ( PNUT, SPIN ) in a language that the community can actually contribute to.

    I for one tried to get allocation addresses to support a debug and emulation tool I have developed for P1 and could not get what I needed from existing tools and could not readily modify OpenSIM to get what I needed either and so gave up and benched the entire project.

    x86 assembly. Really?

  • David Betz wrote: »
    Could the RISC-V JIT P2 compiler be made to optionally support a RISC-V compressed instruction set to get better code density?

    Yes. It would take a bit of work, of course, but that's one of the reasons I've been working on the trace cache version (the original cache version assumed that instructions were all 4 bytes long).

  • VBBSim,
    Chip knew the already working options before he started this. You're way way too late bleating now.

    And he's already said he is working towards redoing it in Spin2. So it won't be x86 in the end.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • cgraceycgracey Posts: 11,129
    edited 2019-06-10 - 14:30:16
    VBBSim wrote: »
    It's quiet because we are all in shock at the realisation you are 'writing spin in 0x86 assembler'

    If you want community support - you are better off to write in a language the community can understand and contribute to.

    It's bad form to put out an 0x86 assembler tool and then expect someone else (Roy?) to convert it to c++ or something else others can understand before anything can happen.

    Chip, do us all a favour, Stop right now on the x86 assembler, spend a few days ( what's a few days in 12 years ) to learn c++ or even better c# and put out at least the core tools ( PNUT, SPIN ) in a language that the community can actually contribute to.

    I for one tried to get allocation addresses to support a debug and emulation tool I have developed for P1 and could not get what I needed from existing tools and could not readily modify OpenSIM to get what I needed either and so gave up and benched the entire project.

    x86 assembly. Really?

    The current path is almost complete using x86. I know it seems so retrograde, but that's where my momentum is. I could have had it running a few weeks ago, but have rethought a lot of the interpreter code which is in P2 assemlbly language. That is almost done and then I will go back to the x86 Spin2 compiler code and make the corresponding adjustments. After that, PNut will start compiling Spin2, not just pasm. I want to get it running before rewriting the complier in a high-level language, hopefully in Spin2, itself. A tiny bytecode interpreter could be written in C that would run it.
  • Like Mickster said, the P2 is a dream motion controller. I already have the 6 axis stuff functioning and it works great for steppers without the feedback if you are careful with the speed and ramping. I'm able to step 6 axis at somewhere around 3 million steps per second. ( not that my machines can do anything like that) My next step was to convert the step and direction code into DC motor control with the encoder feedback. However, without the Quadrature decoding circuits working I'm in a holding pattern for the next silicon.

    My code is at the point where a block of movement data ( steps, start speed, max speed, ramp speeds, etc. ) is transferred from hub memory to cog memory . One cog is actively moving the 6 axis while another is pre-computing the next steps/speeds and buffering them for immediate motion switching between movement segments.

    I was starting on a G-code interpreter, but got side-tracked on another project. Is anyone else working on motion control? As it is right now, my code would work great for a non-feedback 3d printer with a G-code interpreter hooked in. I'd love to have a "Real" project to aim the DC motor stuff at. ( as in very rapid traverse 3d printers, lasers, micron resolution robots, brushless motor control, etc. )
  • It's been so quiet around here.

    I am still hanging around in the background, but my mother died a couple of months ago and I really haven't been in the mood to participate. I am still patiently awaiting a complete P2 Proto or Project board.


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

  • jmgjmg Posts: 13,522
    kbash wrote: »
    ... My next step was to convert the step and direction code into DC motor control with the encoder feedback.
    However, without the Quadrature decoding circuits working I'm in a holding pattern for the next silicon.

    Does this mode still work ?
    %01101 = Accumulate A-input positive edges with B-input supplying increment (B=1) or decrement (B=0)
    or are all modes with decrement broken ?

    or a pair of counters using
    %01100 = Count A-input positive edges when B-input is high
    might give a workaround Quadrature encoder ?
  • cgraceycgracey Posts: 11,129
    edited 2019-06-10 - 21:06:00
    jmg wrote: »
    kbash wrote: »
    ... My next step was to convert the step and direction code into DC motor control with the encoder feedback.
    However, without the Quadrature decoding circuits working I'm in a holding pattern for the next silicon.

    Does this mode still work ?
    %01101 = Accumulate A-input positive edges with B-input supplying increment (B=1) or decrement (B=0)
    or are all modes with decrement broken ?

    or a pair of counters using
    %01100 = Count A-input positive edges when B-input is high
    might give a workaround Quadrature encoder ?

    The modes that are broken in the first silicon are the ones which could either increment or decrement:
    01011 = a-b quadrature encoder
    01101 = a-rise & b-high inc / a-rise & b-low dec
    01110 = a-rise inc (!y[0]), a-rise inc / b-rise dec (y[0])
    01111 = a-high inc (!y[0]), a-high inc / b-high dec (y[0])
    

    I think your quadrature alternative would work with a little extra housekeeping.
  • I've been lurking for quite a while watching P2 and can't wait to get my hands on some silicon. (Just barely missed getting one of the first batch!!) I've recently used the P1 as a low-power EtherCAT slave with a LAN9252 at work and we've been pretty impressed with its flexibility, but it sounds like the P2 will completely blow it out of the water.

    In my other job I develop high-performance electric vehicle inverters, and I am itching to port over from a TI DSP chip to something that's actually nice to program. I can't tell you how much time I've spent pouring over technical reference manual notes (1762 pages!) when I could have written a bit of assembly, not to mention being able to sample a huge number of ADC pins simultaneously.
  • cgraceycgracey Posts: 11,129
    edited 2019-06-11 - 01:57:16
    ntosme2 wrote: »
    I've been lurking for quite a while watching P2 and can't wait to get my hands on some silicon. (Just barely missed getting one of the first batch!!) I've recently used the P1 as a low-power EtherCAT slave with a LAN9252 at work and we've been pretty impressed with its flexibility, but it sounds like the P2 will completely blow it out of the water.

    Welcome, Ntosme2.
    In my other job I develop high-performance electric vehicle inverters, and I am itching to port over from a TI DSP chip to something that's actually nice to program. I can't tell you how much time I've spent pouring over technical reference manual notes (1762 pages!) when I could have written a bit of assembly, not to mention being able to sample a huge number of ADC pins simultaneously.

    Ha, yes, I really think we will shine in understandability and we'll have performance to match. I don't have the stomach, anymore, to make time and energy investments in things that cannot be understood or actually controlled. I don't like the rug potentially being pulled out from under me, either, or feeling like a guest making requests. I want to feel like I own it and be able to control it absolutely. The P2 should impart a solid sensibility and give people the confidence they need to really make things, instead of virtually hot-gluing pipe cleaners to chunks of styrofoam or feeling unwelcome in a byzantine mess of over-wrought complexity. The P2 is going to work right alongside your brain.
  • I'm busy working on P2 debugging tools and preparing for Spin2 testing.
    Lots of P2 stuff rattling around in head at the moment. :)
    Melbourne, Australia
  • I was over at my brothers place on the weekend. On his coffee table, he had this cool book about the Spectrum microcomputer, with interviews with many programmers and designers, including Baggers talking about the games he ported across and some of the 'easter eggs' he coded in.

    Those days seemed pioneering, creative programmers were having a go at all sorts of things. It was quite an interesting read, believe it might have been a kickstarter project

  • I got the ENC28J60 drivers working under FastSpin, which is a very big deal for me that nobody else seemed too interested in. That sold literally hundreds of P1 boards, mostly quickstarts with daughterboards and custom enclosures. And that was all what I call "glue" functions. With P2 I expect to be able to put the business logic on the propeller too, which opens up worlds.
  • jmgjmg Posts: 13,522
    ntosme2 wrote: »
    In my other job I develop high-performance electric vehicle inverters, and I am itching to port over from a TI DSP chip to something that's actually nice to program....
    What power and frequency do these run at ?
    P2 should be able to interface to any number of isolated ADCs on the sense side.
    If you needed dithered PWM, for finer control, a COG could be dedicated for that.

  • @cgracey
    I have been trying to get different modules to work, i.e. gps, 3 axis gyro and others not too successful but continuing to work on it.
  • localroger wrote: »
    I got the ENC28J60 drivers working under FastSpin, which is a very big deal for me that nobody else seemed too interested in. That sold literally hundreds of P1 boards, mostly quickstarts with daughterboards and custom enclosures. And that was all what I call "glue" functions. With P2 I expect to be able to put the business logic on the propeller too, which opens up worlds.

    I've been using the more powerful and easy to use W5500 chip for many years now. I will probably expand the functionality and protocols with P2 which it already works with, for many years also. Besides basic modes I have Telnet, FTP, and HTTP servers running on the P1 and P2.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Tubular wrote: »
    I was over at my brothers place on the weekend. On his coffee table, he had this cool book about the Spectrum microcomputer, with interviews with many programmers and designers, including Baggers talking about the games he ported across and some of the 'easter eggs' he coded in.

    Those days seemed pioneering, creative programmers were having a go at all sorts of things. It was quite an interesting read, believe it might have been a kickstarter project


    Do you happen you know the name of that book ?
    I'd like to get a copy.

    Bean
  • Tubular wrote: »
    Those days seemed pioneering, creative programmers were having a go at all sorts of things.
    Hell yeah! Pioneering is exactly how it felt. It wasn't like the consoles or the PC. Anyone could dabble with the software and hardware was inventive and bare metal all the time. It was like everyone having a propeller setup as a home computer.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Bean wrote: »
    Tubular wrote: »
    I was over at my brothers place on the weekend. On his coffee table, he had this cool book about the Spectrum microcomputer, with interviews with many programmers and designers, including Baggers talking about the games he ported across and some of the 'easter eggs' he coded in.

    Those days seemed pioneering, creative programmers were having a go at all sorts of things. It was quite an interesting read, believe it might have been a kickstarter project


    Do you happen you know the name of that book ?
    I'd like to get a copy.

    Bean

    I'll find out for you Bean, when he gets back from E3. He also had a C64 version
  • Here's a photo I took of the page @Baggers was quoted on

    3456 x 4608 - 2M
  • If you love the ZX Spectrum, you might get a kick out of this:

    https://www.amazon.com/ZX-Spectrum-Games-Code-Club-ebook/dp/B018R4DS22
    http://spectrumcode.club/

    j
  • msrobots wrote: »
    'Whats a microcontroller' rewritten for the p2. :smile:

    Is this something that is being worked on?

  • ...waiting for the retail version to drop.
    Looking forward to a proper P2 protoboard to exist.
    <br>
  • ...waiting for the retail version to drop.
    Looking forward to a proper P2 protoboard to exist.

    Hmmm, I was thumbing through a copy of "Programming and Customizing the Multicore Propeller Microcontroller" and in one project they had gone through a few iterations of their prototype which was built on a Prop proto board. But because this was hardwired it was probably too much of a mess to try to rework the old one and they would just use a new board each time. Eventually they had the project on a pcb that plugged in onto pin headers. Now if they had used a plug-in matrix proto board in the first place they would not have had to use a new Prop board each time.
    But why can't the Prop be plugged onto the project board rather than the other way around? That's exactly what the P2D2 does since it is a compact module with all the smarts that you can plug into cheap 0.1" matrix board that just needs pin headers for the P2D2 to plug into.

    Now, you were saying...?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • For the month of June
    Spammers-0
    Moderators-18
    Infernal Machine
Sign In or Register to comment.