Shop Learn
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 107 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1104105107109110160

Comments

  • 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.
  • Cluso99Cluso99 Posts: 17,970
    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. :)
  • cgraceycgracey Posts: 13,627
    Right on!
  • 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.
  • cgraceycgracey Posts: 13,627
    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.

    Sorry if I've already proposed this a while back.
  • 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....
  • Cluso99Cluso99 Posts: 17,970
    edited 2017-12-10 05:34
    In v27z, where are SD pins connected? BeMicroCV-A9

    I have to babysit a solar installation tomorrow, so may get some P2 testing time.
  • cgraceycgracey Posts: 13,627
    Peter, is there any kind of error that you can reliably cause?
  • Hmmm, I haven't had it crash on me yet, and that is with the nop removed. I will try the other boards.
  • evanhevanh Posts: 11,862
    Chip,
    For clarity, I'd like PASM syntax changed from PTRx[index] to PTRx[#index]
  • jmgjmg Posts: 14,820
    evanh wrote: »
    Chip,
    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.
  • evanhevanh Posts: 11,862
    jmg wrote: »
    evanh wrote: »
    Chip,
    For clarity, I'd like PASM syntax changed from PTRx[index] to PTRx[#index]
    Many decades ago, intel and Motorola decided to use # prefix for #immed8 , #immed16 constants.
    That is true for Prop as well. In the Prop2 it's either # (for 9-bit) or ## (for 32-bit).

    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.
  • evanhevanh Posts: 11,862
    Of course, the far superior assembly format is Mnemonic Source Destination :D Why anyone would think putting destination first is a good idea beats the hell out of me.
  • jmgjmg Posts: 14,820
    evanh wrote: »
    Of course, the far superior assembly format is Mnemonic Source Destination :D 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

    RegName++
    RegName--



  • 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
  • jmgjmg Posts: 14,820
    T Chap wrote: »
    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.
  • rjo__rjo__ Posts: 2,115

    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.



  • cgraceycgracey Posts: 13,627
    The new v28 is posted at the top of this thread.

    There are many internal optimizations and some functional changes.

    Please try these out, if you can.

    Thanks!
  • cgracey wrote: »
    The new v28 is posted at the top of this thread.

    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?

  • cgraceycgracey Posts: 13,627
    cgracey wrote: »
    The new v28 is posted at the top of this thread.

    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.
  • Chip
    All V28 images loaded on all boards Ok.
    All looks good so far.
    Thanks!
  • Yes, all looks good on the CVA9, and I will check those I/O on the DE2 a little later.
  • 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
  • Tubular wrote: »
    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.
  • cgraceycgracey Posts: 13,627
    Any signs of flakiness, so far?
  • All solid on the CVA9!
  • jmgjmg Posts: 14,820
    All solid on the CVA9!

    Does that include the CLKSET/NOP pairing dictate issue you reported above ?
    Has that gone away on v28 ?
  • jmg wrote: »
    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.
  • cgraceycgracey Posts: 13,627
    edited 2017-12-11 20:12
    ozpropdev wrote: »
    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.
Sign In or Register to comment.