New Article: Pivotal Digital

[The Tone God]

Hello Everyone.

I just posted a new article called "Pivotal Digital" which talks about how to use the digital inputs and outputs of the AVR uC with C. This should give everyone the ability to do some real programming with their uC.

Enjoy.

The Tone God's Domain

Andrew

[bioroids]

Hi!

Very nice article! I think it's pretty clear.

Is good that you explained all the tricky bit operators and manipulations, as that is one of the hardest parts for people who is not a C programmer.

Also I think there is a little mistake on the first paragraph of the "Code changes" part. Where it says "should enable the internal pull up on PB0", I think you meant enable the internal pull-up on PB1 (on the other hand I may be totally lost  )

Ok, I have a question: suppose you are using the pin as an output, and at some part of the code you flip it to be an input. In what state does the pull-up resistor appears? It appears always clear unless you set it explicitly or it somehow remembers it previous state (if it ever was an input), or maybe it depends on the state the pin was as an output (if it was set, then when changing the pin to input the pull-up is enabled).

Well, thanks again for your effort!

Miguel

[The Tone God]

Also I think there is a little mistake on the first paragraph of the "Code changes" part. Where it says "should enable the internal pull up on PB0", I think you meant enable the internal pull-up on PB1 (on the other hand I may be totally lost  )

I'm never wrong! Oh wait...corrected. 

Ok, I have a question: suppose you are using the pin as an output, and at some part of the code you flip it to be an input. In what state does the pull-up resistor appears? It appears always clear unless you set it explicitly or it somehow remembers it previous state (if it ever was an input), or maybe it depends on the state the pin was as an output (if it was set, then when changing the pin to input the pull-up is enabled).

PORTx and DDRx are in general independent of each other. The pull up appears when the corresponding pin in PORTx is high so it depends on the last state of the output is before the change in DDRx. You may have to address both both registries right after each other to get to the desired state.

Are you still trying to read a pot ?

Andrew

[Peter Snowberg]

Great job!!!

[bioroids]

Are you still trying to read a pot ?

Not right now, but that was a doubt that came to me when trying to do that. Having the ADC on the chip pretty much makes it pointless.

At the moment I'm trying my luck at the C code (at first I was working in Assembler, just to get a feel of the hardware, and because I'm a nerd).

Thanks for all your time and effort!

Miguel

[DavidS]

It's been said already, but very nice handling of the bit manipulation! I DID know all of that at some point, but I'd kind of forgotten it. Binary math is not something that sticks with you don't use it for a while, especially if you never used it much to begin with!

Great article, can't wait for the next!

[The Tone God]

Thank you everyone.

At the moment I'm trying my luck at the C code (at first I was working in Assembler, just to get a feel of the hardware, and because I'm a nerd).

While being a fan of higher level languages I think its a good idea for everyone to learn to do some basic assembly. Even just learning how to make the "Hi There!" program in assembly will help give alot of insight into what the compiler is doing.

If you don't have any Tiny13s at the moment you could still use the Mega16 that should have come with your STK500 and just recompile the code for it with a few if any changes. That way you can still get in on the action.

It's been said already, but very nice handling of the bit manipulation! I DID know all of that at some point, but I'd kind of forgotten it. Binary math is not something that sticks with you don't use it for a while, especially if you never used it much to begin with!

Great article, can't wait for the next!

Thats pretty much why I thought it would be good even for the experienced C programmers to recap all of it if even just to give the final formulae.

As for the next article I'm not sure what I'm going to do. I think there is enough basic information now to atleast get people started on their own projects. For now I'm in a "holding pattern" observing what will happen next. I want to see how many STK500 people jump in, what questions pop up, what other suggestions are made, how much interest there is, what the requirements of other proposed projects are to try to work in tandem.

Article-wise I think the next logic step in programming is to cover interrupts. The other thought was to cover some basic hardware interfacing in a separate section thus breaking uC articles into hardware and software as it were.

Andrew

[DavidS]

Interrupts would be nice, but what I'd most like to see would be switch debouncing.

[R.G.]

David's right - it would be far more useful to the group of followers if you'd leave off interrupts for a while.

I can do the switch debouncing if you'd rather not, although about two web links would do just as well.

[bioroids]

I'd like to hear about interrupts as well, but switch debouncing it's also must-know stuff.

I need to find a good tutorial or description about the AVR extensions made to 'C'. Right now I'm searching on the AVRFreaks forum, but it would be a lot simpler to have an official specification, or something like that.

Luck!

Miguel

[The Tone God]

Interrupts would be nice, but what I'd most like to see would be switch debouncing.

Ah someone has be working/thinking ahead. Good job!

David's right - it would be far more useful to the group of followers if you'd leave off interrupts for a while.

I can do the switch debouncing if you'd rather not, although about two web links would do just as well.

Thanks for the offer. I already was planning a software debouncing article as the second article to go in the hardware section. I have a few dozen debouncing algorithms so I can give a few basic ones up. Maybe it would be better if I spend some time on hardware side of things for now.

The hardware section is going to be less AVR-centric since the hardware interfaces of various uC are generally similar to each other. Anything software related was going to be written in pseudo-code as to be less uC/language specific.

I'd like to hear about interrupts as well, but switch debouncing it's also must-know stuff.

I need to find a good tutorial or description about the AVR extensions made to 'C'. Right now I'm searching on the AVRFreaks forum, but it would be a lot simpler to have an official specification, or something like that.

Ok the angry mob has spoken. Debouncing is coming soon.

What "extensions" are you having trouble with ? You can fire up another thread so it can be discussed without hijacking this thread.

Andrew

[R.G.]

http://www.maxim-ic.com/appnotes.cfm/appnote_number/764
http://www.rentron.com/Myke6.htm
But possibly the best, and which explains why the simple "read it twice" stuff won't work
http://www.ganssle.com/debouncing.pdf

For those who'd rather read about an intro to microcontrollers all at once, Myke Predko's book
http://www.myke.com/hom-book.htm
Covers many of the topics that will be questions and wonderments here for weeks, for the PIC - and the AVR, and the 6805, and the 8051...

============================================================================

For those of you ready to stretch your programming muscles, I developed a circuit that uses the same PIC pin to both read a switch and control a switch-state LED - but with the same pin.

On my custom footswitchers, I use eight pins of a PIC to not only read the switch, it debounces the switch, and also leaves an LED attached to the same pin that reads the switch in the correct on/off status for what the switch state is inside the uC, which may not be the same state as the physical switch is at the moment. For instance, this can make momentary footswitches look like alternate action OR momentary OR sticky-switches OR one-of-N.

So, for extra credit - howzat work?

[DavidS]

Umm, maybe in your delay loop for the debouncer you're switching the pin back to output and writing to it in place of NOPs or counter decrement and periodically going back to input to check the switch state?

EDIT:

Or maybe you're doing something tricky with the internal pullups?

[R.G.]

Umm, maybe in your delay loop for the debouncer you're switching the pin back to output and writing to it in place of NOPs or counter decrement and periodically going back to input to check the switch state?

Close, but backwards.

The trick is that it's always an output - except when I want to see whether the switch is made or not. I blip it over to "input" for just long enough to tell if the switch is up or down, whether or not that's a bouncing up or down. The human eye can't tell if an LED is off for a few milliseconds.

I have a timer interrupt set for 10ms, and every timer tick, I go make all the switch pins be inputs by manipulating the data direction register, not the data holding register. That leaves what the controller thinks is the LED state alone in the data holding register, and lets me make the pins all be inputs. There is a mild RC on the switch, enough so that if the switch is not bouncing, it settles in under 100uS to the value it would be if the output happened to be in the wrong direction.

So when a timer tick happens, the pins are set to inputs, and I spend the next millisecond or so doing my math from the last timer tick. That math includes all of the record keeping and thinking about whether the switch is debounced, etc.  Then I read the pins, store what the pins read now, flip the data direction register back to all outputs, and resume from the interrupt. Now I have 9ms (or 90% of the available processor) to do whatever the processor was doing anyway. And that doesn't even have to be concentrated in 90% intervals, as the program never sees what happens in the interrupts.

Ah - but how does the program know if switches have changed? I set flag bytes while I'm in the interrupt level indicating the current state of the switches. The main loop just looks at the state of the switches as reflected in the flag bytes and manipulates things accordingly,  including turning the switch LEDs on and off. The switch polling routine doesn't know or care what the main loop is doing. I just rounds up data from the switches and sets the flags for "here's what's happing now".

However, this whole thing could easily enough be done without interrupts. You just put the interrupt code in line with the main loop and pad out the operations with a wait loop to use the other 80% of the time that nothing's happening.

[DavidS]

Hey Tone God,

Minor critique on the article, when you're showing a sequence of bitwise operations and then the result, like this:

value = 01010101 & ~(00000001);

value = 01010101 & 11111110;

value = 01010100;

I found it a little confusing that the last line which seems to show the result looks like another assignment. Maybe use the equality operator (==) instead? Might make it a little more readable.

Thanks again for the article!

[The Tone God]

I found it a little confusing that the last line which seems to show the result looks like another assignment. Maybe use the equality operator (==) instead? Might make it a little more readable.

We aren't testing for equality. We are assigning the value but that is a moot point. I'm not using C style math nomenclature when evaluating those equations. I'm using boolean math for clarity sake.

Also you will see that I compress the equations after going through the evaluation. Using == would result in a different equation compression which then causes a "Why did you use == then compress the equation when it really is = when expanded ?" post.

Andrew

[DavidS]

OK, right, I was looking at it wrongwise. Got it now. Thanks!

[bioroids]

The trick is that it's always an output - except when I want to see whether the switch is made or not. I blip it over to "input" for just long enough to tell if the switch is up or down, whether or not that's a bouncing up or down. The human eye can't tell if an LED is off for a few milliseconds.

What I dont understand is how you wire the "hardware" part: the switch and the led, together.

Luck!

Miguel

[Dave_B]

But possibly the best, and which explains why the simple "read it twice" stuff won't work
http://www.ganssle.com/debouncing.pdf

Thanks R.G. that was helpful, though I'm not sure if my variation will work.  I'm processing based on the leading edge of a switch transition, then telling the processor to ignore hardware interupts for about 5ms to provide the debounce.

More specifically:
1) Loop infinitely until a hardware interupt occurs (the stompswitch being pressed or released)
2) Turn the effect on or off, based on the position of the switch
3) Turn off the hardware interupt for x number of milliseconds using the timer interupt (to provide debounce)

Does anyone see a reliability issue with this method?  I am using a timer interupt instead of wasting cycles on a timer loop, not that it matters with this simple code.

Thanks again.

[R.G.]

I'm creating a new topic on switch debouncing as this line of discussion does not match the title of this thread.