srinusingh wrote:
> hi......... iam doing ADC using PIC18f452.This ADC is 12bit.
> NOW i have to send that 12bit output data to PC, my problem is that in PIC
> we have only 8bit data transmit register , but i have to send this 12
> digital data .How i can do this 
> 
> 

With FlashForth I would do it like this

\ Define the address of the A/D result register

$ffc3 constant ADRES <enter>

\ 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. <enter>

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

Check out http://flashforth.sourceforge.net

On Tue, 27 Jan 2009 06:06:21 -0800 (PST),
bigbrownbeastiebigbrownface@googlemail.com wrote:

>On Jan 27, 1:03&#4294967295;am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> On Mon, 26 Jan 2009 19:35:43 -0500, Robert Adsett
>>
>> <s...@aeolusdevelopment.com> wrote:
>> >In article <-76dnUzuiZiWbuDUnZ2dnUVZ_jydn...@web-ster.com>, Tim Wescott
>> >says...
>> >> I've used protocols as you describe, and I've used human-readable ones;
>> >> each has it's place. &#4294967295;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.
>>
>> >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).
>>
>> 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. &#4294967295;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:
>>
>> &#4294967295; RATE 10
>>
>> then you should support a query like this:
>>
>> &#4294967295; RATE?
>>
>> and it should be reported in command format like this:
>>
>> &#4294967295; 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:
>>
>> &#4294967295; 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. &#4294967295;The nice thing is that they've
>> put it all into a single document causes you to think a little more
>> closely about details. &#4294967295;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:
>>
>> &#4294967295; RATE 10s
>>
>> or,
>>
>> &#4294967295; 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
>
>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:

http://www.ivifoundation.org/specifications/default.aspx

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

On Jan 27, 1:03=A0am, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Mon, 26 Jan 2009 19:35:43 -0500, Robert Adsett
>
> <s...@aeolusdevelopment.com> wrote:
> >In article <-76dnUzuiZiWbuDUnZ2dnUVZ_jydn...@web-ster.com>, Tim Wescott
> >says...
> >> I've used protocols as you describe, and I've used human-readable ones=
;
> >> each has it's place. =A0I _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.
>
> >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).
>
> 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. =A0Yes, 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:
>
> =A0 RATE 10
>
> then you should support a query like this:
>
> =A0 RATE?
>
> and it should be reported in command format like this:
>
> =A0 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:
>
> =A0 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. =A0The nice thing is that they've
> put it all into a single document causes you to think a little more
> closely about details. =A0By they way, they suggest (but do not demand,
> of course) the idea of allowing units, so that the above command might
> be specified as:
>
> =A0 RATE 10s
>
> or,
>
> =A0 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

thats called SCPI

On Mon, 26 Jan 2009 19:35:43 -0500, Robert Adsett
<sub2@aeolusdevelopment.com> wrote:

>In article <-76dnUzuiZiWbuDUnZ2dnUVZ_jydnZ2d@web-ster.com>, Tim Wescott 
>says...
>> 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.
>
>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).

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

In article <-76dnUzuiZiWbuDUnZ2dnUVZ_jydnZ2d@web-ster.com>, Tim Wescott 
says...
> 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.

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

Tim Wescott schrieb:
> On Sat, 24 Jan 2009 21:10:59 +0100, Falk Willberg wrote:
...

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

...

> I've used protocols as you describe, and I've used human-readable ones; 
> each has it's place.
...

Ack.

Falk

On Sat, 24 Jan 2009 21:10:59 +0100, Falk Willberg wrote:

> Tim Wescott schrieb:
>> On Sat, 24 Jan 2009 19:45:03 +0100, Frank Buss wrote:
>> 
>>> srinusingh wrote:
>>>
>>>> hi......... iam doing ADC using PIC18f452.This ADC is 12bit. NOW i
>>>> have to send that 12bit output data to PC, my problem is that in PIC
>>>> we have only 8bit data transmit register , but i have to send this 12
>>>> digital data .How i can do this
> 
> ...
> 
>> If I have the bandwidth,
> 
> One day your boss will say "Now we need to transfer ten times more
> data...."
> 
>> I prefer to do something that's human-readable,
> 
> 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

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

In article <MPG.23e7b77615dfc6fc98a9ca@newsgroups.bellsouth.net>, 
asgard24@mindspring.com says...
>  hex (0x0000 - 0x1000)
> 
Sorry, 0x000 - 0xfff
Damn, rolled over.

In article <fJKdnQ5ARupg7ObUnZ2dnUVZ_rfinZ2d@web-ster.com>, 
tim@seemywebsite.com says...
> On Sat, 24 Jan 2009 19:45:03 +0100, Frank Buss wrote:
> 
> > srinusingh wrote:
> > 
> >> hi......... iam doing ADC using PIC18f452.This ADC is 12bit. NOW i have
> >> to send that 12bit output data to PC, my problem is that in PIC we have
> >> only 8bit data transmit register , but i have to send this 12 digital
> >> data .How i can do this
> > 
> > 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).
> 
> 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.
> 
> 
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.