After getting the gcc-arm compiler working with the mbed, I decided to take a look at my LPCXpresso LPC1769 development board. The mbed is really easy to program. It mounts as a flash drive and you just drag and drop the binary file onto it. Unfortunately, that’s it. There is no way to get any debug information out of it. The LPCXpresso, on the other hand, comes with a nice LPC-link board attached just for this purpose. Unfortunately(again), it only works with certain IDE’s, like code_red. I cut the lpc-link board off and instead used a BusBlaster from Dangerous Prototypes along with OpenOCD. It took me a while to actually program the device, so I’ll leave that for later. This post is about debugging!
BusBlaster and LPCXpresso LPC1769
So why, you might ask, do I go to all this trouble to get a debugger working? Because debuggers are awesome! Without them, one has to resort to printf statements(if you’re lucky enough to have that working) and LED’s. Sure, those are useful sometimes, but having access to memory, registers, stepping through code, etc. makes debugging much easier!
* All of the following takes place in Ubuntu 12.04.
Don’t want to read though this post? Just want the code, go get it from my github repo!
I’ve been meaning to start working with Cortex-M3 processors for a few of my projects. Sometimes the MSP430′s I usually use just aren’t fast enough.
Previously, I’ve used the mbed, which is a nice Cortex-M3(LPC1768) development board. The best part about it is that you program it by just copying the bin file to it as if it was a flash drive. It takes care of the actual device programming for you. The downside is that you don’t have any debugging capabilities, and that you have to use their online compiler.
The online compiler isn’t so bad, but you have to use their libraries and it’s all in C++. When working with microcontrollers, I prefer plain old C. To get around this, I decided to figure out how to use the GNU GCC-ARM compiler so I could have full control of the processor. I’m not going to cover every step I took, because that’s boring, but here’s a quick summary of how it went. (You can also look at my commit history for more details).
While trying to figure out what flags to pass to the compiler to build the most basic program, I found out the online mbed compiler has a ‘recently’ added export feature! You write your program with their online, C++, compiler, export it for gcc-arm, then you can build it all off-line. They include all the pre-compiled libraries and header files required, along with a nice Makefile. This made my life much easier. Now all I had to do was start cutting stuff out until I was happy.
I started by switching the main file to C, from C++. I then started removing all of their included libraries. Eventually, I was able to remove all of their files and start using the standard CMSIS headers. I had to find a plain C version of the startup_LPC17xx.c from some other code examples on NXP’s site. Finally, I had a very basic Makefile that built an LED blinky program that actually worked on the mbed.
One thing that was slightly disturbing was that my blinky program was ~20kB! That is way too big! Turns out they were including things like the C math library and floating-point versions of scanf and printf! I don’t need that… Now the code is ~2.5kB, which is still a bit high, but not 20kB!
So that was my experience getting started with the gcc-arm compiler. You can get the code from my github repo. I will keep updating this as I learn more. My goal is for every new ARM project I work on to start from here.
If you haven’t heard about my ‘home automation’ project, you should probably read this first.
This weekend was rather productive. I managed to get my light alarm working! I wrote escheduler, which is something like crond, but calls functions, instead of running programs. It’s also more limited, since it only schedules events on a weekly basis.
Beaglebone with a more ‘permanent’ radio setup
Escheduler runs on the beaglebone, which is currently my ‘home server’. The current set-up turns on the light behind my bed a few minutes before I’m supposed to wake up. Eventually there will be a whole fade-in period, but I just wanted to get something working. I left it running overnight, and sure enough, the lights turned on on time this morning!
Previously, the only way to control the lights was to ssh into the beaglebone and run swrite with the radio commands. You might not think so, but ssh-ing into the server and typing commands from a smartphone in bed at 6am is not as easy as it sounds! To make things easier, I decided to make a web interface I can use from my phone.
Simple RGB LED controller in smartphone browser
It took longer than expected, but I ended up using the twitter bootstrap. I haven’t done any web development in several years, so I had to re-learn a lot of things. In the end, I just set up a few buttons to turn the lights on or off. When clicked, there’s an AJAX request in the background to a php file that calls swrite to send the commands via the beaglebone radio. Next up will be controlling the actual colors from the web interface, as well as viewing and editing the alarms.
I’ve been neglecting my projects for a while, but I finally decided to stop being lazy and started working on them again. Several of my old posts deal with msp430′s and cc2500′s, but they’re mostly hardware updates and examples of changing lights to music. Now that I have a semi-stable platform and decent libraries, I figured I might as well do something useful with them.
My ‘end goal’ is to be able to control things like lighting and temperature automatically(and/or remotely) as well as gather data about the environment(temperature, motion, air quality, etc.) As usual, the first thing I did was start designing the whole system in my head and over-complicating things. I wanted to do a fancy server with flexible communications protocols, which got overwhelming pretty fast. After some time without getting anything done, I decided to start fresh and do small, manageable, tasks that eventually will end up being the full working system.
The first task I decided to do was to get my beaglebone talking to my cc2500 radios. I didn’t want to waste time trying to figure out how to get SPI and interrupts working on the beaglebone, so I went for the simpler solution and put an msp430 to control the cc2500. I say simpler because I already had a uart-to-msp430-to-cc2500 bridge working, so the only new thing was figuring out the uart on the beaglebone. Luckily, there are several good posts about it online.
The “Server” — Beaglebone with CC2500
Once I had my ‘server’ talking to the radio, I had to write a program to control it. Again, I could write an entire, complicated, sever application, or I could do something much simpler to start. Since I’m currently only testing with wireless lighting, I don’t need the server to receive data. Instead of having an always running application that takes over the serial port, my swrite program is called from the command line each time a new packet is sent. While limited, this solution is enough for now.
Wireless RGB LED controller mounted on bike rack
To start testing the lighting control, I mounted two RGB LED strips with controllers in my apartment. One is behind my bike rack in the living room, and the other behind my bed. The one behind my bed will eventually be tied to my alarm clock, so I can start turning up the lights before I wake up. Since my computer is not in my room, I use the one in the bike rack for testing.
Lights on Bike Rack
So that’s what I have so far. It’s not terribly exciting, but maybe if I write about it, I’ll be more motivated to keep working on it. Right now I’m writing a program on the server that will allow me to schedule events. A bit like crond, but instead of running programs, it calls my own functions. The first test will be to set up the light-alarm. I hope it works!
I recently found out that the San Francisco International Airport (SFO) offers bike parking for up to 14 days. I decided to try it out during the thanksgiving break just for fun (with the added bonus of saving on driving/parking or taxi costs).
The San Jose airport is much closer to where I live (San Jose/Cupertino area), but SFO has more direct flights to where I need to go. SFO is over 40 miles from my apartment, so the trip did require some planning. First of all, I had to reduce the amount of luggage I packed, since I was going to be carrying it on my back. I can’t predict if it’s going to be raining or not, so I decided to use a waterproof backpack. Finally, I didn’t want to bike all 40 miles, so I only biked to/from CalTrain stations and took the train the rest of the way.
Getting There
My flight was at 12:40 on Saturday. I decided to take the 8:14am train from Sunnyvale, so I would get to the airport around 9:30am. (This way, I could miss the train and still make it in time. Flats happen!) The weather was great, cold and rainy, so I got to use all my waterproof gear.
Ready for some rain!
It took me about half an hour to get to the caltrain station. I didn’t run into any problems on the way there.
I probably shouldn’t stand there…
The train was on time and the bike car was fairly empty.
That’s the waterproof bag! (On the train)
I got off the train at the Millbrae station. There are two options to get to SFO from there. One is to take the BART, the second is to bike the rest of the way. Since I already had my bike, I decided to use it. It was just over 2 miles, so it took around 10 minutes(Which I assume is faster than taking the BART).
Yup, it was still raining a bit. (Millbrae Station)
To get to the airport from the station, I took Millbrae Ave to S McDonnell Rd. Millbrae Ave was the only segment of the trip without a dedicated bike lane. Once I reached the airport, I registered my bike with the guy in the security booth (who had never done it before) and locked it away.
Yes, it folds!
So that was the trip there… Oh wait, I should warn anyone trying to do the same. If it happens to be raining, and your clothes are soaking wet, change before going through security! I always opt out of the TSA’s full body scanners and get the enhanced pat down (fun!). After they pat you down, they scan the gloves they used on you for whatever it is they’re looking for. Turns out, if the gloves are soaked, the machine doesn’t like it, and you get an extra-special pat down and search. Luckily, I had plenty of time and the TSA agents were nice.
Be sure to bring a change of clothes. Nobody likes traveling with wet socks/shoes!
Getting Back
I was slightly worried when the airport guy had never had anyone register a bike with him. Turns out, we did it right and my bike was still there when I returned. Phew!
Bike was still there when I returned!
I got back after dark, but I brought my bike lights so that wasn’t a problem. The airport road was pretty well lit, so if you forget, you should be ok.
Millbrae station. Busy!
The train was surprisingly full(after seeing the empty-ish station), but the bike car didn’t have too many bikes.
NOT my bike on the train
Since I flew across the country and didn’t have much to eat, I did have to make an unscheduled stop for food.
Turns out they have bike parking too!
That’s it, my experiment was successful! It is possible to get to SFO on your bike.
I recently started working on a project that might require some Passive Infra-red (PIR) sensors. Sparkfun had two different ones, so I figured I’d try them both.
Zilog ePIR and SE-10
The comparison is between a Zilog ePIR and an SE-10. One very important thing to note is that I did not use the ePIR‘s serial interface. I only used the hardware interface, set to the highest sensitivity, and shortest delay. I felt that this would be a better comparison. I made a video that shows my test setup, as well as some results, so most of the relevant information is there. I’ll use this blog post to add some setup details, as well as my conclusion.
First of all, I must warn everyone (as Sparkfun did) about the SE-10. The wire colors mean absolutely NOTHING. As you can see in the photo, there is a black, brown, and red cables. Here’s what they were connected to on mine: Black=12V, Brown=GND, Red=Alarm. It’s not a huge problem, just make sure you know before supplying power. There’s a small label that says B+ and AL on the bottom near each wire that should help.
The alarm pin needs to have a pull-up resistor, but that’s about it. Out of the box, it worked without a problem.
You’ll notice the SE-10 takes in 12V. Several comments on the Sparkfun product page deal with powering the device with 5V or 3.3V. All I did was remove the 5V regulator and jump across it with a wire (big red one on the photo). Unfortunately, I ripped off some traces while attempting to remove the regulator (oops!). At first it wouldn’t work, but I noticed a very small trace going under one of the resistors and connecting to the ground pin of the regulator. After connecting that to ground again (small red wire on the photo), everything worked fine at 5V.
The ePIR sensor took me a bit longer to get working. The datasheet is quite long, mostly documenting all the configurations and serial interface. They do have a nice schematic showing the Hardware Interface Mode. It shows all the connections required to get this working without the serial interface. The schematic has three potentiometers, a photoresistor and three regular resistors. Luckily, you don’t even need that for the most basic operation. The pots are all for setting the delay(pin 2), sensitivity(pin 3), and light gate threshold(pin 6). You can just connect the delay and sensitivitypins to ground, and the light gate to VCC(which is 3.3V for this device). This will use the minimum delay (2 seconds), maximum sensitivity, and have the device always on.
The light gate is there in case you want to enable/disable your sensor depending on ambient light with a photoresistor. You can also just use the pin as an enable/disable for the whole device. It is disabled while the input is less than 1V.
The delay had me a bit confused initially. It is not a delay before it lets you know something is moving. On the other hand, once it detects something, it holds a ‘detected’ state for the delay period. I had the minimum delay setting of 2 seconds (it goes up to 15 minutes), so after detecting motion, the signal would stay low for that amount of time.
So which sensor should you use? As always, it depends… I found the ePIR sensor to be much more sensitive than the SE-10. Maybe it was just the one I received, or maybe they’re all like that, but the ePIR could detect me at a wider angle (and behind the blanket!). It also seemed faster than the SE-10 at longer distances. On the other hand, when I stood a few feet in front of the sensors and turned around, the response was about the same.
Another thing I mentioned in the video is the ‘delay’ time with the ePIR. The output signal is much cleaner because of it. The SE-10, on the other hand, constantly switches while something is moving. I guess that could be useful if you’re trying to count something…
If you’re looking for a very easy to setup sensor, and aren’t too worried about sensitivity, I’d go with the SE-10. It’s three wires and a pull-up resistor! Doesn’t get much simpler than that. On the other hand, if you want more control, and are willing to spend more time tweaking stuff, the ePIR is probably a better idea.
The Wireless Friend Finder was my project for the Bring-a-Hack dinner after the 2012 Bay Area Maker Faire. I made it in a hurry, so it’s not terribly well documented.
The wireless friend finder is a device that will start buzzing when another device gets near. This can be used to find a friend in a crowd(or to stay away from someone you don’t like)! Here’s a quick video I did while I was prototyping the project.
The actual devices consist of an msp430 microcontroller a cc2500 radio, and an annoying buzzer. The devices are sending radio messages every second. If a message from another device is received, the buzzer starts going off. In order to make it slightly more interesting, they measure the signal strength of the incoming message and determine how long the buzzes last. The stronger the signal, the longer the buzz. Here’s a video of some outdoor testing. (I had to do it around the apartments to get an ok result. I tried doing it with direct line-of-sight across the parking lot, but after 300ft, it was still buzzing!)
Since the devices aren’t very nicely built, I was slightly worried about the airport security. Luckily, they didn’t even ask me to take them out of my bags!
Even though the project was for the bring-a-hack dinner, I carried it around while I was at the faire. I was surprised at the reactions it received. Many people were asking if I had plans to make these into an actual product!(And suggesting new features) Moms wanting to find their kids, concert goers wanting to find their friends, burning man attendees, etc… The devices themselves are really cheap, under $10 each, so who knows…
Ian from DangerousPrototypes was nice enough to ask a few questions about the friend finder and put it online (along with other awesome interviews!):
So that’s the wireless friend finder… If you’re interested, you can get the code from github.
I finally decided to get a dedicated electronics workbench. I had been working on my computer desk until now, but it wasn’t quite working out. The first problem was having to clean up my electronics gear all the time, so I could have space to work comfortably and have other stuff out. The second was that it’s a glass desk, so I had to be really careful not to break it (No hammers!).
It took me a while to pick this specific workbench. After looking around, I saw Joe Grand’s workbench on flickr. It was perfect! I live in a rented apartment, so I can’t(ok… shouldn’t) just go around mounting shelves on walls. The bench from formaspace.com has shelves and lights built in, and you can get one with locking casters so it is easy to move around.
The actual purchase process was strange. FormaSpace is a technical furniture company not really focused on individuals. I had to call, get quotes, fax papers, pay over the phone, and wait two months to get it. The trouble was well worth it though. Last Friday, I received a 390lb crate with the pieces. (They usually ship them pre-assembled, but it wouldn’t have fit through my apartment door!)
As usual, I documented the build process with time-lapse videos. Here is the result:
I finally managed to make a quick video of the build process for my wireless RGB LED controller. I used two cameras to do a time-lapse of the build. Unfortunately, they were using different frame-rates, so it took me a bit to get both of them synchronized. If you’re curious how the setup looked, here’s a (bad) picture of it:
Second Attempt at Dual-Camera Time-lapse
I uploaded the EagleCAD files for the board(schematic and PCB) to github: https://github.com/alvarop/eagle/tree/master/wirelessrgbled
I’m not sure what the ‘official’ way of making this open hardware, so I just put the OSHW logo on the latest revision. Here is the video of the build (with a quick demo!):
I just spent several hours debugging my cc2500 radio libraries. What changed you might ask? Two lines of code…
My Wireless RGB LED driver had been using the msp430g2452 microcontroller. So far it has been working great! Someone emailed me asking about the msp430g2533, and how it wasn’t quite working. I currently use the msp430g2203 (which is a cheaper variant of the 2533) as my PC-to-cc2500 interface, and it has been working for a while (or so I thought!).
I decided to begin testing the 2533 with the rgb led radio code. As you might expect, it didn’t work. I quickly pulled out my Salae Logic analyzer and connected it to the msp430-to-radio interface to see what was going on. To have an idea of what the signals should look like, I used the 2452. I spent a few hours comparing the two signal captures, measuring timings, read data in the microcontroller, etc… This is a ‘quick’ summary of my findings.
Difference between 2452 and 2533
The first thing I noticed was that the separation between the address and data bytes was different between the devices (Circled in red). The 2452 had about 1.58 µs separation while the 2533 only had 0.5 µs. I looked in the cc2500 datasheet and realized that as long as that separation is greater than 55 ns, everything should work, which meant that was not the problem.
Another thing I noticed was that the 2533 misread some of the radio settings. For example, it would read 0×03 instead of the actual 0×07. This suggested something was wrong with the bit timings. After some more messing around, I saw this:
Clock Edge Configuration
The 2533 was starting the byte transmission half a clock-cycle too early! This also means that it is trying to sample incoming data at the wrong time (which is why some of the data reads were wrong). After digging around in datasheets and code, I found the source of the problem to be this line in the SPI configuration:
The problem was with the Clock phase select bit (UCCKPH). It was set to capture data on the first clock edge and change on the following edge. Clearing that bit configures it to change data on teh first clock edge and capture on the following edge.
So that fixed the communication problem, but there was still a problem. The first setting written to the c2500 after reset was not being saved. Looking at the earlier capture (Blue circles in first image), the cc2500 returns a status byte of 0×87, instead of 0×07. The MSB in this case means that the radio is not ready. The problem here ended up being in the cc_powerup_reset function. Turns out the function wasn’t waiting for the device to actually reset (just sending the reset command), so that first setting write happened while the radio was still restarting.
Not sure if you noticed, but I did mention that the msp430g2203 was previously working with the same (broken) code. My theory for this is that all it ever did was transmit data, so it never ran into the receive problems. Also, the mis-aligned data might have been read properly by the cc2500. Another thing was that the first setting that wasn’t saved wasn’t really important, so I never noticed. I’m glad I figured this out before trying to receive any data on the 2203…
Now that my radio library works with both devices that have USI (msp430g2xx2) and USCI (msp430g2xx3), I can start using them to make some more interesting gadgets.
