Hacking Another Modem

So someone was nice enough to donate a 2-Wire 3801HGV to me. For what purpose? I don't have U-Verse! Why to root it of course! Apparently no one knows how to make a decent modem these days. So, my goals for this are to get as much info as possible, hopefully find a remote exploit like I did with the NVG510 and publish what's possible and what's not, as well as lay the groundwork for future hackers that probably know a lot more about this stuff than I do. My primary goal at this very second is to get a serial port working and get a root shell.

I'll publish more as I work through this

Posted: 5/21/2013 12:43:19 AM

SD cards on Mbed

So, I don't understand why, but apparently hooking up SD cards to an Mbed isn't just "plug in these wires and import this library"

The official library OR something in my circuitry seems to have a bug. So that I won't forget how it all works though here is my quick write up:

First off, I'm using the new Sparkfun SD card breakout board, so I've "translated" the pinouts between SPI and SD formats:

**NEW** SparkFun SD Breakout Board
MicroSD Breakout    mbed
   D3  o-------------o 20    (DigitalOut cs)
   CMD  o-------------o 11    (SPI mosi)
   VCC o-------------o VOUT
   CLK o-------------o 13    (SPI sclk)
   GND o-------------o GND  
   D0  o-------------o 12    (SPI miso)
   CD  o
   D1  o
   D2  o

Then, for some reason, the SD card library for mbed would never work the first time I ran it. So, I had to fork it and make it so that "if initialization fails, try one more time, just in case". It's delightfully horrible, but I'm tired of trying to find the correct solution to the problem

That forked repo is located at SDFileSystem_tryagain

After doing all this, it finally "just works"

Notes about my setup:

  • The try again bit could be caused by noise. the SD card is about 2-3 inches from the mbed and requires long lines
  • I'm using a 4G SDHC card produced by SanDisk
  • I have no idea what I'm doing with hardware :)

Hopefully this helps some helpless soul searching on google. I know I had a ton of problems finding any reference to this problem, even though people have told me that it does happen

Posted: 4/16/2013 5:37:39 AM

LightVM + MbedConsole = Not Dead Yet!

So, I've recently been wanting to really get MbedConsole to a all-in-one system, complete with a programming environment. After spending a few months shifting around different ideas on the best way to implement a programming language in such a small amount of resources, I've decided to go another route.

Yesterday, I created a new bitbucket repo called LightVM. Here, I will implement a very lightweight VM complete with a self-hosted assembler with bootstrapping. After getting it to run good on my PC I'll port it to the mbed and eventually also see if it'll work on an ATMega16 or some such.

So, what all will be added to MbedConsole?

  1. LightVM implementation complete with system calls
  2. Assembler for LightVM which runs in LightVM
  3. A very basic file editor. It'll probably be as horrible as ed
  4. "real" filesystem access.
  5. Because the semi-hosted filesystem sucks horribly, I'll be trying to add SD card support

So again, not dead! Check out LightVM. When it gets to a usable state, I'll start working on the bootstrapping assembler and then the actual assembler. The file editor will probably not be made in LightVM for performance and cost of implementation reasons.

Posted: 4/5/2013 12:16:46 AM

MbedConsole Status

I just felt I should update on the status of MbedConsole. A formal release is coming soon! I'll probably release it before my Forth interpreter is completely done after all though.

Anyway, I received my nice PS/2 Keyboard Breakout today. I soldered some pins on it and got it to read scan codes from a keyboard with a bit code. So that part is working pretty well. The next big thing is getting it to correctly translate those scancodes to ASCII text. I've done this kind of thing before, so it shouldn't be too hard.

So far, about 8K of RAM is used up in all of the overhead, which I don't think is too terrible. My goal is to have 20K available to the Forth compiler/interpreter thing and I think I will be able to easily manage that even with a couple of utilities. Of course, I'm also already up to 32K of Flash, but that's no big deal since I have 512K

Anyway, I expect to release the code in probably another week or two. Hopefully with some small demo of how awesome it is.

