#qi-hardware IRC log for Tuesday, 2017-05-30

--- Tue May 30 201700:00
promachFor https://learn.sparkfun.com/tutorials/serial-communication/uarts , why do we need shift registers ?03:44
wpwrakpromach: the shift reg is what turns a "word" (in this case, a byte) that is transferred parallel, into a sequence of bits (or vice versa)04:02
promachwpwrak: ok04:06
promachso FIFO and shift registers have different purposes04:07
promach?04:07
promachshift registers are doing the serial-parallel (or opposite) work04:07
promachwhile FIFO registers are doing data corruption prevention due to interrupt 04:07
promachwpwrak: Do I get it right ?04:08
wpwrakthat's an usual way to describe what a fifo does ;-)04:41
wpwrakthe role of a fifo is to buffer data so that software can permit itself more latency04:43
wpwrake.g., if a new byte can arrive every 10 us, but it takes you up to 25 us to respond to that, then you need a FIFO that can buffer at least two bytes, or you'll have overruns04:45
wpwrakoverrun = new data is lost because the buffer is already full, or buffered data is overwritten by new data. sometimes that can also result in a genuine corruption. depends a bit on context.04:46
wpwrakwhen sending, there are no overruns but underruns. in the case of UART, an underrun is not a problem, but you waste a bit of time you could have used to transmit data04:48
wpwrakanother purpose of FIFOs is to deliberately increase the latency of software. e.g., if you receive a byte every 10 us, you may buffer up to ten bytes, then generate an interrupt, and then software will retrieve all that's in the FIFO04:49
wpwrakso you only get an interrupt every 10+ bytes, instead of getting one per byte. this means that you pay the overhead for entering and leaving an interrupt less often04:50
promachwpwrak: I do not get what it means by underrun05:10
promachhttps://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter#Underrun_error05:10
promachwhat is wrong when UART transmitter has completed sending a character and the transmit buffer is empty. ?05:10
wpwraknothing. but if you want to maximize throughput, then yuo don't want to have those pauses06:30
wpwrakalso, there are protocols where underrun is not permitted06:31
promachwpwrak: what pauses ? and what for ?11:14
wpwrakpromach: i mean the pauses between bytes you get when you don't have the next byte to send ready when the previous one has finished sending12:24
mthpromach: if you are sending bytes to an audio device for example, if there is an underrun, it has nothing to play for a while and you will hear the sound stutter13:51
promachexamples of artifact of unedrrun13:53
promachis there a way to solve underrun issue for UART ?13:53
pcercueiuse flow control14:01
promachok14:03
mtheh, flow control is used to prevent overruns, not underruns14:13
mthunderrun happens if the software does not deliver data in time to the UART14:13
pcercueiright, read too fast, sorry14:14
mthsome UARTs have a configurable threshold at which they should generate an interrupt to ask for more data: how close to empty the FIFO is allowed to be14:14
mthif that threshold is set high, a lot of interrupts are generated, which eats up performance14:16
promachthreshold ?14:16
mthif it is set low, there is more risk of underrun, since there will be less in the buffer then the software side is asked to refill it14:16
mthlike if you have a 16-byte buffer, you can tell the UART to generate an interrupt when there are 4, 8 or 12 bytes left14:16
promacha lot of interrupts are generated ? what interrupt ?14:17
mthinterrupt request to the CPU14:17
promachfor emptying all entries in the FIFO ?14:17
mthemptying them if you're receiving data, filling them if you're transmitting data14:18
mththere is usually one FIFO for receive and one FIFO for transmit14:18
wpwrakpromach: you could think of it like in a post office. let's assume you're some celebrity and get lots of letters every day.14:19
wpwraknow, each time a letter arrives at the post office, they could send a postman to deliver it. so postman goes to your house, rings the bell, interrupting you, you open the door and get the letter, postman goes back to the post office. when the next letter arrives, this repeats.14:20
promachwhat happen to the post office if mth's threshold parameter is set too high ?14:21
wpwraka more efficient way would be to store letters at the post office. so you get only one delivery per day, the postman doesn't need to go back and forth all the time, and you don't have the doorbell ringing all the time14:21
promachwhat happen to the postman if mth's threshold parameter is set too high ?14:22
wpwrakthen they would deliver mail only, say, every two days, or once per week. and you may not like waiting so long.14:22
promachok14:22
erichvk_you could fix it by replacing paper mail with email sent over a serial line like DSL14:22
promachif that threshold is set high, a lot of interrupts are generated ???14:22
wpwrakbut there's another case of "too high": if space at the post office is limited, they may have to throw away letters if they get too many14:23
mththe threshold for receiving works the other way around as for sending14:23
wpwrakso when they tell the postman to make a delivery, they must do that soon enough before running out of space that the postman has time to remove the bags from the post office before it overflows14:24
wpwraktoo high a threshold would mean that they may run out of space14:24
promachhigh threshold --> overrun14:25
promachlow  threshold --> underrun14:25
mthno, overrun is on receiving, underrun is on sending14:25
wpwrakerichvk_: shush ! :)14:25
erichvk_;-)14:28
mthoverrun means there is data coming in but the buffer is full and therefore cannot store the data, so it must throw it away14:29
mthlike the post office throwing away letters if your mailbox is full14:29
promachmth: I am still quite confused on the relationship between FIFO threshold parameter and (overrun or underrun)14:29
erichvk_no different to writing a CD and the buffer underruns14:30
mthlet's say an UART can send one byte every 1 ms14:30
mthand the buffer is 16 bytes long14:30
mthat the start, you fill the buffer with the first 16 bytes of data14:31
mthif you set the threshold at 12 bytes, you will be alerted to provide more data after 4 ms, since 4 bytes have been sent by then so 12 remain in the buffer14:31
mthso you provide 4 more bytes and then go off to do other things14:32
mth4 ms later, the buffer is again at 12 bytes filled and 4 empty, so it again asks for more data14:32
mththe chance of getting an underrun is low, since you can be up to 12 ms late in responding and there is still enough data in the buffer to send14:32
mthbut you are interrupted every 4 ms to provide more data, so the other things you want to do are slowed down by that14:33
mthlike the postman ringing your door every 5 mintues14:33
mthif you'd set the threshold to 6 bytes, you'd be interrupted every 10 ms, so you'd have to time to do other things14:33
promachso, for transmission, the FIFO buffer is filled in by means of interuppt, which also prevents buffer underrun14:34
mthhowever, you then have only 6 ms to respond before the buffer is empty, so more chance of an underrun14:34
mthyes, underrun happens if the transmit buffer gets empty, so if you refill it in time, it won't underrun14:35
mthand the interrupt is the way the UART tells you that the buffer needs refilling14:35
promachsorry, I should not say "filled in"14:35
promachI should say dequeue instead14:35
mthhowever, there can be a delay between the time the interrupt request is made and the time the buffer is refilled14:35
promachsince it is transmission14:35
mthlike the time between someone ringing your doorbell and you answering the door14:36
promachok14:36
mthdepending on how long that delay might be, you'd have to set the threshold lower or higher14:36
promachit has to be depend on the exception handler14:37
mthit would be "enqueue" for sending, "dequeue" for receiving14:37
mthinterrupt handler, not exception handler; they have similarities but they're not the same14:38
promachwhy dequeue for receving ?14:38
mthif you receive data, the OS/application takes it out of the buffer14:39
promachok14:42
promachmth: I have understood the effect of "threshold" for transmission FIFO buffer14:44
promachwhat about receiving FIFO buffer ?14:44
mthwith receiving, the risk is overruns: when data comes in and the buffer is full14:45
promachhow is the "threshold" affecting the probability of receiving FIFO buffer overrun ?14:45
mthso here you want to take bytes out of the buffer in time14:45
promachyes14:46
mthif you have a low threshold, say 4 bytes filled of 16 total, there is a small chance of an overrun, since there are 12 spare positions in case there are delays14:46
mthbut it means you get a lot of interrupts asking you to take bytes of out of the buffer14:46
mthif you set the threshold higher, there will be fewer interrupts, but when an interrupt does come you'll have to respond quicker or the buffer might overflow14:47
promachrespond quicker or the buffer might overflow ? I thought when the CPU is in interrupt handler14:48
promachand RTS is deasserted to prevent data coming in ?14:48
mththere might be more than one device generating interrupt requests14:49
mthand if your CPU has a single core, it can only handle one at a time14:49
mthso if the CPU is already handling a request from for example the audio chip, the UART interrupt request has to wait for a bit before it is handled14:50
promachI see, this UART interrupt to take out bytes from its receiving FIFO buffer might not take effect until all other previous interrupt had finished14:50
mthyes, the UART makes an interrupt request (IRQ), but that means it should be handled as soon as possible, which is not always immediately14:50
promachok14:51
promachmth: do we *really* need to have such "threshold" parameter for both tx and rx FIFO buffer ?14:52
mthit doesn't have to be a parameter, it could be a fixed value14:53
promachyes, I know14:53
promachbut do we really need to have this threshold for FIFO buffer ?14:54
mthif the FIFO makes interrupt requests, it has to base that one something14:54
mthyou could have a FIFO that doesn't make interrupt requests, but then an application would have to poll the buffer (look at it regularly to see if there is any data)14:55
mthand polling is very inefficient for things that happen at a high frequency14:55
mthwith regular mail, polling your mailbox once a day is fine14:56
mthbut if you get 1000 letters a day in a small mailbox, you'd be checking the mailbox very often14:56
larscat a very high-frequency polling becomes more efficient than interrupts again though14:57
promachI have a feeling that this threshold serves as a warning 14:57
mthlarsc: yes, but then you're basically doing nothing but polling14:57
promachhuh?14:58
mthif you're working at an assembly line, you just stand there waiting for the next item to arrive, you don't walk off and go back when you hear a bell alerting you of a new item15:00
mthfor the frequency at which data comes out of an UART, interrupts are the best way of handling it15:01
mthI don't know if there are UARTs that don't provide interurpts; I do know that even UARTs from the 1980's already used interrupts15:01
promachmth: at a very high-frequency polling becomes more efficient than interrupts again though ?15:03
promachmore efficient than interrupt ?15:03
promachdoes this apply to UART FIFO buffer threshold issue ?15:03
mthnot really; UARTs aren't used for such high frequencies15:04
mththe underlying issue is though that handling interrupts has some overhead15:05
mthso you don't want to get too many interrupts15:05
promachoverhead due to interupt request priority ?15:05
mthpriority is an entirely different thing15:06
mthoverhead due to task switching: the CPU must stop doing what it was doing and start work on the interrupt handler15:06
mthit needs to store register contents somewhere so it can use those registers for handling the interrupt, for example15:06
promachok15:07
promachmth: what are the pros and cons between using polling and interrupt in FIFO buffer threshold issue ?15:09
mthpolling if difficult to program: how would you make sure you look for data in the buffer often enough, without looking too often and wasting time that way?15:11
mth*is difficult15:11
mthyou could use a timer, but a timer would be using a timer interrupt, so then you'd still be using an interrupt and it would be more efficient to just let the UART generate the interrupt15:12
promachmth: For UART buffer, if I set the buffer size to multiples of byte size, do I still need to consider the threshold problem ?15:19
mthI guess if you make a really large buffer, you could poll it instead, but that would be a much more expensive design (uses more transistors)15:22
mthyou can calculate it: if you know what transfer rate you want to support, you know how quickly a buffer fills up15:23
mthwhat is the context of your questions? are you just curious or do you have to design an UART for an assignment or something?15:26
promachmth: I am working on building a softcore UART IP15:27
promachI mean in verilog15:27
mthif you want to use it in actual running systems, then I think you really need an interrupt that is triggered at a certain threshold15:28
mthideally you'd mimic the 16550, since there are standardized drivers for that15:28
promachhttps://en.wikipedia.org/wiki/16550_UART15:30
mthyes, that one15:30
mth"To overcome these shortcomings, the 16550 series UARTs incorporated a 16-byte FIFO buffer with a programmable interrupt trigger of 1, 4, 8, or 14 bytes."15:30
promachwhy would polling uses more transistors ?15:30
mthpolilng wouldn't use more transistors per se, but to make polling work in a system, you'd need a very large buffer and that uses lots of transistors15:31
promachto have polling working, I need large FIFO buffer ? Why ?15:31
wpwrakmth: only if you're doing much of anything else :)15:32
mthfor example, if you have data coming in at 115200 bits per second and you want to poll the buffer at most 10 times per second, you'd need a buffer of 1440 bytes15:32
mthyes, if you're OK with polling the buffer thousands of times per second, you don't need a big buffer15:33
mthbut most applications wouldn't consider that an option15:33
promachif baud rate = 115200 and polling rate = 10 per second, why buffer size > 1440 bytes ?15:36
promach115200/10/8 ?15:37
promachif baud rate = 115200 and polling rate <= 10 per second, why buffer size > (115200/10/8) bytes ?15:38
promachmth: do I translate your sentence correctly ? 15:39
mthyes15:44
mthif you poll the buffer 10 times per second, then it has to be large enough to contain the data that comes in in 1/10th of a second15:45
mthotherwise it would overflow/underflow before you check again15:46
promachI thought polling does not need to wait to be served by CPU15:48
promachwhy take into account the data that comes in during polling ?15:48
mthnot during polling, the data that comes in between two polls15:49
promachI see15:50
promachis routine checking fast enough to prevent buffer overflow/underflow15:50
promachI got it now15:50
promachbut why is it 1/10th of a second ?15:51
mththat's just an example interval15:52
mthLinux has a 100 Hz timer interrupt by default, systems which output video often have 60 Hz vblank interrupts15:52
mthso you'd have to think somewhere in that order for recurring tasks15:53
mthbut if you want people to actually use your softcore, please make it as similar to the 16550 as possible15:53
mththat way they can easily adapt the code they already have15:53
promachfor buffer underflow, buffer size does not depend on polling rate, right ?15:58
promachI will definitely use interrupt, but I am only considering using polling if I have extra time15:59
promachto implement15:59
mthunderflow could happen with polling as well: if you don't poll often enough, the buffer might sit empty16:06
mththat is less of a problem than an overflow because no data gets lost16:06
mthbut it would hurt the effective bandwidth16:06
mthI don't think you need to do anything special to support polling16:06
promachtrue16:06
promachhttp://www.ti.com/general/docs/datasheetdiagram.tsp?genericPartNumber=PC16550D&diagramId=SNLS378C16:06
larscpolling is certainly simpler to implement16:08
larscboth in hw as well as sw16:08
promachmth: for buffer underrun issue, do we still need buffer size > baudrate/polling rate ?16:08
promachlarsc: why would you say so ?16:08
larscbecause it is the truth!16:09
larscfor interrupts you need special logic that generates the interrupt16:09
larscyou need special interrupt handling routines in sw16:09
larscyour flow control is not linear16:09
promachnot linear ? huh /16:11
promach?16:11
larscthe interupt handler interrupts normal flow control16:12
larscat a more or less random point16:12
promachlarsc: you are not referring to flow control bits RTS and CTS ?16:13
larscno16:14
larscthe flow of your software16:14
kyakthat would be control flow :)16:28
promachmth: for buffer underrun issue, do we still need buffer size > baudrate/polling rate ?16:32
mthif you want to use the bandwidth efficiently, yes16:38
promachhuh ?16:40
promachdoes it have to do with buffer size ?16:40
mthif the UART is sending data at a particular baud rate, the buffer will at some point be empty16:41
mthso if you don't fill it in time, you get an underrun16:42
promachhow do you derive this inequality     buffer size > baudrate/polling rate       16:42
mthmaybe it's easier to understand as   buffer size * polling rate > baudrate17:32
mthon the left side is the amount of data you can process per second, on the right side is the amount of data that you can send or receive per second17:33
promachmth: I got to run. I have a rough idea on what you said, let me ponder a bit more later17:38
--- Wed May 31 201700:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!