RS232 interface

Send two bytes.

You can try to insert some timeout, if it is slow, to find the start of a two byte packet, but I would encode it, e.g. sending 7 bits for the first byte and 5 bits for the second byte. Then you can set the 8th bit of the first byte to mark it as the first byte. For more reliability you can add a

3rd byte with a checksum (use only 7 bits for the checksum).

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Or look ahead to the day (that's coming soon) when the boss says "great, now add these other three channels to it, and get it working by Monday".

And make yourself a whole little protocol.

If I have the bandwidth, I prefer to do something that's human-readable, i.e. lines of text that's in a format that's rigid enough to parse easily by machine, but goes "keyword number number number" so you can read it on a terminal when your PC software doesn't work right. Even if the keyword is one, two or three letters, if you make it relevant you can read the data stream.

--
http://www.wescottdesign.com

Should be no problem, as long as the start of the packet is unique. Just add a version number as the first byte, to make it backward compatible (but it is not upward compatible).

You are right. If the bandwidth is no problem, I'll do the same, see e.g. this small protocol:

This could be even upward compatible (a new hardware would work with an older software), which is more difficult with binary protocols.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

...

One day your boss will say "Now we need to transfer ten times more data...."

I prefer compact binary protocols (STX, data, CSUM, ETX) and a simple perl-script to implement it on the PC-side. Easy to change, easy to handle...

YMMV, Falk

And, to do that, the scheme used by NMEA isn't the worst one out there. A human-readable char that's only ever permitted as the start of sentence indicator, a mnemonic (holy crap! I spelled that correctly on the first try!) to id the type of sentence, comma-separated fields, and a trailing checksum.

--
Rich Webb     Norfolk, VA

Don't forget to escape STX and ETX when it occurs in data or CSUM fields...

--
Grant

My suggestion is convert it into a hex value, which takes 3 chars (each char encodes 4 bits). Send a burst of 4 chars, where the last is a checksum. All conversion is easy, uses existing code, and the results are readable on any intermediate terminal monitoring transmissions.

You might want to send the 3 chars in a hex record, which is already a standard format, with checking methods included. Then the total record, where each ADDR field is expressed as 4 hex chars, (others are 2) will be:

": TYPE(1) LENGTH(1)=3 ADDR(2) DATA(3) CKSUM(1)"

The CKSUM is just the byte oriented sum of all preceding bytes, omitting the ':'. I suggest seizing the type 10 (in the hex characters '1','0') which I believe is not in use elsewhere. Thus a typical message for the ADC value 345 (hex) would be:

":030000345SS" and is easily expanded.

Written at the keyboard, not checked, errors expected.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I forgot the LEN-field, sent directly after STX. In this case ETX is not strictly necessary, but with STX, LEN, ETX you can check for frame-errors.

No escapeing needed.

Falk

I agree. It is nice to be able to check on the output BEFORE you start on the consumption end of the data equation. A 12 bit sample would only occupy

4 digits of hex (0x0000 - 0x1000) or decimal (0 - 4095) maximum, so there wouldn't be much more overhead compared to sending raw data, even with some additional characters to make a basic protocol. I guess it all comes down to the sample rate required.

Sorry, 0x000 - 0xfff Damn, rolled over.

I guess it depends on just how elaborate the project is going to be, and how tight one is for bandwidth.

I've used protocols as you describe, and I've used human-readable ones; each has it's place. I _can_ say that the ones that stay useful the longest for the most people -- barring bandwidth problems -- are the human-readable ones, because then _anybody_ who can fire up Hyperterm can read the output.

--
http://www.wescottdesign.com

...

...

...

Ack.

Falk

yep, I had a small project a couple of years ago that would have been a lot more difficult if the protocol used wasn't human readable (or human- writeable).

Robert

Just to add a small tidbit of no consequence... there is a set of guidelines that I _did_ find helpful in thinking through issues when designing my own readable commands and queries -- the IEEE 488.2 standard. Yes, originally for GPIB (HPIB) devices, but it is quite applicable to RS-232 -- it's about command/query design issues that are useful right across the board and it's not about GPIB hardware.

For example, it says that if you support a command like this:

RATE 10

then you should support a query like this:

RATE?

and it should be reported in command format like this:

RATE 10

The idea is that if you query a box, the replies are in command form that can be "blasted right back at the box" to re-set the parameters. They also recommend this specific one:

SET?

Which would dump out a series of commands of user-controllable settings.

It's not genius stuff... just reasonable recommendations that many folks would arrive at on their own. The nice thing is that they've put it all into a single document causes you to think a little more closely about details. By they way, they suggest (but do not demand, of course) the idea of allowing units, so that the above command might be specified as:

RATE 10s

or,

RATE 10000ms

and that there exist a default unit when none is specified that is also used by the SET? query when dumping out results (unless you also support commands to set the default units.. which of course means more commands and queries... but oh, well.)

Jon

;

can

thats called SCPI

No, SCPI came later and builds on it. It's not the same thing. And if you are going to do one-upsmanship, it's called the IVI specifications now:

In short, I'm aware of what I was saying. Read back and I think you will agree that I was reasonably choosing a first step. IVI (and SCPI) is a bit much to bite off or suggest at the first round and a lot of folks don't want to go quite that far in their implementations, anyway.

Jon

With FlashForth I would do it like this

\ Define the address of the A/D result register

$ffc3 constant ADRES

\ Make the A/D conversion

\ Fetch the result of the AD conversion and \ print it to the serial port in an unsigned format. \ The output will be a ASCII string number according to BASE

ADRES @ u.

Did you know that PIC18F452 only has a 10 bit ADC, maybe you are using an externals ADC ?

Check out