Friday 27 October 2017

Proxy settings for HTTP/FTP/APT/RSYNC/GIT/CURL/YUM/DNF

#HTTP Proxy/FTP Proxy

# export http_proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>

# export ftp_proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>

# vi /etc/bash.bashrc
export http_proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>/
export ftp_proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>/


# Proxy Settings in APT on Ubuntu Linux

# vi /etc/apt/apt.conf
Acquire::http::Proxy "http://<proxy-server-ip-or-dns-name>:<Port-Number>";

#RSYNC

# export RSYNC_PROXY="http://<proxy-server-ip-or-dns-name>:<Port-Number>”


# For Git Clone 

#vi ~/.gitconfig
[http]
    proxy = http://username:password@<proxy-server-ip-or-dns-name>:<Port-Number>



#Yum Proxy setting

vi /etc/yum.conf

proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>
proxy_username=username
proxy_password=password


#DNF proxy setting

vi /etc/dnf/dnf.conf

proxy=http://<proxy-server-ip-or-dns-name>:<Port-Number>
proxy_username=username
proxy_password=password



#Curl

vi ~/.curlrc

proxy = http://username:password@<proxy-server-ip-or-dns-name>:<Port-Number>


Sunday 22 October 2017

Proxy setting in Browsers - Internet Explorer, Firefox, Chrome


1) Internet Explorer 



2) Firefox



3) Chrome



Installation of Kernel from source file

Download the latest tar source files:

https://git.kernel.org/torvalds/t/linux-4.12-rc1.tar.gz

Copy the file to /usr/src location

  • tar -xvzf [file name]
  • cd /usr/src/
  •  make menuconfig\
Exit from the window and save the kernal

  • make bzImage
  • make
  • make modules
  • make modules_install
  • make install

Note:


 "make bzImage" command sometimes fails, install dependency libraries.

scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or directory
#include <openssl/opensslv.h>
compilation terminated.
make[1]: *** [scripts/sign-file] Error 1
make: *** [scripts] Error 2

yum install openssl / dnf install openssl

Install kernel headers and kernel developmental tool in Fedora


Give the uname -r and copy the kernel version and fedora version
   Ex. # uname -r
            4.8.6-300.fc22.i686

Copy "4.8.6-300.fc22.i686" and replace in the below command instead of 'uname -r'

dnf install kernel-headers- `uname -r` kernel-devel- `uname -r`

How to stop Kernel from assigning random Interface names



In order to ensure the the kernel uses the name assigned to it, below command can be used:

On Ubuntu


ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules


In Fedora:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules



Reference: https://bbs.archlinux.org/viewtopic.php?id=162519
https://forums.gentoo.org/viewtopic-t-959308-start-0.html

Change MAC address of Bluetooth Dongle


Download the tool 
  • Kernel should be 4.X or above versions.
  • Download bdaddr from below website:
  • bdaddrtar.bz2
  • tar xvf bdaddrtar.bz2
  • cd bdaddr 
  • make



Usage

  The "bdaddr" application is generated which can be used to change MAC address of dongle.



  1. Insert dongle and make interface up 

hciconfig -i hci0 up

      2./bdaddr ==> it will show current mac address
  root@bt:# ./bdaddr
Manufacturer: Cambridge Silicon Radio (10)
Device address: 00:50:F2:7E:2F:9B
     
      3.To change mac address give new MAC address as below
         root@bt# ./bdaddr -i hci0 00:01:E3:64:DD:9B
Manufacturer: Cambridge Silicon Radio (10)
Device address: 00:50:F2:7E:2F:9B
New BD address: 00:01:E3:64:DD:9B

Address changed - Reset device now

     4.Re -connect the dongle it should show new MAC address.

Note: If any dependency error install BlueZ, otherwise not required.


  •  Install BlueZ
  •  http://www.bluez.org/download/
  •  tar xf bluez-5.46.tar.xz 
  •  cd bluez-5.46 
  •  ./configure --enable-test
  •  make 




