Author Topic: Hardware interrupts  (Read 1822 times)

0 Members and 1 Guest are viewing this topic.

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Hardware interrupts
« on: March 16, 2009, 12:32:32 PM »
Edit: Turns out it was an rprintf problem. Interrupts were working all along. Arg.

I am trying to get wheel watcher from nubotics.com to work with the Axon.

I got it sort of working... but I think it is missing readings as the wheel turns faster.

Currently I just have a function that checks bit_is_clear(PINC,0) that is in the main control loop.

The problem is, the wheel watcher pulses low for 25us every time a wheel maker passes, so there should be 128 per rotation and I am looking at roughly 4 revolutions per second, so it needs to catch about 500 per second per wheel for two wheels.

Is it even possible to do at this resolution? And if so, is there a better way to do it than to just check bit_is_clear() once per loop? It seems like I will start missing markers as the program gets more complex.

Thanks
J
« Last Edit: March 17, 2009, 03:25:06 PM by Resilient »

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Re: Wheel watcher quesion
« Reply #1 on: March 16, 2009, 12:52:02 PM »
Doing a bit of reading, some basic information on how to use interrupts would probably be all I need here..

Edit: Found it http://members.shaw.ca/climber/avrinterrupts.html

 :P
« Last Edit: March 16, 2009, 12:54:01 PM by Resilient »

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Re: Wheel watcher quesion
« Reply #2 on: March 16, 2009, 04:01:18 PM »
Ok I lied, I need help with hardware interrupts.

How would I trigger a function when a pin goes low on the Axon using a hardware interrupt? Its for a wheel encoder if that matters.

And what is the story with PCINT pins? From what I can tell, they trigger any time there is a pin change, but I can only find references to PCINT0, PCINT1 and PCINT2.  But the schematic shows PCINT0 through PCINT23.

Sorry for replying to myself twice  :P.

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Re: Hardware interrupts
« Reply #3 on: March 17, 2009, 12:08:16 AM »
I have made some progress.  I have the following now.

Code: [Select]

volatile uint32_t left_clicks = 0;
volatile uint32_t right_clicks = 0;
const int WHEEL_UPDATE = 64;


ISR (SIG_INTERRUPT4)
{
if(left_dir)
{
left_clicks++;
}
else
{
left_clicks--;
}
}

ISR (SIG_INTERRUPT6)
{
if(right_dir)
{
right_clicks++;
}
else
{
right_clicks--;
}
}

void main(void)
{
cbi(DDRC, PC1); //right dir, set for input
cbi(DDRE, PE6); //right clock, set for input
cbi(DDRE, PE4); //left clock, set for input
cbi(DDRE, PE3); //left dir, set for input
EICRB = 0b00100010; //sets pind 4 and 6 to interrupt on falling edge
EIMSK=0b01010000; //enables interrupts on 4 and 6
sei ();
while(1)
{
current_time = get_timer0_overflow()/WHEEL_UPDATE;
if(current_time >= 1)
{
rprintf("Left:%d  Right:%d\n",left_clicks,right_clicks);
reset_timer0();
}
}

}

So every second it tells me how far each wheel has gone.  Well it should.  It works exactly as expected for the left wheel, but for the right wheel it doesn't work. And oddly enough, if I run the left wheel backward and send it negative, THEN the right wheel will click to -1, if I turn the left wheel so its positive again, then the right wheel will register 0.

I have tried switching the sensors, and still only left_clicks will change, so its not a sensor problem.  This one has me totally puzzled.

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,657
  • Helpful? 169
    • Society of Robots
Re: Hardware interrupts
« Reply #4 on: March 22, 2009, 06:34:28 AM »
To be honest I never really understood rprintf entirely myself, and found a quirk in it for long ints. Try this:

Code: [Select]
rprintf("Left:%d%d  Right:%d%d\n",left_clicks,right_clicks);

Also, read through this post:
http://www.societyofrobots.com/robotforum/index.php?topic=3006.0

Offline chelmi

  • Supreme Robot
  • *****
  • Posts: 496
  • Helpful? 15
Re: Hardware interrupts
« Reply #5 on: March 22, 2009, 09:52:28 AM »
To be honest I never really understood rprintf entirely myself, and found a quirk in it for long ints. Try this:

Code: [Select]
rprintf("Left:%d%d  Right:%d%d\n",left_clicks,right_clicks);

Also, read through this post:
http://www.societyofrobots.com/robotforum/index.php?topic=3006.0


It won't work because you have 4 format specifiers for 2 variables. Also, left clicks are unsigned 32 bits integer, your format string should be:
Code: [Select]
rprintf("Left:%ul  Right:%ul\n",left_clicks,right_clicks);

Chelmi

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Re: Hardware interrupts
« Reply #6 on: March 24, 2009, 11:58:08 AM »
To be honest I never really understood rprintf entirely myself, and found a quirk in it for long ints. Try this:

Code: [Select]
rprintf("Left:%d%d  Right:%d%d\n",left_clicks,right_clicks);

Also, read through this post:
http://www.societyofrobots.com/robotforum/index.php?topic=3006.0


So I read that post and I am still having a bit of a hard time getting it to work right. I put #define RPRINTF_COMPLEX as the first line in axon.c and it gave me compile errors. So I took it out of axon.c and tried putting it right before #include "rprintf.h" in SoR_Utils.h.  Still got compile errors. (I get a bunch of "undefind reference to 'rprintf2Ramrom' errors)

So now I put RPRINTF_COMPLEX = 1 in the beginning of the makefile, but I dont know if that's the right way to make it defined in the makefile.  It complies fine, but it doesn't seem like RPRINTF_COMPLEX is working so I suspect I didn't do it right.

And if I make a local copy of rprintf.h and change RPRINTF_SIMPLE to RPRINTF_COMPLEX there then I get some different compile errors like "warning implicit declaration of function 'Isdigit'. Then latter, "conflicting types for 'Isdigit'.
« Last Edit: March 24, 2009, 12:12:25 PM by Resilient »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,657
  • Helpful? 169
    • Society of Robots
Re: Hardware interrupts
« Reply #7 on: March 24, 2009, 09:16:35 PM »
Those errors are why I never managed to get it to work, too . . . have you tried what chelmi said?

Also, trust me on the %d%d trick I did. It's a quick hack, but it works.

Offline ResilientTopic starter

  • Full Member
  • ***
  • Posts: 111
  • Helpful? 4
Re: Hardware interrupts
« Reply #8 on: March 24, 2009, 10:21:40 PM »
Well, I seemed to get it to work actually.

In the local copy of rprintf.c I included <string.h> and moved the Isdigit and atoiRamRom function definitions to before the rprintf2RamRom definition.

Then in the local rprintf.h file I changed it to

Code: [Select]
#ifndef RPRINTF_COMPLEX
#define RPRINTF_COMPLEX
#endif

and now it seems to work.

 


Get Your Ad Here