LeafLabs Garden » Topic: Non-blocking serial transmit

LeafLabs Garden » Topic: Non-blocking serial transmit http://forums.leaflabs.com/topic.php?id=1142 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:14:13 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7120 Tue, 08 Nov 2011 21:28:47 +0000 tdc218 7120@http://forums.leaflabs.com/ I can read the control and status regs just fine, and I can change their settings - it all works until I try to enable the TXE interrupt. I can pump characters into the DR and have them show up on a serial LCD, and it doesn't matter whether it's usart 1, 2, or 3, they all behave the same way. It's all very confusing, this ought to be really straight forward. Anyway, since I'm kinda stuck and since my original method works, I'm gonna set this aside for a while and get back to work on my project. gblumer - thanks very much for all of your help. gbulmer on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7108 Mon, 07 Nov 2011 08:53:39 +0000 gbulmer 7108@http://forums.leaflabs.com/ <blockquote>... It behaves exactly the same regardless of whether the isr is in or commented out. Is that really an issue? </blockquote> I believe a Maple sketch is compiled with a whole set of default interrupt handlers, most of which 'throb' the LED if they are called. So yes, I think it is an issue. <blockquote>When you're just setting the enable bit, no interrupt should occur. </blockquote> So, assuming you have removed (commented out) the <code>USART3->regs->CR1 |= USART_CR1_TXEIE;</code> and everything works okay (but does nothing), then we can conclude that that line of code breaks something. You can try to eliminate some potential errors, e.g. a bad address, by only reading the bit and not setting it: <pre><code>unsigned int txeie_bit = (USART3->regs->CR1 & USART_CR1_TXEIE)? 1 : 0; SerialUSB.print("TXEIE is "); SerialUSB.println(txeie_bit);</code></pre> If that works okay, then I think we can assume for now, there is something happening when the bit is set, and the likely cause is an interrupt. I don't know what happens if the USART triggers an interrupt, and the cause isn't dealt with. I'd expect it to continuously trigger. That might be enough to make a Maple behave badly. RM0008 27.6.1 "Status register (USART_SR)" says: "Bit 7 TXE: Transmit data register empty This bit is set by hardware when the content of the TDR register has been transferred into the shift register. An interrupt is generated if the TXEIE bit =1 in the USART_CR1 register. It is cleared by a write to the USART_DR register." So I would expect the interrupt service routine to either put a character into the USART_DR register (which may trigger a different interrupt), or clear the TXEIE bit. Is USART3 connected to anything? Can you pump characters down the wire? e.g. something dumb like: <pre><code>volatile unsigned char c = 0; void __irq_usart3(void) { USART3->regs->DR = 'A'+c; c = (c+1) & 0x1F; toggleLED(); }</code></pre> would give you a bit more information. tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7093 Sat, 05 Nov 2011 21:00:08 +0000 tdc218 7093@http://forums.leaflabs.com/ That pretty much IS the whole program, but it follows. It behaves exactly the same regardless of whether the isr is in or commented out. Is that really an issue? When you're just setting the enable bit, no interrupt should occur. Also, isn't there already an isr? usart.c says there is - sure, it's for servicing the receive interrupt, but it is there; it may not do anything intelligent if called by a tx interrupt, but that shouldn't crash the Maple. <pre><code>#include "usart.h" void __irq_usart3(void) { toggleLED(); } void setup(void) { pinMode(BOARD_LED_PIN, OUTPUT); // wait for the serial monitor to be connected while(!(SerialUSB.isConnected() && (SerialUSB.getDTR() || SerialUSB.getRTS()))) { toggleLED(); delay(123); } digitalWrite(BOARD_LED_PIN, LOW); // set up the serial port Serial3.begin(9600); // wait to make sure things are stable ... delay(2); // and ... SerialUSB.println("Enabling TXEIE..."); // this prints USART3->regs->CR1 |= USART_CR1_TXEIE; // set txe interrupt SerialUSB.println("TXEIE should be enabled"); // this never prints } void loop(void) { }</code></pre> gbulmer on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7087 Fri, 04 Nov 2011 21:31:13 +0000 gbulmer 7087@http://forums.leaflabs.com/ tdc218 - It is a bit hard to diagnose the problem without seeing the whole program. Would you either post a minimal program, or paste your program into pastebin and post a link here? One reason the led fades is when an interrupt service routine is missing. (full disclosure: I am not a member of LeafLabs staff.) tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7086 Fri, 04 Nov 2011 15:39:46 +0000 tdc218 7086@http://forums.leaflabs.com/ So I've been playing with making this interrupt driven. However, trying to set the TXEIE bit in CR1 seems to cause the Maple to crash. My code: <pre><code>Serial3.begin(9600); SerialUSB.println("Enabling TXEIE..."); USART3->regs->CR1 |= USART_CR1_TXEIE; // set txe interrupt SerialUSB.println("Registers after RXEIE");</code></pre> The first line prints, the second line never does. If I try to upload the sketch again, it doesn't find the Maple and the on-board led fades in and out like something ASSERTed. I've studied RM008 and the usart.c code in libmaple and this looks exactly like what they do in the latter. Is there some trick I'm missing? gbulmer on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7062 Tue, 01 Nov 2011 09:50:16 +0000 gbulmer 7062@http://forums.leaflabs.com/ tdc218 - <blockquote>Instead of DMA, can you have your own interrupt service routine on TXE interrupt?...</blockquote> Yes, absolutely. tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7059 Mon, 31 Oct 2011 19:45:35 +0000 tdc218 7059@http://forums.leaflabs.com/ In my application, I can easily tolerate the few microseconds that update burns off every time it's called far more than I can tolerate stopping the whole program for a few milliseconds every time I want to update the display. I took a brief look at DMA in the reference manual. My head asplode. ;) If my admittedly quick reading of it is correct, one challenge seems to be that you set up the DMA and then don't bother it 'till it's done, so if more characters get added to the buffer while it's busy sending the last batch, you need some way to remember that and update it when it's done. This seems like it could get rather unwieldy very quickly. Instead of DMA, can you have your own interrupt service routine on TXE interrupt? That would make it really easy, something like: <pre><code>void usart_tx_isr(void) { if (!(rb_is_empty(&rb))) // if there is a character to send xregs->DR = rb_remove(&rb); // then pull it from the buffer and send it }</code></pre> Yeah, it'll burn a few CPU cycles every character but unless you're in a real time critical situation so what? The putc routine would need minor alteration to kick start the usart if it were idle. gbulmer on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7058 Mon, 31 Oct 2011 18:27:11 +0000 gbulmer 7058@http://forums.leaflabs.com/ <blockquote>When I think of non-blocking, I think of something that's asynchronous with the main program.</blockquote> Yes. <blockquote>The simplest solution is to setup a timer that handles shoving data from the buffer to the hardware. ... </blockquote> A solution I think of is using a 'data arrived', or 'data sent' interrupt if there is a peripheral involved. This is exactly the time when data is ready or the peripheral is ready for more data. So it makes more sense (to me) than a timer. Connecting DMA to a "ready" signal is a straightforward improvement over the interrupt service routine. robodude666 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7056 Mon, 31 Oct 2011 11:48:14 +0000 robodude666 7056@http://forums.leaflabs.com/ When I think of non-blocking, I think of something that's asynchronous with the main program. The simplest solution is to setup a timer that handles shoving data from the buffer to the hardware. Since the STM32 is blessed with a powerful DMA controller, it's ultimately the better alternative. By giving the DMA controller (hardware) the responsibility of dumping data from the buffer to the serial peripheral you're insuring the non-blocking serial class to also be wait-free, which I think is important to achieve. Certainly, waiting a couple dozen cycles for <code>update</code> to finish isn't much, but when you're dealing with time-sensitive situations it may be too much to wait. gbulmer on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7054 Sun, 30 Oct 2011 19:31:45 +0000 gbulmer 7054@http://forums.leaflabs.com/ robodude666 <blockquote>A true non-blocking serial class would use RAM to USART DMA transfers ... </blockquote> I believe the meaning of 'non-blocking' is not about whether DMA is used or not. DMA can certainly be used to implement non-blocking I/O, but it isn't essential. The essential feature is only not to block !-) <blockquote>Also, if the class is specifically designed to be a non-blocking serial class, under no circumstance should the class block. </blockquote> Agreed. <blockquote>To support this, I think that puts and putc should return a BOOL, true or false, as to whether or not the buffer was full before attempting to insert the data. If the buffer cannot support the entire string of data, none of it should be inserted. A false is returned, and the user decides what they want to do. ... </blockquote> This is one perfectly reasonable approach. A common alternative technique is to 'peek' and see that there is enough space available in the output buffer (tdc218 <code>space</code> function) before trying to 'put' the characters. The disadvantage of only returning the <code>bool</code> 'failed' is the program doesn't know how much it's failed by, which I think is too little information. So using tdc218's approach, it is trivially easy to write a version of, e.g. nputs which returns a bool when there isn't enough space: <pre><code>void nbSerialTx::bool_fail_nbputs(char *s) { char c; if (strlen(s) > space()) return false; while ((c = *s++)) nbputc(c); }</code></pre> But it isn't trivial to create <code>void nbSerialTx::nbputc(char c)</code> and <code>void nbSerialTx::nbputs(char *s)</code> using the 'boolean fail' versions. robodude666 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7051 Sun, 30 Oct 2011 15:23:33 +0000 robodude666 7051@http://forums.leaflabs.com/ I should probably elaborate. It's not blocking in the sense that it prevents the entire program from running, as the current one does. It still does, however, delay the program while the <code>update</code> routine is being called. Even if that delay is as small as one if statement that returns false. If the statement is true, and it does continue to push data from the buffer then the delay is longer. This overall creates unpredictable slows in the program (they're predictable based on the buad rate used). tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7050 Sun, 30 Oct 2011 13:16:50 +0000 tdc218 7050@http://forums.leaflabs.com/ Actually it doesn't block (assuming I got the logic right). Examining the update method will show that the first thing it does is check the TXE bit of the usart status register. If the usart is NOT ready to take a character, it returns and does nothing. When the usart is ready for a character, then and only then does it pluck another one out of the ring buffer (assuming there are any to be had) and shove it into the usart. One of the assumptions here of course is that our main loop, or wherever we're calling update from, will cycle significantly faster than the characters will send so this has the most utility with slower peripherals. On the what to do if the buffer gets full question, the way it's written now the user can specify whether to block on full or discard on full in the init call (defaults to discard). I also provided the space function that returns how much room is left in the buffer. But I like your idea about never blocking and returning a bool - that seems like it might be a more elegant solution. I'll have to think about that. There are many improvements that could be made, as I said, this is pretty raw code. Thanks for your comments. robodude666 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7047 Sun, 30 Oct 2011 09:56:25 +0000 robodude666 7047@http://forums.leaflabs.com/ Very handy! But, it's still technically blocking I think.. it just blocks one character at a time. A true non-blocking serial class would use RAM to USART DMA transfers and wouldn't require the <code>update</code> routine. Once data is available to transmit, a DMA transfer is enabled to push the data out of the buffer. The DMA transfer is handled via hardware, and will not consume any CPU like the <code>update</code> routine currently does. Also, if the class is specifically designed to be a non-blocking serial class, under no circumstance should the class block. To support this, I think that <code>puts</code> and <code>putc</code> should return a <code>BOOL</code>, true or false, as to whether or not the buffer was full before attempting to insert the data. If the buffer cannot support the entire string of data, none of it should be inserted. A false is returned, and the user decides what they want to do. If it's important data to send, they can block themselves and wait for the buffer to relieve itself before successfully attempting to insert the data or move on with the program and do it later. -robodude666 tdc218 on "Non-blocking serial transmit" http://forums.leaflabs.com/topic.php?id=1142#post-7046 Sat, 29 Oct 2011 22:06:29 +0000 tdc218 7046@http://forums.leaflabs.com/ I needed non-blocking serial transmit for a project I'm working on and so I got the following code working tonight. Eventually it'll turn into a library but for now it's straight out of the incubator - all in one file with it's test program. The hardest part was understanding how to get ring_buffer working. To make it work you have to poll the update() method in loop which means that nothing in your main loop can block either. A much more elegant solution would be to make it interrupt driven but I'm not ready to climb that mountain yet. Use, comment, improve, or flame as desired. ;) <pre><code>// ******************************************************************************** // begin future nbSerialTX library code //nbSerialTx.h /* * nbSerialTX - non-blocking Serial Transmit library * by <a href="mailto:tdc218@sbcglobal.net">tdc218@sbcglobal.net</a> * 2011-Oct-28 * */ #include "ring_buffer.h" #include "usart.h" #ifndef _NBSERIALTX_H_ #define _NBSERIALTX_H_ #define NBS_BLOCKONFULL 13 #define NBS_DISCARDONFULL 218 class nbSerialTx { public: nbSerialTx(usart_dev *); ~nbSerialTx(); void init(char *, int); void init(char *, int, int); void update(void); void nbputc(char); void nbputs(char *); int space(void); private: usart_reg_map *xregs; int bufsize; ring_buffer rb; int blockflag; }; #endif // ******************************************************************************** // nbSerialTx.cpp //#include "nbSerialTx.h" nbSerialTx::nbSerialTx(usart_dev *device) { this->xregs = device->regs; this->bufsize = 0; // this->rb = NULL; // compiler doesn't like this blockflag = NBS_DISCARDONFULL; } nbSerialTx::~nbSerialTx() { rb_reset(&rb); this->xregs = (usart_reg_map *)NULL; this->bufsize = 0; // this->rb = NULL; // compiler doesn't like this } void nbSerialTx::init(char *buffer, int buffer_size) { this->bufsize = buffer_size; rb_init(&rb, buffer_size, (uint8 *)buffer); } void nbSerialTx::init(char *buffer, int buffer_size, int block) { this->bufsize = buffer_size; rb_init(&rb, buffer_size, (uint8 *)buffer); blockflag = block; } void nbSerialTx::update(void) { if (xregs->SR & USART_SR_TXE) // if uart transmitter is ready for another character if (!(rb_is_empty(&rb))) // if there is a character to send xregs->DR = rb_remove(&rb); // then pull it from the buffer and send it } // // Send one character // if blockflag is NBS_BLOCKONFULL then the function will block when the buffer gets full // otherwise the character will be discarded if the buffer is full // void nbSerialTx::nbputc(char c) { if (blockflag == NBS_BLOCKONFULL) while (!rb_safe_insert(&rb, (uint8)c)); // wait for buffer to be not full before inserting else (void)rb_safe_insert(&rb, (uint8)c); // will only insert if buffer is not full } // // send a string // // If you want to print numbers or other fancy stuff, use sprintf, eg: // #include <stdio.h> // char buf[SIZE]; // you define SIZE to something larger than the longest string you're likely to run into // sprintf(buf, "x=%04.3f address=%04x\n", float_var, uint16_var); // void nbSerialTx::nbputs(char *s) { char c; while ((c = *s++)) nbputc(c); } /* * space * returns the number of bytes available in the buffer * */ int nbSerialTx::space(void) { return this->bufsize - rb_full_count(&rb); } // end of future library code // ******************************************************************************** // begin main // Assumes a Gravitech SLCD-3 serial LCD on Serial 2 // #include <stdio.h> #define MAXMYS2BUF 128 nbSerialTx mys2 = nbSerialTx(USART2); char mys2buf[MAXMYS2BUF]; // My serial 2 transmit buffer (wouldn't need this if we had malloc) unsigned int sendMillis = 0; // store the last time serial test was sent unsigned int sendInterval = 50; // interval at which to send serial text unsigned int previousBlinkMillis = 0; // will store the last time the LED was updated unsigned int Blinkinterval = 500; // interval at which to blink (in milliseconds) void setup(void) { // Set up the built-in LED pin as output: pinMode(BOARD_LED_PIN, OUTPUT); // Seed the random # generator pinMode(28, INPUT_ANALOG); randomSeed(analogRead(28)); Serial2.begin(9600); Serial2.print("?f"); // Gravitech SLCD-3 clear screen command delay(100); Serial2.print("?g"); // beep the LCD's beeper delay(100); Serial2.print("Begin test "); Serial2.print(random(100), DEC); // print a random number so I can tell it really restarted Serial2.print("?n"); // stupid LCD doesn't understand real newlines // initialize mys2.init(mys2buf, MAXMYS2BUF); // send a string to the non-blocking routines mys2.nbputs("Hello,world?n"); } void loop(void) { unsigned int currentMillis; static unsigned int variation = 0; static char spbuf[32]; currentMillis = millis(); mys2.update(); // update the non-blocking serial transmit // // blink the LED for something to do // if (currentMillis - previousBlinkMillis >= Blinkinterval) { // Save the last time you blinked the LED previousBlinkMillis = currentMillis; // If the LED is off, turn it on, and vice-versa: toggleLED(); } // // spit out currentMillis to the serial port at intervals with some random variation // The LED should still blink at the correct intervals // if ((currentMillis - sendMillis) >= (sendInterval + variation)) { sendMillis = currentMillis; variation = 10 - random(20); sprintf(spbuf,"%08x?n", currentMillis); mys2.nbputs(spbuf); } }</code></pre>