YUN use of PCINT3:1 on ICSP connector.

Hi,

I'm new user of arduino and i chose Yun,

I need 4 interruptions for my application,
I chose INT0 and 1 but i need 2 more.
As i want tu use the bridge INT3 (Tx), 2(Rx) and 6 (handshake) seem unusabled.

So i tried to use 2 PinChange Interruptions.

My sketch seems to work with PC_Int7:4 but fails working with PCINT3 and 1 but 2.
(works for PCINT2). The entrance swings. :angry:

So, my question is : Is-it possible to use PCINT3:1 (port PB3:1 on ATmega U32 pins 11:9) and what's the best way?
in fact, these pins are connected to the ICSP connector and the processor U1 through a bi-directionnal buffer which OE pin's state is unknown.

Thanks,

Kind regards.

See my code below...
PS : i also tried PCINT7:4 with PinChangeInterrupt's library

// PCINT test

//#define PIN_CHANGE_INT_LIB

#ifdef PIN_CHANGE_INT_LIB
#include <PinChangeInt.h>
#endif PIN_CHANGE_INT_LIB

#define PIN08_PCINT4 8
#define PIN09_PCINT5 9
#define PIN10_PCINT6 10
#define PIN11_PCINT7 11

// Notice that values that get modified inside an interrupt, that I wish to access
// outside the interrupt, are marked "volatile". It tells the compiler not to optimize
// the variable.
volatile uint16_t PCINTx_interruptCount=0; // The count will go back to 0 after hitting 65535.

void setup()
{
Serial.begin(9600);
while (!Serial); // do nothing until the serial monitor is opened
Serial.println("GO !");

InitialiseIO();

#ifdef PIN_CHANGE_INT_LIB
attachPinChangeInterrupt(PIN11_PCINT7, PCINTx_interruptFunction, FALLING);
#else PIN_CHANGE_INT_LIB
InitialiseInterrupt();
#endif PIN_CHANGE_INT_LIB
}

volatile uint16_t PCINTx_interruptCount_Cpy_old;

void loop() {

volatile uint16_t PCINTx_interruptCount_Cpy;
uint8_t oldSREG; // Status Register

// to read a variable which the interrupt code writes, we
// must temporarily disable interrupts, to be sure it will
// not change while we are reading. To minimize the time
// with interrupts off, just quickly make a copy, and then
// use the copy while allowing the interrupt to keep working.
//noInterrupts();
//GlobalVar_Copy = GlobalVar;
//interrupts();

// Interrupt Variable's read must be protected.
// Prevent Variable's modification during read operation.
oldSREG = SREG;
cli();
PCINTx_interruptCount_Cpy = PCINTx_interruptCount;
// Restore interrupts
SREG = oldSREG;

if(PCINTx_interruptCount_Cpy != PCINTx_interruptCount_Cpy_old)
{
Serial.print("PCINTx_interruptCount : ");
Serial.println(PCINTx_interruptCount_Cpy);
delay(1000);
}

PCINTx_interruptCount_Cpy_old = PCINTx_interruptCount_Cpy;
}

void InitialiseIO(){

// pinMode(PIN11_PCINT7, INPUT_PULLUP); // Configure the pin as an input, and turn on the pullup resistor.
// pinMode( PIN11_PCINT7, INPUT); // Configure the pin as an input
// digitalWrite( PIN11_PCINT7, HIGH); // Internal Pull-Up
DDRB = 0x00; //PCINT7:0 == input
PORTB = 0xFF; //PCINT7:0 == Pull-Up

}//void InitialiseIO()

#ifndef PIN_CHANGE_INT_LIB

void InitialiseInterrupt(){

cli(); // switch interrupts off while messing with their settings

// EICRA = 0x2; // Falling edge of INT0 generates an interrupt request
// EICRB = 0xFF; // Any edge of INT0 generates an interrupt request
EIMSK = 0; // Disable INTx interrupt enbale
PCICR = 1; // PCIE0 = 1 : Enable PCINT0 interrupt
PCIFR = 1; // PCIF0 = 1 : Clear interrupt flags PCIFR

// PCMSK0 = 0x80; //Enable PCINT7 only !!!
// PCMSK0 = 0x82; //Enable PCINT7 & PCINT1 only !!!
PCMSK0 = 0x88; //Enable PCINT7 & PCINT3 only !!!
// PCMSK0 = 0x84; //Enable PCINT7 & PCINT2 only !!!

sei(); // turn interrupts back on

}//InitialiseInterrupt()

// Do not use any Serial.print() in interrupt subroutines. Serial.print() uses interrupts,
// and by default interrupts are off in interrupt subroutines. Interrupt routines should also
// be as fast as possible. Here we just increment a counter.
ISR(PCINT0_vect) { // Interrupt service routine. Every single PCINT7:0 change
// will generate an interrupt: but this will always be the same interrupt routine

PCINTx_interruptCount++;

// PCIFR = 1; // PCIF0 = 1 : Clear interrupt flags PCIFR

}//PCINT0_vect()

#endif PIN_CHANGE_INT_LIB

void PCINTx_interruptFunction() {
PCINTx_interruptCount++;
}

JustVince:
As i want tu use the bridge INT3 (Tx), 2(Rx) and 6 (handshake) seem unusabled.

