PC-AVR Serial command + data definitions framework?

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to operate my AVR from my PC, I mean that I want to send commands to do things.
The communication goes by serial. I start with ASCII and want to show the characters on a 44780 display. In ASCII some bytes are for control, but also every byte can be "displayable".
I started with finding out how Adobe defined there printer commands. But soon I learned that I want/need to do more then sending just characters to the display (like "printing"). First hurdle is the USART control.
So how to instruct my AVR to handle the byte as a number, a character or a device command.
Is it only a matter of definition? May be de C-people will laugh about my problem... (I use asm).

I am thinking of writing a line (some maximum characters 40, 64, 256?), and defining the first byte as a control byte. This control byte tells how the rest of the line is to be treated: just print/display every byte, execute commands for port reading, define some spreadsheet format for following data, and so on; even I can instruct not to expect a new control byte at the beginning of the next new line(s).

I am looking for guidance how to set it up (what are the usual definitions?). Are there standards? Is the first byte idea good? Or should it be at the end of line? Or do I have to take an entirely different approach?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
what are the usual definitions?).
There isn't any. Get your USART code working with a terminal program first, then you may want to try your hand at the LCD stuff then you combine the 2 together.

What chip are you planning on using?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I started with finding out how Adobe defined there printer commands.

A simpler example would be Epson:

http://lprng.sourceforge.net/DIS...

As you can see their sequences typically start with ESC. Another example is ANSI display codes:

http://www.termsys.demon.co.uk/v...

Again they start with ESC. Such an "escape" character that would not normally occur in standard text (because it's below the usual printable range) is a common way to embed control information in a stream of text data.

Another way is to use a character such a '/' as the start of an escape (and to use a real '/' you actually send "//").

But such "protocols" are up to you to define. You could go with your other suggestion and always send a fixed size packet where the first byte(s) dictate what the command is.

If bandwidth is not a concern you could even choose to use more than single character commands. So instead of sending ESC-C to clear the screen you actually send "CLEAR" or whatever.

Or another way is to effectively have the AVR present "menus" to the UART such as:

1) clear screen
2) light LED 1
3) light LED 2
Enter command:

then the PC program (or you at an interactive terminal) just send '1' to clear the screen or whatever.

At the end of the day it's up to you, how easy you want it to be "driveable" from a simple terminal program (if using "packets" the chances of someone being able to manually construct them simply by typing commands into a terminal is pretty low, whereas the user could select from menus or learn to type ESC-C o whatever)

Cliff