It isn't complex, ask the people here who have used it. Besides, most code is written in XC and C, and one doesn't have to use assembly language as on the Propeller for useful performance.It's a much more powerful device than the Propeller, and hence has a larger instruction set.
It's deterministic, and interrupts are only used when executing legacy code.
The typical propeller build methodology encourages compartmentalization of the various sub-systems, means and methods, which are then integrated to form the higher level solution. The true concurrency of the Prop, combined with it's determinism, makes this possible and practical. IMHO, LMM models will complicate this some, as will the threading potential as I understand it to be implemented right now, but in that case, the kernel can easily provide some functionality needed to step through code, and get values, etc...
Edit: And unless I've missed out on something, it is entirely possible to build the Propeller way on the XMOS devices, until one really wants to fully exploit them. In that scenario, complexity increases significantly. The fact that higher level tools are offered for that exact use case more or less demonstrates that being true. Propellers don't have that same use case / complexity curve, and that gets right to the design differences. Those differences are relevant to this discussion, and it's not about better or worse, just how the differences would play out for various use cases related to hardware debugging.
Again, the question is one of purity. If there is a 80 percent solution, is that enough? I suspect it will be, because the chip attributes will offer other means and methods that are strong. The primary reason for this feature discussion is technology adoption, right? So then, what does it take for people to adopt and use the technology? If that gets answered, the rest is simply practical use cases, and JTAG is not inclusive of those, as already demonstrated on Prop I.
Well, for me, you have convinced me that it's a valid exception to technology adoption. On that basis, offering some JTAG like tools in software makes a lot of sense. I have yet to see the case for it being mandatory on a hardware level. That's the purity question, so far unanswered.
RE: Will the pros buy it?
IMHO, this is a matter of presentation and positioning the technology. How it's sold, and the expectations that go along with that will have a significant impact. Let's say LMM is as potent as we all think it will be, and the COG as micro-code kind of thinking is a part of that. Seems to me then, the IDE and core software package delivered as "dev kit", could present a whole lot of what has been argued as exceptions on this and other threads. If that's done in a holistic, supported way, why not? The "does it have it?" basic check-box will have been met, opening the door to evaluation like any other device.
Not all of those evaluations will be successful. They never are. But, with the core exception removed, Parallax gets a significant benefit for only a software cost, and one that's part of the planning and development needed to roll out the Prop II anyway.
I have been reading(ad nausium) here about the JTAG thing. I have never used such a thing, but then I am no professional. It seems to me that "somebody" needs to write a JTAG "golden" object.
Back to the regularly scheduled show....
Too little?
I don't think so. I would rather have more ram, but it seems that the complexity of the pins has eaten up the space.
The propII seems to be an order of magnitude more complex in the pin department. I would have rather had an incremental small step. A prop1b with it's features filled out would be great..like 64 pins, and the mul and div instructions implemented in 4 cycles, and a deserializer to match the serializer. Just those improvements would have really turned some heads, especially after PhiPi, Heater, RossH, Jazzed, Bill Henning, Hanno, Dr Acula, OBC, Mike Green, etc got a hold of it. I think what makes the propeller great is the people here on the forums. (If I missed your name as a major contributor, don't be offended my memory isn't great for names..but if your name was a part number...). The stuff that the people do with the propII will make it really shine. The "Golden Object" idea may be one way to bring that glory to the professional market.
too late?
OK, here I would have to agree. We are sliding down further to the bottom of the greatest economic depression. I would love to have a propII(or a dozen) to keep my brain keen in the bottom of the depression. Hopefully it comes out before hyper inflation, and hopefully parallax is able to turn a real profit on it.
I kept meaning to make one of those. Someone I know used to program a RAM with a capacitor soldered to it, unplugged it, and plugged it into the target.
I used one of the parallel port handshake signals to set the direction on the loading latch and the same signal to control the reset line on the CPU, so assemble, download and run code. Used NMI IRQ line (another parallel port signal) to trigger register/mem dumps or whatever to serial output.
one doesn't have to use assembly language as on the Propeller for useful performance.
When did we lose Catalina C, PropBASIC, and PropForth? You do not have to use assembly to get usable performance if you do not wish to, we have at least these three good compilers, possibly more that I am unaware (or not mentioning till introduction).
I'm missing something here. Is this aside from using one core as a monitor? I never used JTAG either; but I know in propforth, the software implementation of forth debugger, assembler debugger, and logic analyzer provide all the functions, all interactive with no additional hardware. Isn't there software implementation of JTAG functiuon in other langauge environments? Or is there some additional JTAG function that can't be done this way?
When did we lose Catalina C, PropBASIC, and PropForth? You do not have to use assembly to get usable performance if you do not wish to, we have at least these three good compilers, possibly more that I am unaware (or not mentioning till introduction).
I thought that programs written in those languages for the Propeller ran rather slowly and that most of the time-critical stuff is written in assembler. I don't think that Parallax themselves use anything other than Spin and assembler.
I thought that programs written in those languages for the Propeller ran rather slowly and that most of the time-critical stuff is written in assembler. I don't think that Parallax themselves use anything other than Spin and assembler.
You maybe correct about Parallax using nothing other than SPIN and Assembly (I do not know for sure). As to the speed issue, I have found that at least PropBASIC can be quite fast enough for just about anything (even most custom video no assembly required) as long as you avoid LMM.
I would imagine that the same is probably true for Catalina C (though I have not tried anything that time critical in Catalina).
I do not know enough Forth to comment on the PropForth.
I can say that it will be possible to write time critical code in Pascal with little to no difficulty.
When did we lose Catalina C, PropBASIC, and PropForth? You do not have to use assembly to get usable performance if you do not wish to, we have at least these three good compilers, possibly more that I am unaware (or not mentioning till introduction).
It depends on your definition of usable or useful performance. In the discussion of the Prop II earlier in this thread, it was mentioned that an LMM implementation of C on the Prop II would run at 40 MIPS, which means it's 1/4 the native cog rate of 160 MIPS. Assuming that the Prop I has the same 1/4x factor when running LMM-based C (which it probably doesn't given the improvements in the Prop II), then it will run C code at only 5 MIPS.
Is 5 MIPS useful? Again, it depends on your prospective. You can buy a dsPIC for less than $3 that'll do 40 MIPS.
Sal:
Read my last post. At least with PropBASIC, and probably with Catalina C, if you avoid LMM for the super time critical stuff there is no problem.
Also:
LMM should be able to be done at greater than 60MIPS in the Prop II due to its having 8 cycles between hub windows, and 4 LONG versions of RDQLONG, WRQLONG for hub access. It should in theory be possible to reach 80MIPS, though due to the LMM kernel over head this is not practical.
You maybe correct about Parallax using nothing other than SPIN and Assembly (I do not know for sure). As to the speed issue, I have found that at least PropBASIC can be quite fast enough for just about anything (even most custom video no assembly required) as long as you avoid LMM.
I would imagine that the same is probably true for Catalina C (though I have not tried anything that time critical in Catalina).
I do not know enough Forth to comment on the PropForth.
I can say that it will be possible to write time critical code in Pascal with little to no difficulty.
Who wants to use BASIC - Beginner's All-purpose Symbolic Instruction Code? I've always used assembler and C, and wouldn't touch BASIC with a bargepole!
Leon:
Then see how well Catalina does for time critical stuff if you avoid LMM and XMM, it should do just fine I would think.
I have found that well written Structured BASIC compilers usually have a better 1:1 correspondence between the source and the generated instructions than most other high level languages. Also the acronym probably should be changed as the 'Beginners' portion no longer fits the way it did back in the days of line numbered BASIC interpreters. The BASIC of today is as powerful as just about any other HLL (so long as you avoid compilers by M$).
Who wants to use BASIC - Beginner's All-purpose Symbolic Instruction Code? I've always used assembler and C, and wouldn't touch BASIC with a bargepole!
While BASIC is not my first language choice, there are situations where better versions can be useful. Some may be nostalgic over 20 goto 10 basic; i'm not. VB6 is an example of BASIC that I used often and enjoyed.
PBASIC is fine for small one file programs. VB.net, the language regardless of how you feel about it's purveyor or run-time, is not so bad and is a lot like SPIN. Other BASIC variations are OK too. I anticipate getting a friendly version of BASIC this week to evaluate for including it in the SpinSocket platform kit.
Unfortunately yes PropBASIC is quite more limited than most modern BASICs. I use FreeBASIC, TACKLE-BASIC, and QB64 (not the M$QB) as these are good modern BASICs with pointers, function pointers, a good structure, and the ability to compile fairly well optimized binaries (not .NET byte code).
I certainly would not show my BASIC Programs to a beginner, they would be instantly lost (especially as most beginners seem to have a block against understanding function pointers and callbacks, for some reason I do not understand).
It seems that after all else is said and done, the only two points of concern that remain are:
1) Better HLL support. Parallax appears to be working on this.
2) Better debug documentation. Perhaps some one here with the need experience to write this should pitch a draft to Parallax.
As for the initial question "Too little too late?" I say:
Too little? No:
The Prop II will be one of the more powerful MCUs out there and will make XMM quite simple, so there will be no significant limits to memory. Yes XMM will likely slow us down to the same degree as LMM will (thanks to the design of the Propeller II), but no more than that. The Propeller II will have all the same advantages as the Propeller I, plus more IO, plus more hub mem, plus dedicated DACs, and ADCs, Plus better video, etc.... We should be able to create soft peripherals to an extreme that will make any other MCU look like something ancient in comparison.
Leon:
Looking at the specs that have been given us I would say Yes it would probably be possible to write a high speed USB driver for the Propeller II.
Though It does not appear that we will be able to do SATA or USB 3.0 (2.0 high speed [480Mb/s] should be no prob). Still this gives us so many possible devices that we should be able to do more soft peripherals than any of the competition has in HW.
Dave:
I would think so. Look at the specs we have, if you can do it in software it can be done. Host mode 2.0 USB should be no difficulty, though we will only know for 100% after we have the chip in our hands (soon please ).
Who wants to use BASIC - Beginner's All-purpose Symbolic Instruction Code? I've always used assembler and C, and wouldn't touch BASIC with a bargepole!
I have not used PropBASIC, but I do use Basic Scripts for adding functionality under other tools.
With a good editor and integrated Watch/Step debug, the newest Basics are a long way from your Grandad's ZX81!!.
I would like to see a 'better assembler' , and the Prop is an ideal target, because of the very constrained memory split points.
I see ImageCraft mentions this, as multiple cores becomes more 'normal' :
["NEW: XGATE assembler support.
XGATE is a RISC coprocessor available in some S12X devices that can be used to process interrupts. Since the XGATE core has full access to all the S12X peripherals, careful use of the XGATE can drastically reduce loads on the CPU12X core. The latest version of the compiler (ADVANCED license only) has full assembler support for the XGATE coprocessor. The linker can handle mixed object files from CPU12 assembler and the XGATE assembler" ]
The statement that 480 Mb/s should be "no problem" is quite bold, and gives me considerable cause for doubt. I believe the maximum clock speed in the chip is 160 MHz, so how could one expect to get an output the wiggle at 480 MHz?. Remember, at that speed the pulses are only 1 (approximately) nanosecond long. I suspect this will not be achievable.
Am I missing something?? .... I'd be happy to be wrong!!
pjv:
Unless I misunderstood something, are not there supposed to be much faster shifters integrated into the IO on the Prop II. I forget which thread it was mentioned, though I seem to recall it being said that the Prop II IOs would include shifters at much higher clocking than that of the main chip.
The statement that 480 Mb/s should be "no problem" is quite bold, and gives me considerable cause for doubt. I believe the maximum clock speed in the chip is 160 MHz, so how could one expect to get an output the wiggle at 480 MHz?. Remember, at that speed the pulses are only 1 (approximately) nanosecond long. I suspect this will not be achievable.
Am I missing something?? .... I'd be happy to be wrong!!
Cheers,
Peter (pjv)
It should be OK, the bit-wiggling is handled by the PHY chip which has a parallel interface. XMOS manages it with a 100 MIPS thread, IIRC. I'm not sure if a cog will have enough memory for it, though.
Comments
It's deterministic, and interrupts are only used when executing legacy code.
The typical propeller build methodology encourages compartmentalization of the various sub-systems, means and methods, which are then integrated to form the higher level solution. The true concurrency of the Prop, combined with it's determinism, makes this possible and practical. IMHO, LMM models will complicate this some, as will the threading potential as I understand it to be implemented right now, but in that case, the kernel can easily provide some functionality needed to step through code, and get values, etc...
Edit: And unless I've missed out on something, it is entirely possible to build the Propeller way on the XMOS devices, until one really wants to fully exploit them. In that scenario, complexity increases significantly. The fact that higher level tools are offered for that exact use case more or less demonstrates that being true. Propellers don't have that same use case / complexity curve, and that gets right to the design differences. Those differences are relevant to this discussion, and it's not about better or worse, just how the differences would play out for various use cases related to hardware debugging.
Again, the question is one of purity. If there is a 80 percent solution, is that enough? I suspect it will be, because the chip attributes will offer other means and methods that are strong. The primary reason for this feature discussion is technology adoption, right? So then, what does it take for people to adopt and use the technology? If that gets answered, the rest is simply practical use cases, and JTAG is not inclusive of those, as already demonstrated on Prop I.
RE: Will the pros buy it?
IMHO, this is a matter of presentation and positioning the technology. How it's sold, and the expectations that go along with that will have a significant impact. Let's say LMM is as potent as we all think it will be, and the COG as micro-code kind of thinking is a part of that. Seems to me then, the IDE and core software package delivered as "dev kit", could present a whole lot of what has been argued as exceptions on this and other threads. If that's done in a holistic, supported way, why not? The "does it have it?" basic check-box will have been met, opening the door to evaluation like any other device.
Not all of those evaluations will be successful. They never are. But, with the core exception removed, Parallax gets a significant benefit for only a software cost, and one that's part of the planning and development needed to roll out the Prop II anyway.
Back to the regularly scheduled show....
Too little?
I don't think so. I would rather have more ram, but it seems that the complexity of the pins has eaten up the space.
The propII seems to be an order of magnitude more complex in the pin department. I would have rather had an incremental small step. A prop1b with it's features filled out would be great..like 64 pins, and the mul and div instructions implemented in 4 cycles, and a deserializer to match the serializer. Just those improvements would have really turned some heads, especially after PhiPi, Heater, RossH, Jazzed, Bill Henning, Hanno, Dr Acula, OBC, Mike Green, etc got a hold of it. I think what makes the propeller great is the people here on the forums. (If I missed your name as a major contributor, don't be offended my memory isn't great for names..but if your name was a part number...). The stuff that the people do with the propII will make it really shine. The "Golden Object" idea may be one way to bring that glory to the professional market.
too late?
OK, here I would have to agree. We are sliding down further to the bottom of the greatest economic depression. I would love to have a propII(or a dozen) to keep my brain keen in the bottom of the depression. Hopefully it comes out before hyper inflation, and hopefully parallax is able to turn a real profit on it.
I used one of the parallel port handshake signals to set the direction on the loading latch and the same signal to control the reset line on the CPU, so assemble, download and run code. Used NMI IRQ line (another parallel port signal) to trigger register/mem dumps or whatever to serial output.
Ah the good old days.
I'm missing something here. Is this aside from using one core as a monitor? I never used JTAG either; but I know in propforth, the software implementation of forth debugger, assembler debugger, and logic analyzer provide all the functions, all interactive with no additional hardware. Isn't there software implementation of JTAG functiuon in other langauge environments? Or is there some additional JTAG function that can't be done this way?
I thought that programs written in those languages for the Propeller ran rather slowly and that most of the time-critical stuff is written in assembler. I don't think that Parallax themselves use anything other than Spin and assembler.
I would imagine that the same is probably true for Catalina C (though I have not tried anything that time critical in Catalina).
I do not know enough Forth to comment on the PropForth.
I can say that it will be possible to write time critical code in Pascal with little to no difficulty.
It depends on your definition of usable or useful performance. In the discussion of the Prop II earlier in this thread, it was mentioned that an LMM implementation of C on the Prop II would run at 40 MIPS, which means it's 1/4 the native cog rate of 160 MIPS. Assuming that the Prop I has the same 1/4x factor when running LMM-based C (which it probably doesn't given the improvements in the Prop II), then it will run C code at only 5 MIPS.
Is 5 MIPS useful? Again, it depends on your prospective. You can buy a dsPIC for less than $3 that'll do 40 MIPS.
Read my last post. At least with PropBASIC, and probably with Catalina C, if you avoid LMM for the super time critical stuff there is no problem.
Also:
LMM should be able to be done at greater than 60MIPS in the Prop II due to its having 8 cycles between hub windows, and 4 LONG versions of RDQLONG, WRQLONG for hub access. It should in theory be possible to reach 80MIPS, though due to the LMM kernel over head this is not practical.
Who wants to use BASIC - Beginner's All-purpose Symbolic Instruction Code? I've always used assembler and C, and wouldn't touch BASIC with a bargepole!
Then see how well Catalina does for time critical stuff if you avoid LMM and XMM, it should do just fine I would think.
I have found that well written Structured BASIC compilers usually have a better 1:1 correspondence between the source and the generated instructions than most other high level languages. Also the acronym probably should be changed as the 'Beginners' portion no longer fits the way it did back in the days of line numbered BASIC interpreters. The BASIC of today is as powerful as just about any other HLL (so long as you avoid compilers by M$).
PBASIC is fine for small one file programs. VB.net, the language regardless of how you feel about it's purveyor or run-time, is not so bad and is a lot like SPIN. Other BASIC variations are OK too. I anticipate getting a friendly version of BASIC this week to evaluate for including it in the SpinSocket platform kit.
Unfortunately yes PropBASIC is quite more limited than most modern BASICs. I use FreeBASIC, TACKLE-BASIC, and QB64 (not the M$QB) as these are good modern BASICs with pointers, function pointers, a good structure, and the ability to compile fairly well optimized binaries (not .NET byte code).
I certainly would not show my BASIC Programs to a beginner, they would be instantly lost (especially as most beginners seem to have a block against understanding function pointers and callbacks, for some reason I do not understand).
1) Better HLL support. Parallax appears to be working on this.
2) Better debug documentation. Perhaps some one here with the need experience to write this should pitch a draft to Parallax.
As for the initial question "Too little too late?" I say:
Too little? No:
The Prop II will be one of the more powerful MCUs out there and will make XMM quite simple, so there will be no significant limits to memory. Yes XMM will likely slow us down to the same degree as LMM will (thanks to the design of the Propeller II), but no more than that. The Propeller II will have all the same advantages as the Propeller I, plus more IO, plus more hub mem, plus dedicated DACs, and ADCs, Plus better video, etc.... We should be able to create soft peripherals to an extreme that will make any other MCU look like something ancient in comparison.
Too Late? NO:
Mostly the same argument as above.
Looking at the specs that have been given us I would say Yes it would probably be possible to write a high speed USB driver for the Propeller II.
I would think so. Look at the specs we have, if you can do it in software it can be done. Host mode 2.0 USB should be no difficulty, though we will only know for 100% after we have the chip in our hands (soon please
I have not used PropBASIC, but I do use Basic Scripts for adding functionality under other tools.
With a good editor and integrated Watch/Step debug, the newest Basics are a long way from your Grandad's ZX81!!.
I would like to see a 'better assembler' , and the Prop is an ideal target, because of the very constrained memory split points.
I see ImageCraft mentions this, as multiple cores becomes more 'normal' :
["NEW: XGATE assembler support.
XGATE is a RISC coprocessor available in some S12X devices that can be used to process interrupts. Since the XGATE core has full access to all the S12X peripherals, careful use of the XGATE can drastically reduce loads on the CPU12X core. The latest version of the compiler (ADVANCED license only) has full assembler support for the XGATE coprocessor. The linker can handle mixed object files from CPU12 assembler and the XGATE assembler" ]
The statement that 480 Mb/s should be "no problem" is quite bold, and gives me considerable cause for doubt. I believe the maximum clock speed in the chip is 160 MHz, so how could one expect to get an output the wiggle at 480 MHz?. Remember, at that speed the pulses are only 1 (approximately) nanosecond long. I suspect this will not be achievable.
Am I missing something?? .... I'd be happy to be wrong!!
Cheers,
Peter (pjv)
Unless I misunderstood something, are not there supposed to be much faster shifters integrated into the IO on the Prop II. I forget which thread it was mentioned, though I seem to recall it being said that the Prop II IOs would include shifters at much higher clocking than that of the main chip.
It should be OK, the bit-wiggling is handled by the PHY chip which has a parallel interface. XMOS manages it with a 100 MIPS thread, IIRC. I'm not sure if a cog will have enough memory for it, though.
Oh, I see.
I misunderstood David's statement to mean that the Prop would do the heavy lifting; not some external device.
That said, at 160 Mhz the pins should be able to transition every 3-ish nanoseconds. .... a very impressive performance level in my books!
Cheers,
Peter (pjv)