additional issue with the problem addressed recently about arduino-pinchangeint HOT 19 CLOSED

Fixed for my by changing line 104 of PinChangeInt.h from
portInputReg(*portInputReg(index + 2)),
to
portInputReg(*portInputRegister(index + 2)),

What version of the product are you using?
Arduino 1.0

On what operating system?
Windows 7 (64 bit)

That 'fix' undoes one of the changes made yesterday when there was an issue 
with that same line of code. That was determined as a spelling error and changed
from, 
'portInputReg(*portInputRegister(index + 2))'

to
'portInputReg(*portInputReg(index + 2))'.

Now you are undoing that change.
We are now starting to go around in circles.

I only found this library yesterday... I don't know about the other issue...
For me I have a clean install 'download' of Arduino 1.0...
I hope this can be fixed... the library in wonderful when you are running low 
on pins...

I am having the same issue. I had a version from a couple of weeks ago that was 
working just fine but this latest revision would not work (got the same compile 
errors).
Changed the variable name and now it compiles.

Which variable and what name did you change?

I have the same problem.

FYI

I talked to the person who made comment #4 and they said that they were using 
Arduino 0019 and the variable that was being used was 
'portInputReg(*portInputRegister(index + 2))'. I downloaded Arduino 0019 and 
changed the variable name, and it compiled and ran.

FYI

OK, so where we at with this?  I had the same prob (with A22) and I needed to 
move forward.  stevene is right (comment #2) that this is rolling back a change 
from the authors.  However the authors did not post a working version.  Is 
there any reason to think that they are working on this?  Is there any real 
negative to rolling back the change by renaming the var?

I think it's OK to roll back, this is a mismatch between two modules.  The 
"fix" was to make THEIR modules match, but it doesn't seem to make OUR modules 
match. Any working future release should have a match, with no harm done from 
the hack to get this one working. So, why not?

BTW, this looks to be a pretty nicely built library, kudos over all to the 
authors.

Cheers,
-r

I think your going to need some preprocessor #ifdef statements. Something like 
this:

    #if defined(ARDUINO) && ARDUINO >= 100
        portInputReg(*portInputRegister(index + 2)),
    #else
        portInputReg(*portInputReg(index + 2)),
    #endif

Also in arduino 1.0 you need to #include "Arduino.h" not  "pins_arduino.h".  
This should cover old versions and new versions of arduino, I think... I only 
tested this with Arduino 1.0 not with any older versions.

An updated file is attached.

dropped in the file from #9, got a new error

modified PinChangeInt.cpp replaced

#ifndef WProgram_h
#include "WProgram.h"
#endif

with

#ifndef WProgram_h

#if defined(ARDUINO) && ARDUINO >= 100
  #include "Arduino.h"
#else
  #include "WProgram.h"
  #include <pins_arduino.h>
#endif

Thanks for a great little lib!

Just some comments on the discussion. As discussed the source should use the 
#if defined(ARDUINO) && ARDUINO >= 100 to check wether its running on 1.0 or 
not but when putting this into the checked out source I noticed some other 
things minor issues, more of a conceptual level.

The PinChangeInt.h looks like this in the beginning:

#ifndef _STDDEF_H
#include "stddef.h"
#endif
#ifndef PinChangeInt_h
#define PinChangeInt_h
#include "PinChangeIntConfig.h"
#ifndef Pins_Arduino_h
#include "pins_arduino.h"
#endif

The _STDDEF_H is not needed since stdfe.h does this as the first line of code. 
And following this principle which is extremely common when writing .h-files, 
there is no no need for #ifndef Pins_Arduino_h too. Instead it should look like 
this:

#ifndef PinChangeInt_h
#define PinChangeInt_h

#include "stddef.h"
#include "PinChangeIntConfig.h"

#if defined(ARDUINO) && ARDUINO >= 100
  #include "Arduino.h"
#else
  #include <pins_arduino.h>
#endif

Nor should the PinChangeInt.cpp file look like this:
#ifndef WProgram_h
#include "WProgram.h"
#endif
#ifndef PinChangeInt_h
#include <PinChangeInt.h>
#endif

but rather:
#if defined(ARDUINO) && ARDUINO >= 100
  #include "Arduino.h"
#else
  #include "WProgram.h"
#endif

#include <PinChangeInt.h>

Simpler and cleaner and easier to read.

First I want to thank for the lib, good work.

I faced the same problem and this is what I did to deliver the attached 7z-file.
I have combined:
* Version 1.2
* Comment #10 by [email protected], 
* Comment #11 by [email protected]
* removed a warning on an unused variable "i" in PCintPort::addPin(...)
* Examples
* keywords

Remark on Comment #9: It doesn't help with Arduino 19, checked it by 
compilation.

I have a question: what is second portInputReg refer to in 
"portInputReg(*portInputReg(index + 2)),"?
portInputRegister is unambiguous and makes sense to me.

Thanks for the discussion and comments on this.  I will update PinChangeInt-1.2 
and make PinChangeInt-1.3.  I have a number of libraries and do not work with 
Arduino-1.0, but it looks like I should :-).  Thanks again.

Regarding Comment 1, it's weird but I can't find code with portInputReg(index + 
2).  I find in all versions that I have: Version 0.1, 1.1, and 1.2, that it is: 
 portInputReg(*portInputRegister(index + 2)),   .

The *portIntputRegister is a macro found in pins_arduino.1 (at least in pre-1.0 
Arduino code).  I don't think the portInputReg(index + 2) woulrd work at all... 
 very strange...

Regarding comment 9, this
    #if defined(ARDUINO) && ARDUINO >= 100
        portInputReg(*portInputRegister(index + 2)),
    #else
        portInputReg(*portInputReg(index + 2)),
    #endif

Won't work in older Arduino versions.  The macro is *portInputRegister, and 
that is what one must use.  I would be interested to know where the 
*portInputReg (in *portInputReg(index + 2) ) came from.  It shouldn't work.

...and therefore, that #if is not necessary.

Downloaded pinChangeInt 1.3 and it worked perfectly with Arduino 1.0.

I am using two quad encoders with pinChangeInt and the variables are being 
updated
every 200mS and the counts are around 22 for each encoder, with the power of the
motor at 60%. That means that the interrupts are running about 10ms each but 
because
there a there are 2 quad encoders, that means the interrupts are running at 
about 5ms, I think.

I don't know if that means anything to anybody, but the quadrature interrupt 
code was downloaded from http://www.arduino.cc/playground/Main/RotaryEncoders 
and I am using the last code section on the page if anybody wants to look. It 
is "The XOR method driving an LCD and LED", modified of course.

Good job, thanks...

Absent further input, I'm going to count this one as done.  Thanks all for your 
work, feedback, and input.