Archive for the ‘Projects’ Category.

A Makefile for NXC code

# A Makefile to compile NXC code using NBC
# Copyright (C) 2008 Gary French
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#

INCLUDEDIR =../include
NBC=/usr/local/bin/nbc
NBC_FLAGS=-I=$(INCLUDEDIR)
#optional compiler optimizations
# NBC_FLAGS=-I=$(INCLUDEDIR) -Z1
# NBC_FLAGS=-I=$(INCLUDEDIR) -Z2

#this can also be explicitly set
# NXC_FILES := TheProgram.nxc
NXC_FILES := $(shell ls -1 -t -F *.nxc  2>/dev/null | grep '\.nxc')
RXE_FILES := $(NXC_FILES:.nxc=.rxe)

BYTECODE_FILES := $(NXC_FILES:.nxc=.bytecode)
LISTING_FILES := $(NXC_FILES:.nxc=.listing)
SYMTABLE_FILES := $(NXC_FILES:.nxc=.symtable)

#the targets can be called individually, or called from the "all" target
#all: compile bytecode listing symtable
all: compile

compile: $(RXE_FILES)
%.rxe: $(NXC_FILES)
	@echo "compiling $<"
	$(NBC) $(NBC_FLAGS) -O=$@ $<
	@echo

bytecode: $(BYTECODE_FILES)
%.bytecode: $(NXC_FILES)
	@echo "generating bytecode for $<"
	$(NBC) $(NBC_FLAGS) -b -nbc=$@ $<
	@echo

listing: $(LISTING_FILES)
%.listing: $(NXC_FILES)
	@echo "generating code listing for $<"
	$(NBC) $(NBC_FLAGS) -b -L=$@ $<
	@echo

symtable: $(SYMTABLE_FILES)
%.symtable: $(NXC_FILES)
	@echo "generating symbol table for $<"
	$(NBC) $(NBC_FLAGS) -b -Y=$@ $<
	@echo

clean:
	@echo "cleaning up..."
	-rm $(RXE_FILES)
	-rm $(BYTECODE_FILES)
	-rm $(LISTING_FILES)
	-rm $(SYMTABLE_FILES)
	@echo

.PHONY: clean bytecode listing symtable

Compiling and Transfering NXC Code to a NXT-Brick Under Fedora Linux

you must be able to communicate with the NXT Brick for any of the following to be applicable. there are a few “how-to”s available, including this post.

I am using the compiler available at Next Byte Codes & Not eXactly C site. This is a simple package package to “install” (simply copying the executable from the tar/gzip to /usr/local/bin did it for me), and is wonderfully documented.

I am using a modified version of a script provided by Jan-Klaas Kollhof:

#!/bin/sh
set -e

_nbcpath=/PATH/TO/NBC/EXECUTABLE/DIRECTORY

_dirname=`dirname $1`
if [ "${_dirname}" == "." ]; then
	_dirname=$(pwd)
fi
_basename=`basename $1 .nxc`

echo "compiling ${_basename}.rxe from ${_basename}.nxc..."
${_nbcpath}/nbc \
	-O="${_dirname}/${_basename}.rxe" \
	-nbc="${_dirname}/${_basename}.nbc" \
		"${_dirname}/${_basename}.nxc"

echo "sending ${_basename}.rxe to brick..."
cd "${_dirname}"
nxt_push "${_basename}.rxe"

as should be apparent, /PATH/TO/NBC/EXECUTABLE/DIRECTORY will need to be altered to suit your environment.

the “-nbc” switch will save the generated “Next Byte Code” to YOUR_CODE_FILE_NAME.nbc. the resulting file is not only interesting to poke around in, but may help when optimizing for size.

currently, I am having some issues with nxt_python, documented here.

nxt_pull, a companion program for nxt_push

