PASM2: How to setup the FIFO? (was altsb and setbyte)

ke4pjw

Can altsb be used in combination with setbyte within a loop be used to populate a byte array in hubRAM?

I am having a tough time groking this, so please be kind. I know that it is supposed to be able to populate consecutive byte aligned longs, with the altsb being called once and the setbyte in a loop. However, I don't know if it can touch the hubRAM or not. I know on the P1 you had to used RDBYTE, WRBYTE and had to have your own address book-keeping when populating a byte array.

evanh

Nope. It's the same RDBYTE/WRBYTE ops apply as was used in the Prop1 for hubRAM data access.

SETBYTE/GETBYTE only work on cogRAM.

ALTSB/ALTGB are matching special prefixes for the above, as in they don't make sense in any other use ... but all ALTx instructions just modify, known as prefixing, the subsequent instruction in the execution pipeline irrespective of where those instructions are fetched from or what the prefixed instruction is. So, there is no safety net for combining inappropriate combinations. Sometimes nothing happens when you wanted something, other times really strange unexpected things can happen.

evanh

There is RFBYTE and WFBYTE. Compared to RDBYTE and WRBYTE, they as faster executing when performing consecutive reads or writes of hubRAM.

To use RFBYTE/WFBYTE requires setting up of the FIFO first. This in turn requires hubexec not to be in use. Hubexec needs the FIFO itself. This isn't so scary though. The FIFO will happily jump back and forth between hubexec and data buffering. The switch to hubexec is triggered when branching back to a hubRAM address.

ke4pjw

@evanh So I am scouring the manuals for information on how to setup the FIFO. There isn't much documentation at all for practical application. Seems line I would need to do something like:

          MOV i, #0 ' Loop Counter
          WRFAST #$80000008, #HUB_RAM_PTR  ' Setup a non-blocking 512 byte FIFO that points to @HUB_RAM_PTR
label WFBYTE #42  'Fill this FIFO with 42's :smile: 
          ADD i,#1
          CMP i,#512 wz
if_nz   JMP #label

If that is right, I am not sure what else to take into consideration. There seem to be other considerations with what happens when it wraps. I can't grok how I would use FBLOCK or GETPTR (Or even what the D register is). Maybe GETPTR could be used to help with the position within the FIFO?

Any comments are welcome!

evanh

Oh, there is also SETQ + WRLONG for a fast burst copy or fill. As you can see it only does longwords, not bytes. There's also SETQ + RDLONG and SETQ2 of both for lutRAM. They're intended for copying a block between hubRAM and cogRAM or lutRAM.

The WRLONG version can also be tricked into doing a block fill operation. The easiest being zeroing of hubRAM:

    setq    #41             ' 42 longwords
    wrlong  #0, #@buffer    ' fill hubRAM with zeros

evanh

@ke4pjw said:
@evanh So I am scouring the manuals for information on how to setup the FIFO. There isn't much documentation at all for practical application. Seems line I would need to do something like:

          MOV i, #0 ' Loop Counter
          WRFAST #$80000008, #HUB_RAM_PTR  ' Setup a non-blocking 512 byte FIFO that points to @HUB_RAM_PTR
label WFBYTE #42  'Fill this FIFO with 42's :smile: 
          ADD i,#1
          CMP i,#512 wz
if_nz   JMP #label

That's basically all you need there but be careful with the non-blocking bit. When setting that bit, if not enough clock cycles have elapsed between WRFAST and WFBYTE before the FIFO can be emptied from a prior use then the WFBYTE will not happen. Most of the time it will work for writes to hubRAM but reading hubRAM, with RDFAST, definitely needs a decent grace interval for the FIFO to be preloaded from hubRAM.

If that is right, I am not sure what else to take into consideration. There seem to be other considerations with what happens when it wraps. I can't grok how I would use FBLOCK or GETPTR (Or even what the D register is). Maybe GETPTR could be used to help with the position within the FIFO?

Nominally GETPTR, FBLOCK and block counts can be ignored. Just use WRFAST #0, hubaddr. When you want to change the straight line writing over to a new location then just issue a new WRFAST.

GETPTR is a hack that Chip did on request as a tacked on late change. I believe it only simulates the read address so only works under a particular use case.

ke4pjw

Thanks @evanh ! Yep , it all worked out.

There definitely needs to be some examples and explanations of the FIFO added to the PASM2 manual.

evanh

Good stuff.

Yeah, examples are going to be a never ending job. Prop2 has so much more to it. In some ways I'm just learning that now, as I'm making my first Prop1 project. I'm gritting my teeth a little at the prospect of crafting my own Pasm1 code. I feel adrift not having the cordic, smartpins, fast block copies at my beck and call. I now have to do my own self modifying code for array indexing, I've read plenty but never written any before.

evanh

Why the Prop1 now? It suits the job well, lots of small steppers, and the PCB layout was simplified quite a lot because of the DIP40 pin spacing. I haven't ordered any prototype as yet though. I looked at using the Prop2 Edge but it doesn't really mechanically fit too well. If I was to use a Prop2 at all then it'd need to be in a DIP footprint I think. The pin distribution nicely matches the motor driver chips on both sides.

Wuerfel_21

The DIP package is arguably the P1's greatest asset - so approachable!

I don't think I've actually done indexing in cog RAM a lot. Space's always scarce and it just tends to not be particularly economical, esp. when you can schedule your hub accesses such that they only take 8 cycles a pop.

evanh

This will be for the motor # references. The function is duplicated across all motors so there is going to be parameters and working variables and of course the pin numbers that all have to be dynamic. Maybe it all can go in hubRAM and just do a block copy each way for each motor. I'll find out I guess.