Low level device driver for UART and LCD

From EdWiki


To write drivers for UART peripheral in RISCV processor and Auto baud detection


Kavya and Sumeet from DESE has designed a 32 bit RISCV processor from scratch, as part of Digital Flight Control Computer(DFCC) for LCA-Tejas. The DFCC has to get data from peripherals and process accordingly. For that purpose Peripherals needs to be added to the processor. Since the design of processor and peripherals is from scratch, It needs specific device drivers for peripherals. One of such peripheral is UART, chosen in this miniproject.


  • Open the gtkterm
  • Set the required baud rate
  • Reset the hardware
  • Press Enter
  • Type some character
  • Loop back, if auto baud successful
  • Try with different baud rate

demo video

Algorithm for Auto Baud

Auto baud rate detection, is done by examining one or two characters received. In this case, one carriage return is used to identify baud rates between 115200 and 9600. If the terminal is operating at a baud rate less than 9600, a second carriage return is necessary to idendify the baud. Initially set the baud to 115200, upon the host sends carriage return(CR) it will check with the unique pattern for different baud rates. Step1.png

If it gets zero in the above step, it will go to next level i.e. from 9600 to 1200, with initial baud rate to 9600. Upon the next carriage return(CR), it will be able to identify the baud between 9600 and 1200. If this step fails, the algorithm will start again, i.e. from 115200 to 9600. In the worst case, two carriage returns in sequence, will give a successful result of tuning to the host baud. This can be generalized, according to the random behaviour of entering characters. In a sense, wait until carriage return(most probable character) is pressed.


Main challenge is not to write uart drivers or autobaud. It is a challenge to work with a processor, which is in a developing stage. Any of the c or assembly can be used to write drivers. Here c language is chosen, to increase the scope of usage. i.e. most of the times, user wants to write codes in embedded c. In that case to use drivers in assembly, care should be taken in terms of registers. The procedure is write a c code, using RISCV tool chain convert it to pseudo assembly. And then use interpreter to generate .coe file to be loaded into the RAM of processor. The coe file contains binary instructions, which are in sync with RISCV processor. Writing drivers in c, such that RISCV tool chain and Interpreter converts to satisfy our requirement is a difficult task. For example, In case if you directly use a 32 bit number in some operation, it will generate "li reg,32 bit num". But the actual instruction is of 32 bit. In that case the interpreter should take this number, convert to some other instructions, so that LSB or MSB(depends on conversion) should not be skipped. In our case, interpreter won't take care of these type of conditions. So to write the drivers, it is necessary to cross check c and assembly files, so that end result is satisfactory. Nothing but, how to write the things in c, such that assembly and binary conversion satisfies the purpose. Once things work fine with one set of drivers(here for uart), the same set of logic can be used to write drivers for other peripherals also.

Hardware Used

Virtex-7 FPGA

  • Part number xc7vx485tffg1761-2
Virtex-7 FPGA board

Tools Used

  • PlanAhead
  • Vivado
  • gtkterm

Future Scope

  • Using auto baud, Will be able to read registers like pc
  • Debug unit


Source Codes

Source codes at


Suseela Budi
Pradeep Gupta