Can attachInterrupt() be used for Serial1 pins

Hardware
1

Is it possible to use attachInterrupt() to the serial RX pin?

I was reading here about attachInterrupt():
https://docs.particle.io/reference/firmware/photon/#attachinterrupt-

Where it says “Photon: All pins with the exception of D0 and A5”, and then when I go here, and look at pin desciption section
https://docs.particle.io/datasheets/photon-datasheet/

It says:
RX, Primarily used as UART RX, but can also be used as a digital GPIO or PWM.
TX,Primarily used as UART TX, but can also be used as a digital GPIO or PWM.

But I dont see any pin mapping to use RX/TX. So am I out of luck here ?

2

You can use attachInterrupt(RX, ...) or attachInterrupt(TX, ...), but that will interfere with the use of these pins as Serial1

3

I do not know precisely why you need a interrupt on RX pin.
But if you need a interruption when you have data on RX pin you can use the following function:
serialEvent()

4

serialEvent() is not interrupt driven, it's a sync function called in between iterations of loop() - I've already discussed that with the OP here

Quote from the docs you linked

1 Like
5

Is there a function for generating interupt when there is data to the serial port?
I know that there is a low level such as USART1_IRQHandler but if there’s an API for that?
This is an example for Mbed:

#include "mbed.h"

DigitalOut led1(LED1);
DigitalOut led2(LED2);

Serial pc(USBTX, USBRX);

void callback() {
    // Note: you need to actually read from the serial to clear the RX interrupt
    printf("%c\n", pc.getc());
    led2 = !led2;
}

int main() {
    pc.attach(&callback;);

    while (1) {
        led1 = !led1;
        wait(0.5);
    }
}
6

I had proposed something like that too, but as said in the other thread - no love there either :weary:

7

@developer_bt

To answer your question. Since the RX buffer for Serial1 is fixed at 64 bytes, and I don’t know exactly when I will be receiving this serial data.The serial data will come from another device giving info like:
Level 1 sensor value is 1022
Requested IP address is 192.168.1.23

How fast these happen is another issue, so even though each line may be <64 bytes, if it sends 2 messages back to back is where the trouble comes in. To further complicate things I have my own SPI & I2c devices to talk to. Which limits the amount of time I can sit in a while loop waiting for serial data.

This is the reason I am trying to see if there is another / better way around the limit 64 byte issue. If we could increase Serial1’s buffer this would allow me more time to get back to it.

8

@mikemoy, what would be ideal would be a user-specified buffer for Serial and Serial1. However, the Serial object is instantiated by the system firmware prior to running user code so a buffer had to be specified already. You can increase the system buffer size but only if you compile using a local toolchain.

9

@peekay123, is a feature like acquireSerialBuffer() what your talking about?
https://docs.particle.io/reference/firmware/photon/#acquireserialbuffer-

I am not quite sure what they mean by "…allocate its own buffers for Serial and USBSerial1"
When Serial is the USB connection, so what then is USBSerial ?

10

It's USBSerial1 which is a second virtual serial port via USB to keep logging and data streams seperated - both run via the USB port.

https://docs.particle.io/reference/firmware/photon/#serial

1 Like
11

@mikemoy, you are correct. acquireSerialBuffer() can redirect the serial buffer to a user specified buffer. However, this is not applicable to the UART serial ports such as Serial1 on the Photon.

12

Thank you for the clarification.