XC Ports and Clock Edges

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Post by jonathan »

Actually, in discussion with someone smart...

It would be great if the solution was:

configure_out_port(port, clock, init_value) which by default drives data on negative edge (as current)
toggle(clock/port) which uses the inverse clock to drive the port (allowing dynamic edge selection for more complex protocols).

Then the compiler can check for the presence of calls to "toggle" in the source. If they are present, the initial configuration compiles in two clock blocks - one an inverted version of the first, and then compiles in the appropriate reconfiguration of the port dynamically when required. If no calls to toggle arise, one doesn't need the inverse clock block compiled in.
Image
omega7
Active Member
Posts: 32
Joined: Thu Jun 03, 2010 12:16 pm

Post by omega7 »

configure_out_port(port, clock, initialvalue, edge)
I agree with this. Serializing with port buffering is a great feature, and fast. But, using this with a SPI implementation I recognized the same issue that I need a port update on the rising edge. Most SPI ADC's for example triggers a new conversion on the falling edge and may be read and clocked on the rising edge.
Hopefully possible in the (very) near future.... ;)
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

Peter's come up with a suggestion: Delay the falling edge so that it coincides with the rising edge.

This would mean that the input will be sampled at the same time as the output changes.

You can do this using set_clock_fall_delay. This delays by up to 512 processor clocks. This means that the minimum clock frequency would be under 500kHz.

The down side is that if you're trying to drive this clock out you wouldn't see a clock because the +ve and -ve edges would coincide.