<wpwrak>
promach: 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)
<promach>
wpwrak: ok
<promach>
so FIFO and shift registers have different purposes
<promach>
?
<promach>
shift registers are doing the serial-parallel (or opposite) work
<promach>
while FIFO registers are doing data corruption prevention due to interrupt
<promach>
wpwrak: Do I get it right ?
<wpwrak>
that's an usual way to describe what a fifo does ;-)
<wpwrak>
the role of a fifo is to buffer data so that software can permit itself more latency
<wpwrak>
e.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 overruns
<wpwrak>
overrun = 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.
<wpwrak>
when 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 data
<wpwrak>
another 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 FIFO
<wpwrak>
so 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 often
<promach>
wpwrak: I do not get what it means by underrun
<promach>
what is wrong when UART transmitter has completed sending a character and the transmit buffer is empty. ?
<wpwrak>
nothing. but if you want to maximize throughput, then yuo don't want to have those pauses
<wpwrak>
also, there are protocols where underrun is not permitted
tavish has joined #qi-hardware
pcercuei has joined #qi-hardware
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
qi-bot has quit [*.net *.split]
erichvk_ has joined #qi-hardware
qi-bot has joined #qi-hardware
<promach>
wpwrak: what pauses ? and what for ?
<wpwrak>
promach: 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 sending
<mth>
promach: 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 stutter
<promach>
examples of artifact of unedrrun
<promach>
is there a way to solve underrun issue for UART ?
<pcercuei>
use flow control
<promach>
ok
<mth>
eh, flow control is used to prevent overruns, not underruns
<mth>
underrun happens if the software does not deliver data in time to the UART
<pcercuei>
right, read too fast, sorry
<mth>
some 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 be
<mth>
if that threshold is set high, a lot of interrupts are generated, which eats up performance
<promach>
threshold ?
<mth>
if 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 it
<mth>
like if you have a 16-byte buffer, you can tell the UART to generate an interrupt when there are 4, 8 or 12 bytes left
<promach>
a lot of interrupts are generated ? what interrupt ?
<mth>
interrupt request to the CPU
<promach>
for emptying all entries in the FIFO ?
<mth>
emptying them if you're receiving data, filling them if you're transmitting data
<mth>
there is usually one FIFO for receive and one FIFO for transmit
<wpwrak>
promach: you could think of it like in a post office. let's assume you're some celebrity and get lots of letters every day.
<wpwrak>
now, 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.
<promach>
what happen to the post office if mth's threshold parameter is set too high ?
<wpwrak>
a 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 time
strawberyargon has quit [Ping timeout: 260 seconds]
<promach>
what happen to the postman if mth's threshold parameter is set too high ?
<wpwrak>
then they would deliver mail only, say, every two days, or once per week. and you may not like waiting so long.
strawberyargon has joined #qi-hardware
<promach>
ok
<erichvk_>
you could fix it by replacing paper mail with email sent over a serial line like DSL
<promach>
if that threshold is set high, a lot of interrupts are generated ???
<wpwrak>
but 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 many
<mth>
the threshold for receiving works the other way around as for sending
<wpwrak>
so 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 overflows
<wpwrak>
too high a threshold would mean that they may run out of space
<promach>
high threshold --> overrun
<promach>
low threshold --> underrun
<mth>
no, overrun is on receiving, underrun is on sending
<wpwrak>
erichvk_: shush ! :)
<erichvk_>
;-)
<mth>
overrun means there is data coming in but the buffer is full and therefore cannot store the data, so it must throw it away
<mth>
like the post office throwing away letters if your mailbox is full
<promach>
mth: I am still quite confused on the relationship between FIFO threshold parameter and (overrun or underrun)
<erichvk_>
no different to writing a CD and the buffer underruns
<mth>
let's say an UART can send one byte every 1 ms
<mth>
and the buffer is 16 bytes long
<mth>
at the start, you fill the buffer with the first 16 bytes of data
<mth>
if 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 buffer
<mth>
so you provide 4 more bytes and then go off to do other things
<mth>
4 ms later, the buffer is again at 12 bytes filled and 4 empty, so it again asks for more data
<mth>
the 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 send
<mth>
but you are interrupted every 4 ms to provide more data, so the other things you want to do are slowed down by that
<mth>
like the postman ringing your door every 5 mintues
<mth>
if you'd set the threshold to 6 bytes, you'd be interrupted every 10 ms, so you'd have to time to do other things
<promach>
so, for transmission, the FIFO buffer is filled in by means of interuppt, which also prevents buffer underrun
<mth>
however, you then have only 6 ms to respond before the buffer is empty, so more chance of an underrun
<mth>
yes, underrun happens if the transmit buffer gets empty, so if you refill it in time, it won't underrun
<mth>
and the interrupt is the way the UART tells you that the buffer needs refilling
<promach>
sorry, I should not say "filled in"
<promach>
I should say dequeue instead
<mth>
however, there can be a delay between the time the interrupt request is made and the time the buffer is refilled
<promach>
since it is transmission
<mth>
like the time between someone ringing your doorbell and you answering the door
<promach>
ok
<mth>
depending on how long that delay might be, you'd have to set the threshold lower or higher
<promach>
it has to be depend on the exception handler
<mth>
it would be "enqueue" for sending, "dequeue" for receiving
<mth>
interrupt handler, not exception handler; they have similarities but they're not the same
<promach>
why dequeue for receving ?
<mth>
if you receive data, the OS/application takes it out of the buffer
<promach>
ok
<promach>
mth: I have understood the effect of "threshold" for transmission FIFO buffer
<promach>
what about receiving FIFO buffer ?
<mth>
with receiving, the risk is overruns: when data comes in and the buffer is full
<promach>
how is the "threshold" affecting the probability of receiving FIFO buffer overrun ?
<mth>
so here you want to take bytes out of the buffer in time
<promach>
yes
<mth>
if 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 delays
<mth>
but it means you get a lot of interrupts asking you to take bytes of out of the buffer
<mth>
if 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 overflow
<promach>
respond quicker or the buffer might overflow ? I thought when the CPU is in interrupt handler
<promach>
and RTS is deasserted to prevent data coming in ?
<mth>
there might be more than one device generating interrupt requests
<mth>
and if your CPU has a single core, it can only handle one at a time
<mth>
so 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 handled
<promach>
I see, this UART interrupt to take out bytes from its receiving FIFO buffer might not take effect until all other previous interrupt had finished
<mth>
yes, the UART makes an interrupt request (IRQ), but that means it should be handled as soon as possible, which is not always immediately
<promach>
ok
<promach>
mth: do we *really* need to have such "threshold" parameter for both tx and rx FIFO buffer ?
<mth>
it doesn't have to be a parameter, it could be a fixed value
<promach>
yes, I know
<promach>
but do we really need to have this threshold for FIFO buffer ?
<mth>
if the FIFO makes interrupt requests, it has to base that one something
<mth>
you 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)
<mth>
and polling is very inefficient for things that happen at a high frequency
<mth>
with regular mail, polling your mailbox once a day is fine
<mth>
but if you get 1000 letters a day in a small mailbox, you'd be checking the mailbox very often
<larsc>
at a very high-frequency polling becomes more efficient than interrupts again though
<promach>
I have a feeling that this threshold serves as a warning
<mth>
larsc: yes, but then you're basically doing nothing but polling
<promach>
huh?
<mth>
if 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 item
<mth>
for the frequency at which data comes out of an UART, interrupts are the best way of handling it
<mth>
I don't know if there are UARTs that don't provide interurpts; I do know that even UARTs from the 1980's already used interrupts
<promach>
mth: at a very high-frequency polling becomes more efficient than interrupts again though ?
<promach>
more efficient than interrupt ?
<promach>
does this apply to UART FIFO buffer threshold issue ?
<mth>
not really; UARTs aren't used for such high frequencies
<mth>
the underlying issue is though that handling interrupts has some overhead
<mth>
so you don't want to get too many interrupts
<promach>
overhead due to interupt request priority ?
<mth>
priority is an entirely different thing
<mth>
overhead due to task switching: the CPU must stop doing what it was doing and start work on the interrupt handler
<mth>
it needs to store register contents somewhere so it can use those registers for handling the interrupt, for example
<promach>
ok
<promach>
mth: what are the pros and cons between using polling and interrupt in FIFO buffer threshold issue ?
<mth>
polling 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?
<mth>
*is difficult
<mth>
you 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 interrupt
<promach>
mth: For UART buffer, if I set the buffer size to multiples of byte size, do I still need to consider the threshold problem ?
<mth>
I 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)
<mth>
you can calculate it: if you know what transfer rate you want to support, you know how quickly a buffer fills up
<mth>
what is the context of your questions? are you just curious or do you have to design an UART for an assignment or something?
<promach>
mth: I am working on building a softcore UART IP
<promach>
I mean in verilog
<mth>
if you want to use it in actual running systems, then I think you really need an interrupt that is triggered at a certain threshold
<mth>
ideally you'd mimic the 16550, since there are standardized drivers for that
<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."
<promach>
why would polling uses more transistors ?
<mth>
polilng 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 transistors
erichvk_ has quit [Ping timeout: 258 seconds]
<promach>
to have polling working, I need large FIFO buffer ? Why ?
<wpwrak>
mth: only if you're doing much of anything else :)
<mth>
for 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 bytes
<mth>
yes, if you're OK with polling the buffer thousands of times per second, you don't need a big buffer
<mth>
but most applications wouldn't consider that an option
<promach>
if baud rate = 115200 and polling rate = 10 per second, why buffer size > 1440 bytes ?
<promach>
115200/10/8 ?
<promach>
if baud rate = 115200 and polling rate <= 10 per second, why buffer size > (115200/10/8) bytes ?
<promach>
mth: do I translate your sentence correctly ?
<mth>
yes
<mth>
if 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 second
<mth>
otherwise it would overflow/underflow before you check again
<promach>
I thought polling does not need to wait to be served by CPU
<promach>
why take into account the data that comes in during polling ?
<mth>
not during polling, the data that comes in between two polls
<promach>
I see
<promach>
is routine checking fast enough to prevent buffer overflow/underflow
<promach>
I got it now
<promach>
but why is it 1/10th of a second ?
<mth>
that's just an example interval
<mth>
Linux has a 100 Hz timer interrupt by default, systems which output video often have 60 Hz vblank interrupts
<mth>
so you'd have to think somewhere in that order for recurring tasks
<mth>
but if you want people to actually use your softcore, please make it as similar to the 16550 as possible
<mth>
that way they can easily adapt the code they already have
<promach>
for buffer underflow, buffer size does not depend on polling rate, right ?
<promach>
I will definitely use interrupt, but I am only considering using polling if I have extra time
<promach>
to implement
<mth>
underflow could happen with polling as well: if you don't poll often enough, the buffer might sit empty
<mth>
that is less of a problem than an overflow because no data gets lost
<mth>
but it would hurt the effective bandwidth
<mth>
I don't think you need to do anything special to support polling
<promach>
mth: for buffer underrun issue, do we still need buffer size > baudrate/polling rate ?
<promach>
larsc: why would you say so ?
<larsc>
because it is the truth!
<larsc>
for interrupts you need special logic that generates the interrupt
<larsc>
you need special interrupt handling routines in sw
<larsc>
your flow control is not linear
<promach>
not linear ? huh /
<promach>
?
<larsc>
the interupt handler interrupts normal flow control
<larsc>
at a more or less random point
<promach>
larsc: you are not referring to flow control bits RTS and CTS ?
<larsc>
no
<larsc>
the flow of your software
pcercuei has quit [Quit: bbl]
<kyak>
that would be control flow :)
<promach>
mth: for buffer underrun issue, do we still need buffer size > baudrate/polling rate ?
<mth>
if you want to use the bandwidth efficiently, yes
<promach>
huh ?
<promach>
does it have to do with buffer size ?
<mth>
if the UART is sending data at a particular baud rate, the buffer will at some point be empty
<mth>
so if you don't fill it in time, you get an underrun
<promach>
how do you derive this inequality buffer size > baudrate/polling rate
<mth>
maybe it's easier to understand as buffer size * polling rate > baudrate
<mth>
on 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 second
<promach>
mth: I got to run. I have a rough idea on what you said, let me ponder a bit more later
strawberyargon has quit [Ping timeout: 240 seconds]