Posted: 9/26/2012 3:28:54 AM

Mbed Status Update

So, I've been working more and more on my recent mbed project. I've decided to go for something really interesting and not too hard.

The project is named MbedConsole because I'm bad at names. Anyway it will feature

  1. PS/2 keyboard support
  2. Monochrome VGA. 640x480, with text and/or graphics
  3. A simple shell
  4. A Forth programming environment
  5. About 20K or so of usable RAM for the Forth environment
  6. SD card support of some kind maybe

All of this works with no external components but a few resistors. This means, it's going to be awesome!

About the Forth environment:

I'm not aiming at all for Forth compatibility, but it definitely has a Forth feel to it(everything is in a stack). The big thing that this is enables is semi-self hosting.. That means I can write some system software in Forth. Because Forth programs don't constantly occupy RAM, this means I can make a "real" computer with a whole 20K of memory. After getting the Forth environment created I'd like to rewrite my shell to use Forth as well. If I really want to get awesome I could even write my Forth implementation in Forth and leave on the virtual machine in native code... I'm not that brave.

Anyway, the Forth environment was at first planned to be interpreted only. Now however, I've found that compiling to a virtual machine is about 10 times easier than trying to interpret it directly. It also will save memory, and probably will be faster. The virtual machine is extremely simple. and should already be Turing complete. Forth however is not quite there yet. It's easy to parse, but string handling in C is never quick to implement.

The end goal for me is to have a very retro-feeling operating system running on the mbed powered by it's Forth interpreter. Things I want to have:

  • A simple command shell for file management
  • A way to save the Forth programs you write
  • A simple text editor of some sort
  • At least one super simple game

