Repurposing main UART for other tasks?

I'm using ATMega1284p chip with Mighty bootloader. It has 2 UARTs for serial communication. I'm using 1st to program it via FTDI adapter, however is it possible to use this UART for other things, like communicating to GPS? See the problem is I can't use second UART because it's physically same pins (16,17) as only 2 hardware interrupts (INT0, INT1) and I'm using at least one of them! I can't believe Atmel did this :(

Anyway I still want to be able to use 1st UART for programming chip, I just want GPS connected to it as well and for some reason it's not working. I didn't figure out how to debug it since serial port is in use. Is there something, maybe a bootloader that might prevent me from using UART1 w/ GPS? GPS works fine with UART2 btw.

Using things like SoftwareSerial also won't work, because it doesn't support ATMega1284p...

Hard to comment without seeing your code, but you can use pin-change interrupts on other pins.

bratan: I'm using ATMega1284p chip with Mighty bootloader. It has 2 UARTs for serial communication. I'm using 1st to program it via FTDI adapter, however is it possible to use this UART for other things, like communicating to GPS? See the problem is I can't use second UART because it's physically same pins (16,17) as only 2 hardware interrupts (INT0, INT1) and I'm using at least one of them! I can't believe Atmel did this :(

Anyway I still want to be able to use 1st UART for programming chip, I just want GPS connected to it as well and for some reason it's not working. I didn't figure out how to debug it since serial port is in use. Is there something, maybe a bootloader that might prevent me from using UART1 w/ GPS? GPS works fine with UART2 btw.

Using things like SoftwareSerial also won't work, because it doesn't support ATMega1284p...

Actually I believe the 1284 has a third user interrupt pin INT2 on chip pin 3. Check the datasheet to verify.

Lefty

retrolefty: Actually I believe the 1284 has a third user interrupt pin INT2 on chip pin 3. Check the datasheet to verify.

Lefty

Oh cr@p! Been working for 6 months with this chip and believed it only had 2, you are right, there's a 3rd one!!! Thank you lefty! Unfortunately I already made 100+ PCBs with that use INT1 for radio module :( But as far as my original question, there's nothing that should prevent me from sharing UART1 with FTDI and another devices (i.e. upload sketch via FTDI, disconnect FTDI and connect GPS)?

Got it working!
Basically I’m only using Serial0 for everything.
Step 1. Connect TX wire from GPS to ATMega’s RX via 1K Resistor.
Step 2. Upload sketch
Step 3. Disconnect TX wire from FTDI. At this point it starts getting data from GSP

#include <Time.h>
#include <TinyGPS.h>       // http://arduiniana.org/libraries/TinyGPS/
//#include <SoftwareSerial.h>
// TinyGPS and SoftwareSerial libraries are the work of Mikal Hart

//SoftwareSerial SerialGPS = SoftwareSerial(10, 11);  // receive on pin 10
//#define my Serial1
TinyGPS gps; 

// To use a hardware serial port, which is far more efficient than
// SoftwareSerial, uncomment this line and remove SoftwareSerial
//#define SerialGPS Serial1

// Offset hours from gps time (UTC)
//const int offset = 1;   // Central European Time
//const int offset = -5;  // Eastern Standard Time (USA)
const int offset = -4;  // Eastern Daylight Time (USA)
//const int offset = -8;  // Pacific Standard Time (USA)
//const int offset = -7;  // Pacific Daylight Time (USA)

// Ideally, it should be possible to learn the time zone
// based on the GPS position data.  However, that would
// require a complex library, probably incorporating some
// sort of database using Eric Muller's time zone shape
// maps, at http://efele.net/maps/tz/

time_t prevDisplay = 0; // when the digital clock was displayed

void setup()
{
  Serial.begin(9600);
  //while (!Serial) ; // Needed for Leonardo only
  //Serial1.begin(9600);
  Serial.println("Waiting for GPS time ... ");
}

void loop()
{
  while (Serial.available()) {
    if (gps.encode(Serial.read())) { // process gps messages
      // when TinyGPS reports new data...
      unsigned long age;
      int Year;
      byte Month, Day, Hour, Minute, Second;
      gps.crack_datetime(&Year, &Month, &Day, &Hour, &Minute, &Second, NULL, &age);
      if (age < 500) {
        // set the Time to the latest GPS reading
        setTime(Hour, Minute, Second, Day, Month, Year);
        adjustTime(offset * SECS_PER_HOUR);
      }
    }
  }
  if (timeStatus()!= timeNotSet) {
    if (now() != prevDisplay) { //update the display only if the time has changed
      prevDisplay = now();
      digitalClockDisplay();  
    }
  }
}

void digitalClockDisplay(){
  // digital clock display of the time
  Serial.print(hour());
  printDigits(minute());
  printDigits(second());
  Serial.print(" ");
  Serial.print(day());
  Serial.print(" ");
  Serial.print(month());
  Serial.print(" ");
  Serial.print(year()); 
  Serial.println(); 
}

void printDigits(int digits) {
  // utility function for digital clock display: prints preceding colon and leading 0
  Serial.print(":");
  if(digits < 10)
    Serial.print('0');
  Serial.print(digits);
}

there's nothing that should prevent me from sharing UART1 with FTDI and another devices

GPS devices in particular might be "ticky" because they tend to have text-based command interfaces, and are "somewhat likely" to respond to the traffic that happens during uploading (and thus interfere with it.) If you can keep the other serial devices disabled or disconnected or silent during uploading, you should be OK.

Sorry to hijack this thread, but I've been wondering about a solution for this problem myself for quite some time. Is it even possibly to use a GPS, or GSM modem with I2C, instead of hardware serial ports?

westfw:

there's nothing that should prevent me from sharing UART1 with FTDI and another devices

GPS devices in particular might be "ticky" because they tend to have text-based command interfaces, and are "somewhat likely" to respond to the traffic that happens during uploading (and thus interfere with it.) If you can keep the other serial devices disabled or disconnected or silent during uploading, you should be OK.

That's true, but I'm not using RX pin on GPS module (btw its Ultimate GPS from Adafruit), so GPS doesn't receive any data from arduino. Also addition of 1K resistor after FTDI line should make FTDI's TX a priority. In fact Microcontroller completely ignores data coming from GPS until I disconnect TX wire from FTDI (even when nothing is being sent via FTDI). I'm not sure why this happens, but I'm not complaining! :)

RudiAhlers: Sorry to hijack this thread, but I've been wondering about a solution for this problem myself for quite some time. Is it even possibly to use a GPS, or GSM modem with I2C, instead of hardware serial ports?

Hijack away! :) Here's some suggestion here: http://wyolum.com/gps-over-i2c/ BTW why can't you use Serial ports? Is it hardware limitation or software?

bratan: BTW why can't you use Serial ports? Is it hardware limitation or software?

Simple: The UNO and many other Arduino's only have 1 hardware Serial port which is often used for "debugging", so it could be useful if a GPS or GSM shield could connected to the I2C bus instead.

OR, if someone has too many serial devices, i.e. GPS + GSM + Bluetooth + Wifi + RFID reader, etc.

RudiAhlers:
Simple: The UNO and many other Arduino’s only have 1 hardware Serial port which is often used for “debugging”, so it could be useful if a GPS or GSM shield could connected to the I2C bus instead.

OR, if someone has too many serial devices, i.e. GPS + GSM + Bluetooth + Wifi + RFID reader, etc.

If you are not using ports 10,11 on Uno you can use them as Serial ports with SoftwareSerial. But if you do have more than one Serial device, it could be a problem of course :slight_smile:
In theory tho, you can probably use transistor array to switch RX/TX pins between all serial devices, but of course it will be difficult to manage in code and you won’t be able to receive communication from all of them at the same time.

You can use SPI or I2C for debugging as described here:

http://www.gammon.com.au/forum/?id=11329

It’s fast and effective. Of course if you need SPI, I2C, and serial for something then you are starting to run out of debugging options but there is always bit-banged SPI.