In article <MPG.23e7b77615dfc6fc98a9ca@newsgroups.bellsouth.net>, asgard24@mindspring.com says...> hex (0x0000 - 0x1000) >Sorry, 0x000 - 0xfff Damn, rolled over.
RS232 interface
Started by ●January 24, 2009
Reply by ●January 26, 20092009-01-26
Reply by ●January 26, 20092009-01-26
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, > FalkI 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
Reply by ●January 26, 20092009-01-26
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
Reply by ●January 26, 20092009-01-26
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
Reply by ●January 26, 20092009-01-26
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
Reply by ●January 27, 20092009-01-27
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.) > > Jonthats called SCPI
Reply by ●January 27, 20092009-01-27
On Tue, 27 Jan 2009 06:06:21 -0800 (PST), bigbrownbeastiebigbrownface@googlemail.com wrote:>On Jan 27, 1:03�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. �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 > >thats called SCPINo, 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
Reply by ●January 28, 20092009-01-28
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