If I remove graphics support, I can also add in network support, but I highly doubt there will be anywhere near enough RAM to be useful for Forth after including a TCP/IP stack. I believe it takes about about 16K by itself :(

Anyway, this project will eventually be released under BSD license. I want to get it half way working before I release it.

Posted: 9/21/2012 5:10:27 AM

Motorola NVG510 Reverse Engineering Information

Goto this page unless you're wanting to do some soldering onto your modem This page is only here now for historical reasons

Motorola NVG510 Reverse Engineering Information

This information is still a work in progress, and if it doesn't work, fries your modem, or kills your dog. Don't blame me just because you listened to a random blog on the internet. USE AT YOUR OWN RISK

Rooting It with the WebUI: There is a way to root the modem without opening it up and soldering on it. See http://lastyearswishes.com/blog/view/4fcff51b4aa5d8385420c706 If you don't want to solder onto your modem, use this. In fact, unless you plan on opening the device up or doing some real hacking, everything should be located there. Again goto http://lastyearswishes.com/blog/view/4fcff51b4aa5d8385420c706

Update: A true bridge mode I believe has been found. Scroll to the bottom for more

Big Update: A way to the root shell has been found. At the serial console shell, all that must be entered is ! and it'll take you there.

Introduction

Hopefully, you reached this web page because you are like me. Tired of the shitty NVG510 modem that you can't do anything about because of AT&T. Well, if you have a bit of electronics know how, and are comfortable with a command line, you can make your modem actually pretty decent. I happened to have an extra one of these things(though both work on my U-Verse account) so I decided what better way to put it to use, than to tear it apart. That said, I'm fairly surprised I didn't fry it in some way. You might not be that lucky. Be prepared to buy a new one if things don't work out.

The Basics

The FCC manual should be the first step in understanding the operation of the NVG510. It can be found at this website

To get access to the described console in the manual however, I'm 99% sure that you must open it up. I've yet to find anything that would allow me to enable the console on an unopened modem.

To open it up, on the underside there are 4 rubber/felt pads. Remove those and under two of them there will be screws. Remove the screws and it should open up fairly easily.

The Serial Port

Now take a look at the circuit board. As you can see, there is plenty of things to modify. There are plug-ins for an external wifi antennae as well as a possible JTAG connector that is unpopulated. You should now look for 4 unpopulated pins labeled "J10". This is a 3.3V/TTL serial port. The square hole is Ground, the hole next to it is 3.3V. The hole next to power is TX and next to that is RX.

Those four holes ended up being fairly difficult to desolder for me. The RX and TX luckily are quite easy to desolder and insert pin headers into, and luckily is all you need. I also soldered a wire into GND, though not properly. Soldering the GND wire is very difficult because it's connected to a fairly large ground plane and I couldn't get it hot enough for all of the solder to melt at one time, so I just (improperly) added some solder to the top of it and stuck in a wire. It's worth it to try reading from the serial port now.

To hook this up to you computer you'll need a proper 3.3V serial cable. Computers natively use 5V serial ports, so they must be level shifted. Also, if you're going to hand-make this cable, you'll need to use an isolator. Or, if you'll feeling extra ambitious, (like I was) you can connect a grounded supply up to it. I managed this by using a PC power supply. I connected GND to the negative terminal, and 12V(yellow) to the positive terminal.. I soldered wires straight to the PCB, but a barrel jack that fits would have been a lot more proper.

Also, the way I accomplished the serial port bit is just use an FPGA I had lying around. My FPGA has a USB-Serial FTDI built in, so all I had to do was make a quick VHDL design like so:

ExtTX <= PCRX;
PCTX <= ExtRX;

And then it did all the heavy lifting, and my FPGA works off of 3.3V already, so it did the level shifting for me.

Now, at first I had a problem in that I never received data from the serial port. I ended up finding a 10K pull up resistor on both RX and TX that I had to remove and then create a solder bridge over. If you're having problems getting any data from the modem, desoldering is worth a try. They are just right of the 4 pins, and are easy to trace out to make sure you got the right two. They are extremely tiny though. Remember, flux is your friend.

The serial port on the modem uses 57600bps, 8-bit data, and 1 stop bit. That information I got from wikidevi

So I simply did

$ screen /dev/ttyUSB1
$ sudo stty -F /dev/ttyUSB1 57600 cs8 -cstopb

Where ttyUSB1 is the USB serial port provided by my FPGA FTDI.

Now, you should be able to turn on the modem and see it's boot log and dmesg. After that press enter into the console and it should pop up something like

Axis/1234565678> 

The Console

This console is actually fairly simple and easy to use, and breaks out everything that you can configure on the modem. But, it is not the console described in the FCC manual.

This is the help text:

Axis/124578433> help
help [command]                 : Get help.
history                        : Show command history.
get OBJ.ITEM                   : Get the value of OBJ.ITEM (ITEM is a
                                 parameter or status). ### Hint: run 'info
                                 OBJ.params' or 'info OBJ.status' to get a
                                 list of the OBJ's parameters and status.
set OBJ.ITEM VALUE             : Set the value of OBJ.ITEM to VALUE.
info INFO [ARGS ...]           : Get the INFO information (expert mode).
new OBJ [NAME]                 : Create an object with an (optional) name
                                 (requires an 'apply')
del OBJ                        : Delete an object (requires an 'apply')
aget OBJ.ITEM ATTR             : Get the OBJ.ITEM's ATTR attribute.
aset OBJ.ITEM ATTR VALUE       : Set the OBJ.ITEM's ATTR attribute to VALUE.
name OBJ [NAME]                : Get or set the OBJ's "name" (specify a new
                                 name to set it).
names [OBJ]                    : Recursively show all object names.
validate [OBJ]                 : Validate OBJ, or the entire database if no
                                 OBJ specified.
apply                          : Apply changes to the database (changes are
                                 NOT saved).
revert                         : Revert the database by discarding your
                                 changes.
save                           : Save the database (rewrites config.xml).
defaults                       : Reset the system back to the factory
                                 defaults (deletes config.xml).
dump [OBJ [LEVELS]]            : Dumps the OBJ's parameters, or the entire
                                 database. Use the optional LEVELS parameter
                                 to limit the depth of the database tree.