while working with nxt_python and a few applications written in NXC, I found I had a need to get files from the NXT Brick with a minimum of fuss. The following python script will “pull” a single file from the NXT Brick. Wildcard behavior is undefined, and is planned for version 0.2.

example usage:

[gary@motoko]# nxt_pull log.txt

code:

#!/usr/bin/env python
#
# nxt_pull:
#   Pull a file to a LEGO Mindstorms NXT brick,
#   based on Douglas P Lau's nxt_filer and nxt_push
#   Copyright (C) 2008 Gary French
#   Version: 0.1
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

import sys
import nxt.locator
from nxt.brick import FileFinder, FileReader, FileWriter

def read_file( b, fname ):
	r = FileReader(b, fname)
	r.__enter__()
	try:
		f = open(fname, 'wb')
		print 'Pulling %s ...' % (fname),
		try:
			size = 0
			for data in r:
				f.write(data)
				size += len(data)
		finally:
			f.close()
			print 'read %d bytes' % size
	finally:
		r.__exit__(None, None, None)

if __name__ == '__main__':
	sock = nxt.locator.find_one_brick()
	#sock = nxt.locator.find_one_brick(host='00:16:53:XX:XX:XX')
	if sock:
		b = sock.connect()
		read_file( b, sys.argv[1] )
		sock.close()

Error: “bluetooth.BluetoothError: (115, ‘Operation now in progress’)” while using nxt_python

currently, to avoid a “bluetooth.BluetoothError: (115, ‘Operation now in progress’)” error, I have to:

  1. turn the Brick’s Bluetooth off
  2. turn off the Brick
  3. restart Bluetooth services
  4. turn on the Brick
  5. turn the Brick’s Bluetooth on

it acts as if something is not cleaning up after itself properly.
I’m sure I’ll figure that one out, but I have more pressing concerns at the moment. if anyone has some insight on this issue I’d appreciate the comment.

current workaround:

  • use “hcitool scan” to find the MAC
  • modify nxt_push line 49 from:
    sock = nxt.locator.find_one_brick()

    to:

    sock = nxt.locator.find_one_brick(host='00:16:53:XX:XX:XX')

as one might suspect, this workaround is applicable in any other similar situation.

Setting up Bluetooth communication with a NXT Brick under Fedora linux

it is vital that the following python packages are installed:

to test PyBlueZ, the following can be used (code by Albert Huang <albert@csail.mit.edu>)

#!/usr/bin/env python
import bluetooth
print "performing inquiry..."
nearby_devices = bluetooth.discover_devices(lookup_names = True)
print "found %d devices" % len(nearby_devices)
for name, addr in nearby_devices:
    print "  %s - %s" % (addr, name)

as I do not care for gnome, my default desktop is KDE,
what follows is my procedure for pairing with a NXT Brick.

[root@motoko]# /usr/bin/bluetooth-applet &

a Bluetooth icon will appear in your system tray,

right-click the Bluetooth icon and click “Preferences” from the popup.

  • set the radio button under “Mode of operation” to be “Visible and connectable for other devices”
    (even if it ought to be “connectible”)
  • click “Close”

on the NXT Brick, from the root menu,

  • select “Bluetooth” and press the square button.
  • select “Search” and press the square button.
  • after it has finished searching, select the name that matches your computer and press the square button.
  • select “[1]” and press the square button.
  • wait for it to connect.
  • enter passkey, or press the square button for the “1234″ default.
  • Bluetooth icon will begin to blink, click it and enter the passkey in the resulting dialog.
  • right-click the Bluetooth icon and click “Preferences” from the popup.
    • select the NXT Brick in the “Bonded devices” box.
    • Click “Set Trusted”
    • click “Close”

the connection can now be tested with the following python code:

#!/usr/bin/env python
import nxt.locator
sock = nxt.locator.find_one_brick()
if sock:
	brick = sock.connect()
	name, host, signal_strength, user_flash = brick.get_device_info()
	print 'NXT brick name: %s' % name
	print 'Host address: %s' % host
	print 'Bluetooth signal strength: %s' % signal_strength
	print 'Free user flash: %s' % user_flash
	sock.close()

