Recently I was intrigued by a Hack A Day post regarding a low-cost development platform for their MSP430 line of microcontrollers. I’ve long wanted to toy with an Arduino, but with many other projects currently under my belt, I’ve jut not had the time. When I heard the Launchpad was only $4.30, I figured I might as well pick some up for future use.
To make the shipping worthwhile, I ordered 3 of the boards from DigiKey. Unfortunately they were on back-order, but less than a month later – I got my purchase in the mail:
Each box contains the Launchpad Development board, USB cable, pin headers, a crystal, and two MSP430 chips. The online wiki contains links to a couple IDEs for use in the Windows world – and Hack A Day has a good writeup on using the msp430-gcc compiler in the Linux world.
Acting like an impatient kid, I put schoolwork and other projects on hold for a couple days to dig into the Launchpad. First mission – the basic “RC Car modification”.
After mapping out the pins on the H-Bridge of the RC Car, I decided to do something I’ve always wanted to do – buy a Radio Shack Electronics Learning Lab and brush up on what little I know.
This is something I should have had by the time I was in high-school – if not by 5th grade. The Electronics Learning lab contains 2 lab manuals (one covering Basic Electronics, the other Digital Logic), about 20 ICs, a handful of transistors, numerous resistors and capacitors, and jumper wires (among a few other things). The console itself has numerous built in potentiometers, LEDs, a relay, a transformer, a buzzer, speaker, DPDT switch, and many other components ready to use. Each of the built-in components uses springs to make contact. There’s also a built in breadboard.
Each lab manual contains background information on each of the various components, as well as example circuits that you can build. Each circuit contains a standard schematic, step-by-step instructions, as well as a checklist to help the user build an error-free circuit. The explanations on how many of the circuits work are lacking – requiring the user to do additional searching and reading to get a full understanding of what’s going on. (But seriously, that’s how it should be: You buy the lab to learn, doing additional reading should be encouraged)
Which circuits you build and in what order you build them is entirely up to the user. Each manual is structured so that learning is incremental: You learn how resistors work, you learn how capacitors work, you learn many different ways in which resistors and capacitors can work together.
My goal is to work through each book page by page (I’m only just over halfway through manual 1). Each manual is about 96 pages long so this can easily be done in a long weekend (or a few in my case).
I really wish my high-school had offered an electronics class. My limited knowledge had been enough to get me by for basic projects, but the labs I’ve done so far have really bolstered what I know. And at $70, this is a real deal.
Next up: After completing all the labs, go back to the RC Car modifications and explore the possibilities of a TI Launchpad.
I get a lot of hotlink spam to this site, and normally I don’t particularly care. But when Mercado Libre (an online sales forum similar to E-bay) started using the pictures of one of the switches from my CCNA lab for a posting – I decided I’d try my hand as a sales person.
They could have at least resized the image – but here’s a snippet of what the posting looked like (note: since modern browsers cache imagery, you’ll likely have to hold down the shift button and hit refresh when looking at that post):
A few quick rewrite rules to tamper with that HTTP Referrer:
Numerous attempts to fix the EOC-2610 reboot bug have all been in vain. The problem is this: the device reboots fine until the wireless modules are inserted AND the device placed into Master mode (to serve as an access-point). Removing the modules, using GPIO pin 0 instead of 5 to reset, pointing things back to the bootloader at either address 0xbfc00000 or 0xa8000000, and numerous other tests all fail. I cannot seem to locate the source that Engenius uses (which would help in finding the solution), and neither Engenius nor Senao will respond back to emails or Facebook posts. (I’ve spoken to Engenius reps in California that have pointed me to Singapore – I’ve been on hold for almost an hour there to no avail).
But enough complaining, I’ll fix that bug eventually.
Update 8/10/2010: A coworker suggested double-checking voltage and direction on GPIO pin 0, as well as ensuring that AR2315_RESET_GPIO was set correctly this morning. Sure enough, I had a problem. I’ll release a very basic patch shortly. -=Bug squashed=-
Here’s the lowdown on how to build a basic linux kernel and rootfilesystem using OpenWRT and how to install your new firmware via the Redboot bootloader. I’m posting it as a quick introduction.
First off, use subversion to grab the appropriate source. In this instance, I’m using the BackFire port:
svn co svn://svn.openwrt.org/openwrt/branches/backfire
This contains everything you need to get started: toolchain, compiler, and scripts to pull in the source for the kernel and all packages that will be built. OpenWRT is very well documented, and it’s worth the time to read the README file as well to build and read the contents of the docs/ directory.
Menuconfig is used to determine not only kernel options, but packages that will be built as part of the firmware image.
cd backfire
make menuconfig
Obviously the first thing you want to do is set the appropriate Target System. For the Engenius EOC-2610, you’ll want to use Atheros AR2315:
Next, ensure you select squashfs for the Root filesystem image (under Target Image). Target Profile will only have one option (Default), so no changes are needed there. I generally use the default Global build settings (as they’re ample), but look them over if you want more advanced debugging options and to enable things like IPv6, etc.
The Image Builder option is to allow creation of a firmware image using precompiled binaries. I generally leave this and the other Main build options off..
Base system is exactly as it sounds: it’s a list of base utilities like dropbear, bridging utilities, iptables, mtd, and other items. In fact, all of the remaining options are fairly self-explanatory: Network, Libraries, Kernel Modules – they all mean what they say. If you can’t find an option, use “/” and search for it. Luckily a working firmware (that incorporates wireless) can be built with simply selecting the correct target (Atheros AR2315). You can add more features later.
When you’re ready to roll, a simple make V=99 will cause the OpenWRT system to download all the appropriate tools, compile them, and build your firmware. Obviously the first time you build an image, it will take some time. Subsequent builds focus solely on the kernel and root filesystem, not building the entire toolchain. The images are found under the bin/ directory.
Now that you have an image, one has to use the Redboot bootloader to upload it. There’s excellent documentation out there on this as well, but here’s a quick rundown:
Use a crossover cable to connect to the Engenius EOC2610’s Ethernet port. The bootloader defaults to using 192.168.1.1, so configure your IP accordingly (for this example, I’m using 192.168.1.2).
In one terminal, start pinging 192.168.1.1. Plug in the PoE adapter to start the 2610 and upon receiving an ICMP response, telnet to 192.168.1.1, port 9000. (Since you need to send a Ctrl-C to the Redboot bootloader, I have found that using puttytel seems to be the preferred method to connect to it). You may find a blank screen that doesn’t respond – if you do quickly disconnect and reconnect to the device.
When you see the above screen (and have hit Ctrl-C), you’re ready to go.
Ensure that you have a TFTP server on your local machine and that the kernel (openwrt-atheros-vmlinux.lzma) and rootfs (openwrt-atheros-root.squashfs) are in the TFTP root location. Next, configure the bootloader to use your system as a TFTP server (and ensure that it can connect to you):
RedBoot>
RedBoot> ip_address -l 192.168.1.1 -h 192.168.1.2
IP: 192.168.1.1/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.2
RedBoot> ping -h 192.168.1.2
Network PING – from 192.168.1.1 to 192.168.1.2
PING – received 10 of 10 expected
RedBoot>
Uploading the kernel is easy:
RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma -m tftp
Raw file loaded 0x80041000-0x80110fff, assumed entry at 0x80041000
RedBoot>
Ensure that everything was uploaded ok and that the checksums match:
RedBoot>
RedBoot> cksum
Computing cksum for area 0x80041000-0x80111000
POSIX cksum = 472679704851968 (0x1c2c8518 0x000d0000)
RedBoot>
If all is well, format the flash and burn the kernel image:
RedBoot> fis init
About to initialize [format] FLASH image system – continue (y/n)? y
*** Initialize FLASH Image System
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0x81000000 at 0xa87e0000:
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000
FIS directory 0xA87E0000 0xA87E0000 0x0000F000 0x00000000
RedBoot config 0xA87EF000 0xA87EF000 0x00001000 0x00000000
RedBoot> fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
… Erase from 0xa8030000-0xa8100000: ………….
… Program from 0x80041000-0x80111000 at 0xa8030000: ………….
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot>
You can then verify that the kernel is saved to flash:
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000
vmlinux.bin.l7 0xA8030000 0x80041000 0x000D0000 0x80041000
FIS directory 0xA87E0000 0xA87E0000 0x0000F000 0x00000000
RedBoot config 0xA87EF000 0xA87EF000 0x00001000 0x00000000
RedBoot>
Excellent – it is. Next up – the rootfilesystem. It’s loaded into memory via the TFTP server in the same fashion as the kernel (again, run a checksum to ensure all transferred fine):
RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-root.squashfs -m tftp
Raw file loaded 0x80041000-0x801a0fff, assumed entry at 0x80041000
RedBoot>
RedBoot> cksum
Computing cksum for area 0x80041000-0x801a1000
POSIX cksum = 3009821226 1441792 (0xb3663a2a 0x00160000)
RedBoot>
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty’.
iscale=16
oscale=16
A87E0000-A8100000 690000
With this information at hand, you can burn in the Root Filesystem, utilizing all the free space:
RedBoot> fis create -l 0x690000 rootfs
… Erase from 0xa8100000-0xa8790000: ……………………………………………………………………………………………
… Program from 0x80041000-0x801a1000 at 0xa8100000: ………………….
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot>
That’s it – you’ve now uploaded your firmware to the device. Next, lets just double-check and ensure all is well, and finally – let’s boot our new image:
At this point, detach from the telnet session (no output will be seen when the device boots), and once the system has booted – connect using telnet (or SSH if compiled).
Next up – customize your firmware image and build your own packages – and check out the upcoming CPLUG meeting on unleashing your home routers potential.
I’ve been meaning to look at the voice capabilities of the 1750’s I’d purchased while studying for my CCNA
(In previous posts I misspoke and claimed they were 1751’s, they are in -fact 1750’s). The Cisco 1750’s have a slot for Voice Interface Cards, something I’ve not worked with – and something that influenced my purchase of the routers.
I quickly realized I’d need a Digital Signal Processor (PVDM) card (~$90 on ebay) in addition to the VICs – AND I didn’t have enough memory OR flash to run an appropriate IOS image. The Flash upgrade to 32M was appx $30.00, with memory running about the same. Things started to quickly add up.
Which made me look at the Cisco 2621 also sitting on my work-bench. Research quickly revealed I was looking at a much more affordable path. I got a pretty good deal on an NM-2V with 2 FXO cards (ebay – about $115.00 – with the added bonus that the seller lives in my same city, so I saved on shipping and we met in an Aldi’s parking lot):
The NM-2V supports two VIC cards… the FXO (Foreign eXhange Office ~= PSTN origination/termination) and FXS (Foreign eXchange Service ~= provices dialtone service) cards generally run about $50.00 on ebay, with the NM-2V averaging around $14-$45. So all in all, I paid at or below the average price for the entire package, and it all arrives at the same time. (There are other types of cards as well, but FXO and FXS are the only types I’m concerned with)
My first task is to get enough memory installed in my 2621 to support an IOS image with VOIP and ADSL capabilities. I’d searched around for some time before finding a site that I really like – www.parts-quick.com. They provide full specs on each router, the max and min memory capabilities, flash upgrades, etc.. and the prices aren’t bad either.
My overall goal is to have one device that handles everything related to the telephone line: DSL termination/bridging, PSTN gateway, and dialtone server – a device I’m affectionately calling “beigebox0″. This will allow me to replace my Zyxel DSL bridge and Linksys PAP-2T, plus actually hook the PBX into the PSTN. My current layout (an Asterisk box + Linksys PAP-2T) has only SIP origination/termination, leaving an unused POTS line coming into my house. The new setup will still utilize the Asterisk PBX for voicemail and dialplan processing (as well as long distance over SIP, and an IAX2 trunk to Telephreak) , but use the Cisco 2621 for local call termination (calls in my native ratecenter).
Routing (and PPPoE) will still be handled by the Quagga router. The Quagga also has a Courier V.32 Voice modem connected to it for troubleshooting dialup POPs, wardialing the 900 or so phone numbers my company owns (for auditing purposes), and adding a backup connection in the event the DSL line goes dead (of course if dialtone is gone also, I’m out of luck). The modem _could_ be moved over to the 2621’s AUX port, but as all routing occurs at the Quagga, this layout makes more sense.
The link between the 2621 and the PBX could have been done a number of different ways. In the end, I opted to treat the 2621 as being on the WAN side of things, and I am using its management IP for that SIP endpoint. This gives me the ability to filter traffic between the PBX and the “beigebox” at the router. Directly connecting the 2621 to the PBX would reduce hop-count, however also add another location where firewall rules need to be managed and monitored aggressively.
Calls made from the home phone hit the 2621 via the FXS port, and are SIP-ed over the FastEthernet interface through the router and to the PBX. If the call is long-distance it heads BACK out the router to my SIP provider, with local calls heading back to the 2621 for connection to the PSTN. All call routing (local and long distance) is determined at the PBX. (The one exception being 911, which is immediately bridged at beigebox0)
Incoming calls from the PSTN (via the FXO voice-port) will soon be sent to the PBX for handling – which will initially sends the call back to beigebox0 to ring the home phone (via the FXS port), and following a number of rings sent to voicemail on the PBX.
So far, the layout has functioned perfectly. Next up – finish inbound handling of calls on the PBX (voicemail, etc)
Cisco 2621 config snippet:
hostname beigebox0
voice rtp send-recv
!
voice service voip
sip
bind all source-interface FastEthernet0/0
voice-port 1/0/0
description POTS line
ring number 10
!
voice-port 1/0/1
!
voice-port 1/1/0
description HomePhone
timeouts call-disconnect 10
!
voice-port 1/1/1
description ModemLine
timeouts call-disconnect 10
!
!
!
dial-peer voice 100 pots
description Dialing 411
destination-pattern ^411$
port 1/0/0
!
dial-peer voice 101 pots
description Dialing 911
destination-pattern ^911$
port 1/0/0
!
dial-peer voice 102 voip
description TelePhreak
destination-pattern ^666$
session protocol sipv2
session target sip-server
session transport udp
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 200 pots
description PBXManualCallRouting
destination-pattern ^70001…….$
port 1/0/0
forward-digits 7
!
dial-peer voice 300 voip
description PBXConnector
destination-pattern .T
session protocol sipv2
session target sip-server
session transport udp
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
sip-ua
calling-info pstn-to-sip from name set beigebox
calling-info pstn-to-sip from number set 70001
sip-server ipv4:<PBX IP>:5060
!
!
telephony-service