Square Thoughts

an engineering student's blog

Using Scrot (SCReenshOT) and Screen Grabs on the Raspberry Pi

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 Scrot (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
Full Screen Capture

Full Screen Capture

To capture a selected window or selected portion of the screen use

scrot -s image.png
Selected window capture

Selected window capture

 

Arbitrary Screen Capture

Arbitrary Screen Capture

Need more information? Use the command

man scrot

for a list of available options.

 

Raspberry Pi 101 – Lesson 1 – Getting Started

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.

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,

  1. 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.
  2. 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.
  3. 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.
  4. 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,

  1. 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.
  2. 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.
  3. 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.
  4. 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.

PicWand – an easy to use Air Printing Technique

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. Yes AIR. Air printing. Or more closely related to light painting. 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. Why two? 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.

TI India Analog Design Contest 2011 – Entry Video

This is our entry to the TI India Analog Design contest 2011.

JTAG Simplified

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

  1. TDO (Test Data Out) – This is output signal from the target in response to the test query.
  2. TDI (Test Data In) – This is the input signal for the target carrying the test query.
  3. TCK (Test Clock) – This is the synchronization clock signal
  4. TMS (Test-Mode Select) – This controls the TAP state, explained later.

Signals Explained

  1. 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).
  2. 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”.
  3. 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. The most common of them grabbed from a .bsdl file are

attribute INSTRUCTION_LENGTH of EP1C3T100 : entity is 10;

attribute INSTRUCTION_OPCODE of EP1C3T100 : entity is
  "BYPASS            (1111111111), "&
  "EXTEST            (0000000000), "&
  "SAMPLE            (0000000101), "&
  "IDCODE            (0000000110), "&
  "USERCODE          (0000000111), "&
  "CLAMP             (0000001010), "&
  "HIGHZ             (0000001011), "&
  "CONFIG_IO            (0000001101)";

attribute INSTRUCTION_CAPTURE of EP1C3T100 : entity is "0101010101";

attribute IDCODE_REGISTER of EP1C3T100 : entity is
  "0000"&               --4-bit Version
  "0010000010000001"&   --16-bit Part Number (hex 2081)
  "00001101110"&        --11-bit Manufacturer's Identity
  "1";                  --Mandatory LSB

attribute BOUNDARY_LENGTH of EP1C3T100 : entity is 339;

Querying the JTAG Chain

Whenever the JTAG IC powers up it may end in any TAP state. Hence, it is mandatory to get it to a known state. One such method which is guaranteed to toggle the TAP state to Test-Logic-Reset is to hold TMS high for five clock cycles.

  1. Set TMS high.
  2. Send minimum of five clock cycles.
  3. Set TMS low.

1. Count number of ICs on the JTAG chain

One important IR value is the “all-ones” value. For the CPU that would be 11111 and for the FPGA, that’s 1111111111. This value corresponds to the mandatory IR instruction called BYPASS. In bypass mode, the TAP controller DR register is always a single flip-flop which does nothing besides delaying the TDI input by one clock cycle before outputting to TDO.

One interesting way to use this BYPASS mode is to count the number of ICs that are present in the JTAG chain.
If each JTAG IC delays the TDI-TDO chain by one clock, we can send some data and check by how long it is delayed. That gives us the number of ICs in the chain.

2. Identify ICs on the JTAG Chain

The IDCODE instruction is used to identify ICs on the JTAG chain. The IDCODE instruction is automatically executed once the TAP state is forced to Test-Logic-Reset i.e the IDCODE data register appears on the TDO line. It is usually 32-bits long.

  1. Go to Test-Logic-Reset.
  2. Go to Shift-DR.
  3. Shift out 32 bits of data onto the TDO line by passing 32 clock pulses. LSB comes out first.

Similarly, other instruction can be passed to the IR and response read from the Shift-DR TAP state.

Boundary Scan Testing

This was the primary purpose of the JTAG interface when it was launched. In the boundary scan mode, the DR chain goes through each IO block and can read or hijack each pin.

