Microcontroller and Linux PC

On Jul 27, 2:14=A0pm, "Joel Koltner" wrote: [....]

does

cmd.exe isn't the old command prompt. It was command.com and several things don't work exactly the same between them. On both XP and Vista, the command prompt is configured to have no free environment space by default. This breaks batch files that depend on using environment variables. I also ran into a difference in how the copy command worked but I can't remember that right now.

On a sunny day (Tue, 28 Jul 2009 10:06:25 -0700 (PDT)) it happened mkr5000 wrote in :

One extra thing: once you make a text file executable, so a script, to run it, type: ./my_script not my_script in the same directory, as it will not normally be in the search path. You can find the search path, that is the directories your system looks in for executables, by typing: env | grep PATH

'env' shows the whole environment in the shell, 'grep' just filters out the lines with PATH in it, An other example of the use of a 'pipe'.

If you were to put the my_script file in one of the directories of the search path, then you could just type my_script. For this reason I put all my scripts in /usr/local/sbin/ so they are always found.

When you get a small board like that, get a cheap one with a parallel printer port. Funny enough a lot of the very cheap ones have a parallel port, the more expensive ones not :-)

When you have the parallel port, then you can do direct I/O to 8 data lines, plus some control lines. That means if you have 4 data lines for a text LCD, plus 2 control lines for R/W and E, you still have

4 data lines to do a 2x2 switch matrix, and no PIC needed! How to do direct I/O to the par port in Linux I recently posted here, else ask.

Gosh, i suggest you take a serious look at how ncurses interfaces are built as a first leg up. The yast ncurses interface is a pretty good example.

IME command line provides more options and more flexible arguments as well as much more progress, status, and error reporting. It is really uncommon for a graphical interface to provide as much power and control as a CLI.

Just getting started? Here's a couple of pointers:

There are quite a few command line applications that provide functions similar to what you'd expect of a GUI. In fact, many of these are much more powerfull than their equivalent GUI interface.

There are a few apps that operate like a command line interpreter. That is: once started, you enter a command (specific to your app) at a prompt, the app processes it and returns a response and a new prompt.

Many of these existing apps are available as 'open source' programs. So you can download the code, look through it to see how its done and then roll your own. Likewise, the audio applications are (probably) available as libraries, so you can write a simple command processor that calls the appropriate audio lib functions. Do be aware of the open source licensing requirements: If you write _and_distribute_ your own piece of software that is based on this code, that's OK as long as you meet the requirements to distribute your source (or whatever the license requires). But its a great way to learn.

Once you get a simple command processor up and running, you can 'hook' it to a serial port (like Rich suggested). It would be a good idea to familiarize yourself with users, permissions, etc. and launch such an application as a uid with minimal permissions, so if something goes wrong, your app can't bugger up the entire system.

Once you have a 'command in', 'response out' app running, you can have any serial capable piece of h/w talk to it to do what you want.

--
Paul Hovnanian  paul@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.