Go Down

Topic: Need help troubleshooting variable not getting set by interrupt (Read 1 time) previous topic - next topic

MatCat

This is not the PinchangeInt library, it is the PinchangeInterrupt library for the ATTINY core,  I dunno why everyone want's to focus on the interrupts when they work and the last bit of code does not even apply to this library... At either rate I AM open to ideas and if everyone thinks it's better to keep track of the actual rise/fall change myself vs letting the library do it I can, but the way it's coded and how simple it is I do not see it making much of a difference...

This type of project is REALLY tough without a serial port!!!  I just have no IDEA how to tell what is going on... I think I will use a pin for debugging and just bitbang to my oscilloscope to try to debug...



MatCat

Ok I wrote a little function to bitbang a byte to a pin so I could see on oscilloscope... now I need to make one that can do multibyte so I can see whats going on with timer variables because I couldn't find any issues with any variable that is just a byte.  The flags are working fine, though the output level goes to 255 every time it binds, so that tells me the timer isn't working properly for some reason.

DuaneB

Hi
  Fair enough comment on the library. I guess that most people see attaching two different handlers to a single pin as being something that is not supported at the hardware level, if it works using the library, it maybe by a side effect rather than a design intention - its better not to build projects that rely on side effects.

I can appreciate that it must be very hard to do these things without serial, but testing a single channel version using the single ISR with change interrupts will simplify the task a little.

Duane B


MatCat

#8
Nov 18, 2012, 06:08 am Last Edit: Nov 18, 2012, 12:33 pm by MatCat Reason: 1

Hi
 Fair enough comment on the library. I guess that most people see attaching two different handlers to a single pin as being something that is not supported at the hardware level, if it works using the library, it maybe by a side effect rather than a design intention - its better not to build projects that rely on side effects.

I can appreciate that it must be very hard to do these things without serial, but testing a single channel version using the single ISR with change interrupts will simplify the task a little.

Duane B



EXT interrupts are limited and do hardware RISING/FALLING detection and can only detect either one or the other at a time, but PC interrupts are triggered whenever any pin on the entire port change.  All the library does when an interrupt is given is check if the pin state is high or low, and call the appropriate callback for RISING/FALLING.

It's certainly a timing issue at this point somewhere, because I did have it working perfectly with only a single in/out, but I wrote 90% of that code at work with no chip on me to test as I went along hehe.  I ended up writing a little routine set to output bytes and ints to a digital pin which I can see with my oscope, I tested the single byte version this morning and it worked quite well to see some of the variables, so when I get home I can now check the counters and timers and see exactly what sort of measurement result on the width timing it is coming up with, it has to be higher then it should because it binds but assumes it is getting a full power signal reguardless of the pulse width.

Just for reference here are the few routines I came up with to see variables on scope, it's simple and basic and works hehe:
Code: [Select]
void debugPulse(int time) {
// A simple debugging routine to pulse pin 0 to debug variables using a scope
 digitalWrite(0,HIGH);
 delayMicroseconds(time);
 digitalWrite(0,LOW);
}
void debugPrintByte(byte bOut) {
// A simple function to pulse out a byte in bits, 50us width = 1, 10us width = 0
 if (bOut & 1) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 2) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 4) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 8) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 16) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 32) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 64) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }
 delayMicroseconds(5);
 if (bOut & 128) {
   debugPulse(50);
 } else {
   debugPulse(10);
 }

}
void debugPrintInt(int iOut) {
  // This function will outpit all 16 bits of an int on pin 0
  static byte singleByte = 0;
  singleByte |= (255 & (iOut & 1));
  singleByte |= (255 & (iOut & 2));
  singleByte |= (255 & (iOut & 4));
  singleByte |= (255 & (iOut & 8));
  singleByte |= (255 & (iOut & 16));
  singleByte |= (255 & (iOut & 32));
  singleByte |= (255 & (iOut & 64));
  singleByte |= (255 & (iOut & 128));
  debugPrintByte(singleByte);
  delayMicroseconds(20);
singleByte = iOut >> 8;
  debugPrintByte(singleByte);
}


DuaneB

Again, fair enough, as you say pin change interrupts work very differently on the tiny - I had a quick search and also turned up this reference to a serial debug option for the attiny which you might find useful -

http://arduino.cc/forum/index.php?topic=51838.0

Duane B

Go Up