Go Down

Topic: suggestion to add TOGGLE in digitalWrite() (Read 5907 times) previous topic - next topic

sv1eed

hello,
i didn't do much of a research about it (not much free time), but i think the library does not provide an easy/efficient way to toggle a pin.

anyway, i modified wiring.h and added:
...
#define HIGH 0x1
#define LOW  0x0
#define TOGGLE  0x2   // added line
...

and wiring_digital.c and changed to:
     if (val == LOW) *out &= ~bit;
     if (val == HIGH) *out |= bit; // added line
     if (val == TOGGLE) *out ^= bit; // added line
     // replaced line // else *out |= bit;


now it looks like i can write for example:
digitalWrite(ledPin, TOGGLE);
instead of calling other functions or keeping the state of the pin in the program.

if this modification does not create any issues, i think it would be a nice addition to a next version.

- chris

Osgeld

#1
Aug 18, 2010, 10:45 pm Last Edit: Aug 18, 2010, 10:48 pm by Osgeld Reason: 1
what speed does it toggle at? (and what if I want it faster or slower)

;)

and it already keeps the state of the pin that is why

pin = !pin works
[edit]
oh nevermind, i just re-read that, yea I guess that could be more noob friendly than the above, so why not [/edit]
http://arduino.cc/forum/index.php?action=unread;boards=2,3,4,5,67,6,7,8,9,10,11,66,12,13,15,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,86,87,89,1;ALL

westfw

Quote
so why not

Well, changing the "any non-zero value causes a 1 to be written" behavior may screw up any number of existing sketches...

BenF

Quote
Well, changing the "any non-zero value causes a 1 to be written" behavior may screw up any number of existing sketches...

I agree to this - it really is not wise to change this behavior considering backwards compatibility.

That AVR's support a lesser known direct pin toggle, so for those who don't mind using direct port IO, you can do toggle as follows:

Code: [Select]

// Example is for digital pin 2.

PIND = _BV(PIND2);  // toggle pin2 on AtMega168/328


deSilva

#4
Aug 19, 2010, 03:10 pm Last Edit: Aug 19, 2010, 03:10 pm by mpeuser Reason: 1
There seems to be a problem with the forum's software
The code should read
Code: [Select]
PIND ^= _BV(PIND2)

BenF

Quote
The code should read

No, it should not! Go and look it up.

deSilva

#6
Aug 19, 2010, 10:32 pm Last Edit: Aug 20, 2010, 11:40 am by mpeuser Reason: 1
:o

I see....
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1266933248/3#3
---
And it works for the 168 and 328 only, not with old mega8

westfw

Ah.  Using the PINx magic toggle port, and a variation of the FastDigitalWrite macro that has been floating around, it should be possible to create a "digitalToggle()" function (macro) that takes up no space unless it is used, and operates in a single cycle if all the arguments are constant, and IT DOESN'T HAVE TO BE BACKWARD COMPATIBLE WITH ANYTHING!
:-)

cr0sh

Quote
Well, changing the "any non-zero value causes a 1 to be written" behavior may screw up any number of existing sketches...


I don't necessarily think this is "one of those times", but sometimes you have to decide to say "fsck backwards compatibility" and make a change "for the better".

Deprecate and move on...

;)
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Osgeld

coughheaderspacingcough (although its way too late for that)

now what were you saying?

http://arduino.cc/forum/index.php?action=unread;boards=2,3,4,5,67,6,7,8,9,10,11,66,12,13,15,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,86,87,89,1;ALL

deSilva

IMHO he wanted to say "To hell with compatibility!"  ;D

fog44

Hello,
I think it is a good idea.
The same thing should be done to reverse the direction of a pin
(an input becomes an output, and an output becomes an input).
It would be great to write
pinMode(ThisPin, REVERSE);
Best regards,

sv1eed

well, i can not see why one should use macro's, or secret codes, or any other tricks to do what the digitalWrite() function should do anyway.

where is the logic in it then? if we do direct port manipulation, then digitalWrite() is completely useless (it is bigger and slower anyway),

on the other hand, if for any reasons we want a digitalWrite(), it should do all 3 useful bit manipulations (and, or, xor)

as for backwards compatibility:
this thing: "any non-zero value causes a 1 to be written"
looks seriously wrong anyway...


Go Up