How big is the serial input buffer in the teensy LC?

Status
Not open for further replies.
I'm writing a simple OS for the Teensy LC and am transferring my user programs over serial, at the moment. Some of them will get quite large, around 4KB max. Is there a serial input buffer in the LC, like there is in the arduino? If so, how big is it? If not...how does serial data get buffered? I've tried sending over 300 bytes and my programs still load and run just fine, so I'm assuming it's at least as large as that :p
 
Hm, I guess I'm replying to my own thread, but something very strange is going on. I just uploaded a program via the Arduino serial monitor. That program was huge, 3559 bytes, which turns into approx. 1750 bytes when converted from its hex format. Everything worked fine. However, the problems with that are:

I've updated the linker file so that only 3968B of RAM are available for the kernel itself, with the remaining bytes used by the user space programs. According to the Arduino IDE, I'm using about 2500B of RAM for things like Serial setup etc in the kernel. So...how can I possibly send such a large program? In theory what could happen is that the serial buffer grows, but then it would have to grow *into* my user space, which is where I'm writing the program to. My program shouldn't run if it overwrites itself!

I wonder if it's the Arduino IDE doing something nice for me, like packaging the bytes and sending them at the right time or reading them all sequentially or something?
 
Is there a serial input buffer in the LC, like there is in the arduino? If so, how big is it?

Yes, there is. It's defined in serial1.c. The default size is 63 bytes. Due to the way the buffer works, 1 byte can't ever be used, so a 64 byte array gives 63 bytes of actual buffering. The buffers in Arduino's code work pretty much the same way.

If you really need a bigger buffer, you can edit this to a larger number. But larger buffer sizes aren't the answer to all problems.

I've tried sending over 300 bytes and my programs still load and run just fine, so I'm assuming it's at least as large as that :p

If your program uses Serial1.available() and Serial1.read() to fetch the data as it's arriving, odds are you're grabbing the data quickly enough that the buffer never gets full.

If you want to know more, you could try printing the actual number Serial1.available() returns, instead of just checking whether it's zero. Everything you add to your program, like printing extra info, will take away some of the time you can use to read data out of the buffer. But if that printing shows the available() is never more than a few bytes, you can feel pretty confident things are going well.

If you're really paranoid, you could add some code to keep track of the largest number available() gives, perhaps printing that every minute or two and then reset it. Then you can monitor a "worst case", and usually simple comparisons and just storing stuff into variables is very quick.
 
Oh, that makes sense. I guess it's something I shouldn't rely on, then, since it seems to be a nice feature of the kernel just because it does things fast enough. Oh well. Until I upgrade to a 3.5 or something I'm stuck with the RAM I have, so I'll just have to hope I don't modify the kernel enough to remove the speed-reading thing.
 
Status
Not open for further replies.
Back
Top