NXT Puzzlebot

not much yet, but with two development forks we’ll probably have something workable soon.
 
 
as of 11/16/2008:
a few test ideas.


 
 
as of 11/22/2008:
some general refinements, and the software to raise and lower the whatever-the-hell-that-is is working.

 
 
PuzzleBot - 2008-11-28

AVR Toolchain - Build 2008-04-15

Contains all the tools for developing on the AVR under Linux.

This includes:
AVR-gcc - a full-featured ANSI C compiler.
AVR-Binutils - includes tools capable of linking and managing archives, including handling object code, libraries, profile data, and symbol names.
AVR-Libc - this package provides a subset of the standard C library for Atmel AVR 8-bit RISC microcontrollers.
AVRDUDE - an open source utility to download/upload/manipulate the ROM and EEPROM contents of AVR microcontrollers using the in-system programmer (ISP).
AVR-gdb - a debugger, GDB lets you to see what is going on ‘inside’ another program while it executes.
ddd - this works with command-line debuggers such as GDB to give a graphical front-end.
Simulavr - A simulator for the Atmel AVR family of microcontrollers.
 

Known MCU names:
avr1 avr2 avr3 avr4 avr5 avr6 at90s1200 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22 attiny26 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534 at86rf401 attiny13 attiny2313 attiny261 attiny461 attiny861 attiny24 attiny44 attiny84 attiny25 attiny45 attiny85 attiny43u attiny48 attiny88 atmega103 at43usb320 at43usb355 at76c711 at90usb82 at90usb162 atmega48 atmega48p atmega8 atmega88 atmega88p atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm2b at90pwm3 at90pwm3b atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p atmega168 atmega168p atmega169 atmega169p atmega32 atmega323 atmega324p atmega325 atmega325p atmega328p atmega329 atmega329p atmega3250 atmega3250p atmega3290 atmega3290p atmega32hvb atmega406 atmega64 atmega640 atmega644 atmega644p atmega128 atmega1280 atmega1281 atmega1284p atmega645 atmega649 atmega6450 atmega6490 atmega16hva at90can32 at90can64 at90can128 at90pwm216 at90pwm316 at90usb646 at90usb647 at90usb1286 at90usb1287 at94k atmega2560 atmega2561
 

core package:
binutils-2.18
gcc-4.2.2
avr-libc 1.6.2
avrdude 5.5


AVR-Toolchain - Core - 2008-04-15 Build Binary Package


AVR-Toolchain - Core - 2008-04-15 Build Binary Package - No Docs

debug package:
ddd-3.3.11
gdb-6.8
simulavr-0.1.2.5


AVR-Toolchain - Debug - 2008-04-15 Build Binary Package


AVR-Toolchain - Debug - 2008-04-15 Build Binary Package - No Docs

 

AVR Toolchain - Build 2008-04-15 - Build Tests

AVR Toolchain - Build 2008-04-15 - Man Pages

Every version of UNIX comes with an extensive collection of online help pages called man pages (short for manual pages). The man pages are the authoritative documentation about the system.

This is a web-accessable front end for the man pages generated by the packages in the GNU AVR toolchain, namely: AVR-gcc, AVR-binutils and AVR Libc.

Continue reading ‘AVR Toolchain - Build 2008-04-15 - Man Pages’ »

Eagle3D Component - Simple Jumpers

some very simple jumpers for Eagle3D, I tend to use a lot of them due to single-sided board restrictions.

the include file, to be placed in “[Eagle3D Root]/povray” and added to “[Eagle3D Root]/povray/user.inc”. see this post for details.
user_jumper.inc

 

and the associated images (to be placed in “[Eagle3D Root]/ulp/img” to aid in identification, optional):

Zip archive of images

Method to simplify adding Eagle3D components

