"Glenn" <glenn2233@gmail.com> wrote in message news:50c45e31$0$284$14726298@news.sunsite.dk...> On 07/12/12 15.17, Ivan Shmakov wrote: >> BTW, is there an easy way to autodetect the baud rate while >> using an AVR UART? (Preferably something that works with >> ATmega8, given that those MCU's are such a cheap thing >> nowadays.) >> >> There're some ideas (and 8051 code) for that on [1], but I'd >> like to know if there could be any better techniques. >> >> TIA. >> >> [1] http://www.pjrc.com/tech/8051/autobaud.html >> >> PS. It seems that I'm slowly drifting into designing my own, AVR-based >> Bus Pirate clone. The good news is that the parts for this one >> will likely cost under $10... (connectors included.) >>Pefectly possible...you just have to write the software....
baud rate autodetection on AVR 8-bit?
Started by ●December 7, 2012
Reply by ●December 9, 20122012-12-09
Reply by ●December 9, 20122012-12-09
On Sunday, December 9, 2012 9:38:50 AM UTC-6, TTman wrote:> "Glenn" <glenn2233@gmail.com> wrote in message > > news:50c45e31$0$284$14726298@news.sunsite.dk... > > > On 07/12/12 15.17, Ivan Shmakov wrote: > > >> BTW, is there an easy way to autodetect the baud rate while > > >> using an AVR UART? (Preferably something that works with > > >> ATmega8, given that those MCU's are such a cheap thing > > >> nowadays.) > > >> > > >> There're some ideas (and 8051 code) for that on [1], but I'd > > >> like to know if there could be any better techniques. > > >> > > >> TIA. > > >> > > >> [1] http://www.pjrc.com/tech/8051/autobaud.html > > >> > > >> PS. It seems that I'm slowly drifting into designing my own, AVR-based > > >> Bus Pirate clone. The good news is that the parts for this one > > >> will likely cost under $10... (connectors included.) > > >> > > > > Pefectly possible...you just have to write the software....someone beat you to it... http://blog.hodgepig.org/busninja/
Reply by ●December 9, 20122012-12-09
On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote:> >I am so "pissed" about RS-232/EIA-232. > >After so many years with that "stupid vintage" serial communications >protocol, we still do not have autonegotiation (and auto-baud-detection) >built into the protocol definitions. Why not?RS-232 originally only specified, how a DCE (Data Communication Equipment, i.e. a modem) should be connected over a short distance (up to 15 m) to a DTE (Data Terminal Equipment) either a central computer or a remote terminal. Thus it made possible to use remote terminals (DTE to DCE) over a communication channel e.g. (leased) phone line to central computer (DCE to DTE). The standard specifies the voltage levels and abstract CCITT signal numbers as more familiar signal names. The original standard did not specify the DB25 connector or pin numbering. However, the specification includes secondary channel, clock signals (for synchronous communication) etc. Later on the standard was "misused" to directly connect terminals to a computer locally and various modem eliminators (null modems) to skip the DCE-phone_line-DCE part of the remote circuit. In the simplest case, just cross connect TxD and Rxd, however, various tricks are needed to fool handshakes. For interfacing two synchronous devices, some electronics is actually needed in the "null modem". The problem was that each manufacturer "misused" the DTE-DCE standard _differently_ causing problems for "null modems" for direct DTE to DTE connections !! It should once more be stressed that the RS-232 standard was not originally designed for direct terminal to computer interfacing. Much simpler systems existed for local terminal to computer interfacing, such as 20 mA current loop. In a mechanical Teletype, the only semiconductors were the rectifier diodes in the power supply (24-60 V) and a big power transistor to generate the 20 mA current source. A Teletype with RS-232 interface required at least an additional +/-12 V power supply and at least two ICs (e.g. 1488/1489) or a lot of discrete components before those chips were available.
Reply by ●December 9, 20122012-12-09
>>>>> MK <mk@nospam.co.uk> writes: >>>>> On 08/12/2012 11:31, Ivan Shmakov wrote: >>>>> MK <mk@nospam.co.uk> writes: >>>>> On 07/12/2012 20:47, Ivan Shmakov wrote:[Cross-posting to news:comp.sys.arm, at last.] >>>> AIUI, ATmega8 only allows for input capture to happen on an >>>> "event" occurring either on analog comparator output, or a >>>> specific ICP1 pin. Unfortunately, I'd need the latter for GPIO. >>>> (Naturally, ICP1 is distinct from UART's RxD.) >>> Since you are starting out on a new project why use an obsolete >>> processor? You can buy an LPC1113 (or some one else's ARM Cortex >>> M0) for less money than an ATmega8 and it has much better timers >>> with input capture. >> Apart from lacking any experience whatsoever with ARM, I'm also >> somewhat concerned about the ARM's /generally/ being unavailable in >> TQFP, SO or DIP packages, which may be important should I'll be >> making a "kit" of the design I'm currently working on. >> Besides, where can I find an ARM for $0.9 (or less; including >> shipping)? (For the quantity, I'd readily buy 10 or so.) > ARMs are easily available in TQFP packages and I rarely use anything > else. As for prices: > 100 off Digikey, > LPC1113FBD48/302,1 = $2.05 > ATMEGA8A-AU = $1.79 Well, I was able to order 10 ATmega8's for $8.80 on eBay. (Hopefully, I'll get them within a week from now.) Besides, it isn't quite "for less money than," as was stated above. Digi-Key doesn't seem like a sensible choice /for me/, either. FWIW, they're located on a whole different continent. >>> It also has a good 10x the performance! >> ... And what about the power consumption? > You'll need to compare power consumption yourself but generally ARM > M0s are pretty good and will easily beat the AVR in terms of useful > calculations per watt. ACK, thanks. > If you'll relax your package demands and accept LPC1111FHN33/201,5 in > QFN it'll only cost you $1.38 (Digikey 100 off). > I've hand soldered quite a few of these and it's perfectly feasible > (you may need a microscope but I use one for TQFPs any way.) The point is that should I ever end up designing my own kits, there'd be a whole world of hobbyists that won't be able to tackle anything with pitch finer than that of TQFP. (Or perhaps even finer than SO; but there, ARM seem to be in an advantage, as some LPC111x seem to be available in SO just as well.) -- FSF associate member #7257
Reply by ●December 9, 20122012-12-09
On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote:>On 07/12/12 15.17, Ivan Shmakov wrote: >> BTW, is there an easy way to autodetect the baud rate while >> using an AVR UART? (Preferably something that works with >> ATmega8, given that those MCU's are such a cheap thing >> nowadays.) >> >> There're some ideas (and 8051 code) for that on [1], but I'd >> like to know if there could be any better techniques. >> >> TIA. >> >> [1] http://www.pjrc.com/tech/8051/autobaud.html >> >> PS. It seems that I'm slowly drifting into designing my own, AVR-based >> Bus Pirate clone. The good news is that the parts for this one >> will likely cost under $10... (connectors included.) >> > >(Please respond to news://comp.arch.embedded ) > >Hi! > >I am so "pissed" about RS-232/EIA-232. > >After so many years with that "stupid vintage" serial communications >protocol, we still do not have autonegotiation (and auto-baud-detection) >built into the protocol definitions. Why not?RS232 doesn't have a protocol definition. And it never will. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
Reply by ●December 9, 20122012-12-09
Le 09/12/2012 18:02, John Larkin a �crit :> On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote: > >> On 07/12/12 15.17, Ivan Shmakov wrote: >>> BTW, is there an easy way to autodetect the baud rate while >>> using an AVR UART? (Preferably something that works with >>> ATmega8, given that those MCU's are such a cheap thing >>> nowadays.) >>> >>> There're some ideas (and 8051 code) for that on [1], but I'd >>> like to know if there could be any better techniques. >>> >>> TIA. >>> >>> [1] http://www.pjrc.com/tech/8051/autobaud.html >>> >>> PS. It seems that I'm slowly drifting into designing my own, AVR-based >>> Bus Pirate clone. The good news is that the parts for this one >>> will likely cost under $10... (connectors included.) >>> >> >> (Please respond to news://comp.arch.embedded ) >> >> Hi! >> >> I am so "pissed" about RS-232/EIA-232. >> >> After so many years with that "stupid vintage" serial communications >> protocol, we still do not have autonegotiation (and auto-baud-detection) >> built into the protocol definitions. Why not? > > RS232 doesn't have a protocol definition. And it never will. >There is a "protocol" in that RTS must be followed by CTS and so on. Apart from that, there are a lot of embedded systems that don't need "fancy" features. When the data rate is fixed there is no need for autodetection. It adds cost, complexity, rampant bugs, all sorts of nastiness. A good design is the least complexity to achieve maximum safety and compliance, not a host of sophisticated features that are used for no good reason, only because it is trendy. Of course, in some cases, you need sophistication, but then, by all means, one should use another protocol.
Reply by ●December 9, 20122012-12-09
On Sun, 09 Dec 2012 18:13:30 +0100, Lanarcam <lanarcam1@yahoo.fr> wrote:>Le 09/12/2012 18:02, John Larkin a �crit : >> On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote: >> >>> On 07/12/12 15.17, Ivan Shmakov wrote: >>>> BTW, is there an easy way to autodetect the baud rate while >>>> using an AVR UART? (Preferably something that works with >>>> ATmega8, given that those MCU's are such a cheap thing >>>> nowadays.) >>>> >>>> There're some ideas (and 8051 code) for that on [1], but I'd >>>> like to know if there could be any better techniques. >>>> >>>> TIA. >>>> >>>> [1] http://www.pjrc.com/tech/8051/autobaud.html >>>> >>>> PS. It seems that I'm slowly drifting into designing my own, AVR-based >>>> Bus Pirate clone. The good news is that the parts for this one >>>> will likely cost under $10... (connectors included.) >>>> >>> >>> (Please respond to news://comp.arch.embedded ) >>> >>> Hi! >>> >>> I am so "pissed" about RS-232/EIA-232. >>> >>> After so many years with that "stupid vintage" serial communications >>> protocol, we still do not have autonegotiation (and auto-baud-detection) >>> built into the protocol definitions. Why not? >> >> RS232 doesn't have a protocol definition. And it never will. >> >There is a "protocol" in that RTS must be followed by CTS and so on.There are quite lot of handshaking in the DTE-DCE connection. Typically the DTE computer/terminal sets the DTR (Data terminal Ready) when it is powered up. The modem (DCE) sets the DSR (Data Set Ready) when it is powered up and ready to communicate (telephone contact established). Until both DTR and DSR are on, there is not much point of trying to communicate. In half duplex (radio)communication world, rising RTS is an indication that this station wants to transmit. For a radio link, this might include listening to the radio channel if the radio channel is free and if so, turn on the radio transmitter and wait until the PLL is stabilized, before turning on the actual radio transmitter, after which the CTS is raised and the actual message transmission can begin. Those signals are there or a reason, not to make it harder to interface ordinary devices.
Reply by ●December 9, 20122012-12-09
In article <v1b9c8d9tvv7aj506fi6nf1t33bpn4idl6@4ax.com>, upsidedown@downunder.com says...> > On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote: > > > > >I am so "pissed" about RS-232/EIA-232. > > > >After so many years with that "stupid vintage" serial communications > >protocol, we still do not have autonegotiation (and auto-baud-detection) > >built into the protocol definitions. Why not? > > RS-232 originally only specified, how a DCE (Data Communication > Equipment, i.e. a modem) should be connected over a short distance (up > to 15 m) to a DTE (Data Terminal Equipment) either a central computer > or a remote terminal. Thus it made possible to use remote terminals > (DTE to DCE) over a communication channel e.g. (leased) phone line to > central computer (DCE to DTE).Actually RS232 specifies signal levels the cable length urban myth is a common misreading of RS232A and RS232B, where it said that if configured using a very capacative cable with lots of adjacent signals the noise level went up at 15m. However the noise level never went across a noise margin to cause problems. I have seen RS232 driven down 1km of bell wire and function correctly. The DTE/DCE comes from CCIT V24 (Now part of ITU in particular ITU-T) is a telecoms standard particularly for modems and working out what was an end point and a mid-point (modem). This is what originally specified the DB25 and the signal naming.> The standard specifies the voltage levels and abstract CCITT signal > numbers as more familiar signal names. The original standard did not > specify the DB25 connector or pin numbering.The abstract CCITT numbers are CCITT V24 refernce not RS232 until about RS232 Rev D. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
Reply by ●December 9, 20122012-12-09
In article <50c4c6ba$0$16503$426a34cc@news.free.fr>, lanarcam1@yahoo.fr says...> > Le 09/12/2012 18:02, John Larkin a �crit : > > On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote: > > > >> On 07/12/12 15.17, Ivan Shmakov wrote: > >>> BTW, is there an easy way to autodetect the baud rate while > >>> using an AVR UART? (Preferably something that works with > >>> ATmega8, given that those MCU's are such a cheap thing > >>> nowadays.) > >>> > >>> There're some ideas (and 8051 code) for that on [1], but I'd > >>> like to know if there could be any better techniques. > >>> > >>> TIA. > >>> > >>> [1] http://www.pjrc.com/tech/8051/autobaud.html > >>> > >>> PS. It seems that I'm slowly drifting into designing my own, AVR-based > >>> Bus Pirate clone. The good news is that the parts for this one > >>> will likely cost under $10... (connectors included.) > >>> > >> > >> (Please respond to news://comp.arch.embedded ) > >> > >> Hi! > >> > >> I am so "pissed" about RS-232/EIA-232. > >> > >> After so many years with that "stupid vintage" serial communications > >> protocol, we still do not have autonegotiation (and auto-baud-detection) > >> built into the protocol definitions. Why not? > > > > RS232 doesn't have a protocol definition. And it never will. > > > There is a "protocol" in that RTS must be followed by CTS and so on.That is CCITT V24 and actually does not specify RS232 only actually could be used with all sorts of signalling levels and connectors. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
Reply by ●December 10, 20122012-12-10
On Sun, 09 Dec 2012 10:47:29 +0100, Glenn <glenn2233@gmail.com> wrote:>On 07/12/12 15.17, Ivan Shmakov wrote: >> BTW, is there an easy way to autodetect the baud rate while >> using an AVR UART? (Preferably something that works with >> ATmega8, given that those MCU's are such a cheap thing >> nowadays.) >> >> There're some ideas (and 8051 code) for that on [1], but I'd >> like to know if there could be any better techniques. >> >> TIA. >> >> [1] http://www.pjrc.com/tech/8051/autobaud.html >> >> PS. It seems that I'm slowly drifting into designing my own, AVR-based >> Bus Pirate clone. The good news is that the parts for this one >> will likely cost under $10... (connectors included.) >> > >(Please respond to news://comp.arch.embedded ) > >Hi! > >I am so "pissed" about RS-232/EIA-232. > >After so many years with that "stupid vintage" serial communications >protocol, we still do not have autonegotiation (and auto-baud-detection) >built into the protocol definitions. Why not? > >Why have nobody made a request-for-comment about that, then so many >people do not have to bother with a myriad of out-of-bound signals and >in-band signal (xon, xoff) manually. > >It is simply incredibly, that after so many decades, you manually has to >find out, how to get it to work. > >Please be inspired to release open and free RFC-definitions now, so that >"vintage" serial communication will work smoothly - and with backward >compatibility and of cause with auto "null-modem" functionality. > >I am looking forward to, that all out-of-bound signals can automatically >be mapped by software by a series of signal pertubations and response >measurements. > >I know I am very demanding, but it ought to be possible? At least the >software should detect and notify the user, that a null-modem cable >connection is required. But it is a bad compromise. > >The communications world (and its users) would be much happier with a >full blown software solution. > >Let us exterminate 232 jumper boxes. They are the ultimate time eating >stupid solution, that shows we have given up finding a better solution: >http://www.amazon.com/DB25-Female-RS-232-Jumper-Assembly/dp/B000I996EE > >Instead we should have a 232 autonegotiation-box/cable, that can be >inserted between no-negotiation 232 equipped equipment. > >;-) > >Glenn > >PS: I know that USB exists...As others have mentioned, RS-232 does not come close to defining the stuff you want, and you need several layers higher in the stack. And heck, not even the signal levels required by RS-232 are particularly well respected. But after doing everything you want, you're going to end up with something largely incompatible with conventional async/serial/RS-232 style connections. At that point, there's no point - that sort of serial connection is used *only* because support for it is ubiquitous, not because it's a particularly good technology. So if you change it, it becomes irrelevant. And in this day and age serial ports are (slowly) dying anyway. And once you add all that stuff into your link, you'll be back to something with complexity similar to that of USB anyway, so why reinvent it? And for peripherals, you've been able to get single USB chip implementations for a buck or two for years now, which are only minimally more difficult to use than a bare serial port from your device's CPU. Or if you don't like that, throw a buck or two Ethernet port and a TCP/IP stack on the device.