Driving a seven-segment LED display without interruption
Welcome to real-time programming.  There's an infinite number of things you can do: here's the three most popular:

Update the display out of an ISR that's fired off every 5ms by a timer.  This is kind of cheating, using your interrupt controller as a rather poor RTOS.
Make an event-driven task loop (a &quot;superloop&quot;).  This is a pretty good way to deal with a lot of different event-servicing code that all takes about the same amount of time to run.
Use an RTOS.

I don't recommend the ISR approach except in certain narrow circumstances -- it works, but only until the boss comes up with more features that just have to be implemented.
I'm not going to go into the RTOS approach because there's not room, you don't need it if those two functions are all you're going to implement, and because there's plenty of documentation on how to make it work.
For the code below, assume that timer_ready_flag() returns true the first time that it is called after the timer completes a 5ms waiting time, and false after that until the next time the timer pops off.
digit_count = 0
sensor_time = 0
while True:    # Note that we never return from this
  if not timer_ready_flag():
    # just spin
    continue
  if sensor_time == 0:
    send_sensor_read_command()  # I assume this is the 'transmit' you talked about
    sensor_time += 1
  elif sensor_time &lt; 20:
    sensor_time += 1
  else
    read_sensor_value()
    sensor_time = 0

  deselect_digits()
  write_digit_pattern(digit_count)
  select_digit(digit_count)
  digit_count += 1
  if digit_count &gt;= 3:
    digit_count = 0

Yes, this will complicate your code -- you have to make everything it does event-driven, and if you have some processor intensive long-running task that only happens every once in a while you have to either put up with it messing around with operation, or you need to break that task up into little chunks, or you have to use a preemptive RTOS.  But it's a very common way of writing embedded real-time code because for simple-enough systems it works great.