Hello Atanu, You can imagine BUS as series of bits. In example is created BUS named nibble (it means half byte - four bits) but You can name it as You wish. If You read state of the bus, You will get number (easy to use HEX numbers) which represents state of inputs in the BUS. This is input BUS so each pin in bus can have value 0 or 1. So if You read BUS, You will get 0000 - bin (0x0 hex) if no input or 1111 - bin (0xF hex) if all inputs in BUS are high. You will get 0x3 hex (0011 in bin) reading if pin 5 and 6 is High. And reading 0x8 hex (1000 bin) if pin 11 is high.
In the code is used "switch" command and as parameter is used actual status of BUS. So if p5 and p6 are high program reads bus as 0011 bin (0x3 Hex) and does what is specified in "case" for this value. In this example it prints Hello on terminal. If only p11 is High program reads it as 0x8 hex and again does what is specified in "case" for this value - prints World on terminal. For other combinations of pins are not specified cases so if pin 18 is high, program does nothing. But You can try to add Your case to see how it works.
Example state of bus:
pin - pin 11 , pin 18 , pin 6 , pin 5
state - 0 0 1 1
Pins 11 & 18 are low - 0 and pins 6 & 5 are high - 1. The reading of the bus is 0011 bin or 0x03 in hex.
You can also look on internet for "bit masking" You can use bitmasking to determine which of busIn pins are high - (nibble && 0x8).
Get an mbed!
Wiki home
Recent changes
All Pages
New Page
SerialPC 
Page history
I would like to suggest that the constructor be documented to state that the parameters are specified in LSB-to-MSB order, rather than implicitly as demonstrated in the example.
Although this ordering makes sense from an API definition standpoint, it's likely the opposite sense that a noob would assume (MSB on the left, LSB on the right).