While writing posts for my Raspberry Pi tutorials, I needed an easy and lightweight application to capture screen content. There are many options available for Linux including Gimp, gnome-screenshot and KSnapshot for KDE but I wanted something which I could use through the command line (because I just started scripting and it is kind of cool to throw commands at the terminal). So I grabbed the install package for (SCReenshOT) and started experimenting with it. It is lightweight, about 800kB and is customisable to store images in a variety of formats and resolutions.
Downloading the package Open a terminal window and write sudo apt-get install scrot and provide the user password. Application data will be downloaded and Scrot installed. Invoking Scrot The application can be called from the terminal by calling scrot option argument where argument is the target file name. If an argument isn’t provided, a date-stamped file will be saved in the working directory. Using Scrot To capture the whole screen after a delay of 1 second and save it with the name “image.png” write (Here “1” denotes the time delay in seconds.
You may increase it if you want to arrange windows on your screen before taking a snapshot) scrot -d 1 image.png. A credit card sized board with a Broadcom 700MHz ARM11 processor, 512MB of RAM, a dedicated GPU, USB 2.0, Ethernet, HDMI, Composite Out and OTG. Intended to be used as a tool to teach computer programming to school students, the Raspberry Pi has been put to many applications outside the classroom. Being relatively cheap compared to other single board computers, Raspberry Pi makes it possible to afford failure. After all the buzz surrounding the Pi, I recently bought a board for myself, the Model B, Revision 2.0. It came in a small box which much to my delight was the colour of raspberries. I will be using the term “Raspberry Pi”, “Raspi” and “Pi” interchangeably in this post.
It indeed comes in a box which is the colour of raspberries. Unfortunately, using the Raspberry Pi isn’t an out-of-the-box affair. There are certain hardware prerequisites which need to be met before the Raspi can be put to use. This post is an introduction to the Raspi and the minimum hardware you will need to get the Pi up and running.
Things you will need,. 5V DC adapter with a microUSB plug – The Pi receives power from a 5V DC adapter which connects to the onboard microUSB plug. The recommended power adapter for the Pi is rated at 5V, 700mA (preferably 1A). You may use your mobile phone charger after confirming its rating and load characteristics. Some cheap chargers although rated appropriately fail to deliver the maximum current at the fixed voltage of 5V.
So choose accordingly. The charger I am using for my set up is repurposed from an old Samsung mobile phone and is rated at 5V and 800mA. USB Keyboard and Mouse – As the Pi runs customised Linux distributions and majority of user interactions either take place using the terminal or the GUI, a keyboard and a mouse is indispensable. These connect to the onboard USB ports on the Pi. I am using a Logitech MK200 USB keyboard and mouse.
SD Card – The operating system image running on the Raspi is stored on an external SD card. The minimum required SD card for stable operation of the Pi is a 4GB Class 4 SD card. Class 6 and Class 10 cards are known to have not performed well with the Pi. You can also use a microSD card with a SD card adapter. I am using a SanDisk 16GB microSD card with a Kingston SD card adapter.
A High Definition TV with HDMI input or a standard TV set with composite video input – The Raspi is capable of generating full HD 1080p graphics using the onboard GPU. To fully achieve the graphical capabilities of the Pi you will need a HDTV/monitor with an HDMI input. However, you may also use the composite video out on the Pi with loss in resolution in conjunction with a standard TV set. I am using a Samsung S22B370H LED monitor with my Pi. Apart from the above things, you may need,. Ethernet Cable – The Pi supports 10/100 Ethernet (RJ45).
So if you want to connect your Pi to the internet use an ethernet cable to attach your Pi to the internet router or a laptop with internet sharing enabled. USB Hub – Since you have utilized all the available USB ports available on the board by connecting the keyboard and mouse, you require a USB hub if you wish to connect other USB devices to the Pi.
Protective Case – Careless removal of cords and uneven installation of the SD card may spoil board contacts and since it is a six layer board, debugging track failures becomes difficult. So enclosing your Raspberry Pi in a protective casing prevents it from such unforeseen damages. Multiple SD cards – As the Pi boots the operating system image from an external SD card you may wish to keep several SD cards with different install images handy for easy swapping of operating systems. That’s it for now. I will write more on how to set up your SD card with an operating system image in the next post.
I undertook a real fun project in the December of 2011. Today, when shuffling through my project repositories, I found its schematic files and source code. It is fantastic! It allows a person to write text, draw images and create super cool effects in the air. Air printing. Or more closely related to light painting.
Drivers are the property and the responsibility of their respective manufacturers, and may also be available for free directly from manufacturers' websites. Sciologness.com is not responsible in any way for the performance of or issues caused by any third-party drivers.Drivers may also be available for free directly from manufacturers' websites. The Sciologness.com™ agent utility uses data collection technology to conveniently update multiple PC drivers. 
I named it the PicWand, back then. All you need is a camera with low shutter speed, a computer and the PicWand. The hardware of the PicWand is simple and expandable.
It consists of strip of 8 RGB LEDs, one 74HCT164 shift register and an AVR ATtiny44 microcontroller. It has two onboard LM1117 5.0 volt regulators and can be powered by a single 9V battery. Each RGB LED requires about 120mA of currrent (40mA.3), so total of eight, when lit simultaneously requires about 960mA. The 1117 provides regulated output up to 800mA current draw. So, using two regulators on the same board made sense as it allows me to achieve unmatched brightness levels. Multiple strips of the PicWand PCB can be connected to each other.
The controllers interact over the I2C bus and all the strips share the common voltage supply and ground. So the design can be extended to a maximum of 127 (limited by the 7-bit I2C address) strips all connected together to form one huge wand with each RGB LED individually addressable. The software model is simple. The content to be displayed is broken up into pixels and each RGB LED represents one pixel.
The LEDs are then multiplexed to display all the pixels in one column of the content. As the PicWand is moved laterally in front of a low shutter speed camera, the wand displays all the pixels in the subsequent columns.
At the end of the shutter time, an entire 512 color image is obtained. I tested the PicWand by writing my own name.
The shutter speed was set to 8 seconds and each color in the RGB LED was varied across 8 intensity levels using PWM techniques. The content to be displayed is stored in the flash memory of the microcontroller. You can grab a copy of the schematic and the code files from my Github page.
So the other day, I explored the JTAG bus interface which is frequently found in CPLDs/FPGAs and is most of the times the sole method of programming and debugging them. It is a powerful interface and very easy to use.
I intend to write about the interface and the protocol used for documentation purposes and knowledge sharing. JTAG (Joint Test Action Group) started primarily as a debugging interface for CPLDs or more commonly boundary scan testing, which is explained later. The simplest implementation of the JTAG interface requires 4 signal wires, primarily. TDO (Test Data Out) – This is output signal from the target in response to the test query. TDI (Test Data In) – This is the input signal for the target carrying the test query. TCK (Test Clock) – This is the synchronization clock signal.
TMS (Test-Mode Select) – This controls the TAP state, explained later. Signals Explained. TCK – is the JTAG clock signal. The other JTAG signals (TDI, TDO, TMS) are synchronous to TCK. So TCK has to toggle for anything to happen (usually things happen on TCK’s rising edge). TMS – Inside each JTAG IC, there is a JTAG TAP controller. The TAP controller is mainly a state machine with 16 states. TMS is the signal that controls the TAP controller.
The TAP state diagram can be easily found in data-sheets of several JTAG ICs.The little numbers (“0” or “1”) close to each arrow are the value of TMS to change state. So for example, if a TAP controller is at state “Select DR-Scan” and TMS is “0” and TCK toggles, the state changes to “Capture-DR”. TDI and TDO – These signals carry the query and its response respectively. Referring to the TAP state diagram, Shift-DR and Shift-IR are the states where the query is generally pushed and Shift-DR is the state where the response is collected. The TDI and TDO are daisy-chained. That is, with the Shift-DR size equal to 1-bit, data sent through the TDI starts coming back through the TDO after one clock pulse. Hence, when a response is to be collected from Shift-DR, clock pulses are sent to receive the response on the TDO.
For example, if the Shift-DR size is 32 bits, 32 pulses are sent to completely receive the response of the JTAG query. Registers Each JTAG IC has one instruction register (IR) and multiple data registers (DR).
Each instruction to the IR selects a different data register whose value is shifted out as explained above. For example, a 8-bit IR can select up to 256 DR, if available. The length of each DR and IR registers can be found from the.bsdl file of the specific JTAG IC. Instructions The IR registers take in specific intructions which are listed in the.bsdl file of the JTAG IC.
Remember how you tried endlessly to blow off the last candle on your birthday cake? And it was a daunting task with everyone around me waiting for the candle to blow off and finally eat the cake. This design idea lets you measure the intensity of your blow. The design is simple, connect the thermistor and supporting resistors and make the micro controller read analog values. The magic lies in the algorithm used in the code.
It is the one of the best I have written so far and the maybe the fastest algorithm(in terms of time spent to think) I have written, less than an hour with the client over my head. R1 is used to heat the thermistor TR1. Resistor R2 and the thermistor TR1 form a resistor divider network used to monitor the temperature variations. Typical values of resistors are, R1 = 47 ohms, R2 = 100 ohms. When air blows over the thermistor, it cools the thermistor, increasing the voltage at the junction. The voltage at this junction is monitored continuously by the MCU’s ADC channel.
In my design, I use the thermistor to measure the pressure/force of my blow. So when somebody blows on the sensor, I serially output the intensity of the blow on a scale from 0 to 200 (values less than 20-30 are ignored as they are caused by ambient changes).
Potential applications include use in breath sensor technologies with use of high quality thermistors and regulating air flow in instrumentation applications. To get a copy of the code. It was written for the Arduino but can be used with any micro controller.
The comments make the code self explanatory. Update: – An application of this blow sensor made by me and my friend, is on display at Ambience Mall, Gurgaon, India starting this Saturday, October 22, 2011 in collaboration with, Intel and Hindustan Times. Blow on the sensor to launch a virtual Diwali rocket on a huge LED screen. If your blow is powerful enough, the rocket would be fired else, keep on trying. It could win you prizes too.
Be there to experience it. Have a safe and cracker free Diwali.
I have written a port of the for the TI Stellaris EK-LM3S811 Evaluation board which runs on an ARM Cortex-M3 processor. The library is extensively used when connecting SD Cards to embedded systems. It is freely available under the GNU License. It consists of a File I/O layer and Disk I/O Layer in which the former is constant across all platforms while the latter is specific to a micro-controller. Disk I/O layer specifies the board pins, clocks and timers which are to be used. The board pins I have used are:.
SSIClk (Pad No. Eight) connected to SCK Pin of SD Card. SSIRx (Pad No. Ten) connected to DO of SD Card.
SSITx (Pad No. Eleven) connected to DI of SD Card. PC4 (Pad No. Five) connected to CS of SD Card.
The files can be downloaded from. I have also supplied the makefile which takes care of all the compilation tasks provided your toolchain is set up as described. Steps to use the files in your project. Copy all the files in to your project folder. Include the “ff.h” and “diskio.h” header files in your code.
Refer the ELM – FatFs library reference for writing your program in “main.c”. Compile the program. I implemented the hash generation algorithm on the Arduino. The algorithm is available freely by RSA Data Security Inc.
Subject to some usage restrictions. The algorithm files are written in C. They have to be ported to run on the Arduino, which basically involves changes in the variables used in the algorithm. This 128 bit hash is handled with utter ease by the 8 bit AVR core on the Arduino. It takes a string as the input serially over the Arduino IDE Serial Monitor.
The return value is the MD5 hash computed on the 16MHz Arduino processor. The complete step by step algorithm can be found. I intend to use it later in my projects for security enhancements and error detection and of course.
Click to download source code and library files used in this project. The feature to remap pins of an ARM processor sounds cool. But it can be bothersome at times, if you configure pins the wrong way. The same happened with me which almost bricked my TI Stellaris LM3S811 Evaluation Board.
I accidentally configured the JTAG pin, PC0, which was the TCK pin for the JTAG peripheral, to be a GPIO pin. I uploaded the code onto the board and it ran like a charm for my application. But unknowingly, I had done changes which would prevent me from uploading new code on the board.
I had bricked it. The Reason:- The LM3S811 Evaluation board uses a PCUSBFT2232JTAGMCU interface. Which basically means, all upload and download of code onto the MCU is done through the JTAG interface. The code reconfigured the JTAG pin to be a GPIO, disabled the JTAG peripheral of the MCU and would not let me upload any code. Even after reset, the pin would lose its JTAG functionality whenever the command to remap would be executed. And this happened way too early in program execution(within microseconds) as the command was the fourth statement in my code. So yes, the computer interface was no longer valid.
What I Tried:-. Knowing other ARM processors could be interfaced using an UART connection, I tried to do the same to upload new code on my device. But a drawback of Stellaris microcontrollers, or infact the Stellaris Bootloader is that it doesn’t allow you to upload code using UART once the bootloader is put on the device.
If you want to use it, it needs to be specified in the startup.c file, which I hadn’t done. So I had no luck.
The Stellaris Board has an onboard 20 pin JTAG connector. I installed OpenOCD to somehow do hardware debugging to stop the controller before it reconfigures the pin. Failed again. Reason being, first, the JTAG would use the the same TCK pin which I had reconfigured, and second, the most important, the JTAG connector on the Stellaris board is OUTPUT only.
It can only be used to program or debug another device. Next I looked up the TI E2E Community (it is great!) for solutions.
There I found a post discussing a similar problem. The person instructed to halt the microcontroller immediately after reset and then try.
In all MCU, there is time gap between the reset button being pressed and code execution starting. It was a “hit and trial” method (worked in some cases) in which I would erase the flash memory immediately after reset. I tried doing this for almost four hours. But had no luck since the reconfiguration took place very early in my code. I decided to post my query on the TI E2E Community. I waited for a response for hours and after some discussion on the forum, was finally blessed with a solution, though not a complete one. The Solution:- In my code, the first statement selected the clock I wanted to use, the second initialized my display adapter, the third configured the pin PC5 and the fourth, and the one which should always be avoided, configured the pin PC0.
The main motive was to halt program execution just before the reconfigure takes place. As instructed on the forum, if I could somehow stop the display initialization and come up with an error at that point, program execution would stop. But how to do it? The guy on the forum told me to pull out the display from the board I didn’t do that. Learning how the display was connected to the the MCU, I figured out how it could be done.
The display on the Stellaris Eval Board uses the I2C interface to communicate with the processor. I decided to pull the SCL or the clock pin of the I2C low and connected it to GND using a jumper. As there was no clock to the display, it wouldn’t initialize, and program execution would halt. Job Well Done:- I connected the modified board to my computer.
Pressed reset, and Eureka! The program execution did stop before the pin could be reconfigured and I successfully uploaded the new code on the board. Things I Learnt:-. Use the ARM Pin mapping feature cautiously. Always add a delay before you set up the peripherals in your program code.
Atleast 500ms. This might sound silly, but when you need to halt the controller, you can do it in that time or else nothing can be done. Specifically for all Stellaris microcontrollers, enable UART support in the startup.c file. You never know when you will need it. The TI E2E Community is far more helpful than the official TI support.
The TI support replied to my problem three days after I posted it, it had been fixed by then. You will find some great people on the community. Never lose hope. It took me two days to finally make it work, again. I was introduced to the open source integrated development environment Eclipse by my friend Shan. Since then, I have shifted all my development routines for Arduino, Python and now ARM onto Eclipse. It is the best IDE I have used so far which supports almost everything, all programming languages, hardwares and toolchains.
The post is a simple walkthrough to making your first ARM project on Eclipse Helios on a Mac running OS X 10.7(the walkthrough is also applicable to previous generation OS X). I am using Helios.
Yes, it is old. A new version is already out. But some of the plugins we need to use, which I shall be explaining later in this post, still run on Helios.
The Basics Eclipse CDT is a C/C development IDE based on Eclipse (which defaults to Java development). CodeSourcery Lite is GCC-based ARM toolchain which provides all the basic ingredients (compiler, assembler, archiver, linker, libraries, newlib, binutils, etc.) in console based executables. The best thing about CodeSourcery is that they also offer commercial solutions which result in quarterly updates to the Lite tool-chain also. This way you always stay inline with the latest GCC developments.
First let’s have a look at the pre-requisites. You will need the latest version of Apple Developer Tools which include Xcode, Interface Designer, Instruments etc. And can be download from the Mac App Store. It is needed for the initial building of the toolchain which requires gcc, binutils and make. If you do not want to install the Developer Tools package, you will have to download and install these components individually. Google will help you. Let’s start now.
Step 1 – Install Eclipse Download and install the Eclipse IDE from. Eclipse Helios. The download page would provide you with a variety of flavors for the IDE. All of them are useful sometime or the other and can be ported to different versions using plugins. So go for the “Eclipse IDE for C/C Developers”. It would have all the functionality needed to set up the toolchain.
Step 2 – Install Eclipse Plugins – Fueling up Eclipse This step involves adding the necessary plugins to Eclipse which are needed to successfully compile an ARM application. Eclipse CDT. Go to Help Install New Software. In the dialog which appears, type “; in the Work With text area.
Press enter. You will get a window as shown below.
Select both the choices and click on Next. Accept the license agreement and continue with the installation. Once the installation is complete, restart Eclipse. Step 3 – Install CodeSourcery This step can be put as the most time consuming and mind boggling of the entire process.
It took me more than 10 hours to get it working correctly. Thanks to I was able to get it up and running in less than 30 minutes. Ensure again, you have the Apple Developer Tools installed. Point your browser to Snyder’s github.com. Click on the top right “Downloads” button and download the.tar.gz archive. This is isn’t the toolchain, but a very important makefile written by Snyder that can be used to conveniently build everything from sources, by automating all steps from downloading, compiling and installing the binaries.
mkdir -p $HOME/Work/ – directory for saving all the downloaded content. This won’t contain the installed toolchain. Just it’s.tar archive. cp $HOME/Downloads/jsnyder-arm-eabi-toolchain-.tar.gz $HOME/Work/ – copy the downloaded archive. cd $HOME/Work/.
Fullscreen Support Eclipse Helios And Indigo For Mac Download
tar xzvf jsnyder-arm-eabi-toolchain-.tar.gz – extract the downloaded/copied archive. cd $HOME/Work/jsnyder-arm-eabi-toolchain-. sudo port install mpfr gmp libmpc texinfo – this will download and build the GMP and MPFR packages. It will take a few minutes for this step to complete.
sudo make install-deps. mkdir -p $HOME/arm-cs-tools/pin – create destination folder for the toolchain.
export PATH=$HOME/arm-cs-tools/bin:$PATH – add the destination folder to the PATH variable. Be sure not to skip this step and step 8, otherwise the procedure will fail. make clean. sudo CC=clang make cross-binutils cross-gcc cross-g cross-newlib – builds the final toolchain. It will take about 30 minutes for complete installation. sudo make cross-gdb – builds and installs the debugger.
Close Terminal. Open Terminal. Type “ open.bashprofile”.
In the TextEdit windows which appears, add to the bottom of the text contents – export PATH=$HOME/arm-cs-tools/bin:$PATH. Close the window.
Logout from the Terminal. Restart Terminal. Type echo $PATH and in the variables which appear, /Users//arm-cs-tools/bin should be present. Another way to ensure you have successfully installed the toolchain and added it to your SYSTEMPATH is to type “ arm-none-eabi-gcc –version“.
You should get something like this. Arm-none-eabi-gcc (GCC) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If you are not getting this message, you have missed out some steps above. Delete the folder arm-cs-tools in your HOME folder and repeat Step 3 again.
Step 4 – Firing up Eclipse Now that the plugins have been installed and the toolchain set up, it is time to write our first ARM code. But before that, one thing to note is that Eclipse doesn’t pick up its PATH variables from the bash directly or rather there is a flaw in Eclipse for Mac. It took me a while to figure this out. So the way out is to edit the proprietary $HOME/.MacOSX/environment.plist file.
But an easer way out, is to start Eclipse from the Terminal directly. This way, the PATH we created in our.bashprofile script will be automatically added to Eclipse’s PATH variables. To do that,. Open Terminal. Go to the directory where Eclipse was installed or its archive unpacked. In my case it was in the Applications folder, so I had to type “ cd /Applications”. Type “ cd eclipse”.
Type “open eclipse” And you will be presented by the ever beautiful, Eclipse IDE. Yes, it is beautiful. Step 5 – Writing your first ARM Application. Open your workspace. Go to File. Save the project contents. Go to Project Processor: cortex-m3.
Additional Tools: Uncheck Create Flash Image. ARM Sourcery Mac OSX GCC C Linker General. Uncheck all the boxes. Click on Apply, and press OK to close the Project Properties window. Go to Project Build Configurations Set Active and chose Debug.
Go to Project Build Project. This should compile and build project files for debugging of your project.
Go to Project Build Configurations Set Active and chose Release. Go to Project Build Project.
This should compile your project and build the.hex and.elf files which can be then uploaded to your micro-controller. If build of these files fails, you have not installed the toolchain properly or your PATH variables are incorrect. Hope this post helps you setup your own ARM toolchain. I took to writing this post because I couldn’t find any which instructs on how to set up an Open Source ARM toolchain on a Mac and specifically on OSX 10.7. It took me a total of 36 hours to get this toolchain working.
Why not use KEIL instead? First reason, it is paid and my lab doesn’t allow me to use pirated software. Second, I cannot purchase it. It is $1500 for a single user license. Why pay such a price when you can get all those features for free. All Hail the Open-Source!