<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>EmbLogic &#187; pankaj.e1</title>
	<atom:link href="https://www.emblogic.com/blog/author/pankaj-e1/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.emblogic.com/blog</link>
	<description>Embedded System and ARM Training</description>
	<lastBuildDate>Tue, 03 Mar 2020 13:00:06 +0000</lastBuildDate>
	<language>en-US</language>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.9.1</generator>
	<item>
		<title>usb</title>
		<link>https://www.emblogic.com/blog/03/usb-4/</link>
		<comments>https://www.emblogic.com/blog/03/usb-4/#comments</comments>
		<pubDate>Tue, 15 Mar 2011 11:56:28 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=581</guid>
		<description><![CDATA[Disconnect() In the disconnect function, it is also important to retrieve from the interface any data that was previously set with a call to usb_set_intfdata. Then set the data pointer in the struct usb_interface structure to NULL to prevent any &#8230; <a href="https://www.emblogic.com/blog/03/usb-4/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><strong>Disconnect()</strong></p>
<p>In the disconnect function, it is also important to retrieve from the interface any data<br />
that was previously set with a call to usb_set_intfdata. Then set the data pointer in<br />
the struct usb_interface structure to NULL to prevent any further mistakes in access-<br />
ing the data improperly</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/usb-4/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>usb</title>
		<link>https://www.emblogic.com/blog/03/usb-3/</link>
		<comments>https://www.emblogic.com/blog/03/usb-3/#comments</comments>
		<pubDate>Mon, 14 Mar 2011 11:45:43 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=576</guid>
		<description><![CDATA[probe function In the probe function the USB driver should initialize any local structures that it might use to manage the USB device. It should also save any information that it needs about the device to the local structure, as &#8230; <a href="https://www.emblogic.com/blog/03/usb-3/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><strong>probe function</strong></p>
<p>In the probe function the USB driver should initialize any local structures<br />
that it might use to manage the USB device. It should also save any information that<br />
it needs about the device to the local structure, as it is usually easier to do so at this<br />
time. As an example, USB drivers usually want to detect what the endpoint address<br />
and buffer sizes are for the device, as they are needed in order to communicate with<br />
the device.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/usb-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Standard Descriptors</title>
		<link>https://www.emblogic.com/blog/03/standard-descriptors/</link>
		<comments>https://www.emblogic.com/blog/03/standard-descriptors/#comments</comments>
		<pubDate>Sun, 13 Mar 2011 12:30:39 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=574</guid>
		<description><![CDATA[A Device Descriptor describes general information about a USB device. It includes information that applies globally to the device and all of the device&#8217;s configurations. A USB device has only one device descriptor.]]></description>
				<content:encoded><![CDATA[<p>A <strong> Device Descriptor</strong> <a name="70"></a> describes general information about a USB device. It includes information that applies globally to the device and all of the device&#8217;s configurations. A USB device has only one device descriptor.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/standard-descriptors/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>usb Driver</title>
		<link>https://www.emblogic.com/blog/03/usb-driver-3/</link>
		<comments>https://www.emblogic.com/blog/03/usb-driver-3/#comments</comments>
		<pubDate>Sat, 12 Mar 2011 12:38:37 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=564</guid>
		<description><![CDATA[Types of transfer Control Transfers Interrupt Transfers Isochronous Transfers Bulk Transfer Control transfer Control transfers are typically used for command and status operations. They are essential to set up a USB device with all enumeration functions being performed using control &#8230; <a href="https://www.emblogic.com/blog/03/usb-driver-3/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><strong>Types of transfer</strong></p>
<ul>
<li>
<ul>
<li><strong><a href="http://www.beyondlogic.org/usbnutshell/usb4.shtml#Control">Control Transfers</a></strong></li>
<li><strong><a href="http://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt">Interrupt Transfers</a></strong></li>
<li><strong><a href="http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous">Isochronous Transfers</a></strong></li>
<li><strong><a href="http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk">Bulk Transfer</a></strong></li>
</ul>
</li>
</ul>
<p><strong>Control transfer</strong></p>
<p>Control transfers are typically used for command and status operations. They are  essential to set up a USB device with all enumeration functions being performed using  control transfers. They are typically bursty, random packets which are initiated by  the host and use best effort delivery. The packet length of control transfers in low  speed devices must be 8 bytes, high speed devices allow a packet size of 8, 16, 32  or 64 bytes and full speed devices must have a packet size of 64 bytes.</p>
<p><a name="Control"></p>
<h1></h1>
<p></a></p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/usb-driver-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Usb driver</title>
		<link>https://www.emblogic.com/blog/03/usb-driver-2/</link>
		<comments>https://www.emblogic.com/blog/03/usb-driver-2/#comments</comments>
		<pubDate>Fri, 11 Mar 2011 12:36:09 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=559</guid>
		<description><![CDATA[Endpoints Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints occur at the end of the communications channel at the USB function. At the software layer, your device driver may send a &#8230; <a href="https://www.emblogic.com/blog/03/usb-driver-2/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><a name="Endpoints"></p>
<h1>Endpoints</h1>
<p>Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints  occur at the end of the communications channel at the USB function. At the software layer, your  device driver may send a packet to your devices EP1 for example. As the data is flowing out  from the host, it will end up in the EP1 OUT buffer. Your firmware will then at its leisure  read this data. If it wants to return data, the function cannot simply write to the bus as  the bus is controlled by the host. Therefore it writes data to EP1 IN which sits in the buffer  until such time when the host sends a IN packet to that endpoint requesting the data. Endpoints can also be seen as the interface between the hardware of the function device and the firmware running on the function device.</p>
<p>All devices must support endpoint zero. This is the endpoint which receives all of the devices  control and status requests during enumeration and throughout the duration while the device is  operational on the bus.</p>
<p></a></p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/usb-driver-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>usb driver</title>
		<link>https://www.emblogic.com/blog/03/usb-driver/</link>
		<comments>https://www.emblogic.com/blog/03/usb-driver/#comments</comments>
		<pubDate>Thu, 10 Mar 2011 12:39:21 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=550</guid>
		<description><![CDATA[All devices have an upstream connection to the host and all hosts have a downstream connection to the device. Upstream and downstream connectors are not mechanically interchangeable, thus eliminating illegal loopback connections at hubs such as a downstream port connected &#8230; <a href="https://www.emblogic.com/blog/03/usb-driver/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>All devices have an upstream connection to the host and all hosts have a downstream connection to the device.  Upstream and downstream connectors are not mechanically interchangeable, thus eliminating illegal loopback  connections at hubs such as a downstream port connected to a downstream port. There are commonly two types of  connectors, called type A and type B.</p>
<p>Type A plugs always face upstream. Type A sockets will typically find themselves on hosts and hubs. For example  type A sockets are common on computer main boards and hubs. Type B plugs are always connected downstream and  consequently type B sockets are found on devices.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/usb-driver/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>network driver</title>
		<link>https://www.emblogic.com/blog/03/network-driver-3/</link>
		<comments>https://www.emblogic.com/blog/03/network-driver-3/#comments</comments>
		<pubDate>Wed, 09 Mar 2011 12:46:27 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=545</guid>
		<description><![CDATA[struct net_device *alloc_netdev(int sizeof_priv, const char *name, void (*setup)(structnet_device *)); Here, sizeof_priv is the size of the driver&#8217;s &#8220;private data&#8221; area; with network devices, that area is allocated along with the net_device structure. In fact, the two are allocated together &#8230; <a href="https://www.emblogic.com/blog/03/network-driver-3/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>struct net_device *alloc_netdev(int sizeof_priv, const char *name,</p>
<p>void (*setup)(structnet_device *));</p>
<p>Here, sizeof_priv is the size of the driver&#8217;s &#8220;private data&#8221; area; with network devices, that area is allocated along with the net_device structure. In fact, the two are allocated together in one large chunk of memory, but driver authors should pretend that they don&#8217;t know that. name is the name of this interface.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/network-driver-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>network driver</title>
		<link>https://www.emblogic.com/blog/03/network-driver-2/</link>
		<comments>https://www.emblogic.com/blog/03/network-driver-2/#comments</comments>
		<pubDate>Tue, 08 Mar 2011 12:13:25 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=542</guid>
		<description><![CDATA[struct net_device *alloc_etherdev(int sizeof_priv); This function allocates a network device using eth%d for the name argument. It provides its own initialization function (ether_setup) that sets several net_device fields with appropriate values for Ethernet devices.]]></description>
				<content:encoded><![CDATA[<p>struct net_device *alloc_etherdev(int sizeof_priv);</p>
<p>This function allocates a network device using eth%d for the name argument. It provides its own initialization function (ether_setup) that sets several net_device fields with appropriate values for Ethernet devices.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/network-driver-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>network Driver</title>
		<link>https://www.emblogic.com/blog/03/network-driver/</link>
		<comments>https://www.emblogic.com/blog/03/network-driver/#comments</comments>
		<pubDate>Sat, 05 Mar 2011 12:28:44 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=531</guid>
		<description><![CDATA[struct sk_buff Designed to easily support encapsulation/decapsulation of data through the protocol layers. In addition to the data itself, an sk_buff maintains head : the start of the packet data : the start of the packet payload tail : the &#8230; <a href="https://www.emblogic.com/blog/03/network-driver/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><strong>struct sk_buff</strong></p>
<p>Designed to easily support encapsulation/decapsulation of data<br />
through the protocol layers.<br />
In addition to the data itself, an sk_buff maintains<br />
<strong>head :</strong> the start of the packet<br />
<strong>data</strong> : the start of the packet payload<br />
<strong>tail</strong> : the end of the packet payload<br />
<strong>end</strong> : the end of the packet</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/network-driver/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>socket function description</title>
		<link>https://www.emblogic.com/blog/03/socket-function-description/</link>
		<comments>https://www.emblogic.com/blog/03/socket-function-description/#comments</comments>
		<pubDate>Tue, 01 Mar 2011 12:26:51 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=514</guid>
		<description><![CDATA[int socket(int domain, int type, int protocol); The socket created is one end point of a communication channel. The domain parameter specifies the address family, the type parameter specifies the type of communication to be used with this socket, and &#8230; <a href="https://www.emblogic.com/blog/03/socket-function-description/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p><strong>int socket(int domain, int type, int protocol);</strong></p>
<p>The socket created is one end point of a communication channel. The domain parameter specifies the address family, the type parameter specifies the type of communication to be used with this socket, and protocol specifies the protocol to be employed.</p>
<p><strong><br />
</strong></p>
<p><strong>int bind(int socket, const struct sockaddr *address, size_t address_len);</strong></p>
<p>The bind system call assigns the address specified in the parameter, address, to the unnamed<br />
socket associated with the file descriptor socket. The length of the address structure is passed as address_len.</p>
<p><strong><br />
</strong></p>
<p><strong>int listen(int socket, int backlog);</strong></p>
<p>A Linux system may limit the maximum number of pending connections that may be held in a queue.Subject to this maximum, listen sets the queue length to backlog. Incoming connections up to this queue length are held pending on the socket; further connections will be refused and the client’s connection will fail.</p>
<p><strong>int accept(int socket, struct sockaddr *address, size_t *address_len);</strong></p>
<p>The accept system call returns when a client program attempts to connect to the socket specified by the parameter socket. The client is the first pending connection from that socket’s queue. The accept function creates a new socket to communicate with the client and returns its descriptor.</p>
<p><strong>int connect(int socket, const struct sockaddr *address, size_t address_len);</strong></p>
<p>The socket specified by the parameter socket is connected to the server socket specified by the parameter address, which is of length address_len. The socket must be a valid file descriptor obtained by a call to socket</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/03/socket-function-description/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>socket</title>
		<link>https://www.emblogic.com/blog/02/socket/</link>
		<comments>https://www.emblogic.com/blog/02/socket/#comments</comments>
		<pubDate>Mon, 28 Feb 2011 12:41:39 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=510</guid>
		<description><![CDATA[In sockets five main functions that r used are: socket() , bind(), listen(), accept() and close()]]></description>
				<content:encoded><![CDATA[<p>In sockets</p>
<p>five main functions that r used are:</p>
<p>socket() , bind(), listen(), accept() and close()</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/02/socket/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>parallel port</title>
		<link>https://www.emblogic.com/blog/02/parallel-port-2/</link>
		<comments>https://www.emblogic.com/blog/02/parallel-port-2/#comments</comments>
		<pubDate>Sat, 26 Feb 2011 12:45:01 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=504</guid>
		<description><![CDATA[After a driver has requested the range of I/O ports it needs to use in its activities, it must read and/or write to those ports. To this end, most hardware differentiates between 8-bit, 16-bit, and 32- bit ports.]]></description>
				<content:encoded><![CDATA[<p>After a driver has requested the range of I/O ports it needs to use in its activities, it must read and/or write to those ports. To this end, most hardware differentiates between 8-bit, 16-bit, and 32- bit ports.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/02/parallel-port-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Parallel port</title>
		<link>https://www.emblogic.com/blog/02/parallel-port/</link>
		<comments>https://www.emblogic.com/blog/02/parallel-port/#comments</comments>
		<pubDate>Fri, 25 Feb 2011 12:33:45 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=500</guid>
		<description><![CDATA[To use parallel port we need to allocate region using following  function struct resource *request_region(unsigned long first, unsigned long n, const char *name); We can also check whether region available or not by this function int check_region(unsigned long first, unsigned &#8230; <a href="https://www.emblogic.com/blog/02/parallel-port/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>To use parallel port we need to allocate region using following  function</p>
<p>struct resource *request_region(unsigned long first, unsigned long n, const char *name);</p>
<p>We can also check whether region available or not by this function</p>
<p>int check_region(unsigned long first, unsigned long n);</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/02/parallel-port/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>parallel port usage</title>
		<link>https://www.emblogic.com/blog/02/parallel-port-usage/</link>
		<comments>https://www.emblogic.com/blog/02/parallel-port-usage/#comments</comments>
		<pubDate>Thu, 24 Feb 2011 12:38:59 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=498</guid>
		<description><![CDATA[To test parallel port we can do the following step: Create a node by  mknod /dev/parlelport c 61 0 The module can now be installed, parlelport. You can check that it is effectively reserving the input/output port addresses 0x378 with &#8230; <a href="https://www.emblogic.com/blog/02/parallel-port-usage/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>To test parallel port we can do the following step:</p>
<ul>
<li>Create a node by  <code>mknod /dev/parlelport c 61 0</code></li>
</ul>
<ul>
<li>The module can now be installed, <code>parlelport</code>. You can check that it is effectively reserving the input/output port addresses <code>0x378</code> with the command:</li>
</ul>
<p><code> cat /proc/ioports</code></p>
<ul>
<li>To turn on the LEDs and check that the system is working, execute the command</li>
</ul>
<p><code> echo -n A &gt;/dev/parlelport</code></p>
<p>This should turn on LED zero and six, leaving all of the others off.</p>
<ul>
<li>You can check the state of the parallel port issuing the command:</li>
</ul>
<p><code> cat /dev/parlelport</code></p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/02/parallel-port-usage/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Memory management</title>
		<link>https://www.emblogic.com/blog/02/memory-management/</link>
		<comments>https://www.emblogic.com/blog/02/memory-management/#comments</comments>
		<pubDate>Fri, 04 Feb 2011 12:37:24 +0000</pubDate>
		<dc:creator><![CDATA[pankaj.e1]]></dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://emblogic.org/blog/?p=440</guid>
		<description><![CDATA[The Memory management unit consists of Segmentation unit and Paging unit. Segmentation unit allows the use of two address components, viz. segment and offset for relocability and sharing of code and data. •Segmentation unit allows segments of size 4Gbytes at &#8230; <a href="https://www.emblogic.com/blog/02/memory-management/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>The Memory management unit consists of<br />
Segmentation unit and<br />
Paging unit.</p>
<p>Segmentation unit allows the use of two address components, viz. segment and offset for relocability and sharing of code and data.<br />
•Segmentation unit allows segments of size 4Gbytes at max.<br />
•The Paging unit organizes the physical memory in terms of pages     of        4kbytes size each.</p>
<p>Paging unit works under the control of the segmentation unit, i.e. each     segment is further divided into pages. The virtual memory is also organizes in terms of segments and pages by the memory management unit.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.emblogic.com/blog/02/memory-management/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
