next topic »

[on:]

I'm creating my own sort of one wire protocol (to drive a attiny10):

when I drive the line low for a moment the other side starts reading pulses.

So far so good. But I detect that:

if I do a digitalWrite(line, HIGH); (e.g. on D12 or D13), the other side starts to respond.

it should only respond to a digitalWrite(line, LOW);

To confirm this issue I also tried it with:

Code:

PORTB &= ~1<<PINB5;
  delay(1000);
  PORTB |= 1<<PINB5;
  delay(1000);

That gives exactly the expected behavior.

It seems that digitalWrite(x, HIGH) does more than PORTB &= (1 << PINB4);

That is very interesting isn't it?!

[Reply #1 on:]

I assume from your post that you are trying to claim digitalWrite is buggy.  Before making that claim, you may want to correct a mistake in your snippet and rerun your test.

Code:

  PORTB &= ~1<<PINB5;

Bitwise-not has a higher precedence than shift-left.  I'll let you work out what that line of code really does.

[Reply #2 on:]

What CB said, check out operator precedence, remember that these core functions have been around for a LONG time, the chance of an undocumented bug is essentially 2/5ths of 5/8ths of bugger all.

______
Rob

[Reply #3 on:]

What CB said, check out operator precedence, remember that these core functions have been around for a LONG time, the chance of an undocumented bug is essentially 2/5ths of 5/8ths of bugger all.

Surly you mean just two chances. Fat & Slim

[Reply #4 on:]

Of course it does, that was my mistake, but that must have been the rush this morning before going to work. I corrected it the way I normally do it, so with parenthesis before the 1 and a closing one before the semicolon.

Didn't change the effect (actually I programmed it correctly but posted it here incorrectly). I will use my scope to it to see the effects, but not before tonight. No matter what, I detect a high/low switch when I perform a drigitalWrite(x, HIGH). Not that it matters to me but I thought it would be interesting to you all. I use a recent rev. UNO b.t.w. it could be hardware related of course.

Code:

PORTB &= ~(1<<PINB5);
  delay(1000);
  PORTB |= (1<<PINB5);
  delay(1000);

No offense, but I consider just exploring it myself and then just share it with my students

[Reply #5 on:]

Did you remember to set the pin to OUTPUT?

[Reply #6 on:]

Sorry, I won't go further with this... I have used Atmel uC for some years now, I have programming experience as a software engineer since 1997, I teach computer science both at high school and university, etc. I even wrote a complete educational Arduino program for high schools all around my country.

So I screwed up my first post because of being in a hurry (I should have done better, I agree). I know there are a lot of novice users here, but sorry this topic was a mistake it will lead to nothing. (of course I set the DDR on port B by using pinMode in Arduino). I am a bad reader myself, but a lot of experienced people here don't seem to read my issue and just comment by doing lucky guesses...

My mistake. I will just enjoy the fun of Arduino with myself and my always positive, helping and understanding students

[Reply #7 on:]

(of course I set the DDR on port B by using pinMode in Arduino).

Well you didn't really post anything someone else could test with.  So you left the door wide open for assumptions.  You gave a vague issue and expect precise answers. 

The behavior you are describing with digitalWrite() doesn't make sense.  The behavior with (the correct) direct port manipulation doesn't make sense.  In all the time I watched digital outputs on my scope, I have never captured a spurious transition like you suggest.  So something else is going on.  For example, is there another function those pins have that are interfering with their operation?  What is the hardware on the other side?  etc.

[Reply #8 on:]

but a lot of experienced people here don't seem to read my issue and just comment by doing lucky guesses...

In the absence of full code what are they supposed to do?

I won't go further with this.

Do you want me to delete/move/lock the thread?