Interrupts for UART using Teensy 3.1 or 3.0

Status
Not open for further replies.
Hi Duff,
your library is great, but won't you use the newlib-inbuilt-memcpy instead ? It's assembler-hand-optimized by the ARM-guys.
Even there is no great difference - it would save some space at least.

That newlib-inbuilt-memcpy is the default memcpy now for (Teensyduino 1.21) Teensy 3.1 or do I need to use optimized menu item in the ide? I tested both optimized and not optimized via the ide against memcpy from Daniel Vik and his was still faster. I didn't look at the ram size difference though.

The other problem was I had cast away the volitileness of the TX buffer to use the regular memcpy, this is one thing maybe you or someone else can shed some light on is if I do cast away volatile global array like (uint8_t*)"volatile"buffer does it lose all its volatilness forever or just in the local scope that it is cast awayed? Sorry for the convoluted question but I'm just not sure.

I tested the speed by toggling a digital pin and using my oscope before (HIGH) and after (LOW) the call to *.write(packet, size). Maybe this is not the best metric to measure the speed of a function?
 

duff, I'm experiencing problems with your library. I noticed that the bytes getting sent aren't the ones I'm writing (ex: Event1.write(myPacket, packetSize) ). I thought this was a problem with my application but when running the Fill_Internal_Buffer_Time.ino example where the sent bytes are only 'A's I'm also seeing this problem. The Serial1 sends them correctly but using the library Event1 sometimes sends the correctly ('A') but sometimes sends 'f' instead.

p.s I'm actually using Uart3Event if it matters somehow.

Anyway to fix this?
 
I thought this was a problem with my application but when running the Fill_Internal_Buffer_Time.ino example where the sent bytes are only 'A's I'm also seeing this problem. The Serial1 sends them correctly but using the library Event1 sometimes sends the correctly ('A') but sometimes sends 'f' instead.


I've been running that example for 20 minutes and haven't seen any problems like this. What baud rate are you using and whats connected to the teensy serial3?
 
I've been running that example for 20 minutes and haven't seen any problems like this. What baud rate are you using and whats connected to the teensy serial3?
230400 bps. Connected to a Wifi232-t module. The problem is surely not with the wifi module, as it works perfectly with normal Serial.write(). I might be able to send some example data tomorrow for your analysis, if needed.
 
230400 bps. Connected to a Wifi232-t module. The problem is surely not with the wifi module, as it works perfectly with normal Serial.write(). I might be able to send some example data tomorrow for your analysis, if needed.


ok, i'll look into this tonight I was gone this last weekend.
 
I'm not seeing any spurious characters at that baud rate(230400), I ran the example sketch mentioned for a while now with a custom serial monitor to check for errors in character reception and none to mention. I've let it run for hours. Can you post an example of your program that causes this?
 
Nice work! I got the loopback test running and it looks awesome.

Would this work to communicate with a Beaglebone Black? Is there any flow control to stop the transmission if the receive buffer is full at the other end?

I want to make the Teensy a node on a ROS network hosted by the Beaglebone.
 
Nice work! I got the loopback test running and it looks awesome.

Would this work to communicate with a Beaglebone Black? Is there any flow control to stop the transmission if the receive buffer is full at the other end?

I want to make the Teensy a node on a ROS network hosted by the Beaglebone.

I'm looking at the rts/cts signaling for uart0 (Serial1) now, looks like it might work. Does the beaglebone black have the rts/cts pins available?
 
RTS/CTS is not a good choice, IMO. Not reliable or even implemented in most situations in microprocessors.
Best to use a frame oriented protocol.
 
RTS/CTS is not a good choice, IMO. Not reliable or even implemented in most situations in microprocessors.
Best to use a frame oriented protocol.

Hardware Flow Control can be used in a "frame oriented protocol". Just because you don't use it doesn't make it "not a good choice".
 
I just expressed an opinion (IMO) based on long experience. Some on-chip UARTs do nothing with the CTS signal other than present it in a status bit. The software/ISR must implement flow control. Some stop sending characters after x number of additional bytes go out, e.g., to empty either a dual-rank buffer or a FIFO of 8-16 bytes. So, what I said is an opinion (IMO as I said).
 
