T4 uart enhance

[KurtE]

@PaulStoffregen - you may want to review this to see what you think.

First part for T4 - set the RX Watermark to 0, which fixed some issues people were running into when the last few bytes did not show up in SerialX.available() (nor read)...

Half duplex support - if the format you pass in to SerialX.begin includes:
#define SERIAL_HALF_DUPLEX 0x200

The begin code, turn on LOOPS and the like, to set the TX pin to support half duplex. I also enable PU resistor on the pin.

On T4 - the code added another check like transmitting pin

	if (transmit_pin_baseReg_) DIRECT_WRITE_HIGH(transmit_pin_baseReg_, transmit_pin_bitmask_);
	if(half_duplex_mode_) {		
		__disable_irq();
	    port->CTRL |= LPUART_CTRL_TXDIR;
		__enable_irq();
	}

And likewise to turn it back to RX mode. For T3.x I added it, but I did not need to add the extra checks and the like in the code. Instead, I use the bit band address.
transmit_pin = (uint8_t*)GPIO_BITBAND_PTR(UART0_C3, C3_TXDIR_BIT);
And then the code already in place that looked at transmit pin like:

	if (transmit_pin) transmit_assert();

Took care of it for us...

Note: So far T3.x I replicated the changes for Serial1-Serial6. I have not yet done Serial6 of T3.6 as it uses LPUART instead of UART. Thought I would get your input before I did that.

[PaulStoffregen]

Setting the watermark to 0 has an impact on everyone trying to use fast baud rates, so this isn't a simple or easy decision.

[KurtE]

As you mentioned, there is no complete perfect answer.

The set watermark for RX to zero I would assume will cause more interrupts, which will eat up more room, at highest speeds, it might cause us to potentially lose less characters? As there will be more room still available in the FIFO for the RX data.

I am assuming that the code currently relies on the input line to go idle and be detected? I need to look to see if that timeout is configurable. That is if we receive one byte, when does it then decide to go ahead and cause the ISR to be called. Probably need to look again, Of some other reason to call the ISR? ...

Another option would be to update all of the functions that look at data,

Like potentially would change available...

int HardwareSerial::available(void)
{
	uint32_t head, tail;
	int avail;
	__disable_irq();
	head = rx_buffer_head_;
	tail = rx_buffer_tail_;
	if (head >= tail) avail =  head - tail;
	avail = rx_buffer_total_size_ + head - tail;
	avail +=  (port->WATER >> 24) & 0x7;
	__enable_irq();
	return avail;
}

And of course then peek and read would need to be updated as well.

Will look at some more... Question is should I add in the stuff to look at the adding the looking and peeking directly into FIFO?

[KurtE]

Hi @PaulStoffregen - I verified as I suspected that the last bytes are reported after a one character idle time.

Did a quick and dirty test program:void setup() {

  while (!Serial && millis() < 3000) ;
  Serial.begin(115200);
  Serial1.begin(115200);
  Serial2.begin(115200);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
}

int loop_cnt = 0;
void loop() {
  digitalWrite(3, HIGH);
  Serial1.printf("%d: abcdefghijklmnopqrstuvwxyz\n", loop_cnt++);
  Serial1.flush();
  digitalWrite(3, LOW);
  elapsedMillis em = 0;
  while (em < 100) {
    if (Serial2.available()) {
      digitalWrite(4, HIGH);
      while(Serial2.available()) {
        Serial.write(Serial2.read());
      }
      digitalWrite(4, LOW);
    }
  }
}

You can see on the red line there are two pulses the first one processed most of the characters and then the gap and then small pulse when the last two characters were received.

Note: I also ran it on T3.6..

And there is no such gap in time.

[KurtE]

@PaulStoffregen - I pushed up a change to Hardware Serial for T4, that leaves the WATER > 0 and

Add code to SerialX.avail, read and peek

for avail add in count of entries in RX FIFO.

For Read, if our queue is empty, and FIFO is not empty, read first element and return it.

For Peek if queue is empty and FIFO is not empty, read it and reinitialize queue to have this item as first item in queue and return it.

I tried the above sample and it is working. I verified that it was grabbing data from FIFO.

I also reran the version of the example app that the user on forum was doing for ASYNC tx between two ports back and forth. The one I am running is using the Half duplex support that I have in this PR...

#define SPEED     9600
#define BUFFERED  8
//#define BIT9


