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.
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"
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.
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.
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).
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. )
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.
... 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 ?
... 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:
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.
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 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.
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.
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.
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.
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.
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
...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.
Comments
-Phil
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.
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
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
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?
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).
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.
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.
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. )
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.
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:
I think your quadrature alternative would work with a little extra housekeeping.
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.
Welcome, Ntosme2.
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.
Lots of P2 stuff rattling around in head at the moment.
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
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.
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.
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.
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
https://www.bitmapbooks.co.uk/products/sinclair-zx-spectrum-a-visual-compendium
https://www.amazon.com/ZX-Spectrum-Games-Code-Club-ebook/dp/B018R4DS22
http://spectrumcode.club/
j
Is this something that is being worked on?
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...?
Spammers-0
Moderators-18