sdump [OBJ [LEVELS]]           : Dumps the OBJ's status, or the entire
                                 database.
tdump [TEMPLATE [LEVELS]]      : Dumps the template, or the entire SDB schema.
dirty [OBJ]                    : Displays which parameters are dirty.
run CMD [ARGS ...]             : Run the SDB's CMD command (expert mode
                                 only!).
event EVT [ARGS ...]           : Send the EVT (event number) to the SDB
                                 (expert mode only!).
console [on | off]             : Direct all log messages to this console.
                                 Without arguments, toggles on and off.
log [OPTIONS]                  : View log messages. See "log help" for more
                                 information.
voiplog [OPTIONS]              : View log messages. See "log help" for more
                                 information.
mfg [OPTIONS]                  : Set or view MFG parameters. See "mfg help"
                                 for more information.
mirror [PORT CAPTURE-PORT] | "off" : Mirror Ethernet traffic on PORT so that it
                                 may seen on CAPTURE-PORT. Specify "off" to
                                 turn mirroring off.
resetstats [OBJ] ["all"]       : Reset any statistics the object may have.
                                 The optional "all" argument will recursively
                                 reset all children's stats as well. If only
                                 "all" is given (OBJ is omitted), this will
                                 reset all statistics starting at the root
                                 node.
metadata OBJ.PARAM             : Returns metadata information about a given
                                 parameter.
fwinstall URL | "last"         : Install a firmware image. Use "last" to
                                 reuse the last URL.
crashdump ["erase"]            : Shows the most recent crash dump contents.
                                 The optional "erase" will erase both current
                                 and last saved crash dump contents.
reboot [N] | ["cancel"]        : Reboot the router in N seconds (default is
                                 2). "cancel" argument can be issued to
                                 cancel a previous reboot command.
source FILE                    : Read and process commands from FILE.
. FILE                         : An alias for 'source'.
exit                           : Exit from this shell.
quit                           : An alias for 'exit'.
magic                          : Enter magic mode.
crash                          : Read and Write the Memory mapped registers

Well, seems simple enough then doesn't it? I don't understand the difference in sdump and dump, but I don't think it matters too much.

Now what you want to probably do next is do mfg show and copy those values and then do dump and copy that text.

If you're new to screen, what you need to do is have defscrollback 10000 in your ~/.screenrc and then to copy the text, just push CTRL-A and then [. Then push space to get the first "mark" and then scroll up (with pg-up/up arrow) and press space again. After that, just do CTRL-A and then > and it will write what you just "copied" into /tmp/screen-exchange.

From there, you can easily browse all of the available configuration options.

Configuration

As you can tell from the dump log, there are a ton of configuration options. Here I'll give you a hint to the more useful ones, as well as some configuration stuff to be aware of

DNS problem fix:

ip.dns.domain-name             = att.net
ip.dns.primary-address         = 99.99.99.53
ip.dns.secondary-address       = 99.99.99.153
ip.dns.proxy-enable            = on
ip.dns.override-allowed        = off

You should be able to change these to something more appropriate. override-allowed should be turned on(otherwise I believe they will be reset by DHCP over the DSL link).

So, let's say we want to set the primary name server to 8.8.8.8, google's sane primary name server. We would enter this at the command line:

set ip.dns.primary-address 8.8.8.8

Now if that's about all the configuration we want to do and we want to save our changes and make the modem notice them, we have to do a few commands:

validate
apply
save

You don't necessarily have to do validate, but I assume it's safer to use it I think. I believe that this is what happens:

  1. validate will validate the changes to make sure that no data was input in a way that wouldn't make sense (like if nameserver was set to 921.123.45.673)
  2. apply will actually cause the modem to notice the changes and begin executing using those changes you've made
  3. save will cause the changes you made to persist after reboot. I assume it saves it to flash with this command.

Enabling Telnet:

mgmt.shell.ssh-port            = 0
mgmt.shell.telnet-port         = 0

