New favorite Microchip PIC is the 18F14K22

I discovered this little microchip recently. The 18F14K22 PIC is really neat. At about $2 from mouser or digikey and supported by the USBProg for ICSP and also supported by mikroC compilers, it is my new favorite low-end chip. I use it anywhere USB coms are not required. It also runs at 64 MHz with an external crystal, but I mostly use the 2 internal clock sources. The primary internal runs at up to 16 MHz and has fantastic stability. The secondary clock runs at 31 KHz, which is great for saving the batteries. This chip comes in SMD/SMT and PDIP flavors as you might expect. I like the SOIC-20 style because this is really easy to solder down quickly on a prototype board (like a schmartboard). You can also run them at 1.8v to 5.5v, which is nice is you are using usb power or 2 double A batteries. I use this chip with the Linx TRM433 transceiver, which runs at a strict 3v. So I regulate power once and smooth it out and forget about it! If you are getting into the embedded world, I would highly recommend this chip! It beats the pants off of any arduino out there at a fraction of the cost!

Git: What SHA does this tag refer to?

I often have to tag a branch in my Git repo for QA. Our QA people prefer to have a tag to deploy on to their QA environments, so that they do not have a "moving target" to ensure features and bugs are accounted for. Sometimes, however, I forget exactly where in the lineage the tag was created. In other words, on which commit the tag was drawn.

There is a way in Git to see this information. Here is a use case for the situation.

You complete feature A and commit it. You then tag feature A with an annotated tag and immediately start working on feature B, then C, etc. QA asks about the tag. You no longer remember what that tag was for, so you fire up a console and type in the following to find out:

git show-ref --dereference


You can find the tag in the list and perform a simple git log matching the sha from the show-ref to the sha in the git log. Simple. Even easier would be to run a filter using --exclude-existing on the show-ref using a regular expression and then piping the result to git show or git log.

Debian Unstable (SID) Squeeze: installing Grub2

This is frustrating. Installing the Debian system in development (SID, AKA squeeze) is really broken currently. Installing GRUB or GRUB2 just does not work at all and can ruin your day. You get all the way to the end of the install when the error pops up. During the install of either GRUB or GRUB2.

Here is what you can do to fix this:

1. Choose to install GRUB2 and let it fail; be sure to allow GRUB to write to the MBR.
2. Go back to the main menu of installer items and choose "continue without installing a bootloader". Trust me on this one, it will all work out.
3. reboot your machine, the grub (this will be the GRUB2) bootloader prompt will be presented. This is your ticket back into your newly installed system
4. At the "grub>" prompt, type the following: (you may need to adjust the boot drive)

linux hd(0,1)/boot/vmlinuz-2.6.32-5-amd64 root=/dev/sda1

then:

initrd /boot/initrd-2.6.32-5-amd64

then:

boot


of course substitute the kernel and initrd you are using for the real ones. Also check the root drive for the correct one. Sometimes you can just guess, the machine will just not boot if it is wrong and you can go back and do it again until you get it right.

Then once you have everything booted. You can install GRUB2 properly by doing the following:

apt-get install grub2

then:

grub-install /dev/sda


then:

grub-mkconfig > /boot/grub/grub.cfg

then:

reboot

All should be well after the reboot.

Changing xterm-new/xterm text output colors

I recently found that in my iterm (and Mac terminal) applications the text coloring was not optimal. For instance, I use a dark background, but when issuing a command such as 'ls' would list directories in dark blue. This is impossible to read. It seemed to me that this would affect most who prefer a dark background in their terminals. I think this only applies to Mac terminal since the environment variable used is a bit different than what Linux uses.

to find out which terminal you are using (aside from the application running the terminal such as terminal app or iterm) issue this command:

echo $TERM

as always, you can read all about the information here in the ls man page

man ls

here is what you can do to change one or all of your lscolors, environment variable is LSCOLORS

Add the following to .bashrc or .bash_profile or whatever file runs when you start an interactive shell: (mine is called .bash_profile and lives in my home directory)

LSCOLORS='fxfxcxdxbxegedabagacad'
export LSCOLORS

straight from 'man ls'

LSCOLORS
The value of this variable describes what color to use for which attribute when colors are enabled with CLICOLOR. This string is a concatenation of pairs of the format fb, where f is the foreground color and b is the background color.
The color designators are as follows:

a black
b red
c green
d brown
e blue
f magenta
g cyan
h light grey
A bold black, usually shows up as dark grey
B bold red
C bold green
D bold brown, usually shows up as yellow
E bold blue
F bold magenta
G bold cyan
H bold light grey; looks like bright white
x default foreground or background


Note that the above are standard ANSI colors. The actual display may differ depending on the color capabilities of the terminal in use.


The order of the attributes are as follows:


