Have we confirmed that it is flakey for anyone other than Peter? Perhaps he just has a bad board/fpga chip that only exhibits notible problems with the V27 build?
Do other people have the same setup as Peter that can test it the same ways?
I have two cva9s and a de2 that i can test on as well as other smaller fpas. But i will have some time later today hopefully that i will confirm v27z on cva9 and de2 again to try to make some sense of it.
V27z worked fine for me. No flakiness whatsoever. But I wasn't pushing anything hard, just outputting serial data over and over. Ran for more than 6 hours without a problem.
Once v28 is anailable for the BeMicroCV-A9 I will get SD boot debugged and my P1 prop OS running on P2. The OS will take time as it's mostly Spin
This and TAQOZ should give us some tools for testing.
Loaded V27z on a CVA9 and so far, so good, but only time will tell. If it works for an hour without crashing then it is already "fixed' but if not I will try to get to the bottom of it. But if V28 is available I will run the other CVA9 on that as well. Perhaps I will fire up the DE2 at the same time and check the I/O pins again.
Peter, could you take the failing setup and unplug everyhing that mght cause a ground loop, and have it report to its own LEDs if it's passing or failing?
Your time to fail is so long that I'm wondering if maybe an air conditioner contactor is causing some periodic line-power spike that disrupts your setup.
My supplies are isolated (RIGOL DP832 etc) and the only ground I need to worry about is the USB if I don't have the scope connected. Definitely not a ground loop or a spike, plus that would affect any and all hardware really, not just V27. However it is still running so that's a good sign. If it doesn't go legs up in the next couple of hours I will load in the version without the nop and see how it goes....
Of course, the far superior assembly format is Mnemonic Source Destination Why anyone would think putting destination first is a good idea beats the hell out of me.
Of course, the far superior assembly format is Mnemonic Source Destination Why anyone would think putting destination first is a good idea beats the hell out of me.
hehe, yes... I like to think of a missing 'to' in the MOV (etc) so it becomes
MOVto Dest, Source
I think it was Analog Devices, who tried to clean ASM up more, by allowing a simple equals, and some limited operators in their DSP ASM tools ...
Dest = Source
and I'd say in 2017+, most coders would also know what to make of
Is there any mechanism In PASM to be able to use pseudonyms in place of opcodes for those that want to stay at arms length but dabblenin PASM. For example what if you could create a reference table somewhere and create your own opcode names
Compare = cmp
MoveValue = mov
Then in your PASM use your own names for easier reference.
These aren’t great examples because these are already obvious but there are lots that will not be obvious and to avoid memorizing the commands just keep a reference chart in your code
Is there any mechanism In PASM to be able to use pseudonyms in place of opcodes for those that want to stay at arms length but dabblenin PASM. For example what if you could create a reference table somewhere and create your own opcode names
Compare = cmp
MoveValue = mov
Then in your PASM use your own names for easier reference.
These aren’t great examples because these are already obvious but there are lots that will not be obvious and to avoid memorizing the commands just keep a reference chart in your code
A Text pre-processor, as found in C, could do this, or a MACRO Assembler could define NewLongerMnemonic as a macro, and pass parameters as per a 'normal' opcode.
eg fasmg supports macros.
Will the average engineer abandon everything that he knows and loves?
Probably not, but that really isn't necessary.
One very unique place for the P2 will be in the process of rapid prototyping.
Spin2 is going to be a lot faster than Spin1. Between Spin2, P2asm examples, and forum support, if an engineer can't produce faster prototypes using the P2, he/she just isn't trying. There should be a nearly flat learning curve, if the rest of the ecosystem is properly in place.
For prototyping, the P2 should be an absolute wonderland, very much like an FPGA, without all of the fuss.
There are many internal optimizations and some functional changes.
Please try these out, if you can.
Thanks!
Ok, if you insist
I see you have a 16 cog version in there as well, that's the one I will try out first!
btw, is there any info on using the smartpins for SPI?
There are many internal optimizations and some functional changes.
Please try these out, if you can.
Thanks!
Ok, if you insist
I see you have a 16 cog version in there as well, that's the one I will try out first!
btw, is there any info on using the smartpins for SPI?
You'd need to use an image that has smart pins on P61..P58. Those would be the 8-cog images.
Peter, I'll be up your way in 24 hours or so. Let me know if a P123-A7 would be useful for your development efforts.
cheers
Lachlan
Thanks, I haven't bothered using any of the smaller FPGAs as there is simply no need to for me I guess. What to do we all those other boards...
Give us a call when you think you'll have some free time and hopefully we can catch up.
Does that include the CLKSET/NOP pairing dictate issue you reported above ?
Has that gone away on v28 ?
Just prior to V28 I ran my software without the nop on V27z and I couldn't fault it. If I find the time I will go back with the version that gave me problems but worked on V26 and see if I can track it down further.
Chip
All V28 images loaded on all boards Ok.
All looks good so far.
Thanks!
Ozpropdev, I suppose you've already realized, but it will be necessary to modify your tools to accommodate the moved instructions: WAITX/RFVAR/RFVARS and the new instruction: ONES. Also, the data reported back from GETINT and SETBRK has been changed and added to. These may have effect on your single-step debugger.
Comments
Do other people have the same setup as Peter that can test it the same ways?
Once v28 is anailable for the BeMicroCV-A9 I will get SD boot debugged and my P1 prop OS running on P2. The OS will take time as it's mostly Spin
This and TAQOZ should give us some tools for testing.
Your time to fail is so long that I'm wondering if maybe an air conditioner contactor is causing some periodic line-power spike that disrupts your setup.
Sorry if I've already proposed this a while back.
I have to babysit a solar installation tomorrow, so may get some P2 testing time.
For clarity, I'd like PASM syntax changed from PTRx[index] to PTRx[#index]
If you are talking about clarity, PASM needs a much larger fix than that
Many decades ago, intel and Motorola decided to use # prefix for #immed8 , #immed16 constants.
The newer AVR removes the chaff, and they use an opcode suffix to more clearly indicate immediate.
eg AVR mnemonics : ANDI, ADIW, LDI, CPI, SBIW etc
In all of the above MCUs,
CALL Label
does exactly what a reader expects, and there are a lot of calls/jumps in most ASM code.
Reality: Compared with 'common industry practice' the Prop Assembly Syntax is quite the accidental orphan.
If I were selling the Prop, I would strive to reduce everything that signals 'orphan part' to all the new users I would be hoping to attract.
The index component here is supplied as a 5-bit immediate but not indicated as such. It's just one little place that has been missed I think.
MOVto Dest, Source
I think it was Analog Devices, who tried to clean ASM up more, by allowing a simple equals, and some limited operators in their DSP ASM tools ...
Dest = Source
and I'd say in 2017+, most coders would also know what to make of
RegName++
RegName--
Compare = cmp
MoveValue = mov
Then in your PASM use your own names for easier reference.
These aren’t great examples because these are already obvious but there are lots that will not be obvious and to avoid memorizing the commands just keep a reference chart in your code
A Text pre-processor, as found in C, could do this, or a MACRO Assembler could define NewLongerMnemonic as a macro, and pass parameters as per a 'normal' opcode.
eg fasmg supports macros.
Will the average engineer abandon everything that he knows and loves?
Probably not, but that really isn't necessary.
One very unique place for the P2 will be in the process of rapid prototyping.
Spin2 is going to be a lot faster than Spin1. Between Spin2, P2asm examples, and forum support, if an engineer can't produce faster prototypes using the P2, he/she just isn't trying. There should be a nearly flat learning curve, if the rest of the ecosystem is properly in place.
For prototyping, the P2 should be an absolute wonderland, very much like an FPGA, without all of the fuss.
There are many internal optimizations and some functional changes.
Please try these out, if you can.
Thanks!
Ok, if you insist
I see you have a 16 cog version in there as well, that's the one I will try out first!
btw, is there any info on using the smartpins for SPI?
You'd need to use an image that has smart pins on P61..P58. Those would be the 8-cog images.
All V28 images loaded on all boards Ok.
All looks good so far.
Thanks!
cheers
Lachlan
Give us a call when you think you'll have some free time and hopefully we can catch up.
Does that include the CLKSET/NOP pairing dictate issue you reported above ?
Has that gone away on v28 ?
Just prior to V28 I ran my software without the nop on V27z and I couldn't fault it. If I find the time I will go back with the version that gave me problems but worked on V26 and see if I can track it down further.
Ozpropdev, I suppose you've already realized, but it will be necessary to modify your tools to accommodate the moved instructions: WAITX/RFVAR/RFVARS and the new instruction: ONES. Also, the data reported back from GETINT and SETBRK has been changed and added to. These may have effect on your single-step debugger.