Electronic Excursions
Friday, August 24, 2012
New Blog!
I've recently been exploring the world of WordPress in order to give me a more robust website for my main site. Check out my new site, which includes its own blog.
Saturday, April 21, 2012
simulating a raspberry pi with arch linux
This tutorial will get everyone started with a raspberry pi simulation on their pc. I'm using arch linux as my host platform as well as my client (rasp pi) operating system. I haven't experimented with networking yet, but perhaps if that's figured out it will be posted in the comments below. I mainly wrote this blog because it was difficult to piece this info together from forums and googling. Good luck!
Steps:
This is our emulator for the ARM processor and virtual machine. It creates a machine then hosts the screen via vnc, if my thoughts are correct. You can put these files where ever you want. Mine are in ~/qemu and the arch linux stuff is in ~/qemu/arch in case I wanted a debian or fedora version to run.
Arch Linux img
We'll be using the Arch Linux image for our raspberry pi emulation. Mainly because I prefer the minimal approach and having the control!
I'm not a Linux wizard, so I just looked until I found a downloadable kernel. Others were assembling (compiling? wrong word?) their own.
The command I use is:
qemu-system-arm -M versatilepb -cpu arm1176 -hda <arch img> -kernel <zImage> -m 256 -append "root=/dev/sda2"
** note the replacables indicated with <?> syntax!
If someone knows what steps need be taken to add networking, please post a comment. Being able to install packages would help tremendously!
Steps:
- Download newest QEMU src, configure, make, and install
- Download the archlinux image
- Download an appropraite kernel (or you can build one, but I found one just the same)
- Run!
This is our emulator for the ARM processor and virtual machine. It creates a machine then hosts the screen via vnc, if my thoughts are correct. You can put these files where ever you want. Mine are in ~/qemu and the arch linux stuff is in ~/qemu/arch in case I wanted a debian or fedora version to run.
- Download here: http://wiki.qemu.org/Download
- Extract: tar xvf <name of file>
- Navigate in to file and execute './configure' (you'll need python installed).
- When finished execute 'make' (takes a long time)
- When finished execute 'make install' (need to be root user)
- Add /usr/local/bin to your bash $PATH if that's not already done
Arch Linux img
We'll be using the Arch Linux image for our raspberry pi emulation. Mainly because I prefer the minimal approach and having the control!
- Download the img from http://www.raspberrypi.org/Downloads and move it to where you prefer
- Extract the downloaded zip with executing 'unzip <name of file>'
- Note the name and location of .img file. Mv it if preferred. I'll refer to this location/name as <arch img>
I'm not a Linux wizard, so I just looked until I found a downloadable kernel. Others were assembling (compiling? wrong word?) their own.
- I found a compatible kernel from smithae's post at this site: http://www.raspberrypi.org/forum/general-discussion/arch-linux-arm-and-qemu
- The direct link is here: http://www.smithae.pwp.blueyonder.co.uk/zImage-devtmpfs
- Download and note the location/name. i'll refer to it as <zImage>
The command I use is:
qemu-system-arm -M versatilepb -cpu arm1176 -hda <arch img> -kernel <zImage> -m 256 -append "root=/dev/sda2"
** note the replacables indicated with <?> syntax!
If someone knows what steps need be taken to add networking, please post a comment. Being able to install packages would help tremendously!
Thursday, February 9, 2012
Latest holdup involves interrupts destroying delay
Last night I had an interesting adventure getting my ATmega48 to actually delay for a second. I would use the command _delay_ms(1000); and the board would indicate the delay lasting around 13 second. Let me elaborate more on what I was trying to do. Here's some code:
hwserial_init();
int num = 0;
char thing[20];
while(1){
//Clear LCD
hwserial_transmit_byte(0xFE);
hwserial_transmit_byte(0x01);
itoa(num, thing, 10);
hwserial_transmit_string(thing);
_delay_ms(1000);
num++;
}
return 0;
This is the code from my main function. It's pretty simple. Loop indefinitely outputting a number every second that is one more than the last number outputted (I guess that's a word). The 'clear lcd' two lines simply send two bytes to my LCD. They clear the display. The itoa command takes an int (as a reminder in avr this is a 2 byte signed number) and converts it to a string which is stored in the char array 'thing.' This is then printed on the LCD.
So you'd think this program (if all of my methods for hwserial work correctly) would write 1, 2, 3, 4, 5... changing every second. Wrong. It output said numbers but changing every 13ish seconds - and it was never constant. So I did a whole bunch of crazy stuff: re-declared F_CPU, checked and re-burned fuses, and Googled. Finally I started commenting out code to see if I could knock out any lines that would make it work correctly.
Well sure enough, in my hwserial_init() method, interrupts are being enabled. This makes sense because as data comes in on the RX port, my program needs to be made aware of it. So I have this interrupt service routine to take care of the incoming bytes:
ISR(USART_RX_vect){
}
It doesn't do anything because my LCD doesn't talk back to me. So why would disabling interrupts return my delay to the proper time of 1 second? Well it was because of something I did wrong either physically or in the program. Here's the problem: my RX (serial receiving) pin was hanging wide open. Because of the voltage crazily fluctuating on this pin, the interrupt was being triggered maybe tens of thousands of times every second. Even though there's no code in the ISR (interrupt service routine), in assembly there are a few commands that it still needs to execute. One way that I could fix this would be to disable RX when communicating with the LCD. This way interrupts could still be enabled but the chip would disregard any input from the RX pin. The other way (which is the way I quickly fixed it) would be to wire RX to some solid input: 5V.
Well if this post helps out one frustrated engineer, then it's served its purpose. Watch that RX pin!
hwserial_init();
int num = 0;
char thing[20];
while(1){
//Clear LCD
hwserial_transmit_byte(0xFE);
hwserial_transmit_byte(0x01);
itoa(num, thing, 10);
hwserial_transmit_string(thing);
_delay_ms(1000);
num++;
}
return 0;
This is the code from my main function. It's pretty simple. Loop indefinitely outputting a number every second that is one more than the last number outputted (I guess that's a word). The 'clear lcd' two lines simply send two bytes to my LCD. They clear the display. The itoa command takes an int (as a reminder in avr this is a 2 byte signed number) and converts it to a string which is stored in the char array 'thing.' This is then printed on the LCD.
So you'd think this program (if all of my methods for hwserial work correctly) would write 1, 2, 3, 4, 5... changing every second. Wrong. It output said numbers but changing every 13ish seconds - and it was never constant. So I did a whole bunch of crazy stuff: re-declared F_CPU, checked and re-burned fuses, and Googled. Finally I started commenting out code to see if I could knock out any lines that would make it work correctly.
Well sure enough, in my hwserial_init() method, interrupts are being enabled. This makes sense because as data comes in on the RX port, my program needs to be made aware of it. So I have this interrupt service routine to take care of the incoming bytes:
ISR(USART_RX_vect){
}
It doesn't do anything because my LCD doesn't talk back to me. So why would disabling interrupts return my delay to the proper time of 1 second? Well it was because of something I did wrong either physically or in the program. Here's the problem: my RX (serial receiving) pin was hanging wide open. Because of the voltage crazily fluctuating on this pin, the interrupt was being triggered maybe tens of thousands of times every second. Even though there's no code in the ISR (interrupt service routine), in assembly there are a few commands that it still needs to execute. One way that I could fix this would be to disable RX when communicating with the LCD. This way interrupts could still be enabled but the chip would disregard any input from the RX pin. The other way (which is the way I quickly fixed it) would be to wire RX to some solid input: 5V.
Well if this post helps out one frustrated engineer, then it's served its purpose. Watch that RX pin!
Wednesday, December 28, 2011
Pololu Orangutan SV-328 in Eclipse
Last night I received my Pololu Orangutan SV-328 in the mail. At Pololu, they recommend using AVR Studio 4, which they conveniently package in their installation bundle. However, I was determined to get everything working in Eclipse, because I'm used to that IDE and would be more productive in it. I've got nothing against AVR Studio, it's just my unwillingness to learn a new development environment! Much of this info came from this forum post, however one thing had changed so I wanted to address that.
Prereqs: This tutorial requires that eclipse is installed on your machine and the eclipse avr plugin. Basically you're able to program lone AVR chips through eclipse. Also I did this in Windows XP, using the Orangutan SV-328, and the USBtinyISP from Adafruit for my ISP. I haven't tested other hardware nor operating systems.
Step One: Installation
Install the Pololu Orangutan package. As far as I know, you need to download the whole thing, but then you can pick and choose what you want to install. Do not install the things that you don't need, but at least install the Pololu AVR C/C++ Library. You should have WinAVR installed already. Remember the directory you install to. I think the default is C:\libpololu-avr. In this screenshot, I have Pololu USB AVR Programmer selected, however if you're using your own programmer, you do not need this.
Step Two: Copy Files
You need to copy files to their appropriate places. First open one explorer window to where you installed the pololu library. Then open another explorer window to your WinAVR installation directory. In WinAVR directory go to the avr/include folder. Does the folder 'pololu' exist? If so, good; you do not need to copy that one. If not, copy the pololu folder from your libpololu-avr pololu library to here.
Next, in your pololu installation directory, find the file that starts with libpololu_ and ends with your unit's microcontroller. My needed file was libpololu_atmega328p.a . Copy this file to <WinAVRDirectory>/avr/lib. Remember this file name!
Step Three: Configure Eclipse
Open Eclipse. Create a project. Right click on the project from the 'Project Explorer' section and select properties. On the left side, drop down C/C++ Build. Click on Settings. Then in the main section of this dialog, click on the Tool Settings tab, click on Directories under AVR Compiler. Add a path (button on the right). Point it to <WinAVRDirectory>/avr/include/pololu. If you have release and debug configurations, remember to do this step for both!
One last thing! In that same window, click on Libraries under AVR C Linker. Add a new one to Libraries (not Library Path). What you enter here will be that funky .a file's name WITHOUT lib nor .a For example if you copied the file libpololu_atmega328p.a, enter pololu_atmega328p for your library. Here's a screenshot of mine. If you have release and debug configurations, remember to do this step for both!
Step Four: Program!
Now, you should be ready to code away. Here's some unteseted code that should play a C major scale and invert the output of the red LED every iteration.
#include<pololu/orangutan.h>
int main( void ){
char LED_onness = 1;
while(1){
play("cdefgab>c");
while(is_playing());
delay_ms(500);
red_led(LED_onness);
LED_onness ^= 1;
}
}
Step three (and four) needs to be completed every time you make a new project, unfortunately. Perhaps there's a better way to do this, but it escapes me. Let me know if this tutorial worked for you or if you have any questions! Thanks!
Prereqs: This tutorial requires that eclipse is installed on your machine and the eclipse avr plugin. Basically you're able to program lone AVR chips through eclipse. Also I did this in Windows XP, using the Orangutan SV-328, and the USBtinyISP from Adafruit for my ISP. I haven't tested other hardware nor operating systems.
Step One: Installation
Install the Pololu Orangutan package. As far as I know, you need to download the whole thing, but then you can pick and choose what you want to install. Do not install the things that you don't need, but at least install the Pololu AVR C/C++ Library. You should have WinAVR installed already. Remember the directory you install to. I think the default is C:\libpololu-avr. In this screenshot, I have Pololu USB AVR Programmer selected, however if you're using your own programmer, you do not need this.
Step Two: Copy Files
You need to copy files to their appropriate places. First open one explorer window to where you installed the pololu library. Then open another explorer window to your WinAVR installation directory. In WinAVR directory go to the avr/include folder. Does the folder 'pololu' exist? If so, good; you do not need to copy that one. If not, copy the pololu folder from your libpololu-avr pololu library to here.
Next, in your pololu installation directory, find the file that starts with libpololu_ and ends with your unit's microcontroller. My needed file was libpololu_atmega328p.a . Copy this file to <WinAVRDirectory>/avr/lib. Remember this file name!
Step Three: Configure Eclipse
Open Eclipse. Create a project. Right click on the project from the 'Project Explorer' section and select properties. On the left side, drop down C/C++ Build. Click on Settings. Then in the main section of this dialog, click on the Tool Settings tab, click on Directories under AVR Compiler. Add a path (button on the right). Point it to <WinAVRDirectory>/avr/include/pololu. If you have release and debug configurations, remember to do this step for both!
One last thing! In that same window, click on Libraries under AVR C Linker. Add a new one to Libraries (not Library Path). What you enter here will be that funky .a file's name WITHOUT lib nor .a For example if you copied the file libpololu_atmega328p.a, enter pololu_atmega328p for your library. Here's a screenshot of mine. If you have release and debug configurations, remember to do this step for both!
Step Four: Program!
Now, you should be ready to code away. Here's some unteseted code that should play a C major scale and invert the output of the red LED every iteration.
#include<pololu/orangutan.h>
int main( void ){
char LED_onness = 1;
while(1){
play("cdefgab>c");
while(is_playing());
delay_ms(500);
red_led(LED_onness);
LED_onness ^= 1;
}
}
Step three (and four) needs to be completed every time you make a new project, unfortunately. Perhaps there's a better way to do this, but it escapes me. Let me know if this tutorial worked for you or if you have any questions! Thanks!
Wednesday, December 21, 2011
Christmas-time Hiatus
I've taken a short break from blogging for the last few weeks. This is due to the business of the holiday season, hunting season, an ATV purchase and also a little to frustration! The last project I was working on was a permanent thermostat for my garage. I had a prototype working with the Arduino Mega, but I wanted something more permanent and not as expensive. I was able to buy all the components for around $20. This involved a relay for switching power, two 7 segment displays (for current and user adjustable temp), potentiometer for adjusting the temperature, temp sensor, microcontroller (ATmega88) for the brains and my own power supply which consisted of a few things.
Here's a picture of the top from what I've done so far (missing relay which goes in upper right by diode).
The jungle of wires makes it pretty ugly, but with two 7 segment displays, there's not much else I could do quickly and cheaply. The next step will be to have a board fabricated for me. I have a few hurdles to leap over before that's a possibility, though, like learning some new software, finding a good company, etc.
Well the frustration is coming from my ATmega88 getting bogus readings from the temperature sensor. Something must be wired incorrectly (ground loops?), or I'm missing a capacitor somewhere. When I hold a multimeter on the signal wire from the temp sensor (TMP36), the voltage moves quite a bit and indicates a much colder temperature than what it really is (~10 degrees F. colder). If anyone has any ideas on this phenomenon, please let me know. I'm about to try a different way of getting the temperature.
Along with getting this thermostat working, I plan on fixing up my inverted pendulum robot. Today I bought larger wheels and a robot controller from Pololu. The larger wheels are needed because I wasn't ever able to get enough speed from my small wheels to right the falling robot if its vertical angle was more than just a couple degrees.
The robot controller is a whole different beast. In my mind it combines three big parts into one convenient package. First it has its own microcontroller. The same uC that's used in the Arduino Uno. Secondly, it has its own small LCD for easy human readable output. Many of you know how big of a relief it is to read words as opposed to counting blinks on an LED or some foolishness like that for output from your uC. Finally it has its own motor driver that can drive two motors (perfect for the robot). So this unit will eliminate the need for an LCD, motor driver and the sort-of-malfunctioning Uno I have mounted on it. I'll just need to purchase a 3.3v regulator and a couple caps for the IMU, but that's not too bad. Another perk about this over the arduino is that it operates at 20MHz instead of 16MHz which gives me a little more speed (about 25% more). Even though this isn't much, it can really help with the complex math that needs to happen in order to get a good stable reading from the IMU.
These two items are shipped an on their way. Getting one of these two projects fully working will be a great step :)
Sunday, November 6, 2011
ATmega48/88/168 Development Board
Lately I've been working on getting a thermostat working without using an Arduino. Instead I'll just be using a microcontroller that is similar to the brain of an Arduino. These only cost around $3-5, so I like to use them in my more permenant projects. In order for me to program these microcontrollers though, it's nice to have an easy interface to plug your chip in, get easy access to all the pins, and make it easily programmable. I've made one of these for the ATtiny84 (part1, part2), but the ATtiny84 simply does not have enough pins to easily do what I want with the thermostat. Anyhow, lets get started.
The development board essentially needs these parts:
Here's some pics on how it came together.
Here's everything out how it will be soldered to check for layout configuration and space constraints:
For mine, the ISCP is on the lower right of the pics, the barrel jack and power stuff is on the left side. Reset button is upper right and everything else is in the middle.
Start soldering!
After every component is soldered, start soldering the needed wires. At least this is how I do it.
Finally with everything hooked up, you're ready to go! You can see the little power indication LED in the lower right hand corner lit up.
The development board essentially needs these parts:
- Microcontroller IC socket
- Female header pins for easy pin access
- Power supply unit
- Will take in a dc signal and use a 5v regulator and caps to give a nice even power supply
- Perhaps an LED to show when on
- ISCP 6 (or 10) pin programmer header
- Reset button circuit
Here's some pics on how it came together.
Here's everything out how it will be soldered to check for layout configuration and space constraints:
For mine, the ISCP is on the lower right of the pics, the barrel jack and power stuff is on the left side. Reset button is upper right and everything else is in the middle.
Start soldering!
After every component is soldered, start soldering the needed wires. At least this is how I do it.
Tuesday, November 1, 2011
Arduino Mega2560 prototype thermostat
In my last post I described my ideas for a thermostat. Well I guess fuses and me don't really get along. I set the wrong fuse on the ATtiny85 and now it's not working at all. I disabled reset so I could have one more output. Unfortunately this also takes away it's programmability... Meh. So I used my hulk of a development board/uC: my Arduino Mega2560 just to see if I could actually make a thermostat.
Video of results:
I guess it is possible! If you'd like code that I used for my Arduino, please let me know. If you'd like more details on how this actually works, also let me know, but read the rest of this because some will be discussed. As of last night I've ordered enough materials to build two permanent versions of these thermostats. I'll be using the ATmega48 as the microcontroller of choice instead of my ATtiny(s) because these have built in UART which makes things much easier to debug. Also they have enough digital IOs to control two 7 segment displays without the use of a shift register which was my original plan for the tiny series. Crazily enough, the ATmega48 is just a somewhat insignificant 50 cents more expensive than the ATtiny84.
Within the next couple weeks I'll be building these two thermostats (one of which was requested by my dad for his shop and the other will be used in my garage) and posting about the progress. Before I can do that, though, I need to build a breakout board for the ATmega48. This will be very similar to the dev board I built for the ATtiny84. It will also be similar to an Arduino Uno because the ATmega48 is a very similar microcontroller except it has less program memory. The 4kB of program memory, as opposed to the 32kB on an Uno, should be fine for a simple thermostat though.
Also I need to give a shout out to this website for using it as a resource on some of the electronics of this project.
Video of results:
I guess it is possible! If you'd like code that I used for my Arduino, please let me know. If you'd like more details on how this actually works, also let me know, but read the rest of this because some will be discussed. As of last night I've ordered enough materials to build two permanent versions of these thermostats. I'll be using the ATmega48 as the microcontroller of choice instead of my ATtiny(s) because these have built in UART which makes things much easier to debug. Also they have enough digital IOs to control two 7 segment displays without the use of a shift register which was my original plan for the tiny series. Crazily enough, the ATmega48 is just a somewhat insignificant 50 cents more expensive than the ATtiny84.
Within the next couple weeks I'll be building these two thermostats (one of which was requested by my dad for his shop and the other will be used in my garage) and posting about the progress. Before I can do that, though, I need to build a breakout board for the ATmega48. This will be very similar to the dev board I built for the ATtiny84. It will also be similar to an Arduino Uno because the ATmega48 is a very similar microcontroller except it has less program memory. The 4kB of program memory, as opposed to the 32kB on an Uno, should be fine for a simple thermostat though.
Also I need to give a shout out to this website for using it as a resource on some of the electronics of this project.
Labels:
arduino,
atmega,
atmega48,
mega2560,
thermostat
Subscribe to:
Posts (Atom)