Reference: 
http://blog.petrilopia.net/linux/change-your-bluetooth-device-mac-address/
http://www.hackgnar.com/2014/03/installing-latest-bluez-software-in.html

Loading a developmental kernel Snap


The command to load the kernel snap is :

#snap install Snapped 96boards-kernel_XXX_arm64.snap --dangerous

Once in a while there is error in loading the kernel, in that case below workaround can be used.

Get the name of  existing kernel snap

# snap list kernel-name

Back up the existing kernel

# cp /var/lib/snapd/snap/kernel-name-version1.snap ~/

Replace the developing kernel to current kernel snap.

# sudo cp <new kernel snap> /var/lib/snapd/snaps/kernel-name-version1.snap

Reboot the system and test it

# sudo reboot

If it doesnt boot up, restore the old snap.

# sudo cp kernel-name-version1.snap /var/lib/snapd/snaps/kernel-name-version1.snap

Installing Kernel header files in ubutntu



  1.  sudo apt-get install linux-headers-4.3.XX-generic
  2.  The header files will be installed in /lib/modules/4.3.XX-generic/build

Sunday 16 July 2017

How to open a cmd window in a specific location in windows 10 and windows 8?



  • Go to specific location.
  • Hold Shift key + right click on content space/ background of folder
  • Click on " Open command Windows here"


Monday 26 June 2017

Brief Explanation for UART RS232 SPI I2C


Reference : https://electronics.stackexchange.com/questions/37814/usart-uart-rs232-usb-spi-i2c-ttl-etc-what-are-all-of-these-and-how-do-th



Serial is an umbrella word for all that is "Time Division Multiplexed", to use an expensive term. It means that the data is sent spread over time, most often one single bit after another. All the protocols you're naming are serial protocols.

UART, for Universal Asynchronous Receiver Transmitter, is one of the most used serial protocols. It's almost as old as I am, and very simple. Most controllers have a hardware UART on board. It uses a single data line for transmitting and one for receiving data. Most often 8-bit data is transferred, as follows: 1 start bit(low level), 8 data bits and 1 stop bit(high level). The low level start bit and high level stop bit mean that there's always a high to low transition to start the communication. That's what describes UART. No voltage level, so you can have it at 3.3 V or 5 V, whichever your microcontroller uses. Note that the microcontrollers which want to communicate via UART have to agree on the transmission speed, the bit-rate, as they only have the start bit's falling edge to synchronize. That's called asynchronous communication.

