Serial Port FIFOs?

Status
Not open for further replies.
J

jkoffman

Well-known member
Hi all,

I know this is stupid, but I'm having some trouble. I'm using a 3.2 on a new project, and if I can I'd like to use the two serial ports that have FIFOs on them. According to the docs 2 of the 3 have them. But...I can't figure out which. I am sure it's obvious somewhere, but I can't see it.

Can anyone shed some light on this?

Thank you!
 
Often heard it stated indeed Serial1 and Serial2 on T_3.2 have the 8 byte hardware FIFO - this looks like the code to back that up.

Reading in Serial2.c and Serial1.c at : arduino-1.8.1\hardware\teensy\avr\cores\teensy3\

In serial2_begin() and serial_begin() :: #ifdef HAS_KINETISK_UART1_FIFO or #ifdef HAS_KINETISK_UART0_FIFO

And this from :: I:\arduino-1.8.1\hardware\teensy\avr\cores\teensy3\kinetis.h showing those states exist:
// Teensy 3.1 & 3.2
#elif defined(__MK20DX256__)
// ...
#define KINETISK
#define HAS_KINETISK_UART0
#define HAS_KINETISK_UART0_FIFO
#define HAS_KINETISK_UART1
#define HAS_KINETISK_UART1_FIFO
#define HAS_KINETISK_UART2
Click to expand...

The code in those serial#.c files sets up a watermark point to feed/unload the hardware FIFO's for those two ports on T_3.2 to the software queues - this code shows UART1 that is in Serial2.c::

#ifdef HAS_KINETISK_UART1_FIFO
UART1_C1 = UART_C1_ILT;
UART1_TWFIFO = 2; // tx watermark, causes S1_TDRE to set
UART1_RWFIFO = 4; // rx watermark, causes S1_RDRF to set
Click to expand...

Reading the kinetis.h file:
> it seems T_3.0 only had the one FIFO - which may explain the comment seen in those .c files.
> for T_LC { KINETISL } I see no FIFO's called out
> Reading further for T_3.5 and T_3.6 they are also marked as { #define KINETISK } and have only the same two FIFO backed UARTS called out.
> Other Serial3.c { and 4 and 5 and 6 ? } file(s) won't have the FIFO provisions noted above.
 
Thank you both for the replies!

I had kind of figured it would be 1 and 2, but good to know. I was hoping it would be 1 and 3, I am using the chip select pin that conflicts with 2. I'll have to investigate moving that. Or just going with software buffering on the serial port for now, it might just be fine.

Thanks again!
 
On T_3.2 - if you can get to the bottom pads there are alternate pins that can be used for normal Serial2: #26 & #31
 
I've added this to the serial page:

On Teensy 3.2, 3.5, 3.6, Serial1 and Serial2 have 8 byte transmit and receive FIFOs, which allow for higher speed baud rates, even when other libraries create interrupt latency.

All serial ports on all Teensy boards use interrupt-based transmit and receive buffering, to allow your program to avoid waiting when writing short messages, and to allow data to be reliably received even if your program must spend time performing other tasks.
Click to expand...

That page already has a *lot* of info, so whether this helps anyone in the future with the same question remains to be seen, but hopefully it will help?
 
Thanks all! And thank you Paul! That little blurb would definitely have helped me, that's for sure.

On the PIC I wrote a library to allow me to transmit and receive two separate DMX streams out of the same port. I need to spend more time with the existing libraries to see how to see how to make that work here. Mostly I just have to make sure buffers don't overlap, etc. For now I'm just designing a board to experiment with so I'm trying to design in the maximum flexibility.
 
DMX is 250,000 baud 8N2 format, or about 22727 bytes/sec. Teensy 3.2 can easily keep up with this rate without the FIFO. However, you do need to be careful not to use other libs which disable interrupts for too long, approx 44 microseconds in this case.
 
This is an old topic, but it is the one that is the closest to my questions ...

What is the size of the Serial Buffer ?
I read that for Serial1 Serial2 and others this is defined in .c files ... But I did not find any serial.c file were the serial buffer size ( serial usb) would be defined ...

More details about what I want to do :
I want to display the biggest number of bytes that have been stored in the serial buffer ...
I would try to find a way to fill completly the buffer and count the number of bytes lost due to full buffer ...

My current observations :
By sending a big load of data with the serial monitor I managed to get Serial.available() returning 768 but never more ...Even when I write more than 2000 bytes at once...
The interesting part is that even if the maximum value of serial.available only 768 instead of 2000, it seems to read well all the2000 bytes ( But I am not sure ... )

These observations gave me a lot of questions :
Is 768 the maximum that can be stored in the Serial buffer? Is the serial monitor the limitation ? How can I set a test to prove that I have no bytes lost?
If I manage to fill completely the buffer... What happen ? Is that a circular buffer and first bytes are erased ? Or last bytes are droped? How can I count the lost bytes?

I really believe that I have no bytes lost in my application but I would like to prove it! =)

Thank you in advance for the help!
 
Starting with 1.54-beta5, all 32 bit Teensy boards have Kurt's addMemoryForRead() and addMemoryForWrite(). Previously they were only on Teensy 4.x.

If you need larger buffers, your best path is to get the latest code and use those functions.

But to answer your original question, search for SERIAL1_TX_BUFFER_SIZE. For Teensy 3.x (I believe your other recent threads mention using Teensy 3.2), it's here:

https://github.com/PaulStoffregen/c...aed6e421216e0744e5f3959/teensy3/serial1.c#L40

If you need more help, use the forum search for "addMemoryForRead" to find the best thread to ask. I'm going to close this very old thread, which was originally about the hardware FIFOs (which are automatically used by Serial1, Serial2, etc) rather than the software buffers.
 
Status
Not open for further replies.
Back
Top