Firstly, I have a Pi3 and I can see only 40 GPIO pins similar to this Pi2 GPIO diagram https://cdn.sparkfun.com/assets/learn_t ... pinout.jpg. But page 89 on the BCM2835 Peripherals document says "There are 54 general-purpose I/O (GPIO) lines split into two banks". Did Pi1 have 54 pins and they reduced it to 40 in Pi2/3? Or am I misunderstanding something?

I understood that above Line 63 in the code selects ALT0 function for pin 14/15. As per page 102 in BCM2835 Peripherals document ALT0 is TXD0/RXD0 (which I guess means transmitter and receiver for serial comms). I also noticed that ALT5 for the pins has the same function. So I modified the code to use ALT5 as below.

r|=(2<<12)|(2<<15); // alt5

I tested is successfully on qemu for raspi3. Next I tried selecting the other ALT functions for the pins and the program still kept working fine in qemu! Either the qemu simulation is not correct or I have misunderstood something. I want to try it on a real Pi3 to verify if qemu is at fault but I am afraid to try it. Is it safe if I make mistakes in my program or is there a possibility to damage Pi3 or my laptop connected via USB? I am a software-only guy and don't understand much about electronics so this worry.

Also I can see pin 32/33 (ALT3 and ALT5), pin 36/37 (ALT2), pin 40/41 (ALT5) say TXD and RXD. So If I connect my UART cable to these pins instead of 14/15 and modify my code to select these pins and appropriate alt functions will the communication work?

Lastly, I just pull out the USB from my laptop as I cannot see any eject option in Ubuntu. Is this safe or is there anything I need to do before I pull out the USB side of the cable?

GPIO32 and GPIO33 don't make there way to that header you can't get access to them there.

The other thing I am just checking you know is at that Header the UART signals are only 3.3V and upside down you can't connect them to a computer serial port. You need an RS232 driver board to transform the signals to +-12V for a normal computer serial port.

They connect to Header Pin 8 and 10 above as well as the +3.3V and GND from that connector which powers up the converter chip and driver on those boards. The onboard IC (usually a MAX3232) does the voltage translation and it provides safety to the Pi.

I understood that above Line 63 in the code selects ALT0 function for pin 14/15. As per page 102 in BCM2835 Peripherals document ALT0 is TXD0/RXD0 (which I guess means transmitter and receiver for serial comms). I also noticed that ALT5 for the pins has the same function. So I modified the code to use ALT5 as below.

r|=(2<<12)|(2<<15); // alt5

I tested is successfully on qemu for raspi3. Next I tried selecting the other ALT functions for the pins and the program still kept working fine in qemu! Either the qemu simulation is not correct or I have misunderstood something.

As for that part. Since there are more GPIO ports than GPIO header pins, you can map the ports to the pins. Therefore you can choose which UART to use without reconnecting the cable. Full comprehensive list can be found here. From that table you can read that ALT0 connects the UART0 to header pins 14/15, while ALT5 maps UART1 to the same pins (which also means you can either use UART0 or UART1 but not both at any given time). So ALT5 won't work, see issue 2. I haven't noticed the copy'n'paste bug because qemu does not emulate pin mapping.

As I have mentioned in my tutorials, qemu's emulation is rudimentary. If something is working on real hardware, it's very likely it will work on qemu, but not the other way around.

Also I can see pin 32/33 (ALT3 and ALT5), pin 36/37 (ALT2), pin 40/41 (ALT5) say TXD and RXD. So If I connect my UART cable to these pins instead of 14/15 and modify my code to select these pins and appropriate alt functions will the communication work?

Yes in theory, if you want to use both UARTs, one of them has to be mapped at those pins. But since those combinations are striked through in the table, I haven't tried.

I cant speak to the specific pi qemu port. But the ones I have dabbled with (used) they not only do not get into pin/pad controls and gpio muxes, they dont even fully implement the uart. You can simply write to the uart transmit register as fast as you can and the characters go out on the console, to find on hardware that your uart_init and possibly many other lines of code are wrong. it is possible someone went to that length, but I would advise against that assumption and not get too deep into your development without trying it on hardware.