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.
Wednesday, September 29, 2010
Tuesday, September 28, 2010
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.
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.
Labels:
18F2455,
Clock,
embedded,
Microchip,
microcontroller,
Oscillator,
PIC programming
Sunday, September 26, 2010
Montana Property
I wish I had the money and freedom to buy this property myself.
Check this beautiful Western USA property out!
Monday, September 20, 2010
SSH: setting up key authorization only (authorized_keys)
This is a great site for dealing ssh key authorization.
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.
Subscribe to:
Posts (Atom)