Boundary-scan can be used even while a device is otherwise running. So for example, using JTAG on an FPGA, you can tell the status of each pin while the FPGA is running. The SAMPLE instruction is used in running a boundary scan. The .bsdl file lists the size of the boundary scan chain and the various pad configurations. In the .bsdl above, the length is 339 bits listed in the last line. Each pin use an IO pad on the IC die. Some IO pads use one, two or three bits from the chain (depending if the pin is input only, output with tri-state, or both). Also some registers correspond to IO pads that may not be bounded (they exists on the IC die but are not accessible externally). Which explains why a 100 pins device can have a 339 bits boundary-scan chain.

attribute BOUNDARY_REGISTER of EP1C3T100 : entity is
  --BSC group 0 for I/O pin 100
  "0   (BC_1, IO100, input, X)," &
  "1   (BC_1, *, control, 1)," &
  "2   (BC_1, IO100, output3, X, 1, 1, Z)," &

  --BSC group 1 for I/O pin 99
  "3   (BC_1, IO99, input, X)," &
  "4   (BC_1, *, control, 1)," &
  "5   (BC_1, IO99, output3, X, 4, 1, Z)," &

  ...
  ...
  ...

  --BSC group 112 for I/O pin 1
  "336 (BC_1, IO1, input, X)," &
  "337 (BC_1, *, control, 1)," &
  "338 (BC_1, IO1, output3, X, 337, 1, Z)" ;

This lists all the 339 bits of the chain, and what they do.
For example, bit 3 is the one that tells us what is the value on pin 99.

Querying the boundary scan chain is straightforward.

  • Go to Shift-IR state.
  • Shift in SAMPLE instruction with TMS low.
  • Go to Exit1-IR.
  • Go to Shift-DR.
  • In our case, the data register is 339 bits long, Read the contents of the Shift-DR over TDO by sending 339 clock pulses with TMS low.

Using the JTAG interface, is pretty simple. It is basically a serial interface with a ‘cool’ name. You shift out a query and shift in the response. Knowledge of this interface is essential as its use is increasing day by day. Almost every microprocessor now uses it as a primary hardware debugging interface.

Blow, Blow, Blown!

Remember how you tried endlessly to blow off the last candle on your birthday cake? I do. 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.

Click here 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 Shanjit, is on display at Ambience Mall, Gurgaon, India starting this Saturday, October 22, 2011 in collaboration with Saurabh Arora, Prabhat Saraswat, Rishabh Verma, 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.

FatFs Library Port for Stellaris EK-LM3S811 Evaluation Board

I have written a port of the ELM-FatFs Generic FAT File System Module 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 here. I have also supplied the makefile which takes care of all the compilation tasks provided your toolchain is set up as described here.

Steps to use the files in your project.

  1. Copy all the files in to your project folder.
  2. Include the “ff.h” and “diskio.h” header files in your code.
  3. Refer the ELM – FatFs library reference for writing your program in “main.c”.
  4. Compile the program.

MD5 Hash Generation on Arduino

I implemented the MD5 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 here.

I intend to use it later in my projects for security enhancements and error detection and of course Geohashing.

Click here to download source code and library files used in this project.

ARM Evaluation Board Bricked?

The feature to remap pins of an ARM processor sounds cool. Ain’t it? 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 PC<->USB<->FT2232<->JTAG<->MCU 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 :-

  1. 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_<compiler>.c file, which I hadn’t done. So I had no luck.
  2. 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.
  3. 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.
  4. 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 :-

  1. Use the ARM Pin mapping feature cautiously.
  2. 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.
  3. Specifically for all Stellaris microcontrollers, enable UART support in the startup_<compiler>.c file. You never know when you will need it.
  4. 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.
  5. Never lose hope. It took me two days to finally make it work, again.