You are correct about the tx/rx pins, but not the handshake line. While that is connected to the Lnux processor, it is through a level shifter that is normally turned off. It's available for your use, but unless you make intentional configuration changes on the Linux side, it's as in the line was disconnected. In normal use, you are free to use that pin for any desired purpose.

Unfortunately, I don't have any experience using these interrupts, so I have no other advice to offer.

Hi,
thanks for your reply.
so as i use OC1A, OC1B, OC1C and OC3A to generate a DC voltage.
i'm dealing with it if i use INT0, INT1, INT6 and PCINT4.
and thanks to the rx/tx pin left, i'll be able to use the bridge too.
I'm saved.

I haven't read about this "level shifter" yet.

  1. But i would like to understand how SPI works through the ICSP connector while PCINT1 n PCINT2 doesn't...
    May be an other opinion?...

  2. Optional question...Did anybody read this book and what's your meaning about it ?
    YUNBOOK1 with YUNKITV2

bye

I'm glad you got it working!

JustVince:
I haven't read about this "level shifter" yet.

The AVR processor (that runs the sketch) is a 5 volt device. The Linux processor is a 3.3 volt device with even lower I/O voltages - 2.5 volts for the lines going to the AVR processor. They cannot be connected directly or it will be too much voltage for the Linux processor. The key is a "level shifter" circuit that is between the two processors, that shifts the 5 volt signals to a lower voltage like 2.5 volts, and the 2.5 volt signals to 5 volts. All of the signals that go between the two processors have a level shifter such as this to translate the voltage levels and keep each processor safe and happy.

These level shifters also have an enable signal. When disabled, it's as if there is no connection between the two processors on that line. When enabled, it's as if they are connected, but using different voltage on the two sides. This enable signal is controlled by a GPIO output pin on the Linux processor.

The default state for the level shifter on the Rx/Tx lines is enabled, but the default state for the level shifter on the handshake line is disabled. You can use that line for passing signals between the two processors, but you have to specifically set the GPIO pin on the Linux side to enable it.

  1. But i would like to understand how SPI works through the ICSP connector while PCINT1 n PCINT2 doesn't...

I haven't tried using any of those pins as interrupts. As long as you are not using the SPI interface, you should be able to field interrupts on that pin. Of course, the first thought is that you might have a bug in your code and you are not setting it up properly? (Although I'm sure you've already looked into this...)

Maybe someone else will come along who has experience with using that particular interrupt.

Speaking of level shifters and connections to the Linux processor: be aware if you use the ICSP connector, that there is another set of level shifters between those pins and the Linux processor. Those are also normally disabled, so you don't normally have to worry about them. However, when you load code over the network, the code is first sent to the Linux processor, and then the level shifters are enabled so that the Linux processor can load the code into the AVR processor using this ICSP connection. If you are using any of the ICSP pins as outputs, you might inadvertently trigger the device connected to it. And if you are using any of these pins as inputs, and have an external device driving the line, you might have problems loading code over the network.

  1. Optional question...Did anybody read this book and what's your meaning about it ?
    YUNBOOK1 with YUNKITV2

Never heard of the book until this moment. Therefore I have no opinion to offer.

Thanks again,
Actually I noticed that these pins should be used to program the component by ethernet through the linux, but obviously i have forgotten ! :grinning:
Indeed as the programming was slower by ethernet, I decided to return to the programming through USB.
So it's probably a bad idea to use these pins for interruptions ...
Perhaps with a little more experience, I would be able, i would be able to figure out this issue
Thanks again.

ShapeShifter:
...
The AVR processor (that runs the sketch) is a 5 volt device. The Linux processor is a 3.3 volt device. They cannot be connected directly or it will be too much voltage for the Linux processor. The key is a "level shifter" circuit that is between the two processors, that shifts the 5 volt signals to 3.3 volts, and the 3.3 volt signals to 5 volts. All of the signals that go between the two processors have a level shifter such as this to translate the voltage levels and keep each processor safe and happy.
...

It is not true for Arduino Yun, Yun use Qualcomm Atheros AR9331 which IO level is 2.5 V. Feed 3.3 volt could fry it.

CPU IO level could be 0.8 V, 1.2 V, 1.5 V, 1.8 V, 2.5 V and 3.3 V. Use correspond level shifter for them please.

sonnyyu:
It is not true for Arduino Yun, Yun use Qualcomm Atheros AR9331 which IO level is 2.5 V. Feed 3.3 volt could fry it.

CPU IO level could be 0.8 V, 1.2 V, 1.5 V, 1.8 V, 2.5 V and 3.3 V. Use correspond level shifter for them please.

Thank you for catching that! I was typing on my tablet and didn't open up the schematic to look at the exact details. While the processor is powered from 3.3V, it is indeed true that the level shifters are translating between 5V on the AVR side and 2.5V on the Linux side.

Fortunately, I was only trying to explain the concept, and the exact voltage level is not critical to that discussion (although I have gone back and clarified my original post.) Although it's generally annoying that none of the Linux I/O pins are directly accessible through the board's connectors, this is one case where that's good because the actual voltage isn't really that important, since everything is already routed properly on the board.

But yes, it would be very important if one were making direct connections to the processor pins (which isn't the case here.)