Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
Sparkfun has recently posted a tutorial on how to write C-based programs that access GPIO/I2C/SPI/UART devices through Linux. The programs are targeted towards the PCDuino board, but because that board runs Linux, much of this information can be useful for those using other embedded Linux boards such as the RaspberryPi, Beaglebone (SPI is a little different on the Beaglebone though) as well as other Linux boards. Continue reading
In this blog entry I will demonstrate how to successfully interface the MCP23017 general purpose input/output (GPIO) expander from Microchip, to the Raspberry Pi over the I2C bus.
The I2C Bus
The I2C bus is a two wire bus developed by Phillips/NXP (4-wire if you want to include power and ground), that is used to connect a single master device to up to 120+ slave peripheral devices. The master device is typically a microcontroller, and the slave device(s) is/are typically peripheral chips that perform special functions such as GPIO expanders, analog to digital converters, digital to analog converters, real-time clocks, eeproms and many more. Continue reading
In this entry I will outline how one can utilize remote debugging tools available in Eclipse to debug applications from a linux PC/VM, on the raspberry Pi. This tutorial assumes that you have already setup your Raspberry Pi cross compiling toolchain and Eclipse and that you are able to build your applications in Eclipse (using the cross-compiling toolchain) as well as transfer the binary executables to the RaspberryPi via the RSE plugin. If you have not done so I urge you to look at the “Development Environment for the Raspberry Pi using a Cross Compiling Toolchain and Eclipse” since this tutorial is really a continuation of the tutorial in that blog entry. Continue reading
About 6 months ago I started a tutorial on how to setup a free development environment for a Cortex-M0 microcontroller from STMicroelectronics. This tutorial utilized a free ARM toolchain, Eclipse and OpenOCD (for debugging) to setup this environment. It was based on the $8 STM32F0Discovery board.
While the tutorial targeted the STM32F0Discovery board, the larger objective of that tutorial was to make setting up a free GCC-based development environment for Microcontroller development (Cortex-M0/M3/M4) more accessible to everyone and not just the geeky few. And I feel that the tutorial has somewhat succeeded in this goal…
My issue with the STM32 and most other Cortex-M0/M3/M4 parts is that they’re only available in hard to solder surface mount packages. While I know that they are solderable, 0.5mm 48/64QFP packages are almost impossible to align with the naked eye (at least my eye). QFN packages are generally harder to solder at any pitch and simply not designed for people who want to mess around with microcontrollers on a breadboard. Sadly most of of the Cortex-M0/M3/M4 parts out there come in these packages. The exceptions are some of the Cortex-M0 chips (LPC1114) from NXP that come in 600mil 28-DIP and 0.65mm SSOP. Unfortunately these parts do not have a large enough memory density (32K Flash and 4KB RAM) and peripheral integration to peak my interest. Continue reading
In case you have been living under a rock, Processing is an open-source Java based development environment with a high level API that gives you access to a variety of mathematical, graphical, data analysis libraries in a few lines of code. Processing is basically to the PC what Arduino is to microcontrollers. Heck Arduino’s IDE is derived from the Processing IDE, so if have done any Arduino programming you should feel right at home with Processing .
Processing is a great tool to learn programming principles. The Processing website has some excellent learning resources.
I also encourage you to have a look at the following books on the basics of Processing:
In this blog entry I will demonstrate how one can access the Raspberry Pi’s GPIO in C++. There are two approaches to accomplish this. The first is to directly manipulate the Raspberry Pi’s GPIO’s registers much like one would do when programming a microcontroller without an operating system (OS) or a memory management unit (approach using mmap). The advantage of this approach is that because the OS (Linux) is being completely bypassed, the GPIO pins can toggle very fast. Bypassing the OS however means that if two processes (instances of a programs) are trying to access the same physical GPIO registers at the same time, a unsafe resource conflict can happen. Examples of this approach to GPIO coding can be found here.
The second approach is the “Linux approach” (sysfs). Linux already has a built-in driver for safely accessing the GPIOs. It basically views each property of each GPIO pin as a file. This is the preferred method of GPIO access. One disadvantage of this approach is that it tends to make for slower (but safer) GPIO pin toggling. Example code for this approach can be found here, and a wiki on how to access GPIO signals using this approach can he found here. This approach will be used in this tutorial. The file accesses will be wrapped in a C++ class to make GPIO access easy and foolproof (sort of).
One of my major gripes with the STM32 family is the documentation. The reference manual is pretty comprehensive but is not well organized. A simple task of figuring out how to use external interrupts is utterly unclear. The availability of the peripheral libraries which again are not well documented exacerbates this problem. Programmers are encouraged to recycle peripheral library based code from the available examples without really understanding the hardware…they simply use the code because they know it works. This approach might seem reasonable but when trying to implement a complicated peripheral setup it can cause much angst.
Now that I’ve got my rant out of the way, let’s take a look at interrupts on the STM32F0 chip and specifically external Interrupts.
The Stellaris Launchpad is a cortex-m4 board that contains an LM4F120 device. This device has 256KB of Flash, 32KB of RAM and a very decent set of peripherals. The LM4F devices are fabricated in a 65nm process which means that they will consume little power compared to similar microcontrollers. The LM4F120 can run up to 80MHz and Deliver 100DMIPs.
The board also has an Onboard “Stellaris-ICDI” hardware debugger. This hardware debugger is unfortunately currently unsupported by OpenOCD but support will be coming in the future: http://forum.stellarisiti.com/topic/197-can-i-debug-the-stellaris-launchpad-via-gccgdb/
Luckily the board also has an onboard JTAG header to allow us to debug the chip with any debugger of our choosing. such as the Olimex and the J-Link JTAG debuggers
The TI stellaris chips are known to have one of the best peripheral libraries and some of the best documentation. I’m really looking forwards to this board and this particular chip.
TI has also launched a ridiculous amount of workshop material to help those getting started with the Stellaris Launchpad. This material can be found here : http://processors.wiki.ti.com/index.php/Getting_Started_with_the_Stellaris_EK-LM4F120XL_LaunchPad_Workshop?DCMP=Stellaris&HQS=StellarisLaunchPadWorkshop
Be sure to check it out!!!! I’ve already preordered 2 Stellaris Launchpad boards that are expected to ship on OCT 2nd.
In this blog entry the setup of a cross-compiling development environment for the Raspberry Pi will be demonstrated. This will include the
We will finally write a simple Hello World program on our Kubuntu virtual machine (VM), compile it using the cross compiler and then deploy it onto our Raspberry Pi board to run it.
I’m going to assume that you have already installed a Raspbian Wheezy image on your RPi board and that you have Ubuntu / Kubuntu Linux installed either has a host OS or guest OS on your desktop PC.
A remote debugging tutorial; which I consider to be the continuation of this tutorial, can be found here.