Setting up CodeSourcery GNU Toolchain for the ARM in Eclipse Helios on Mac OS X 10.7 Lion

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 http://www.eclipse.org. 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
  1. Go to Help > Install New Software.
  2. In the dialog which appears, type “http://download.eclipse.org/tools/cdt/releases/helios&#8221; in the Work With text area.
  3. Press enter.
  4. 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.
  5. Once the installation is complete, restart Eclipse.
  • GNU ARM Eclipse Plugin
This plugin is the link between your Eclipse IDE and your CodeSourcery toolchain which we will install in the next step. The plugin works only on Helios as of now. Once the compatibility with Indigo is achieved, the same steps can be followed for setting up the toolchain on it.
  1. Go to Go to Help > Install New Software.
  2. In the dialog which appears, type “http://gnuarmeclipse.sourceforge.net/updates&#8221; in the Work With text area.
  3. Press enter.
  4. You will get a window as shown below. Select all choices and click on Next. Accept the license agreement and continue with the installation.
  5. You will get an unsigned plugin notification during install. Click OK to continue with the installations.
  6. 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 James Snyder I was able to get it up and running in less than 30 minutes.

  1. Ensure again, you have the Apple Developer Tools installed.
  2. Point your browser to Snyder’s github.com project page.
  3. 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.
The rest of the step is pretty straightforward. Just enter the terminal commands in the exact same order. If, for some reason, the build process fails at any step, restart again by using “make clean”.
  1. mkdir -p $HOME/Work/ – directory for saving all the downloaded content. This won’t contain the installed toolchain. Just it’s .tar archive.
  2. cp $HOME/Downloads/jsnyder-arm-eabi-toolchain-*.tar.gz $HOME/Work/ – copy the downloaded archive.
  3. cd $HOME/Work/
  4. tar xzvf jsnyder-arm-eabi-toolchain-*.tar.gz – extract the downloaded/copied archive.
  5. cd $HOME/Work/jsnyder-arm-eabi-toolchain-*
  6. 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.
  7. sudo make install-deps
  8. mkdir -p $HOME/arm-cs-tools/pin – create destination folder for the toolchain.
  9. 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.
  10. make clean
  11. 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. 
  12. sudo make cross-gdb – builds and installs the debugger.
  13. Close Terminal.
These steps will help you successfully build and install the CodeSourcery toolchain. However, one final step, which is very important, is to set the environment variables to help UNIX know as to where you have installed your toolchain and from where it should pick up the compiler for ARM compilation. This can be achieved by making some changes to .bash_profile script. To do that:
  1. Open Terminal.
  2. Type “open .bash_profile”
  3. In the TextEdit windows which appears, add to the bottom of the text contents – export PATH=$HOME/arm-cs-tools/bin:$PATH
  4. Close the window.
  5. Logout from the Terminal.
  6. Restart Terminal.
  7. Type echo $PATH and in the variables which appear, /Users/<username>/arm-cs-tools/bin should be present.
  8. 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 .bash_profile script will be automatically added to Eclipse’s PATH variables. To do that,

  1. Open Terminal.
  2. 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”. 
  3. Type “cd eclipse”
  4. 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 < New < C Project
  • Insert a Project Name. Select “ARM Cross Target Application” and chose “ARM Mac OSX GCC (Sourcery G++ Lite).
  • Click on Finish.
  • Go to File < New < Source File. And name it main.c
  • In main.c, type in a simple program which prints “Hello World”. Need not worry about this program working on your micro-controller. It is just to check if the toolchain is working fine.
#include <stdio.h>
int main()
{
printf(“Hello World”);
return 0;
}
  • Save the project contents.
  • Go to Project < Properties.
  • Click on C/C++build item and set:
    1. Builder Type : External Builder
    2. Check Use defualt build command
    3. Check Generate Makefiles automatically
  • Now click on the small triangle near the C/C++ Build item to view the subitems and then select Settings and set:
    1. Target Processor > Processor : cortex-m3
    2. Additional Tools : Uncheck Create Flash Image
    3. 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. Eureka! 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!
Do leave a comment if this post helped you.

Post Navigation