I probably have it archived somewhere but I simply had my program in a tight loop that needed to respond to a condition within 50 uSec or so. A blocking write obviously made this impossible. I have since made both hardware and software changes that remove this restriction. Still, a non-blocking write would be nice. The other Arduino platforms have it as do all operating systems so I think it is reasonable to expect it to be available on the Due.From: Paul Stoffregen mailto:Sent: Thursday, December 04, 2014 4:53 PMTo: arduino/ArduinoCc: robertstuartSubject: Re: Arduino Due HardwareSerial Transmit not interrupt-driven. I'm curious about your code that broke without the buffering. Is it available somewhere?—Reply to this email directly or view it on GitHub.
It is good to see that someone else is equally disappointed and perplexed. I have code that reads and IMU 400 time/sec (2500 uSec). The IMU takes about 2000 uSec per read. The processor then sends out status information to an XBee for each read.
This all works perfectly well on an Arduino Uno. This, of course doesn’t work on the Due since the SerialX.write blocks and causes the next IMU read to be missed. There are several hacks to get around this. The one that I am using at the moment is to have a timer interrupt every 200 uSec or so which then does a single byte SerialX.write to empty my own write buffer. This works just fine but it seems very ugly to move to another processor, which is roughly 10 times as fast and then have to resort to a hack like this to get it to perform adequately.Good luck. If you need help making noise about this or help testing your code, please count me in.From: Collin Kidder mailto:Sent: Saturday, December 20, 2014 11:06 AMTo: arduino/ArduinoCc: robertstuartSubject: Re: Arduino Due HardwareSerial Transmit not interrupt-driven. I'm actually very disappointed and perplexed that the Due serial code is so poor.
The processor has DMA for Heaven's sake and we're sitting in a spinlock?!? I guess this was very early code to get it up and running and nobody ever fixed it. There is no excuse for this on a processor with so many resources and so much RAM. I think the core can afford to allocate a 128 byte buffer for serial transmission.
I'll see about fixing it for myself and try to push it back to the main repo.—Reply to this email directly or view it on GitHub. Yesterday I got TX interrupts working for the USART class. It seems to work fine. The only question is how to handle the buffer being full. The two choices are to drop extra characters or to spinlock (like we do now) until the TX buffer has an opening. I have chose the second option for now as it is more novice friendly. I'm contemplating also supporting DMA based transmission of buffers.
This allows larger transmissions to be done without blocking. The default buffer size for Arduino RingBuffer objects is 64 bytes so right now my implementation has a 64 byte TX buffer. I have it working pretty well in the USART class and I've been testing it over these past couple of days. I will commit my changes to my fork soon and then discuss doing a pull request.
As per Robert's suggestion I also increased the space used by RingBuffer to 128 characters instead of 64. The Due does have a huge amount of RAM (for a little processor) and the extra space allocation only adds up to less than an extra kilobyte of RAM usage.And now for the more contentious suggestion. Currently there is exactly zero real difference between the UART and USART devices on the Due.
We configure them exactly the same, the code is exactly the same. The data registers used are exactly the same. Does it make any sense to implement everything twice just to change what everything is called subtly but not the actual memory offsets.Take these two lines:pUart-UARTCRpUsart-USCROn these lines UARTCR = USCR. The only difference is what we call them. The USART uses the same configuration space layout as the UART it just has extra stuff afterward.
So, I see no reason that we couldn't implement everything once. Personally I'd go with using the USART class for all hardware serial. That way if more features are ever added they can be added and all that will happen is that the UART hardware will ignore anything sent to the configuration space it doesn't use. I don't see any harm in this. The UART will still work as a UART this way but won't require special code to support it. I tested your modifications and found a little bug.
If you do a write when the hardware buffer is empty and the soft buffer is not, the write is done immediately and not put in the soft buffer. This result in bytes not send in the good order.I changed:if ((pUart-UARTSR & UARTSRTXRDY)!= UARTSRTXRDY)) //is the hardware currently busy?by:if (((pUart-UARTSR & UARTSRTXRDY)!= UARTSRTXRDY) (txbuffer-iTail!= txbuffer-iHead)) //is the hardware currently busy?and everything is send in order. You're right. I have made your changes and pushed so the pull requestshould now show your proposed change. Thank you.On Tue, Dec 30, 2014 at 10:05 PM, methos10019wrote:I tested your modifications and found a little bug. If you do a write whenthe hardware buffer is empty and the soft buffer is not, the write is doneimmediately and not put in the soft buffer. This result in bytes not sendin the good order.I changed:if ((pUart-UARTSR & UARTSRTXRDY)!= UARTSRTXRDY)) //is the hardwarecurrently busy?by:if (((pUart-UARTSR & UARTSRTXRDY)!= UARTSRTXRDY) (txbuffer-iTail!= txbuffer-iHead)) //is the hardware currentlybusy?and everything is send in order.—Reply to this email directly or view it on GitHub.
The changes have been merged into the 1.6.x branch so you shouldn't need todo anything to get and use them. You do still have a sam directory but theymoved it around. You should be able to search the arduino forums for thenew location.On Sat, May 2, 2015 at 7:24 PM, Ali wrote:HiI am new to Arduino IDE, ARM and github; although I have few years ofprogramming experience with AVR Mega in C.I understood that you guys have solved the problem with serial library ofArduino due.
Now, the only thing that I do not understand is how I canimplement what you have done in my Arduino IDE. I am using 1.6.3 and I donot have sam directory.
Arduino Due Serial Interrupt
Should I downgrade to your version?So could you please help me and I am really sorry if my question are verynoob. If you are busy feel free to just give me keywords, I will read aboutthem till I figure out a solution.Thank you very much.—Reply to this email directly or view it on GitHub. Hi Collin 80I figured it out, I had a mistake in my code which was sending too much info through the port due to the mistake. I fixed it and noticed that it interrupt is used in serial library.
Arduino Due Serial Interrupt Code
That is why I removed my comment so that hopefully you guys won't waste your time answering my question. But thank you very much you actually answered it and I really appreciate that specially for the directory clarification. Sorry that I removed my comment and you had to add it again.thank you very much,Ali.