Beaglebone CTS/RTS

I'm looking at the rts/cts signaling for uart0 (Serial1) now, looks like it might work. Does the beaglebone black have the rts/cts pins available?

There seem to be some issues surrounding the configuration and use of CTS/RTS on Beaglebone but it does seem feasible to implement them. I would be interested to work with you on getting this to work.
 
There seem to be some issues surrounding the configuration and use of CTS/RTS on Beaglebone but it does seem feasible to implement them. I would be interested to work with you on getting this to work.

I'm pretty sure it works well with the Teensy. Once set, rts/cts signaling works with the stock Serial1 code in Teensyduino. Here are some screen shots from my scope on the TX1 pin(1) using a modified serial1.c and HardwareSerial.h:

DS1Z_QuickPrint5.pngDS1Z_QuickPrint6.pngDS1Z_QuickPrint7.png


I haven't tried it with the UartEvent library yet but will today.

One thing is that with this setup Paul can use the rts signaling for transmitterEnable instead of actually having to set a pin in the serial1.c isr. The only thing it would require to use only pin 6 or pin 19. I'm coding up pull request for the rts/cts on all three serial ports and looking at the Teensy LC also.

@stevech - you drop into threads and blant out something that sounds like you're an authoritative voice on how people should do their projects but never followup with actual information that supports your (opinion) like code examples and links or at least very rarely! Though its hard to tell since you seem to have lots of opinions.
 
@stevech - you drop into threads and blant out something that sounds like you're an authoritative voice on how people should do their projects but never followup with actual information that supports your (opinion) like code examples and links or at least very rarely! Though its hard to tell since you seem to have lots of opinions.
Just trying to be helpful... Suggestions. I never mandate.
Your example here of CTS and the driver is an example of what's typical in that few people use RTS/CTS (of the EIA modem era) because it's often/usually not implemented fully. Esp. with dissimilar devices on each end of the link.

In this case, code examples are n/a.
 
Last edited:
NERD FIGHT?

Duff - if you can get good hardware control to prevent loss or overrun that is great - but i take it Steve was noting that there are cases where it isn't supported equally from system to system - and I'd add takes more wires - and could "work" with undetected corruption

Steve - Your FRAME comment is good in many cases where integrity is important as losses & corruption can always happen even without overrun. You inspired me to find this that hopefully describes details of what you rely on for that: http://stackoverflow.com/questions/17073302/what-type-of-framing-to-use-in-serial-communication
 
I've considered adding functions to Serial1, Serial2, Serial3 to turn on the hardware flow control. These's a few (lame) reasons why I haven't done this.... So far, relatively few people have asked, and I haven't personally needed this, and I'm a little uncertain on what function names and format to use. I used to be more concerned about keeping tight compatibility with whatever Arduino does (or might do soonish), but maybe that's not so important for hardware flow control?

I most certainly would be curious to hear how this works, since it's a feature I have not personally used. Not how well it does or doesn't tend to work on other microcontroller, or in general abstract terms, but specifically how well Teensy 3.1 & LC flow control actually works when used together with specific other systems (ones where data loss actually occurs without flow control).
 
Nerd fight, maybe. first I would like to apologize to stevech for being a dick, I understand your trying to be helpful but sometimes the way you say stuff can be seen as not.

While rts/cts signaling is not used much, xbee uses it for uploading new firmware to their modules and can be used for communication also if enabled. I'll start a new thread that reflects this specific topic and post code to support the use of Hardware Flow Control.
 
I wrote a library that you can do this called SerialEvent. But interrupts don't work this way: if(Uart.available()){ interrupt routine }, that is just polling.

Hi, duff. I found your library today and it is very useful. I have spent the past few weeks studying the datasheet and trying to accomplish this exact task. I have been looking through your code and while I don't understand all of it, it will be a good resource for me to learn from. Thank you for this contribution.
 
Hi, duff. I found your library today and it is very useful. I have spent the past few weeks studying the datasheet and trying to accomplish this exact task. I have been looking through your code and while I don't understand all of it, it will be a good resource for me to learn from. Thank you for this contribution.

thanks! let me know how it goes?
 