assuming the Eagle3D directory structure looks as follows:

[Eagle3d Root]
    |- doc
    |- examples
    |- povray
    \- ulp
        \- img

the file “[Eagle3d Root]/povray/user.inc” will contain, by default, nothing.
if the following lines are placed within it (note that the shown filenames are only examples):

#ifndef(__user_inc)
#declare __user_inc = true;

//#include "user_includefile01.inc"
//#include "user_includefile02.inc"

#end

adding new parts is a simple matter of adding the new file to the [Eagle3d Root]/povray/ directory, copying an #include directive, changing the name, and uncommenting it.

in my own installation, I follow the recomended prefix style of filenaming, as do the files available on this site.

additionally, if the current user.inc file is not empty, it can be renamed to “user_orig.inc” or similar, a new user.inc file containing the above added, and the line #include “user_orig.inc” placed within it.

Designing a keypad for an AVR Microcontroller

by using the upper four bits as outputs and the lower four bits as inputs, a simple 4×4, 16 button keypad can be connected to a microcontroller.

the first picture shows the state after the “0″ key has been pressed.
the 0×24 corresponds to the “scancode”, the first digit being the column and the second being the row.
to be exact, in binary 0×24 equals 0b00101000, this shows that during the scan, the key in the second column and the fourth row was pressed.

the bracketed values under that are the contents of the key buffer.

HPIM0056-e.JPG mainboard-top.png mainboard-bot.png
mainboard-sch.png mainboard-brd-e.png mainboard-brd-silk.png

 
 
a simple code example for this:

//high bits are columns, low bits are rows
volatile uint8_t scancode = 0x00;
uint8_t i, j;

// set data direction on PORTD
//   pins 8,7,6,5 as output, pins 4,3,2,1 as input
outb(DDRD,  0b11110000);

//loop over pins
for( i=4; i<8; i++ ) {

	// sets outputs low one pin at a time
	//   also enables internal pull-ups on inputs
	outb( PORTD, ~(1<<i) );

	//debounce delay and settling time
	timerPause(5);

	//loop over port positions
	for( j=0; j<4; j++ ) {
		if( bit_is_clear(PIND,j) ) {
			//set scancode
			scancode = (1<<i)|(1<<j);
		}
	}

}

 
 
the “~(1<<n)” is an example of bitshifting, in this case it means “bitshift 1 left “n” times, then invert the result” or if we take n as 3, it would be:
~(1<<3)
after 0 shifts:
~(0b00000001)
after 1 shift:
~(0b00000010)
after 2 shifts:
~(0b00000100)
after 3 shifts:
~(0b00001000)
then inverted:
0b11110111

a slightly more complicated looking example of this is used in the inner loop:
(1<<n)|(1<<m)
or if we take n as 6 and m as 2 it would be:
(0b01000000)|(0b00000100)
and that would resolve to:
0b01000100

Eagle3D Component - LCD Module

this is a rendering of an Eagle3D component in progress, an LCD module that is part of a set of several text-based modules.

LCD_16×2-top

as requested, the required files:
HD44780 Based LCD Modules Library (lcdmodules.lbr)
user.inc
user_colors.inc
user_lcd.inc
alphalcd.ttf

the lib file should go in your eagle “lbr” directory, and the inc and ttf files should go in your eagle3D “povray” directory.

a word of warning, thes are in pretty rough shape, but usable.
the include files follow the proposed rules in this post, so if you have made any changes to your user.inc, be sure to merge the files.

alternately, you can simply add the following lines to your user.inc:

#include "user_colors.inc"
#include "user_lcd.inc"

happy designing, and any comments or suggestions are welcome.

AVR Toolchain - Build 2007-10-23 - Build Tests

AVR Toolchain - Build 2007-10-23 - AVR-Libc User Manual

  • Categories

  • Need Code Written?

  • Need a Coding Job?

  • Tags

  • Archives