chipKIT® Development Platform

Inspired by Arduino™

Fubarino SD with 6 working hardware UARTs

Created Wed, 26 Feb 2014 14:00:32 +0000 by EmbeddedMan


EmbeddedMan

Wed, 26 Feb 2014 14:00:32 +0000

I've enabled all 6 hardware UARTs on the Microchip Fubarino SD, and tested them all out - they work great. The next build of MPIDE will have this support. If you want to use them before then, simply replace the \hardware\pic32\variants\Fubarino_SD\Board_Defs.h file with the one linked here.

[url]https://github.com/EmbeddedMan/chipKIT32-MAX/raw/master/hardware/pic32/variants/Fubarino_SD/Board_Defs.h[/url]

Below you'll find the test sketch I used. Note that two of these UARTs conflict with the SPI bus that we use for SD access, so you only get 4 UARTs if you're using SD.

Note that the Fubarino SD from SeeedStudio that has the MX460 on it only has 2 UARTs. It's only the one from Microchip with the MX795 on it that has 6.

*Brian

// UART test for Fubarin SD board
// Test out USB Serial and two hardware UARTs
// Use FTDI or other USB to serial cable with PC and
// terminal emulator for the two hardware UARTs

void setup() {
  Serial.begin(9600);     // USB port - baud doesn't matter
  Serial0.begin(115200);  // UART1 - pins 8 (RX) and 9 (TX)
  Serial1.begin(115200);  // UART2 - pins 28 (RX) and 29 (TX)
  #if defined(__PIC32MX7XX__)
  Serial2.begin(115200);  // UART3 - pins 25/SDI (RX) and 26/SDO (TX) (in use by Fubarino SD SPI bus)
  Serial3.begin(115200);  // UART4 - pins 1 (RX) and 7 (TX)
  Serial4.begin(115200);  // UART5 - pins 37/A7 (RX) and 43/A1 (TX)
  Serial5.begin(115200);  // UART6 - pins 27/SS (RX) and 24/SCK (TX) (in use by Fubarino SD SPI bus)
  #endif
}

void loop() {
  Serial.println("This is USB serial ");
  Serial0.println("This is serial0 ");
  Serial1.println("This is serial1 ");
  #if defined(__PIC32MX7XX__)
  Serial2.println("This is serial2 ");
  Serial3.println("This is serial3 ");
  Serial4.println("This is serial4 ");
  Serial5.println("This is serial5 ");
  #endif
  if (Serial.available())
  {
    // Echo back what got sent + 1
    Serial.println(byte(Serial.read() + 1));
  }
  if (Serial0.available())
  {
    // Echo back what got sent + 1
    Serial0.println(byte(Serial0.read() + 1));
  }
  if (Serial1.available())
  {
    // Echo back what got sent + 1
    Serial1.println(byte(Serial1.read() + 1));
  }
  #if defined(__PIC32MX7XX__)
  if (Serial2.available())
  {
    // Echo back what got sent + 1
    Serial2.println(byte(Serial2.read() + 1));
  }
  if (Serial3.available())
  {
    // Echo back what got sent + 1
    Serial3.println(byte(Serial3.read() + 1));
  }
  if (Serial4.available())
  {
    // Echo back what got sent + 1
    Serial4.println(byte(Serial4.read() + 1));
  }
  if (Serial5.available())
  {
    // Echo back what got sent + 1
    Serial5.println(byte(Serial5.read() + 1));
  }
  #endif
  delay(200);
}

laputa

Fri, 14 Mar 2014 02:27:51 +0000

Brian

FYI

I have 4 ports running intensively.

There is a condition where a port will go out to lunch.

May be related to servicing the RX buffer.

I can reset it with .begin and it will provide 1 buffer size of data then hang again.

Is there a method to detect an overflow (i.e force a reset) or disable the locking (i.e let the overrun occur).

The protocol is self syncing


EmbeddedMan

Fri, 14 Mar 2014 14:39:06 +0000

Great question - I've never run into this behavior before, but then again I've never pushed 4 UARTs to their limits.

There are not currently methods such as you describe, however you can easily set/clear any bits in any of the UART registers to accomplish this. There are bits you can read at any time to see if an overrun has occurred, I know that much.

*Brian