1. directory
2. symbolic link
3. socket
4. pipe
5. executable
6. block special
7. character special
8. executable with setuid bit set
9. executable with setgid bit set
10. directory writable to others, with sticky bit
11. directory writable to others, without sticky bit


The default is "exfxcxdxbxegedabagacad", i.e. blue foreground and default background for regular directories, black foreground and red background for setuid executables, etc.



So add the following to your .bash_profile or equivalent:

LSCOLORS='fxfxcxdxbxegedabagacad'
export LSCOLORS

As you can see I just changed the first character from 'e' to 'f'. This has the effect of making directory listings be listed in a magenta color instead of a dark blue.

Save .bash_profile and issue:

. !$

that is the same as:

source ~/.bash_profile

if issued right after the command to edit .bash_profile. In other words, you are asking bash to source (which is what the dot is) and then reprint the last argument to the last command.

Microchip Pic 18F2455/2550/4455/4550 Oscillator Settings Explained

I have a new fav Microprocessor. The Microchip Pic 18F2455. This is a feature-full yet powerful little device has almost limitless possibilities. Alas, you must understand that I am coming from the Pic 16F77, which lacks USB support, but is far more simple to get "blinky lights".

What the 18F2455 achieves in features, it gives up in ease of use (for newbies like myself). The external oscillator settings where an epic nightmare to get right! I believe the reason for this is twofold:

1. Nanowatt (tm) specifies the use of 2 clocks/oscillators for the 18F2455. The first clock for the main clock source to run the cpu itself; the ALU, the USB port(s) and all that. The second clock runs timers. This setup allows the main clock (and CPU) to power down leaving the second clock running to handle checking for new data on the USB port and running timers.


2. The USB port needs a strict 48 MHz clock to run, but Microchip still wanted to allow users of these chips to use oscillator configurations that they were used to. For example, for me, I have always clocked my chips at 20 MHz and I have a surplus of those crystals, so using a 20 MHz clock source would be really nice. I can still do this, but I need to use internal chip configurations to make use of the chip's internal pre/post oscillator scalers.

Here is how it all breaks down for me:

using 18F2455 and a 20 MHz external crystal. Please open the data sheet for the 2455 and refer to figure 2-1.

diagraming it out:

20 MHZ --> pins 9,10 (on pic)

you can see from Figure 2-1 that whatever you hook up to pins 9,10, you are feeding a PLL prescaler internally and you MUST feed the subsequent PLL prescaler a 4 MHz clock source as its input. This means that for me, I have to prescale my 20 MHz oscillator to 4 MHz. This means that we need to divide 20 MHz by 5. You can see from figure 2-1 that this bit setting is 100 on the PLL DIV MUX.

Now you have 96 MHz at the exit of the second PLL that is feeding another divider and also feeding a PLL postscaler. So then you can set the CPU DIV for the appropriate div for the main CPU clock source. This is 1 in my case because I want the main CPU to be clocked at 20 MHz.

If you are thinking that this is pretty confusing, you are right! There are a lot of choices (12 different oscillator modes) in oscillator setup and configuration. This leads to confusion and dismay. Mayhem might ensue. But, I think if you take the time to read Fig. 2-1 and learn the register bits that control which mode the clocks can be in, then I think this is an extremely powerful tool.

Montana Property

I wish I had the money and freedom to buy this property myself.

Check this beautiful Western USA property out!

52 acres for sale in Noxon Montana

SSH: setting up key authorization only (authorized_keys)

This is a great site for dealing ssh key authorization.

http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html

The problem with sites that help you setup ssh key authorization is that they typically leave out the specific chmod commands (permissions) that you need to make the darn thing work!

What I mean to say is that people need to see an example of how this works and not just out of context commands and scripts.

Here is an example of a Mac OS X ssh client trying to setup ssh key authorization with a CentOS ssh server.

on the Mac, issue the following commands (you may or may not want a pass phrase on your private key), also substitute your username and hostname in where the double quotes are.

1. ssh-keygen -t dsa

2. scp .ssh/id_dsa.pub "user"@"CentOS host":~

3. ssh "user"@"CentOS host"

on the CentOS server

1. mkdir .ssh (this directory may or may not already be there; it should be safe to issue either way)

2. cat id_dsa.pub > .ssh/authorized_keys

3. chmod 755 .ssh && chmod 755 .ssh/authorized_keys

on Mac again: (hit ctrl-D to log off the server)

1. ssh -vvv "user"@"CentOS host"

The ssh client should log you in without a password if there is not password protected private key. If you protected your private key with a password, then it should ask for the password for the private key. Ssh should NOT ask you to provide a login for the shell on the remote side. The triple 'V' will display a verbose list of the conversation going on betwix client and server.