Monthly Archives: July 2008

Thermal insulation of windows

An article on using bubble wrap, in PDF. Has pictures, looks really good. Found through.

Advertisements

Note on wireless networking, Windows XP SP2

Did set up an ad-hoc wireless network in Windows, using Intel PRO/Wireless 3945ABG, driver version 11.5.1.15 (released 13-03-2008), and D-Link DWA-110, driver version 1.2.1.0 (released 14-05-2007). NOTE: the latter driver not present on main D-Link site, use the Australian instead.

Using vendor-specific software to manage wireless networks, not Windows-bundled.

So far WEP only, haven’t tried WPA.

No editing of specific wireless communication parameters (B/G filtering, ad hoc channel selection, etc.) was needed. NOTE: the Intel device, even when set channel 11 (default) in “Device Properties”, still tried to use channel 6 when connecting. This wasn’t visible in default Microsoft wireless connection management software, and was only made evident when using Intel’s own.

Copying music to USB flash from command line, fast

Thanks to this post.

EDIT: This doesn’t work well.

#!/bin/sh
# Script to copy music to media player (USB).

# remove the last character
var=`echo $*|sed s/.$//`

echo "Copying: $var"

# now copy
cp -R "$var" /mnt/player/ &

KiCAD’s PCBNEW: change pad dimensions

Don’t get confused by the “Tracks and Vias” menu: it’s just that, tracks and vias. To change pad dimensions:

  1. select one pad;
  2. change it’s dimensions;
  3. right-click it, select Pad N -> Export Pad Settings;
  4. now right click any pad of every element you want to have the same pad sizes, go Pad N -> Global Pad Settings -> Change Module.
  5. look out for the pads that are of different form, like square inside circle and shit.

Annoying, I know, but I haven’t found a faster way this far. If you did, let me know.

P.S. The thing with KiCAD is that no one really works on UI design. Things are usable, but in a backward-ass kind of way. Now, don’t whine about it – if you can, help these folks out instead. After all, it’s just some software a guy wrote for himself (more or less).

Grab’n’drop

Here’s something annoying: when you have to copy/move some files to another directory, and then cd there yourself. Written scripts to do that faster: grab:

#!/bin/sh

dir=`pwd`

for item in `echo $@`; do
	echo $dir/$item >> ~/tmp/grab
done

And drop:

#!/bin/sh

grabfile=~/tmp/grab
tempfile=~/tmp/grab.tmp

echo "" > $tempfile				# create if missing

for item in `cat ~/tmp/grab`; do
	mv $item . 2> /dev/null
	if [ $? -ne 0 ]; then			# was some trouble
		echo $item >> $tempfile
		echo "Cannot move: $item"
	fi
done

mv $tempfile $grabfile

Also, added a lose script, which merely deletes ~/tmp/grab for now.

Atmel AVR timer/counter examples

Here’s the catch: the timer/counter is capable of operating on a completely hardware level, no software interaction required. A nice explanation is given here (section 2). This page starts with an introduction using a software counter. Which shows how tedious that is, especially counting the clock durations yourself.

Another page at AVRfreaks here deals exclusively with the software implementation, although using the timer/counter registers for counting. This is useless and horribly wrong, that’s not how timers/counters with “output compare” capabilities should be used! The dangerous part is that this article doesn’t even mention the hardware-only implementation.

Atmel’s assembly: branch to address, not label

Say you had this code to wait for n iterations, where n is stored in register arg. You could write:

wait:
dec arg
brne wait ; step back to dec
ret

Which would be OK. But if you didn’t have that much free registers, you would probably pass n using the stack. In which case your procedure would grow intensely fucked up, like this:

wait:
; (line/s to get argument from stack)
; ...
wait_dec:
dec arg
brne wait_dec ; step back to dec
ret

This ain’t good. Instead, branch to a relative adress:

wait:
; (line/s to get argument from stack)
; ...
dec arg
brne PC-0x01 ; step back to dec
ret

Trusted computing will make me distrust my computer

This is old news that got happily shoved away and forgotten. And Atmel’s at the forefront, too, wow. Fuckers.

Time to stop upgrading your hardware and start downgrading.

Time to stop listening to RIAA. That’s right, the RIAA are the authors, not the artists, and they suck. You have been giving them too much free advertising by stealing what they have to sell.