void setup() {
  Serial.begin(115200);
  pinMode(5, OUTPUT);

  // Single wire: TX2 connected to TX1
#ifdef BIT9
  Serial1.begin(SPEED, SERIAL_9N1 | SERIAL_HALF_DUPLEX);
  Serial2.begin(SPEED, SERIAL_9N1 | SERIAL_HALF_DUPLEX);
#else
  Serial1.begin(SPEED, SERIAL_8N1 | SERIAL_HALF_DUPLEX);
  Serial2.begin(SPEED, SERIAL_8N1 | SERIAL_HALF_DUPLEX);
#endif

#if defined(__IMXRT1062__)
  Serial.println("Teensy 4.0 9bit Serial Single Wire with reversal test");
#else
  Serial.println("Teensy 3.x x>=2 9bit Serial Single Wire with reversal test");
#endif
}

void loop() {
  static uint32_t data1 = 0x0;
#ifdef BIT9
  static uint32_t data2 = 0xff;
#else
  static uint32_t data2 = 0x80;
#endif
  static uint8_t reverse = 0;
  uint8_t cnt;
  int val1, val2;

  cnt = 0;
  if (reverse == 0) {
    Serial.print("Write TX2");
    for (uint8_t i = 0; i  < BUFFERED; i++) {
#ifdef BIT9
      if (++data2 > 0x1FF)
        data2 = 0;
      Serial2.write9bit(data2);
#else
      if (++data2 > 0xFF)
        data2 = 0;
      Serial2.write(data2);
#endif
      Serial.print(":");
      Serial.print(data2, HEX);
    }
    Serial2.flush();
    Serial.println("");
    Serial.print("Read  TX1");
    while (Serial1.available()) {
      val1 = Serial1.read();
      Serial.print(":");
      Serial.print(val1, HEX);
      cnt++;
    }
    Serial.print(":count=");
    Serial.println(cnt);
  } else {
    Serial.print("Write TX1");
    for (uint8_t i = 0; i  < BUFFERED; i++) {
#ifdef BIT9
      if (++data1 > 0x1FF)
        data1 = 0;
      Serial1.write9bit(data1);
#else
      if (++data1 > 0xFF)
        data1 = 0;
      Serial1.write(data1);
#endif
      Serial.print(":");
      Serial.print(data1, HEX);
    }
    Serial1.flush();
    Serial.println("");
    Serial.print("Read  TX2");
    while (Serial2.available()) {
      val2 = Serial2.read();
      Serial.print(":");
      Serial.print(val2, HEX);
      cnt++;
    }
    Serial.print(":count=");
    Serial.println(cnt);
  }
  reverse = ~reverse;
}

And results are better than the version where I simply disabled the water.

[WestfW]

set the RX Watermark to 0, which fixed some issues people were running into when the last few bytes did not show up in SerialX.available() (nor read).

Do you have pointers to the discussions of these issues?

I verified as I suspected that the last bytes are reported after a one character idle time.

Um; So? Async communications is ... asynchronous. Code expecting to see serial.available() == 10 immediately after the stop bit of the 10th character is transmitted is IMNSHO broken...
I wouldn't mind the "idle timeout" being on the order of 1ms. I guess there are couple of protocols these days that rely on a very-short idle period for packet delimitting, but IMO those ought to be handled by special purpose drivers rather than forcing the generic serial driver to be able to deal with them.

Handling the latency vs efficiency tradeoff on uart reception is really tricky (even more so if you try to use DMA.) For Network terminal servers, we used to hacks like "inputPending() returns at least one if DMA has transferred any bytes", and "read() terminates DMAs early", with the idea that if the system was very busy, neither of those would happen and the FIFO or DMA buffer would just continue filling. If the system had adequate cycles, it would end up calling read() and getting the data close to "as soon as possible." This was highly dependent on UART hardware, and didn't always work perfectly, but it seemed like a reasonable goal. The T4 UARTs don't seem very supportive of such techniques; it looks like they only allow idle times and FIFOs to be manipulated when the TX or RX is disabled :-(

(So, I don't actually own a T4, and I haven't been following the discussion. Everything I said is based on a sort of "technical purity" viewpoint.)

[KurtE]

@WestfW (and @PaulStoffregen )

A lot of the stuff started out with the discussion in the thread: https://forum.pjrc.com/threads/58231-Teensy-4-0-and-single-wire-serial

The code in the last PR, does still maintain the Watermark, so should still help to reduce interrupts.

And as mentioned Serial.available() will return counts including what is in the UARTS fifo queue.
And read will grab out of FIFO if queue is empty, and like wise peek will move first item out of FIFO and put into queue if the queue as empty.

The good news is the sample programs is working with this.

Also I thought one of newer T4 breakout boards was having an issue, and maybe I screwed it up. But so far it now doing a better job talking to Dynamixel Servos at 1mhz Serial.

[KurtE]

@PaulStoffregen - What are your thoughts on adding Half duplex support to the Serial ports.

If you are interested in allowing something like this, I would probably need to redo part of it as we took the other approach to fix the latency issue with the serial, by peaking into the hardware FIFO instead of setting the watermark to nothing...