27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

Hi All, This is slighly an off the topic question.This is basically for a system using 68hc11. we have a requirement for automatically detecting communication parameters of a serial port. Requirements and scenarios are like following, 1. Baud rate, data length, parity, number of stop bits all are unknown and has to be detected. 2. No predefined data can be assumed (everything is valid from 00H - FFH) 3. Since the actual communication is done through RF, it is possible that some amount of Over run/Framing errors can exist even if the communication parameters are set correctly. Any ideas? [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, writes: > Hi All, > This is slighly an off the topic question.This is basically for a system > using 68hc11. > we have a requirement for automatically detecting communication parameters > of a serial port. Requirements and scenarios are like following, > 1. Baud rate, data length, parity, number of stop bits all are unknown and > has to be detected. > 2. No predefined data can be assumed (everything is valid from 00H - FFH) > 3. Since the actual communication is done through RF, it is possible that > some amount of Over run/Framing errors can exist even if the communication > parameters are set correctly. > Any ideas? Not at all, I'm interested in your final solution. Dan [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi, My thoughts are that, we will start with different combination of baud rate and other parameter and try until we get some consucutive bytes without parity/overrun/framing errors and no frequent timeouts..here since the packets are not known, we cannot depend on the checksum initially. Once we start getting bytes without errors, we can reduce the baud rate and see whether we are still able to recieve it.. Any one see any potential problem in doingas described above ?is there any other good methods techniques? thanks anees -----Original Message----- From: [mailto:] Sent: Friday, October 25, 2002 3:46 PM To: Subject: Re: [m68HC11] Comport parameters In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, writes: > Hi All, > This is slighly an off the topic question.This is basically for a system > using 68hc11. > we have a requirement for automatically detecting communication parameters > of a serial port. Requirements and scenarios are like following, > 1. Baud rate, data length, parity, number of stop bits all are unknown and > has to be detected. > 2. No predefined data can be assumed (everything is valid from 00H - FFH) > 3. Since the actual communication is done through RF, it is possible that > some amount of Over run/Framing errors can exist even if the communication > parameters are set correctly. > Any ideas? Not at all, I'm interested in your final solution. Dan [Non-text portions of this message have been removed] To unsubscribe from this group, send an email to: [Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

----- Original Message ----- From: "Anees Hameed" <> To: < > we have a requirement for automatically detecting communication parameters > of a serial port. Requirements and scenarios are like following, > 1. Baud rate, data length, parity, number of stop bits all are unknown and > has to be detected. Do you at least have a list of all possible settings, or is it truly random? If you know the possibilities, you can go around the list in circles until you can receive something intelligible. Are you confined to the SCI, or are you using software routines that can be set at practically any bps? If using the SCI, do all TX possibilities of the remote match the SCI's RX capabilities? If not, you need to redesign. > 2. No predefined data can be assumed (everything is valid from 00H - FFH) > 3. Since the actual communication is done through RF, it is possible that > some amount of Over run/Framing errors can exist even if the communication > parameters are set correctly. RF communications normally use some kind of error detection (two-way tx with retries) or correction (one-way tx). Whether your received data passes these checks will help you detect if you're receiving with the wrong settings.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

For baud rate, you might try measuring the time between transitions and inferring the baud rate knowing they have to be some multiple of the baud "period". Essentially, you are looking for the quantum size of all spaces and some marks (or do I have this backwards). The other marks (spaces if I'm backwards) may represent unquantized time between characters. This might be quicker than scanning through different baud rates and you could also find non-standard ones. For further reference you might look up the Milliken oil drop experiment; he discovered the quantized charge of the electron. Emmett Redd Ph.D. mailto: Associate Professor (417)836-5221 Department of Physics, Astronomy, and Material Science Southwest Missouri State University Fax (417)836-6226 901 SOUTH NATIONAL Dept (417)836-5131 SPRINGFIELD, MO 65804 USA > -----Original Message----- > From: Anees Hameed [mailto:] > Sent: Friday, October 25, 2002 9:31 PM > To: > Subject: RE: [m68HC11] Comport parameters > > Hi, > > My thoughts are that, we will start with different combination of baud > rate > and other parameter and try until we get some consucutive bytes without > parity/overrun/framing errors and no frequent timeouts..here since the > packets are not known, we cannot depend on the checksum initially. Once we > start getting bytes without errors, we can reduce the baud rate and see > whether we are still able to recieve it.. > > Any one see any potential problem in doingas described above ?is there any > other good methods techniques? > thanks > anees > > -----Original Message----- > From: [mailto:] > Sent: Friday, October 25, 2002 3:46 PM > To: > Subject: Re: [m68HC11] Comport parameters > In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, > writes: > > Hi All, > > This is slighly an off the topic question.This is basically for a system > > using 68hc11. > > we have a requirement for automatically detecting communication > parameters > > > of a serial port. Requirements and scenarios are like following, > > 1. Baud rate, data length, parity, number of stop bits all are unknown > and > > > has to be detected. > > 2. No predefined data can be assumed (everything is valid from 00H - > FFH) > > 3. Since the actual communication is done through RF, it is possible > that > > some amount of Over run/Framing errors can exist even if the > communication > > > parameters are set correctly. > > Any ideas? > > > > > > Not at all, I'm interested in your final solution. > > Dan > [Non-text portions of this message have been removed] > > To unsubscribe from this group, send an email to: > > > [Non-text portions of this message have been removed] > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to:

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi thanks for the reply, If I understand correctly ,you are essentially talkign about measuring bit times ?How can i do this using a serial controller in a microcontroller ?. So without any new hardware How can i measure the timings? -----Original Message----- From: Redd, Emmett R [mailto:] Sent: Monday, October 28, 2002 3:52 PM To: Subject: RE: [m68HC11] Comport parameters For baud rate, you might try measuring the time between transitions and inferring the baud rate knowing they have to be some multiple of the baud "period". Essentially, you are looking for the quantum size of all spaces and some marks (or do I have this backwards). The other marks (spaces if I'm backwards) may represent unquantized time between characters. This might be quicker than scanning through different baud rates and you could also find non-standard ones. For further reference you might look up the Milliken oil drop experiment; he discovered the quantized charge of the electron. Emmett Redd Ph.D. mailto: Associate Professor (417)836-5221 Department of Physics, Astronomy, and Material Science Southwest Missouri State University Fax (417)836-6226 901 SOUTH NATIONAL Dept (417)836-5131 SPRINGFIELD, MO 65804 USA > -----Original Message----- > From: Anees Hameed [mailto:] > Sent: Friday, October 25, 2002 9:31 PM > To: > Subject: RE: [m68HC11] Comport parameters > > Hi, > > My thoughts are that, we will start with different combination of baud > rate > and other parameter and try until we get some consucutive bytes without > parity/overrun/framing errors and no frequent timeouts..here since the > packets are not known, we cannot depend on the checksum initially. Once we > start getting bytes without errors, we can reduce the baud rate and see > whether we are still able to recieve it.. > > Any one see any potential problem in doingas described above ?is there any > other good methods techniques? > thanks > anees > > -----Original Message----- > From: [mailto:] > Sent: Friday, October 25, 2002 3:46 PM > To: > Subject: Re: [m68HC11] Comport parameters > In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, > writes: > > Hi All, > > This is slighly an off the topic question.This is basically for a system > > using 68hc11. > > we have a requirement for automatically detecting communication > parameters > > > of a serial port. Requirements and scenarios are like following, > > 1. Baud rate, data length, parity, number of stop bits all are unknown > and > > > has to be detected. > > 2. No predefined data can be assumed (everything is valid from 00H - > FFH) > > 3. Since the actual communication is done through RF, it is possible > that > > some amount of Over run/Framing errors can exist even if the > communication > > > parameters are set correctly. > > Any ideas? > > > > > > Not at all, I'm interested in your final solution. > > Dan > [Non-text portions of this message have been removed] > > To unsubscribe from this group, send an email to: > > > <http://docs.yahoo.com/info/terms/ > [Non-text portions of this message have been removed] > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to: > > > <http://docs.yahoo.com/info/terms/ Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=237459.2482214.3917349.2146399/D=egroupweb/S=17065542 05:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650;sz= 300x250;ord=1035838187111299?> <http://us.adserver.yahoo.com/l?M=237459.2482214.3917349.2146399/D=egroupmai l/S=:HM/A=1267611/rand=157340117> To unsubscribe from this group, send an email to: > . [Non-text portions of this message have been removed]

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

In a message dated 10/28/02 5:05:18 PM Eastern Standard Time, writes: > If I understand correctly ,you are essentially talkign about measuring bit > times ?How can i do this using a serial controller in a microcontroller ?. > So without any new hardware How can i measure the timings? The rxd pin is also port d bit 0..... look for a change and start counting.... 9600 bits per sec is 104 usec per bit as I recall... if you were real lucky, you could get the guy to send you UUUUUUs, which is 0x55.... a bunch of 01010101010s in binary.... [Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

The HC11 has a good timer system (see Chapter 10 of the Pink Book) that includes Input Captures. You could run the signal to both the SCI and an Input Capture. Determine the baud rate via the Timer and Input Capture and use it on the SCI. Or, build a software UART totally on the Input Captures to use after determining the baud rate. (Referring to the Pink Book discussion on how the SCI operates might help design a software UART.) Emmett Redd Ph.D. mailto: Associate Professor (417)836-5221 Department of Physics, Astronomy, and Material Science Southwest Missouri State University Fax (417)836-6226 901 SOUTH NATIONAL Dept (417)836-5131 SPRINGFIELD, MO 65804 USA > -----Original Message----- > From: Anees Hameed [mailto:] > Sent: Monday, October 28, 2002 4:01 PM > To: ' > Subject: RE: [m68HC11] Comport parameters > > Hi thanks for the reply, > If I understand correctly ,you are essentially talkign about measuring bit > times ?How can i do this using a serial controller in a microcontroller ?. > So without any new hardware How can i measure the timings? > > -----Original Message----- > From: Redd, Emmett R [mailto:] > Sent: Monday, October 28, 2002 3:52 PM > To: > Subject: RE: [m68HC11] Comport parameters > For baud rate, you might try measuring the time between transitions and > inferring the baud rate knowing they have to be some multiple of the > baud "period". Essentially, you are looking for the quantum size of all > spaces and some marks (or do I have this backwards). The other marks > (spaces if I'm backwards) may represent unquantized time between > characters. This might be quicker than scanning through different baud > rates and you could also find non-standard ones. > > For further reference you might look up the Milliken oil drop > experiment; he discovered the quantized charge of the electron. > > Emmett Redd Ph.D. mailto: > Associate Professor (417)836-5221 > Department of Physics, Astronomy, and Material Science > Southwest Missouri State University Fax (417)836-6226 > 901 SOUTH NATIONAL Dept (417)836-5131 > SPRINGFIELD, MO 65804 USA > > > -----Original Message----- > > From: Anees Hameed [mailto:] > > Sent: Friday, October 25, 2002 9:31 PM > > To: > > Subject: RE: [m68HC11] Comport parameters > > > > Hi, > > > > My thoughts are that, we will start with different combination of baud > > rate > > and other parameter and try until we get some consucutive bytes > without > > parity/overrun/framing errors and no frequent timeouts..here since the > > packets are not known, we cannot depend on the checksum initially. > Once we > > start getting bytes without errors, we can reduce the baud rate and > see > > whether we are still able to recieve it.. > > > > Any one see any potential problem in doingas described above ?is there > any > > other good methods techniques? > > thanks > > anees > > > > > > > > -----Original Message----- > > From: [mailto:] > > Sent: Friday, October 25, 2002 3:46 PM > > To: > > Subject: Re: [m68HC11] Comport parameters > > > > > > In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, > > writes: > > > > > > > Hi All, > > > This is slighly an off the topic question.This is basically for a > system > > > using 68hc11. > > > we have a requirement for automatically detecting communication > > parameters > > > > > of a serial port. Requirements and scenarios are like following, > > > 1. Baud rate, data length, parity, number of stop bits all are > unknown > > and > > > > > has to be detected. > > > 2. No predefined data can be assumed (everything is valid from 00H - > > FFH) > > > 3. Since the actual communication is done through RF, it is possible > > that > > > some amount of Over run/Framing errors can exist even if the > > communication > > > > > parameters are set correctly. > > > Any ideas? > > > > > > > > > > Not at all, I'm interested in your final solution. > > > > Dan > > > > > > [Non-text portions of this message have been removed] > > > > > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > <http://docs.yahoo.com/info/terms/> > > > > > > [Non-text portions of this message have been removed] > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > <http://docs.yahoo.com/info/terms/> > > > Yahoo! Groups Sponsor > > ADVERTISEMENT <http://rd.yahoo.com/M=237459.2482214.3917349.2146399/D=egroupweb/S=1706 55 > 42 > 05:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650 ;s > z= > 300x250;ord=1035838187111299? <http://us.adserver.yahoo.com/l?M=237459.2482214.3917349.2146399/D=egrou pm > ai > l/S=:HM/A=1267611/rand=157340117> > > To unsubscribe from this group, send an email to: > > > > . > > > [Non-text portions of this message have been removed] > ------------------------ Yahoo! Groups Sponsor > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

With regard to designing software uarts. I suggest a look at AN1818 "Software SCI Routines with the 16-Bit Timer Module" available at the Moto MCU web site. While originally written for the 'HC05, it should contain many ideas and concepts usable for the 'HC11. Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-1065 ----- Original Message ----- From: "Redd, Emmett R" <> To: <> Sent: Monday, October 28, 2002 5:14 PM Subject: RE: [m68HC11] Comport parameters > The HC11 has a good timer system (see Chapter 10 of the Pink Book) that > includes Input Captures. You could run the signal to both the SCI and > an Input Capture. Determine the baud rate via the Timer and Input > Capture and use it on the SCI. Or, build a software UART totally on the > Input Captures to use after determining the baud rate. (Referring to > the Pink Book discussion on how the SCI operates might help design a > software UART.) > > Emmett Redd Ph.D. mailto: > Associate Professor (417)836-5221 > Department of Physics, Astronomy, and Material Science > Southwest Missouri State University Fax (417)836-6226 > 901 SOUTH NATIONAL Dept (417)836-5131 > SPRINGFIELD, MO 65804 USA > > > -----Original Message----- > > From: Anees Hameed [mailto:] > > Sent: Monday, October 28, 2002 4:01 PM > > To: ' > > Subject: RE: [m68HC11] Comport parameters > > > > Hi thanks for the reply, > > If I understand correctly ,you are essentially talkign about measuring > bit > > times ?How can i do this using a serial controller in a > microcontroller ?. > > So without any new hardware How can i measure the timings? > > > > -----Original Message----- > > From: Redd, Emmett R [mailto:] > > Sent: Monday, October 28, 2002 3:52 PM > > To: > > Subject: RE: [m68HC11] Comport parameters > > > > > > For baud rate, you might try measuring the time between transitions > and > > inferring the baud rate knowing they have to be some multiple of the > > baud "period". Essentially, you are looking for the quantum size of > all > > spaces and some marks (or do I have this backwards). The other marks > > (spaces if I'm backwards) may represent unquantized time between > > characters. This might be quicker than scanning through different > baud > > rates and you could also find non-standard ones. > > > > For further reference you might look up the Milliken oil drop > > experiment; he discovered the quantized charge of the electron. > > > > Emmett Redd Ph.D. mailto: > > Associate Professor (417)836-5221 > > Department of Physics, Astronomy, and Material Science > > Southwest Missouri State University Fax (417)836-6226 > > 901 SOUTH NATIONAL Dept (417)836-5131 > > SPRINGFIELD, MO 65804 USA > > > > > -----Original Message----- > > > From: Anees Hameed [mailto:] > > > Sent: Friday, October 25, 2002 9:31 PM > > > To: > > > Subject: RE: [m68HC11] Comport parameters > > > > > > Hi, > > > > > > My thoughts are that, we will start with different combination of > baud > > > rate > > > and other parameter and try until we get some consucutive bytes > > without > > > parity/overrun/framing errors and no frequent timeouts..here since > the > > > packets are not known, we cannot depend on the checksum initially. > > Once we > > > start getting bytes without errors, we can reduce the baud rate and > > see > > > whether we are still able to recieve it.. > > > > > > Any one see any potential problem in doingas described above ?is > there > > any > > > other good methods techniques? > > > thanks > > > anees > > > > > > > > > > > > -----Original Message----- > > > From: [mailto:] > > > Sent: Friday, October 25, 2002 3:46 PM > > > To: > > > Subject: Re: [m68HC11] Comport parameters > > > > > > > > > In a message dated 10/25/2002 2:34:33 PM Eastern Standard Time, > > > writes: > > > > > > > > > > Hi All, > > > > This is slighly an off the topic question.This is basically for a > > system > > > > using 68hc11. > > > > we have a requirement for automatically detecting communication > > > parameters > > > > > > > of a serial port. Requirements and scenarios are like following, > > > > 1. Baud rate, data length, parity, number of stop bits all are > > unknown > > > and > > > > > > > has to be detected. > > > > 2. No predefined data can be assumed (everything is valid from 00H > - > > > FFH) > > > > 3. Since the actual communication is done through RF, it is > possible > > > that > > > > some amount of Over run/Framing errors can exist even if the > > > communication > > > > > > > parameters are set correctly. > > > > Any ideas? > > > > > > > > > > > > > > Not at all, I'm interested in your final solution. > > > > > > Dan > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > > > <http://docs.yahoo.com/info/terms/> > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > > > <http://docs.yahoo.com/info/terms/> > > > > > > > > > > > Yahoo! Groups Sponsor > > > > ADVERTISEMENT > > > > > <http://rd.yahoo.com/M=237459.2482214.3917349.2146399/D=egroupweb/S=1706 > 55 > > 42 > > > 05:HM/A=1267611/R=0/*http://ad.doubleclick.net/jump/N2524.Yahoo/B1071650 > ;s > > z= > > 300x250;ord=1035838187111299?> > > > > > <http://us.adserver.yahoo.com/l?M=237459.2482214.3917349.2146399/D=egrou > pm > > ai > > l/S=:HM/A=1267611/rand=157340117> > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > . > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > To unsubscribe from this group, send an email to: > > > > > > > > > > > > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )