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
RS232 interface
Started by ●January 24, 2009
Reply by ●January 24, 20092009-01-24
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 thisSend 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
Reply by ●January 24, 20092009-01-24
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. -- http://www.wescottdesign.com
Reply by ●January 24, 20092009-01-24
Tim Wescott wrote:> 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".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).> 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.You are right. If the bandwidth is no problem, I'll do the same, see e.g. this small protocol: http://www.frank-buss.de/rs232toi2c/ 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
Reply by ●January 24, 20092009-01-24
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
Reply by ●January 24, 20092009-01-24
On Sat, 24 Jan 2009 13:54:37 -0600, Tim Wescott <tim@seemywebsite.com> wrote:>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.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
Reply by ●January 24, 20092009-01-24
On 2009-01-24, Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:> 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...Don't forget to escape STX and ETX when it occurs in data or CSUM fields... -- Grant
Reply by ●January 24, 20092009-01-24
srinusingh wrote:> > 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 thisMy 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]: <http://cbfalconer.home.att.net> Try the download section.
Reply by ●January 25, 20092009-01-25
Grant Edwards schrieb:> On 2009-01-24, Falk Willberg <Faweglassenlk@falk-willberg.de> wrote: > >> 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... > > Don't forget to escape STX and ETX when it occurs in data or > CSUM fields...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
Reply by ●January 26, 20092009-01-26
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.
