I2C and SPI are both bus protocols that allow short-distance, serial data transfer. I2C originates from the Philips semiconductor devision, while SPI was created by Motorola. Both protocols are commonly used in electronic devices like smartphones, TV's and laptops to control peripherals like power management chips, input devices and DACs.
I2C allows multiple masters and slaves on the bus. On the other hand SPI can only work with one master device controlling multiple slaves. In both I2C and SPI the master device controls the clock for all slaves.
Device Drivers
To dynamically load or unload a driver, use these commands, which reside in the /sbin directory, and must be executed with root privileges:
- lsmod — lists currently loaded modules
- insmod — inserts/loads the specified module file
- modprobe — inserts/loads the module, along with any dependencies
- rmmod — removes/unloads the module
All printk calls put their output into the (log) ring buffer of the kernel. Then, the syslog daemon running in user-space picks them up for final processing and redirection to various devices, as configured in the configuration file/etc/syslog.conf.
Difference Between Semaphore and Mutex
Mutex:
Is a key to a toilet. One person can have the key – occupy the toilet – at the time. When finished, the person gives (frees) the key to the next person in the queue.
Semaphore:
Is the number of free identical toilet keys. Example, say we have four toilets with identical locks and keys. The semaphore count – the count of keys – is set to 4 at beginning (all four toilets are free), then the count value is decremented as people are coming in. If all toilets are full, ie. there are no free keys left, the semaphore count is 0.
Interrupt handled in Linux
An interrupt is an event that changes the sequence of instructions executed by the processor.
There are two different kinds of interrupts:
There are two different kinds of interrupts:
- Synchronous interrupt (Exception) produced by the CPU while processing instructions
- Asynchronous interrupt (Interrupt) issued by other hardware devices
When an interrupt occurs, the processor looks if interrupts are masked. If they are, nothing happens until they are unmasked. When interrupts become unmasked, if there are any pending interrupts, the processor picks one.
Then the processor executes the interrupt by branching to a particular address in memory. The code at that address is called the interrupt handler. When the processor branches there, it masks interrupts (so the interrupt handler has exclusive control) and saves the contents of some registers in some place (typically other registers).
The interrupt handler does what it must do, typically by communicating with the peripheral that triggered the interrupt to send or receive data. If the interrupt was raised by the timer, the handler might trigger the OS scheduler, to switch to a different thread. When the handler finishes executing, it executes a special return-from-interrupt instruction that restores the saved registers and unmasks interrupts.
The interrupt handler must run quickly, because it's preventing any other interrupt from running. In the Linux kernel, interrupt processing is divided in two parts:
- The “top half” is the interrupt handler. It does the minimum necessary, typically communicate with the hardware and set a flag somewhere in kernel memory.
- The “bottom half” does any other necessary processing, for example copying data into process memory, updating kernel data structures, etc. It can take its time and even block waiting for some other part of the system since it runs with interrupts enabled.
Exceptions in Kernel
Exceptions are caused by programming errors (f.e. Divide error, Page Fault, Overflow) that must be handled by the kernel. He sends a signal to the program and tries to recover from the error.
The following two exceptions are classified:
- Processor-detected exception generated by the CPU while detecting a anomalous condition; divided into three groups: Faults can generally be corrected, Traps report an execution, Aborts are serious errors.
- Programmed exception requested by the programmer, handled like a trap.
What are the different bottom-half mechanisms in Linux?
Softirq, Tasklet and Workqueues
differences between softirqs and tasklets?
- Softirq is guaranteed to run on the CPU it was scheduled on, where as tasklets don’t have that guarantee.
- The same tasklet can't run on two separate CPUs at the same time, where as a softirq can.
No comments:
Post a Comment