For long distance communication (That doesn't have to be hundreds of meters) the 5 V UART is not very reliable, that's why it's converted to a higher voltage, typically +12 V for a "0" and -12 V for a "1". The data format remains the same. Then you have RS-232 (which you actually should call EIA-232, but nobody does.)

The timing dependency is one of the big drawbacks of UART, and the solution is USART, for Universal Synchronous/Asynchronous Receiver Transmitter. This can do UART, but also a synchronous protocol. In synchronous there's not only data, but also a clock transmitted. With each bit a clock pulse tells the receiver it should latch that bit. Synchronous protocols either need a higher bandwidth, like in the case of Manchester encoding, or an extra wire for the clock, like SPI and I2C.

SPI (Serial Peripheral Interface) is another very simple serial protocol. A master sends a clock signal, and upon each clock pulse it shifts one bit out to the slave, and one bit in, coming from the slave. Signal names are therefore SCK for clock, MOSI for Master Out Slave In, and MISO for Master In Slave Out. By using SS (Slave Select) signals the master can control more than 1 slave on the bus. There are two ways to connect multiple slave devices to one master, one is mentioned above i.e. using slave select, and other is daisy chaining, it uses fewer hardware pins (select lines), but software gets complicated.

I2C (Inter-Integrated Circuit, pronounced "I squared C") is also a synchronous protocol, and it's the first we see which has some "intelligence" in it; the other ones dumbly shifted bits in and out, and that was that. I2C uses only 2 wires, one for the clock (SCL) and one for the data (SDA). That means that master and slave send data over the same wire, again controlled by the master who creates the clock signal. I2C doesn't use separate Slave Selects to select a particular device, but has addressing. The first byte sent by the master holds a 7 bit address (so that you can use 127 devices on the bus) and a read/write bit, indicating whether the next byte(s) will also come from the master of should come from the slave. After each byte receiver must send a "0" to acknowledge the reception of the byte, which the master latches with a 9th clock pulse. If the master wants to write a byte the same process repeats: the master puts bit after bit on the bus and each time gives a clock pulse to signal that the data is ready to be read. If the master wants to receive data it only generates the clock pulses. The slave has to take care that the next bit is ready when the clock pulse is given. This protocol is patented by NXP(formerly Phillips), to save licensing cost, Atmel using the word TWI(2-wire interface) which exactly same as I2C, so any AVR device will not have I2C but it will have TWI.

Two or more signals on the same wire may cause conflicts, and you would have a problem if one device sends a "1" while the other sends a "0". Therefore the bus is wired-OR'd: two resistors pull the bus to a high level, and the devices only send low levels. If they want to send a high level they simply release the bus.

TTL (Transistor Transistor Logic) is not a protocol. It's an older technology for digital logic, but the name is often used to refer to the 5 V supply voltage, often incorrectly referring to what should be called UART.


Difference between USB and USB CDC and other USB standards



HID (Human Interface Device) generally requires no Drivers to be installed by the User
It is limited to 64 Bytes/ms (~64K/second) per endpoint used
It is guaranteed to get the timeslot because it uses INT transfers.

CDC (Comunication Device Class) requires drivers (INF file) to be installed and then simulates a serial port.It uses Bulk transfers so theoretically can have good bandwidth but is NOT guaranteed
There are also other code and packet overheads involved. USB CDC can work as UART.

Various USB standards

  • The USB 3.1 Specification released on July 26, 2013 and ECNs approved through February 15, 2017
  • USB 3.1 Appendix E:  Repeaters
  • USB 3.0 Adopters Agreement
  • On-The-Go and Embedded Host Supplement to the USB Revision 3.0 Specification Revision 1.1 as of May 10, 2012
  • Inter-Chip Supplement to the USB Revision 3.0 Specification, Revision 1.02 as of May 19, 2014
  • USB 3.1 Device Class Specification for Debug Devices as of July 14, 2015
  • USB Type-CTM Locking Connector Specification, March 9, 2016
  • USB Type-CTM Cable and Connector Specification Revision 1.2, March 25, 2016 and ECNs
  • USB Type-CTM Port Controller Interface Specification as of November, 2016
  • USB Power Delivery Specification Rev. 2.0, Version 1.3 is available at http://www.usb.org/developers/powerdelivery/
  • USB Power Delivery Specification Rev. 3.0, Version 1.1, January 12, 2017, and corresponding Adopters Agreement
  • USB Authentication Specification Rev. 1.0 with ECN and Errata through February 2, 2017


 There are 5 modes of USB data transfer, in order of increasing bandwidth: Low Speed (from 1.0), Full Speed (from 1.0), High Speed (from 2.0), SuperSpeed (from 3.0), and SuperSpeed+ (from 3.1); modes have differing hardware and cabling requirements. USB devices have some choice of implemented modes, and USB version is not a reliable statement of implemented modes. Modes are identified by their names and icons, and the specifications suggests that plugs and receptacles be colour-coded (SuperSpeed is identified by blue).



References : 
  •   WIki
  •   https://cscott.net/usb_dev/data/devclass/usbcdc11.pdf
  •   http://www.usb.org/developers/docs/
  • http://www.microchip.com/forums/m420851.aspx