Nerd fight, maybe. first I would like to apologize to stevech for being a dick, I understand your trying to be helpful but sometimes the way you say stuff can be seen as not.

While rts/cts signaling is not used much, xbee uses it for uploading new firmware to their modules and can be used for communication also if enabled. I'll start a new thread that reflects this specific topic and post code to support the use of Hardware Flow Control.

Not a problem.
I could do better .. in my earlier post here, I did add "IMO" to my recommendation. Perhaps that pseudonym is easily overlooked, versus a more politically correct "you might want to consider" and such fiddlye that is in vogue.

On subject: most modern microprocessors have one (rarely, 2+) of the UARTs that provides CTS flow control in hardware. The driver sets a bit to enable it, and from there, it's software-transparent. Of course, users don't want this single-UART-with-CTS limitation, but, se la vie applies in most cases. Conversely a software driven use of CTS does the same but has the big disadvantage of latency at high baud rates. This can cause a few more characters to flow before the software stops the transmissions. And some UARTs lack a deep FIFO in hardware on some or all UARTs.

This is all well and good so long as whatever is on the other end of the wire also implements CTS flow control.

The XBee can use CTS for flow control. However, most "serious" applications use the Digi binary API (esp. for series 1 XBees). That API is frame oriented with a status report on each frame. If the code properly waits for the transmit complete status before sending another frame, there cannot be a buffer overrun on the transmit side of the XBee. The receiver side of the XBee is easily overrun in transparent OR frame mode unless at the network or application layer there's a reasonable flow control protocol. This is becuase the XBee S1 (based on an old 8051) has only 100 bytes each way of buffer, and the largest 802.15.4 frame payload can get to 90+ bytes. The Series 2 is a different beast, being Zigbee only, whereas Series 1 cannot be zigbee but can be 802.15.4 routed or Digi's proprietary mesh protocol which is better than Zigbee's meshing, "IMO"!
 
Last edited:
thanks! let me know how it goes?

Hi Duff,

I wanted to let know you that I've spent some time working with your library and it has worked pretty well. There is, however, a problem that I have encountered that I think I have traced back to your library. There is a problem with writing data when the writing occurs inside of your rx1Event ISR.

In my project, I am using your library to sense when a byte has been received via the serial. I want this to happen immediately which is why I am using your library and not simply polling serial read. So, we read the byte inside of your rx1Event and then send out serial data if necessary. Every time, it causes my program to hang/crash.

I made a modification to my program so that I was using one serial TX/RX port with your library to receive and process incoming serial on TX/RX 1 and used TX/RX 2 with the teensy serial library to do just the sending and everything works fine. I wish I could figure out what is wrong but I am having a hard time understanding your code (my lack of knowledge/skills) so I can't make the changes myself but I wanted to let know. Here is a cleaned version of my code.

Code:
void setup()
{	// Initial setup

	Serial.begin(57600);
	
	//Event1.loopBack = true;                // internal loopback set / "default = false"
	Event1.txEventHandler = tx1Event;			// event handler Serial1 TX
	Event1.rxEventHandler = rx1Event;			// event handler Serial1 RX
	Event1.rxBufferSizeTrigger = 1;				// set trigger for (buffer size) - 1
	Event1.begin(31250);						// start serial port
	
	HWSERIAL2.begin(31250);

}



void rx1Event(void)
{												//	Interrupt Event for the Incoming Serial
	serialData = Event1.read();					//	Read the byte
	if (serialData == 100)				
	{
			read_isr();							//	Actual ISR
	}
}

void read_isr ()
{													// Interrupt routine for when we receive a MIDI clock on the serial port
		Event1.write(12);			
		Event1.write(100);			
		Event1.write(105);			
}
 
can u post the code that dosen't work and everthing I need to get it to compile. That code you just posted doesn't compile and from what you posted doesn't seems like where the problem is? This is with Teensy 3.1 right?
 
can u post the code that dosen't work and everthing I need to get it to compile. That code you just posted doesn't compile and from what you posted doesn't seems like where the problem is? This is with Teensy 3.1 right?

Oops. Sorry about that. Yes, I can post a sample program for you showing that it doesn't work but it might be a few weeks or a month before I can get to it. I will post back here when I have something.
 
Status
Not open for further replies.
Back
Top