Electronic – get dynamic length packet from UART

The problem is that your "transmission_test" code is written such that it assumes that "is_transmitting" from the UART goes true before the clock edge that follows the assertion of "begin_transmit". It doesn't -- it takes a clock cycle before the UART transmitter moves out of its "idle" state, after which "is_transmitting" is true.

As a result, your "transmission_test" state machine is advancing two states for each byte transmitted, and you see only every other byte at the output of the UART.

There are many minor problems with your code samples, but the main thing you need to fix is to verify that "is_transmitting" has gone true before you advance to the next byte in the message.

This would have been pretty obvious if you had taken the time to simulate this project. I can't overemphasize the importance of simulation in verifying FPGA code. Take the time to get familiar with your simulator and learn how to write good module testbenches.

Many (probably most) UART designs operate by dividing a system clock by some value to yield a rate which is some multiple of the desired baud rate (often 16x), and then only examining the state of the serial line once for each edge of that clock. For 9600 baud operation and 16x scaling, the clock period would be 6.5 microseconds. Since the system only looks at the receive line once every 6.5 microseconds, it can't tell when within the 6.5 microsecond window the falling edge occurred.

I would guess that the reason this design is so common is that it allows one programmable divider circuit to be used to set the baud rate for both transmission and reception; the transmitter and receiver will need separate divide-by-16 counters, but a fixed divide-by-16 circuit is a fair bit simpler than a programmable one. I would guess that 16 is the preferred divide ratio because power-of two ratios are a little easier to implement than other ratios in discrete silicon, and 1/16-bit timing uncertainty was "good enough" but 1/8-bit wasn't. Crystals were manufactured to drive UARTs that were built from discrete logic using power-of-two scaling factors, and later integrated UARTs wanted to keep using the stock crystal frequencies that had been used with the UARTs that had been constructed from discrete logic. In fact, an odd-number divide ratio like 1/13 would probably been better than 1/16, since the window of uncertainty will be centered about each bit (rather than off to one side). A 1MHz clock divided by two and then by 13 would yield a baud rates of 38461.5 (about 0.2% above 38400); inserting additional divide-by-two stages would allow for slower baud rates.

I don't know why more UARTs don't have a separate baud-rate generator for the receiver which starts counting when the start bit arrives. The extra silicon cost would be by today's standards negligible. My guess would be that a lot of chip designers don't give UARTs much thought, since many of them have many other annoying quirks or misfeatures and provide no means of finding out useful things (such as whether the UART is presently in the process of receiving a byte, or whether a byte is currently being transmitted or received).