Time to stop downloading shitty movies and finally let Hollywood understand they will get no money in either case. Although if you did download Spiderman more than once, you should go die straight away. That will be more effective.

And Microsoft… Nah, just screw Microsoft. Wipe it off your PC. Just wipe that vomit off of you and try to live along.

Short note on reading Usenet newsgroups in FreeBSD

A very simple setup is tin (usenet client) + leafnode (lightweight newsgroup server/proxy). You could even use just tin.

Leafnode has its own mechanism on fetching news articles (called fetchnews). It won’t fetch news from groups you haven’t shown interest in (haven’t opened/read). Which bugs me somewhat, since there are some groups I’m interested in, but which have really rare posts. So if there are no posts, I don’t open them, leafnode thinks I’m not interested, and when news do appear, leafnode doesn’t fetch them. Vicious circle.

So I might consider adding suck or something similar to the line: make it tin + leafnode + suck.

Another option I’ve considered is using inn instead of leafode. That might be a valuable experience, since inn is rich in features. But in reality, I don’t need its horsepower.

Making my own USBasp programmer

I’ve been trying to make some for the last two weeks (yes, two weeks). I didn’t use the provided designs, that’s why it took so long: first, I wanted to get apprehended with the UNIX electronics CADs; then, as one should expect, I ran into design trouble of a layout that hasn’t been tested.

So here’s some valuable experience:

0) When developing with a crystal, make sure it’s the first thing you put near the IC! You need minimal distances, remember?

1) Design the PCB while looking at the schematic – you can actually see that C1 and C3 can be put very nicely near the USB connector (pins 1 and 4); R3 right next to it, too (pins 1 and 2); and some components “stick” naturally to the IC. This can be applied to other schematics.

2) check your schematic, not just the PCB. I’ve actually wasted the last week trying to pin-point the cause of a weird behaviour: the programmer can be programmed, the fuses can be set, it works as a stand-alone USB device (when no target is connected) and even when the target (a known-to-work USBasp) is connected, but not set to self-programming mode. As soon as it is (jumper 2 is set), the built USBasp starts to malfunction:

  • if the Brown-Out Detector is enabled (some other fuse combinations also apply), the power LED flickers, and the device is unrecognized;
  • under other configurations, the device simply does not power-on (the LED stays blank);

What I have found out is that I accidentally put JP2 in the wrong place: as you can see on the schematic, the wire that goes out of pin 5 of the ISP socket branches into one that joins the SS, and the other one that goes to ~RESET. Since I’ve redrawn my schematic, I accidentally put the jumper in the wire that goes with the SS.

Now, this has far-reaching complications. First off, this means that ~RESET is always connected to pin 5 of X2. Thus if the programmer is in slave mode (being programmed), the master controls ~RESET when it issues commands, and its +5V (through pin 2, VCCINT) influences the ~RESET through R6 (10K). Cumulatively, this provides the same conditions that would be seen in proper master-mode.

When such a USBasp is a master with no target, or the target is not set to self-programming (target’s JP2 disconnected), then master’s ~RESET is only influenced by the +5V, which comes from the USB. Also no problem here.

But when the target has JP2 set, you effectively have two programmers set to self-programming! This results in a race condition and also a loop, where master feeds the slave with VCCINT, which is then provided back to the master through pin 5 of X2 – and since master has its JP2 “shorted out”, it all effectively sets its ~RESET to +5V!

“Now, that’s pretty fucked up right here!” – you’re going to say; but, actually, this can be worked to an advantage. If you test your programmer on a known-to-work USBasp target, you will immediately notice such non-standart behaviour. If it was a normal target on the other end, you’d have an even bigger hell of a time finding what’s wrong than I did.

Not to mention you’d get a programmer that’s unable to reproduce itself.

3) If this is your first USBasp, build it of discreet components (and let teh ceiling cat be with you, ameh). This way you:

  • can change the IC easily if you misprogram the fuses (say, edit “hfuse” to “lfuse” in avrdude, move the cursor to change the fuse value, and accidentally press Enter instead of Backspace (doh!);
  • can use resistors to “jump” long distances over several lines you’ve already run;
  • know for sure what the values of the capacitors are (!).
  • don’t have to deal with SMT Zener diodes, which might only be available in MINIMELF packages.

4) Along the way, I also got to read some valuabl infoz on how AVR and USB get along.