Reading UART Rx Buffer (MKR WiFi 1010 / MKR 1000)

Hello All, (michaelkellett)

I think I may have made some progress... It doesn't really help having spent so long with C and left my C++ behind although I guess this is also found in C.

Have have found some code that may point me in the right direction but pointers and references...

In \AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.4\variants\mkrwifi1010\variant.cpp

Uart Serial1(&sercom5, PIN_SERIAL1_RX, PIN_SERIAL1_TX, PAD_SERIAL1_RX, PAD_SERIAL1_TX);

In \AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.4\cores\arduino\Uart.cpp

Uart::Uart(SERCOM *_s, uint8_t _pinRX, uint8_t _pinTX, SercomRXPad _padRX, SercomUartTXPad _padTX, uint8_t _pinRTS, uint8_t _pinCTS)

{

  sercom = _s;

In \AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.4\cores\arduino\SERCOM.cpp

uint8_t SERCOM::readDataUART()

In \AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.4\cores\arduino\Uart.cpp

sercom->readDataUART();

In \AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.4\cores\arduino\SERCOM.cpp

return sercom->USART.DATA.bit.DATA;

Its this last line I'm having issues with. sercom is a pointer to sercom5, which I assume (I can't find it for sure) is a pointer to the UART registers? I'm not really sure what to make of this line, so I'm putting it out there and hoping someone can help me make heads or tails of this.

Thanks

Kas

I've just ordered an MKR 1010 - in stock at F so should get here tomorrow .

More stuff to do before Christmas so it  might be a week before I get a look at it.

I did find this:

https://community.atmel.com/forum/atsamd21-sercom-interrupt-using-asf

If it helps - great.

MK

Hello michaelkellett,

I've read over that link now and cant find a clear answer. I've attempted to look for the functions mentioned as well as tried running their code in the Arduino IDE, no dice . I have also continued to try drill down with in the code to find the callback function that puts the received characters in the ring buffer, also no dice. This is really turning out to be a hunt that doesn't look like will have an easy or quick solution.

If you have any further ideas, I'll be more than happy to entertain them. The one thing I'm trying to avoid is installing Microchips IDE. I currently don't have much space left on my hard drive or the SD card I'm using to extend my storage space. So if this can be resolved with out going that route, I'd greatly appreciate that.

Kas

P.s

After a bit more reading and digging there maybe something else to try. I'm putting it here for later reference as well as so others can possibly try this out.

There is a file called variant.cpp that has a function

void SERCOM5_Handler()
{
  Serial1.IrqHandler();
}

this appears to be where the interrupt is handled in real time (this is what would need to be tested) if this is correct then this would be where any additional code can be added to stop timers or get data directly from the UART. I have already tried

(sercom5).readDataUART();

in the arduino IDE and it complies. This does not mean it works but there is a better chance then it not even compiling. This might therefore allow me to stop or reset a timer as well as getting received bytes right away. Once tested I'll update this post.

Hello Kas,

Sorry. I've been busy with lots of other stuff and haven't looked at this since I did the last post.

My initial conclusion was that I just can't see any value (for me at least) in getting bogged down in the Arduino stuff. I can get more value from my time just hitting an ARM or AVR processor in C directly.

I know that's not much help to you -  but good luck with your efforts.

MK

Hi Kas,

I've got a MKR WIFI 1010 and was interested in how the serial works, so I thought I'd join in and have a look at this.

For what you want to do, could you manage with just modifying the existing handler?

I'm not a C++ programmer and don't really understand OO stuff, so what I'm doing here is probably really horrible, but it does work.

If I understand this, this is a serial class, so the serial instance inherits it and so my changes will apply to any serial port instance [I might be way off the mark there]. But if I'm very careful what I do in my additions, it shouldn't matter too much if I change it. I also need to be careful because it's inside an interrupt routine, so I can't call anything that relies on interrupts. Safest thing was setting IO pins (I can look at those and debug with the oscilloscope, too).

Here I've changed the handler in Uart.cpp so that: if 'R' is received, I set pin 2 low; 'G' received sets pin 3 low; and 'B' received sets pin 4 low. The pins are connected to LEDs so that I can see what they're doing. I also programmed a UNO to send those letters in sequence, at 9600 baud, at half second intervals. I've got a 4k7 resistor between the UNO tx pin and the MKR rx pin, for safety, so that I can power them up and down separately without any worries

void Uart::IrqHandler()
{
  if (sercom->isFrameErrorUART()) {
    // frame error, next byte is invalid so read and discard it
    sercom->readDataUART();
    sercom->clearFrameErrorUART();
  }
  if (sercom->availableDataUART()) {

      // start of my changes

//    rxBuffer.store_char(sercom->readDataUART());
      uint8_t tempData = sercom->readDataUART();
      if (tempData == 0x52)
        digitalWrite(2,LOW);
      else
        digitalWrite(2,HIGH);
      if (tempData == 0x47)
        digitalWrite(3,LOW);
      else
        digitalWrite(3,HIGH);
      if (tempData == 0x42)
        digitalWrite(4,LOW);
      else
        digitalWrite(4,HIGH);
      rxBuffer.store_char(tempData);

      // end of my changes

    if (uc_pinRTS != NO_RTS_PIN) {
      // RX buffer space is below the threshold, de-assert RTS
      if (rxBuffer.availableForStore() < RTS_RX_THRESHOLD) {
        *pul_outsetRTS = ul_pinMaskRTS;
      }
    }
  }
  if (sercom->isDataRegisterEmptyUART()) {
    if (txBuffer.available()) {
      uint8_t data = txBuffer.read_char();
      sercom->writeDataUART(data);
    } else {
      sercom->disableDataRegisterEmptyInterruptUART();
    }
  }
  if (sercom->isUARTError()) {
    sercom->acknowledgeUARTError();
    // TODO: if (sercom->isBufferOverflowErrorUART()) ....
    // TODO: if (sercom->isParityErrorUART()) ....
    sercom->clearStatusUART();
  }
}

That works ok. I can see the LEDs changing.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: Reading UART Rx Buffer (MKR WiFi 1010 / MKR 1000)

Poster

Upload Preview

Ok

Cancel

Here's how the timing looks. The yellow trace is the serial at the rx pin, the blue trace is the red LED being turned on in the interrupt routine after receiving an 'R' [0x52] character. It happens just over halfway through the stop bit [I assume, from that, that the UART samples close to the middle of each bit].

Here it is again with an accumulated trace so that you can see the spread in the timing back to the beginning of the stop bit

Perhaps you might be able to test which instance it is from inside the routine? Alternatively, you might be able to copy the whole handler and overload the existing one [I can't help with that because I haven't a clue how that kind of thing works].

michaelkellett,

I hear your sentiment 100%, Arduino is not my platform of choice for this exact reason. I find I can get stuff most stuff done faster and easier using straight C (unless is really is doing something generic). Unfortunately for this project I need to use an Arduino and so here I am, using a product with hard to find documentation (I can't find clear register information for the AVR).

Kas

michaelkellett,

I hear your sentiment 100%, Arduino is not my platform of choice for this exact reason. I find I can get stuff most stuff done faster and easier using straight C (unless is really is doing something generic). Unfortunately for this project I need to use an Arduino and so here I am, using a product with hard to find documentation (I can't find clear register information for the AVR).

Kas