These you should change to what port you want it to run on. Note though that I've yet to figure out the username and password used for SSH. I've searched through both the dump and through the GPL source code and can't find any hints really.

So, to enable these you can just do something like

set mgmt.shell.ssh-port 22
set mgmt.shell.telnet-port 23
validate
apply
save

If you want to enable remote access to telnet and/or ssh (I highly recommend not opening up telnet to the world) you can modify these values to something appropriate:

mgmt.remoteaccess[3].protocol  = telnet
mgmt.remoteaccess[3].port      = 0    XX change this to 23
mgmt.remoteaccess[3].idle-timeout = 5
mgmt.remoteaccess[3].total-timeout = 20
mgmt.remoteaccess[3].max-clients = 4
mgmt.remoteaccess[4].protocol  = ssh
mgmt.remoteaccess[4].port      = 0     XX change this to 22
mgmt.remoteaccess[4].idle-timeout = 5
mgmt.remoteaccess[4].total-timeout = 20
mgmt.remoteaccess[4].max-clients = 4

Enabling UPnP:

I haven't confirmed this, but I believe UPnP can be enabled by changing this to on:

mgmt.upnp.enable               = off

Disabling "Potential connection issue" and "no connection" redirect loop crap:

mgmt.lan-redirect.enable       = on

Change it to off. lan-redirect is what causes that extremely annoying redirecting to happen when the connection is lost or "has possible problems". What the modem will do is when you request a nameserver, it will, instead of sending back no route, timeout, or the actual name servers response, it will instead make every domain forward to 192.168.1.254, so that you can then load an HTML page that causes a redirect(but doesn't set it to do-not-cache) to /cgi-bin/home.ha... So basically, you click do not show, yet the page continues to try to redirect due to modern web browser caching and the lack of a no-cache directive on the redirect page.

Disabling the DHCP server:

conn[1].dhcps-enable           = on

Note that you'll have to configure a static connection to the modem to access it. I don't see much of a point in disabling it completely, as there is (still) no true bridge mode unfortunately.

Bridge mode discoveries:

There does not appear to be a straight forward PPPoE bridge mode, even with full control over the device. I believe there could be a way by doing some special stuff with the link configuration objects, but I don't see anything obvious so far

Possible money saver

From this bootloader, you can change a lot of things AT&T probably would frown upon. Basically, you can make it look like another modem. I'm not 100% sure, but I believe 1 modem is tied to 1 account, making modems that are used worthless. I'm not for sure about this though and will have to test it and research it more. I don't recommend changing anything in the mfg section.

Conclusion

The NVG510 is really a decent modem, but has been kiddie-proofed so hard that it hurts. I hope this guide helps you to taking full control of your modem. Also, I don't recommend trying to evade your U-Verse accounts capabilities. I imagine AT&T won't care much if they catch you modifying your modem... they will care if you modified it to reach 16Mbit speeds when you only have a 3Mbit account though, and I'm sure they keep tabs on it. Don't be stupid.

Same goes for trying to boost wifi power or use channels not specified for use in your country.

True Bridge Mode

A very often wanted feature of the NVG510 is for it to just get out of your way and let your (hopefully more sane) router to deal with all the firewall and NAT business. After quite a bit of experimenting and starting over with default and a bit of an accident, I believe I've figured it out.

Some of the values in the NVG510's configuration "database" appears to be magical, and lots of assumptions have to be made without real technical documentation. So, let's look at the link object that appears to be linked to WAN and LAN connections in an assumed manner.

Here is what was in my modem's dump about links. Your's should look similar:

link[1].type                   = ethernet
link[1].igmp-snooping          = off
link[1].mtu-override           = 0
link[1].port-vlan.ports        = lan-1 lan-2 lan-3 lan-4 ssid-1 ssid-2 ssid-3 ssid-4
link[1].port-vlan.priority     = 0
link[2].type                   = ethernet
link[2].mtu-override           = 0
link[2].supplicant.type        = eap-tls
link[2].supplicant.qos-marker  = AF1
link[2].supplicant.priority    = 0
link[2].port-vlan.ports        = vc-1
link[2].port-vlan.priority     = 0
link[2].tagged-vlan[1].ports   = ptm
link[2].tagged-vlan[1].vid     = 0
link[2].tagged-vlan[1].priority = 0

ptm is the PPP connection. So we basically want for the PPP connection to be routed straight to an ethernet port so our router can handle it. So here is what I did

set link[1].port-vlan.ports "lan-2 lan-3 lan-4"
set link[2].port-vlan.ports lan-1

The first command sets the LAN link so that only the LAN ports 2-4 is used. The next link sets the link for the WAN side of the link. Previously, the port is vc-1. I assume vc-1 is hardwired to magically go to the LAN somehow. Anyway, replacing vc-1 with lan-1 basically makes the equivalent of a PPP bridge.

On the router side, all you have to do is use that port and the modem will do all of the PPP authentication, and I assume MRU shifting to 1500.. All your modem will get is a raw stream from AT&T's servers. So if you send it a DHCP client request, you'll get a response straight from AT&T's servers.

This is the only configuration required as well. This will short through all of the modem's crappy configuration and directly forward it to the first ethernet port(the one closest to the barrel jack power adapter).

And if for some odd reason you need to access the actual modem(such as for reconfiguration), just plug your network cable into another port. The built-in DHCP server runs just as before, except it will never be connected to the internet.

Configuration Template You can dump this for yourself, but to see what Motorola's "template" is for it's configuration options you can check out this pastebin. If you don't know what options a configuration object supports, this is a good bit to look at. Though a few things in the template don't exist in my NVG510 at least and will cause crashes if objects are created. (cifs will not work for me)

Posted: 6/4/2012 7:54:36 AM

Building the Arduino Libraries from the command line

If you're like me, (few probably are) then you're one of those that likes long-term solutions instead of short-term workarounds.

Well, I've been building an FM transmitter using an Ardunio(more details about that later). When I first went to write code for my Ardunio, I noticed that my libraries are massively out of date. So out of date that most of the Ardunio code I found would no longer work for me. So, it was time to upgrade. I don't remember how I got the Arduino library before, so I set out to download a copy of it...

After an hour of searching... hmmm no one hosts a copy of it for some reason. Well, I guess I'll build it. I look at the ill-documented mess that is the Arduino source tree... no makefile for the library. The common solution is to run the Arduino IDE once, build a sketch, and copy the library from there. Well, that's not good enough for me. So I made a makefile and set out to get it to build from the command line

Directions:

  1. Download a copy of the Arduino IDE source code
  2. Copy the contents of hardware/arduino/cores/arduino to a new directory I'll refer to as arduino_build
  3. Copy the pins_arduino.h file from whichever Arduino variant is yours from hardware/arduino/variants (check boards.txt if you're not sure) to arduino_build
  4. Add this makefile to arduino_build:

.

#<Copyright Header>
#Copyright (c) 2012 Jordan "Earlz" Earls  <http://lastyearswishes.com
#All rights reserved.
#
#Redistribution and use in source and binary forms, with or without
#modification, are permitted provided that the following conditions
#are met:
#
#1. Redistributions of source code must retain the above copyright
#   notice, this list of conditions and the following disclaimer.
#2. Redistributions in binary form must reproduce the above copyright
#   notice, this list of conditions and the following disclaimer in the
#   documentation and/or other materials provided with the distribution.
#3. The name of the author may not be used to endorse or promote products
#   derived from this software without specific prior written permission.
#
#THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
#INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
#AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL
#THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
#EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#</Copyright Header>

HDRS = Arduino.h binary.h Client.h HardwareSerial.h IPAddress.h new.h pins_arduino.h Platform.h Printable.h Print.h \
    Server.h Stream.h Udp.h USBAPI.h USBCore.h USBDesc.h WCharacter.h wiring_private.h WString.h


OBJS = WInterrupts.o wiring_analog.o wiring.o wiring_digital.o wiring_pulse.o wiring_shift.o CDC.o HardwareSerial.o \
    HID.o IPAddress.o main.o new.o Print.o Stream.o Tone.o USBCore.o WMath.o WString.o

#may need to adjust -mmcu if you have an older atmega168
#may also need to adjust F_CPU if your clock isn't set to 16Mhz
CFLAGS = -I./ -std=gnu99  -DF_CPU=16000000UL -Os -mmcu=atmega328p
CPPFLAGS = -I./ -DF_CPU=16000000UL -Os -mmcu=atmega328p

CC=avr-gcc
CPP=avr-g++
AR=avr-ar


default: libarduino.a

libarduino.a:   ${OBJS}
    ${AR} crs libarduino.a $(OBJS)

.c.o: ${HDRS}
    ${CC} ${CFLAGS} -c $*.c

.cpp.o: ${HDRS}
    ${CPP} ${CPPFLAGS} -c $*.cpp

clean:
    rm -f ${OBJS} core a.out errs

install: libarduino.a
    mkdir -p ${PREFIX}/lib
    mkdir -p ${PREFIX}/include
    cp *.h ${PREFIX}/include
    cp *.a ${PREFIX}/lib

And then just run

make
make install PREFIX=/usr/arduino (or whatever)

And then to make use of the compiled libraries and such you can use a simple makefile like this:

default:
    avr-g++ -L/usr/arduino/lib -I/usr/arduino/include -Wall -DF_CPU=16000000UL -Os -mmcu=atmega328p\
      -o main.elf main.c -larduino
    avr-objcopy -O ihex -R .eeprom main.elf out.hex
upload:
    avrdude -c arduino -p m328p -b 57600 -P /dev/ttyUSB0 -U flash:w:out.hex

all: default upload

Also, if you try to compile the libraries in libraries/ you'll get a linker error if you don't do things in the right order. For instance, I had to do this to use SoftwareSerial:

avr-g++ -L/usr/arduino/lib -I/usr/arduino/include -Wall -DF_CPU=16000000UL -Os -mmcu=atmega328p\
   -o main.elf main.c -lSoftwareSerial -larduino

The -larduino must be the last library on the command line

Anyway, this was a pretty easy way to compile it for me. As future versions of the Ardunio come out, this makefile should be fairly future-proof, requiring just a few modifications to OBJS and HDRS. Also, this makefile should work with both BSD make and GNU make

Also, if you're like me and you weren't interest in building the library, just wanted to download a copy of the binary, here is a copy: Arduino library (built using the "standard" pins_arduino.h)

Posted: 3/22/2012 7:24:54 PM

mbed :)

I got my mbed today. It actually is extremely simple. It took me a bit to figure out the options to give to mount so that I could write to the umass device without sudo. But that's not mbed's fault. Anyway, Very simple and I've just compiled the hello world program and it works. One note for anyone who has problems with their mbed and programming: When you download the file onto the device(on Arch Linux at least), it won't actually put the program on the device until some undetermined time. To force it to put it on there now, you'll have to run the sync command after downloading a program.

Posted: 3/26/2011 3:56:14 PM

Dear Ashley

Stop making me wait on you to get off work lol.

So I'm stuck at taco mayo waiting for my girlfriend to get off work. My only form of entertainment is my cell phone. What else to do than blog?

In other news, the mbed platform looks like an awesome step up from the arduino. It has an arm processor and like 512k of ROM and 64k of RAM. I'm interested in all 3 aspects of that. And its breadboard compatible requiring no surface mount soldering. It will probably be my next electronics purchase. Also, sparkfun(link pending) has an awesome terminal printer which prints on thermal paper. Who needs to log things to a computer when you got a printer :D. Only bad thing is its a bit on the pricey side. I think its like 40 bucks.

Posted: 3/14/2011 12:16:56 AM