Logic analyzer is a handy tool for hobbyists. There are numerous occasions we come across scenarios where we doubt whether the module that we connected is not working or our SPI/I2C signals are wrong. Then all we tell to ourselves is “eeeerrr I wish I had a logic analyzer”. I came across the same scenario several times, finally decided to buy a logic analyzer.
There are many EXPENSIVE logic analyzers available by many suppliers. I’m sure that they work flawlessly and they are really accurate. But I cannot afford them. So I went to E-Bay and typed “Logic Analyzer” and filtered “Lowest Price First”. I selected the product below. It is just 11$. There are few logic analyzers for 9$ also (Damn I didn’t see!!!) I did not think twice, I bought it and waited a few weeks. I was not sure whether it will work.
In a world where all the developers are fogged under IDEs this post might sound a bit obsolete. But when it comes to highly demanding embedded applications the Electronics Engineers need unlimited access to hardware. Then we will have to rethink whether the flexibility we required is provided by the “Expensive” IDEs.
This blog post is an aggregation of information I found through following sites. I took time to repost them here to give them wider audience. They are wonderful references.
I tested the whole system under Ubuntu 14.04 LTS x64 OS. It worked perfectly. Mostly I followed the steps provided by the link 1. But some parts were carried out in a different way. I still did not try any debugging. In this post it will be about compiling and flashing a simple sample firmware. (more…)
Hello once again. It has been a while since I updated any thing on the blog. It was not because there is nothing for me to update on the blog, but because I have very less time to work on the blog articles lately. This post, as the topic implies, will consider about one of the trivial technique that Embedded programmers should understand nowadays. That is how to connect the device using USB.
Even though there are millions of standalone embedded devices, there are tens of millions of embedded devices which eventually will come across a state where it should be connected with a PC. There are various ways to perform this, for example using WiFi, Bluetooth, Serial, Parellel, etc.. But among all these technologies most popular and most effective communication method would be through USB. Nowadays there are plethora of devices which implement USB communication.
In order to understand USB, I recommend reading following two websites,
Texas Instruments chips are renowned for their low power operations. In this example I will go through basics of the hibernate module available with Stellaris devices which enables the user to put the device i low power mode. This module becomes trivial in low power consumption demanding applications. They claim that the processor only consumes around 6 micro amperes of current when it is configured to work in the hibernate module. Within this article I will refer to the datasheet of the device where applicable.
It is fairly easy to use the hibernation module in the Stellaris devices through their “Peripheral driver library”. Also the module is very well explained in the datasheet. So I recommend everyone to go through the datasheet and understand the behavior of the module prior to coding. At-least, that is my approach. The hibernate module related information can be found in Chapter 7.
The Stellaris launchpad PWMs will be deceiving if you start the design by reading ‘Stellaris® Peripheral Driver Library’ instead of the “LM4F120H5QR” datasheet. You will assume that it has hardware PWMs and you will directly use the PWM APIs available in the driver library. Unfortunately this is not the case with the launchpad. It does not have seperate hardware PWM modules but it has timers which can be configured as PWMs. I will be explaining how to configure the PWM modules available in timer0 andtimer1 to drive the R,G,B LEDs available in the launchpad.
First thing you need to understand is the architecture of the Timer modules. These timer modules contain six 16/32 bit timers and six 32/64 bit timers. Each of these twelve timers can be further divided into two independent timers named as TimerA and TimerB. These can be configured to operate separately or can combine.
a 32 bit Timer0 has 16 bit Timer_A and 16 bit Timer_B, a 64 bit Timer1 has 32 bit Timer_A and 32 bit Timer_B. Refer to the Chapter 11 of the datasheet for more information.
Then you need to know what are the pins connected with the Launchpads LEDs and whether we can drive them using the PWM signals. If you refer to the Stellaris Launchpad Pinmaps, you will understand that PF_1, PF_2 and PF_3 will be respectively connected to RED, BLUE and GREEN LEDs.
Also if you refer to Table 11-1, Table 11-2 and Table 10-2 in the datasheet you will understand that
PF_1 can be driven through T0CCP1 (Timer 0 Timer B),
PF_2 can be driven through T1CCP0 (Timer 1 Timer A) and
PF_3 can be driven through T1CCP1 (Timre 1 Timer B).
That is all the hardware information you need to know. After that you need to go through the ‘Stellaris® Peripheral Driver Library’ to understand how to configure the Clocks, Timers and GPIO pins. (more…)
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,
HID class specifications
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.
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.