What I want to see is a specific app that the P2 can do that the P1 can't. More memory is nice, but there are other ways to deal with such a limitation
Well, you could also argue that you can't imagine a place you can reach with a car that you can't with your bicycle. But it's just so much more convenient.
With the P2 you can use more of your time for actual development and creativity instead of fighting against limitations. Having to add external memory, external ADCs, using multiple P1s if you run out of cogs and pins etc. is possible, but it takes time, money and board space and it makes the code more complex requiring more debugging.
So if you do it for fun keep riding your bike. But If you have to get to the destination quickly I'd use a car.
Show me a specific app that the P2 can succeed in that the P1 cannot, and I might be a believer. But I will be hell-bent to demonstrate that the P1 can do the same thing.
Where I'm dreaming of using it is as an I/O controller for a manufacturing test fixture. In particular the BIT_DAC and DAC_COMPARE features look amazing for all sorts of digital communication and validation. Also, the fact that each set of 8 I/O pins has its own independent VDD is tremendously useful, and the only MCUs I know of that come close are Maxim's Cortex-Ms (where the I/O pins can be software configured to two different I/O voltage ranges).
I just designed and had prototype circuit boards made for a device that was to use a P1 to break out up to 12 serial ports, an IIC port, and an ENC28J60 ethernet port with custom precision timing for an interfaced PC application (which would control the breakout via its ethernet port). This seemed reasonable because all the things I wanted the board to do had been done in previous projects, but I had to abandon the project because I was running short of both Hub RAM and clock cycles. Now I'm using an ESP32 and a Digi Edgeport with entirely rearranged hardware architecture. Had the board been built with P2, it would have been easily capable of doing everything I wanted, and my PC app would not have a dependency on the Edgeport USB driver.
This was so far the best intro to the P2 that I have read. Most of the information about the P2 is a struggle for me to understand. I hope to see a whole lot more documentation in this format so that myself and others at my level can make use of the P2.
Very nice article, Jon! You mention that Chip is porting Spin2 to C. I hadn't heard that. That's good news for the prospects of a portable byte code compiler for the P2.
He agreed that it would be good to do that, and he read and approved the article before I sent it to N&V. That said -- and as the last 14 years have shown -- things change....
It's what a programming language should be. No jumping through hoops, no command line switches...type simple, understandable syntax and end-up with fast code.
It's what a programming language should be. No jumping through hoops, no command line switches...type simple, understandable syntax and end-up with fast code.
"understandable syntax" and "jumping through hoops" is in the eye of the beholder . PropBasic is a great "high level assembler", as someone put it above. For me personally I prefer not having to do explicit RDLONG, RDBYTE, and the like to access variables in HUB, and I prefer the compiler to parse expressions rather than making me split everything up so each line just has one operator. But de gustibus non est disputandum...
A man convinced against his will is of the same opinion, stiil.
Phil could do all kinds of things with the P2 if he wanted.
I guess I'm just a minimalist at heart: i.e. squeeze performance out of a chip that no one thought possible. I'll be more than happy to embrace the P2 when I see it as the minimal solution to a problem. Seriously, there's a lot there to like, and I hope Parallax has wild success with it. But I'll always try something with the P1 first, until I hit a roadblock, at which point necessity will rule changing horses. Jon's clear and concise writing will make that transition easy, which is where my discussion in this thread started.
It's what a programming language should be. No jumping through hoops, no command line switches...type simple, understandable syntax and end-up with fast code.
"understandable syntax" and "jumping through hoops" is in the eye of the beholder . PropBasic is a great "high level assembler", as someone put it above. For me personally I prefer not having to do explicit RDLONG, RDBYTE, and the like to access variables in HUB, and I prefer the compiler to parse expressions rather than making me split everything up so each line just has one operator. But de gustibus non est disputandum...
Oh, admittedly, I have yet to try FlexBASIC because my Prop work is on hold at the moment but does your alternative to RDLONG, RDBYTE result in more clock cycles?
My use of the Prop, thus far has been 100% cog because I utilise it only as a peripheral and I count clocks. I have yet been able to optimise the generated PASM. Granted, I am not as skilled as our resident PASM programmers.
The other turn-off, although it might be unwarranted is the mention of GC.
Not sure if this applies to pure cog code, can't see it TBH.
Coding is a small part of what I do. I understand logic and I know what I need to achieve. I need to spend my time making things work as opposed to worrying about stupid rules like indentation and curly brackets.
(not referring to BASIC)
I type in PropBASIC exactly what I think and it works, just like all the other BASICs that I use.
Back in the 80s I destroyed my Watcom C competition because I actually got product to market using QuickBasic. The rumor in my industry was that I was merely a front for a secret team of programmers
The exciting feature regarding FlexBASIC is the possibility of being able to link directly with existing objects but I haven't seen this happen yet.
Any form of BASIC has my full support because I have been able to tackle any task and blow away my competition and when you're self employed, time really is money.
Screw these other new fangled fashionable languages, they are slow or complicated and can't achieve anything that BASIC can't.
Oh, admittedly, I have yet to try FlexBASIC because my Prop work is on hold at the moment but does your alternative to RDLONG, RDBYTE result in more clock cycles?
No more clock cycles needed. But we should probably not derail this thread any more and just agree that having a robust set of tools for the P2 is a good thing, and the more the merrier .
Comments
Well, you could also argue that you can't imagine a place you can reach with a car that you can't with your bicycle. But it's just so much more convenient.
With the P2 you can use more of your time for actual development and creativity instead of fighting against limitations. Having to add external memory, external ADCs, using multiple P1s if you run out of cogs and pins etc. is possible, but it takes time, money and board space and it makes the code more complex requiring more debugging.
So if you do it for fun keep riding your bike. But If you have to get to the destination quickly I'd use a car.
Where I'm dreaming of using it is as an I/O controller for a manufacturing test fixture. In particular the BIT_DAC and DAC_COMPARE features look amazing for all sorts of digital communication and validation. Also, the fact that each set of 8 I/O pins has its own independent VDD is tremendously useful, and the only MCUs I know of that come close are Maxim's Cortex-Ms (where the I/O pins can be software configured to two different I/O voltage ranges).
Lets start a new thread titled "Things that the P2 can do that the P1 can't do"
Then fill it up with new ideas and projects. We really need Phil's talent and experience on board with the P2 .
It's what a programming language should be. No jumping through hoops, no command line switches...type simple, understandable syntax and end-up with fast code.
A man convinced against his will is of the same opinion, stiil.
Phil could do all kinds of things with the P2 if he wanted.
"understandable syntax" and "jumping through hoops" is in the eye of the beholder
-Phil
Oh, admittedly, I have yet to try FlexBASIC because my Prop work is on hold at the moment but does your alternative to RDLONG, RDBYTE result in more clock cycles?
My use of the Prop, thus far has been 100% cog because I utilise it only as a peripheral and I count clocks. I have yet been able to optimise the generated PASM. Granted, I am not as skilled as our resident PASM programmers.
The other turn-off, although it might be unwarranted is the mention of GC.
Not sure if this applies to pure cog code, can't see it TBH.
Coding is a small part of what I do. I understand logic and I know what I need to achieve. I need to spend my time making things work as opposed to worrying about stupid rules like indentation and curly brackets.
(not referring to BASIC)
I type in PropBASIC exactly what I think and it works, just like all the other BASICs that I use.
Back in the 80s I destroyed my Watcom C competition because I actually got product to market using QuickBasic. The rumor in my industry was that I was merely a front for a secret team of programmers
The exciting feature regarding FlexBASIC is the possibility of being able to link directly with existing objects but I haven't seen this happen yet.
Any form of BASIC has my full support because I have been able to tackle any task and blow away my competition and when you're self employed, time really is money.
Screw these other new fangled fashionable languages, they are slow or complicated and can't achieve anything that BASIC can't.