Hacking a generic USB joystick using HIDAPI.

It has been a while since I posted something here. Lately I have been working on USB firmware and software applications. There are loads of things to post but have very less free time. I’ll post them when I got a free time.

What this article primarily talks about is on a method to communicate with the joystick using your own application. It may be to control a robot, who knows. I will be using a simple MFC application to communicate with the joystick.

In order to understand the article properly you should have at least a slight understanding about,

  1. MFC applications
  2. USB specifications
  3. HID class specifications
  4. C++

A helicopter view of how this communication works,

You have the device. A driver is needed to communicate with the device. The driver has something called IOCTLs which are used by the applications/libraries to communicate with the device. Ya, that’s enough.

HIDAPI is some sort of a library which is cross platform (i will be using it in windows though) and it will take care of all the IOCTL calls and provide us with an API to easily communicate with the device. In other words, we do not need to worry about specific IOCTL details, rather we just need to know how to use the API functions. HIDAPI uses the windows generic driver to communicate with the joystick or any other HID class USB devices. You can find HIDAPI home page here.

First thing I did was connecting the joystick to the pc and sniffing the USB packets using USBlyzer. After that I understood that there is an Interrupt Transfer which has 8 bytes of data. And it simply floods the USBlyzer window. I tried a bit to find the protocol but I haven’t had any luck. So I decided I will figure it out myself.

(more…)

Logic Analyzer on Stellaris LM4F120

It has been a while since I added something to the blog. These days I am working on a cheap wireless module, but it is giving me a lot of trouble due to duty cycle imperfections. Therefore I needed a logic analyzer to check the logic levels being transmitted and received.

I came across a few very useful websites which directed me to the product SLLogicLogger. You can find the product details here.

Make sure you adhere to all the guidelines given there, specially about the RB0 and RB1 pins which are not 5V tolerant.

One of the major issues of this project is that it is infact not a Logic Analyzer but a Logic Logger which can only scan the channels for a period of around 1.5ms. Which is very small period. So if the data rates that we use are really high we can get a good output. Lets say that our synchronization method is sending a stream of ‘1’s and ‘0’s with 1ms period, then this Logic Logger would not be able to assist us much.┬áBut for higher speeds this is really effective.

7 segment up counter for DE0-Nano

In my previous post I have mentioned about the 7-segment display that I soldered for my DE0-Nano board. Now it’s time to get a simple program going in it. Here I will be implementing a up counter in the FPGA fabric. Conventional truth tables and karnaugh maps have been used to derive the logic for this simple task. Also in this demo you will understand how to develop a design module by module and how to combine them together using VHDL.

LED-7-Segment-Display
(more…)

Connecting MSP430 and Stellaris Launchpad through NRF24L01

Last few weeks I have been working with RF modules to establish a wireless communication link between two systems. But most of the times my efforts were a failure. I had an MSP430 Launchpad, Stellaris Launchpad and two NRF24L01 modules. In order to check whether those wireless modules are working I had to setup a wireless communication link. I thought it would be easier for me if I used the available Stellaris and MSP launchpads for this task.

DSC04719

I started threads and followed some more on 430h and Stellaris forum.

http://forum.43oh.com/

http://forum.stellarisiti.com/

(more…)

D-flip flip with Set and Reset

Following is the VHDL code for the design of a D-Flip flop with asynchronous set and reset functions. Normally Set and Reset is used to determine the initial state of a Flip flop in order to prevent it starting off with some arbitrary state.

library IEEE;
use IEEE.std_logic_1164.all;

entity dff2 is
port (D, Clock, Reset, Set: in std_logic;
		Q, Qbar : out std_logic);
end entity dff2;

architecture dff2_arch of dff2 is
begin
p0: process (Clock,Reset,Set) is
variable state: std_logic;
begin
	if (Reset = '0') then
	state := '0';
	elsif (Set = '0') then
	state := '1';
	elsif rising_edge(CLock) then
	state := D;
	end if;
	Q <= state;
	Qbar <= not state;
end process p0; 
end architecture dff2_arch;

The same can be done using a signal instead of a variable as follows,

library IEEE;
use IEEE.std_logic_1164.all;

entity dff2 is
port (D, Clock, Reset, Set: in std_logic;
		Q, Qbar : out std_logic);
end entity dff2;

architecture dff2_arch of dff2 is
signal state: std_logic;
begin
p0: process (Clock,Reset,Set) is
begin
	if (Reset = '0') then
	state <= '0';
	elsif (Set = '0') then
	state <= '1';
	elsif rising_edge(CLock) then
	state <= D;
	end if;
	Q <= state;
	Qbar <= not state;
end process p0; 
end architecture dff2_arch;

Make sure you do the pin assignment correctly.

2

Thank you.

Programming a D-flip flop in VHDL

Following are few ways to code a positively edge triggered D Flip Flop in VHDL.

Method 1:

library IEEE;
use IEEE.std_logic_1164.all;

entity dff1 is
port (D, Clock : in std_logic;
		Q , Qbar : out std_logic);
end entity dff1;

architecture dff_arch of dff1 is
begin
p0: process (Clock) is
begin
if (Clock = '1') then
Q <= D;
Qbar <= not D;
end if;
end process p0;
end architecture dff_arch;

Method 2:

library IEEE;
use IEEE.std_logic_1164.all;

entity dff1 is
port (D, Clock : in std_logic;
		Q , Qbar : out std_logic);
end entity dff1;

architecture dff_arch of dff1 is
begin
p0: process is
begin
wait until (CLock = '1');
Q <= D;
Qbar <= not D;
end process p0;
end architecture dff_arch;

Method 3:( The most correct design)

library IEEE;
use IEEE.std_logic_1164.all;

entity dff1 is
port (D, Clock : in std_logic;
		Q , Qbar : out std_logic);
end entity dff1;

architecture dff_arch of dff1 is 
begin

p0: process (Clock) is
variable state: std_logic;
begin

if rising_edge(Clock) then
state := D;
end if;
Q <= state;
Qbar <= not state;
end process p0; end architecture dff_arch;

Pin configuration is as follows:

1

Thank you.

Configuring DE0-Nano EPCS64 flash device.

Similar to most of the FPGA devices available in the market today, the DE0-Nano also uses SRAM cells to store the configuration data it requires to operate correctly. Since SRAM is a volatile memory it will lose all the data once we power down the device. So whenever we power up the device it will read the configuration data from some other non-volatile memory element and reprogram the FPGA fabric.

DE0-Nano has a flash device named as EPCS64. It has 64Mbits capacity. This blog post will teach you how to program the EPCS64 flash device so that you can save your program in the chip indefinitely (theoretically).

  • Generate the .sof file by compiling your program.
  • Goto File > Convert Programming Files
  • Under ‘output programming file’, select ‘JTAG indirect configuration file’ as the programming file type.’
  • Select ‘EPCS64’ as the configuration device.
  • Give a file name and path.
  • Under ‘Input files to convert’ click on ‘Flash loader’.
  • Then click on ‘Add device’ button at the right side of the window.
  • Select ‘EP4CE22’ under ‘Cyclone IV E’ and click ‘ok’.
  • Under ‘Input files to convert’ click on ‘SOF data’.
  • Then click on ‘Add file’ button at the right side of the window.
  • Select you generated ‘.sof’ file which is generally it is located in the ‘output_files’ folder.
  • Finally click on generate button.

(more…)