How to get the Port Count without a dummy write?

[psupine]

I'm writing to a set of 1 bit ports clocked from a single clock source. Each of these ports is buffered from a 32 bit shift register. The port counters are matched because there were all initialised before the clock source was started and so they all increment together.

The official way in the XMOS Programming Guide (section 6.10) to synchronise multiple ports is to use a sync(p) call to create the largest timing window and then quickly stuff each of the transfer registers before next clock edge. However, I am clocking the shift registers at around 60MHz and the window is too small get everything written in time.

Instead I am using scheduled transfers with the "@ count+delta" form. For this I need to read the current timestamp from one of the ports by doing a dummy write. This is not too bad, because I can write 0xffffffff to a line that is parked high anyway, but it is hugely wasteful of time.

Is there a way that I can read the port timestamp without a dummy write? Anyone used GETTS directly?

(Yes, I know I could use a 4 bit port which would be in sync already, but I have run out of 4 bit ports)

Update:

Code: Select all

count = partout_timestamped(dac_sync_A, 1 ,1);

This is better, in that I can limit the dummy write to a single clocked bit rather than the whole field.

[mon2]

Found this on getts:

https://www.xcore.com/viewtopic.php?t=409

[psupine]

Thanks. That shows me how to inject the assembler instruction into the source code, but I'm still at a bit of a loss as to what's happening at the port hardware. I'm a bit hesitant to climb underneath the hood here.

I had a look at the disassembly around the partout_timestamped() line and don't really understand everything that is happening. I'm usually pretty comfortable around assembler and embedded processors, but the ... um ... novel architecture and sometimes confusing documentation doesn't leave me feeling confident. The only other chip where I've felt this hesitancy was the transputer, so it's not entirely random.

I have the impression that much of the instruction set is actually reading and writing to various control and status registers scattered around the chip. On most other chips, they would be exactly that, and then you could look up the doco on what the various bits in each of those registers do. Instead there is this kind of load/store RISC core with an extended instruction set that directly controls what would normally be memory mapped internal peripherals if it was something like the MSP430 family. Doing it the XMOS way takes the peripheral controls off the internal bus and that's great for bandwidth, but the details are opaque.

Like the transputer, I don't think the customers are meant to peek under the hood, but rather stick to higher level code and libraries. The level of detail in the hardware documentation would seem to reflect this. Maybe one day I'll get to the bottom of this and be able to post answers rather than questions.