Change UART-TSI baudrate

Author: doihead

tutorials/baremetal-ide/Baremetal IDE Lab.md

@@ -178,7 +178,7 @@ Let's break down the arguments here
 {: .note }
 Unfortunately, due to the way Unix handles serial devices, the exact device ID changes every time you unplug and replug your device. The best way of figuring out which serial port is which is unplug the device you are trying to find the id of, run the command `ls /dev/ttyUSB*` to lists out all remaining USB serial ports, plug the device in again, and run the command one last time to find the new serial port. For the lab, UART-TSI is on the usb port hooked directly up to the FPGA, not the one plugged into the FT-LINK.
 
-`+baudrate=<baudrate>` specifies which baudrate the computer should talk to the chip at. This must match whatever the chip was configured for. In our case, this is 921600 baud.
+`+baudrate=<baudrate>` specifies which baudrate the computer should talk to the chip at. This must match whatever the chip was configured for. In our case, this is 115200 baud which is the default so we don't need to specify this argument.
 
 `+no_hart0_msip` specifies that we should not send a **M**achine **S**oftware **I**nterrupt to hart0 or core 0. By default, after completing all reads and writes, UART-TSI sets the hart0 msip register to 1 which sends an interrupt to core 0 of the chip which tells the chip that we are done loading in the program and should jump to the address in the boot address register to start executing. Specify this argument if you do not want the core to boot up, such as when you are just doing read/writes.
 
@@ -194,7 +194,7 @@ Unfortunately, due to the way Unix handles serial devices, the exact device ID c
 Putting that all together we get this command to load the blinky binary we just built to the chip.
 
 ``` bash
-uart_tsi +tty=[YOUR_TTY] +baudrate=921600 build/d01/blinky.elf
+uart_tsi +tty=[YOUR_TTY] build/d01/blinky.elf
 ```
 
 Before running a program with uart_tsi, make sure to hit the reset button. While the read/writes will work just fine, the chip neeeds to be fresh out of the reset state in order to start running the loaded program correctly. If everything worked properly, you should see an LED flashing on the FPGA.