Ok this is too much... i never would have guessed XMOS to mess up (in my mind) with their IO stuff..
Ok i know how to set a port to in or out...ex...
out port LEDS = XS1_PORT_8A;
I also know how to set each bit ...
LEDS <: SOMEVALUE; //8bit value since its a 8bit port...
How would i clear a single bit? By clear i mean set to 0...? While preserving the rest of the bits of course.
Using IO
-
- Experienced Member
- Posts: 77
- Joined: Fri Dec 06, 2013 7:05 pm
lets say you wanna clear the first bit, i would go with something like this:
LEDS <: OLDOUTPUTVALUE & 0b11111110;
LEDS <: OLDOUTPUTVALUE & 0b11111110;
-
- XCore Addict
- Posts: 135
- Joined: Mon Dec 14, 2009 3:02 pm
I assumed that... but are you telling me i have to buffer what im putting out?
There is no way to read the current value back?
There is no way to read the current value back?
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
You can also get the value currently on the pins using peek().
It is better to keep track of the value you are outputting
though, as pasau says.
It is better to keep track of the value you are outputting
though, as pasau says.
-
- XCore Addict
- Posts: 135
- Joined: Mon Dec 14, 2009 3:02 pm
Thanks, im about to try this:
#define CLK_HIGH() SPI2 <: (peek(SPI2) | CLK)
#define CLK_LOW() SPI2 <: (peek(SPI2) & (~CLK))
#define CLK_HIGH() SPI2 <: (peek(SPI2) | CLK)
#define CLK_LOW() SPI2 <: (peek(SPI2) & (~CLK))
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
For a clock i'd just buffer the old value or use constants. (or use a buffered port when applicable)
-
- XCore Addict
- Posts: 135
- Joined: Mon Dec 14, 2009 3:02 pm
Yes its for a clock, i dont see the advantage of using a buffered port. Seems more complex at the moment. Id rather just peek like im doing now, it works as far as i can tell so im happy :)
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Disadvantages of using peek() include: a) it is somewhat
slower; b) it returns the value *currently* at the pins (so
beware with buffered ports, etc.; also, if you do it too fast
after the previous output you will need a sync on the port,
and even then you still need to consider the delay from port
output to port input); and c) it returns the value currently
at the *pins*, which is not necessarily the same thing you
are outputting (say, open drain output -- should not be a
problem with 4-bit ports unless you are overpowering the
pins somehow; bad plan that).
So yes it should work for you, but it is not the best solution.
It does make for a nice quick hack though ;-)
slower; b) it returns the value *currently* at the pins (so
beware with buffered ports, etc.; also, if you do it too fast
after the previous output you will need a sync on the port,
and even then you still need to consider the delay from port
output to port input); and c) it returns the value currently
at the *pins*, which is not necessarily the same thing you
are outputting (say, open drain output -- should not be a
problem with 4-bit ports unless you are overpowering the
pins somehow; bad plan that).
So yes it should work for you, but it is not the best solution.
It does make for a nice quick hack though ;-)
-
- XCore Addict
- Posts: 135
- Joined: Mon Dec 14, 2009 3:02 pm
ah ok, yeah i can see its usefulness ... for a 25mhz max spi i think its ok... i might use it at 10mhz tho.