[Gumstix-users] robostix clock rate

 [Gumstix-users] robostix clock rate From: Florian Loitsch - 2005-05-21 00:29:51 ```hi, perhaps I missed it, but what's the clock speed of the Atmel 128 going to be? I'm asking, cause we had big troubles with the uart at some rates (especially, as the Gumstix detects bad bits and sets the whole byte to 0x00. Therefore multiplying the error-rate by 8). If used for uart-speeds bellow 250k 14.7456MHz or 18.4320MHz would be optimal, otherwise the 16MHz is perfect... // florian -- This function will terminate, if run infinitely. void f() { while (random() != 0); } ```

 [Gumstix-users] robostix clock rate From: Florian Loitsch - 2005-05-21 00:29:51 ```hi, perhaps I missed it, but what's the clock speed of the Atmel 128 going to be? I'm asking, cause we had big troubles with the uart at some rates (especially, as the Gumstix detects bad bits and sets the whole byte to 0x00. Therefore multiplying the error-rate by 8). If used for uart-speeds bellow 250k 14.7456MHz or 18.4320MHz would be optimal, otherwise the 16MHz is perfect... // florian -- This function will terminate, if run infinitely. void f() { while (random() != 0); } ```
 [Gumstix-users] \$99 - A first? From: Chris Bradford - 2005-05-21 01:12:44 ```Here's a thought ... with the new starting price at \$99/unit, isn't the gumstix now the first Linux (any os?) SBC to break the \$100 barrier for real? I recall a previous SBC claiming to have broken the \$100 barrier, but upon closer inspection, it was based on a QTY purchase. --csb ```
 Re: [Gumstix-users] robostix clock rate From: Dave Hylands - 2005-05-21 04:55:46 ```Hi Florian, > perhaps I missed it, but what's the clock speed of the Atmel 128 going to= be? > I'm asking, cause we had big troubles with the uart at some rates (especi= ally, > as the Gumstix detects bad bits and sets the whole byte to 0x00. Therefor= e > multiplying the error-rate by 8). > If used for uart-speeds bellow 250k 14.7456MHz or 18.4320MHz would be opt= imal, > otherwise the 16MHz is perfect... The early prototypes had 8MHz crystals, but the intention is to have 16MHz on the production units. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ```
 Re: [Gumstix-users] robostix clock rate From: Florian Loitsch - 2005-05-21 12:29:55 ```On Saturday 21 May 2005 06:55, Dave Hylands wrote: > Hi Florian, > > > perhaps I missed it, but what's the clock speed of the Atmel 128 going to > > be? I'm asking, cause we had big troubles with the uart at some rates > > (especially, as the Gumstix detects bad bits and sets the whole byte to > > 0x00. Therefore multiplying the error-rate by 8). > > If used for uart-speeds bellow 250k 14.7456MHz or 18.4320MHz would be > > optimal, otherwise the 16MHz is perfect... > > The early prototypes had 8MHz crystals, but the intention is to have > 16MHz on the production units. This would mean, that reliable communications with the robostix are only possible at 250k or higher... (ATmega128 specs, page 197, table 85: Examples of Baud Rate Settings.) At 4800, 19.2k, 38.4k and 76.8k one would "only" have 0.2% error-rate, but afaik this is a "per bit" error-rating. When multiplying by 8 the error-rate would be 1.6% bad bytes. Suppose we checksum 10bytes. In this case we would loose 16% of our sent data. (In our specific case we checksummed 13bytes, and lost more than 20%...). As the Robostix is going to communicate with the outside world many connected devices won't be able to communicate at 250k or add checksums, and hence loose some data... I'm not saying, that 16MHz is bad, but you should at least consider for instance 14.7456MHz (which has the inverse problem: 7.8% error from 250k on). // florian -- This function will terminate, if run infinitely. void f() { while (random() != 0); } ```
 Re: [Gumstix-users] robostix clock rate From: Dave Hylands - 2005-05-21 14:13:42 ```Hi Florian, > This would mean, that reliable communications with the robostix are only > possible at 250k or higher... > (ATmega128 specs, page 197, table 85: Examples of Baud Rate Settings.) > At 4800, 19.2k, 38.4k and 76.8k one would "only" have 0.2% error-rate, bu= t > afaik this is a "per bit" error-rating. When multiplying by 8 the error-r= ate > would be 1.6% bad bytes. Suppose we checksum 10bytes. In this case we wou= ld > loose 16% of our sent data. (In our specific case we checksummed 13bytes,= and > lost more than 20%...). I think that your analysis is flawed ;) The error that's specified is the difference in clock frequencies. A 1.6% error in clock frequency won't cause any problems with communication. The real secret here is that async communication is occuring and everything gets resynced every character. The communication can handle upto to 1/2 bit of clock difference over 10 bits, which means that the clocks can differ by as much as 5% and the two devices can still communicate at any given baud rate. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ```
 Re: [Gumstix-users] robostix clock rate From: Florian Loitsch - 2005-05-21 14:31:38 ```On Saturday 21 May 2005 16:13, Dave Hylands wrote: > Hi Florian, > > > This would mean, that reliable communications with the robostix are only > > possible at 250k or higher... > > (ATmega128 specs, page 197, table 85: Examples of Baud Rate Settings.) > > At 4800, 19.2k, 38.4k and 76.8k one would "only" have 0.2% error-rate, > > but afaik this is a "per bit" error-rating. When multiplying by 8 the > > error-rate would be 1.6% bad bytes. Suppose we checksum 10bytes. In this > > case we would loose 16% of our sent data. (In our specific case we > > checksummed 13bytes, and lost more than 20%...). > > I think that your analysis is flawed ;) > > The error that's specified is the difference in clock frequencies. A > 1.6% error in clock frequency won't cause any problems with > communication. The real secret here is that async communication is > occuring and everything gets resynced every character. > > The communication can handle upto to 1/2 bit of clock difference over > 10 bits, which means that the clocks can differ by as much as 5% and > the two devices can still communicate at any given baud rate. Mea Culpa... We nevertheless had *big* troubles with Atmels that used their internal oscillators. (20% bad checksums over 13 sent bytes). Perhaps we should have calibrated the oscillators (there seems to be a document on Atmel's site). With external oscillators everything worked fine. (we only tried the 0.0% error frequencies). As long as the communication will work fine, I'm fine with 16MHz ;) // florian -- This function will terminate, if run infinitely. void f() { while (random() != 0); } ```
 Re: [Gumstix-users] robostix clock rate From: Dave Hylands - 2005-05-21 19:21:34 ```Hi Florian, > Mea Culpa... > We nevertheless had *big* troubles with Atmels that used their internal > oscillators. (20% bad checksums over 13 sent bytes). Perhaps we should ha= ve > calibrated the oscillators (there seems to be a document on Atmel's site)= . > With external oscillators everything worked fine. (we only tried the 0.0% > error frequencies). > As long as the communication will work fine, I'm fine with 16MHz ;) Yeah - the internal oscillators tend to drift, especially as the part heats= up. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ```