Thread: [Amforth] Thanks

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Thanks all, information was very helpful.

Cheers,

Jan

It looks like I've got amforth working (photographic evidence: 
http://tinyurl.com/2d7cddx) -- thanks for your help!

To avoid future problems, I do have a couple related quick questions. The FAQ 
notes the default 1MHz clock (8 MHz internal RC clock divided by 8) can be 
unreliable and suggests: "Try to maximize the CPU frequency." What are the 
symptoms of this problem? Just not being able to get the serial communication 
to work? Does it help to use the internal clock but not divide by 8 (giving an 
8MHz clock), or is inaccuracy with the internal clock part of the problem?

Thanks.
-Leon

Excellent, well done.

I am just doing a first trial build of my design for a single sided 644
board. Got the wrong 40 pin dil package width. I guess this is why we do
trial builds.

I am using 16Mhz crystal though.

Something that the arduino folk found ages ago was that certain clock
frequencys don't divide down correctly with the provided options to give
baud rates that are close enough to the established usuals in terms of
error factor.

I did'nt follow the discussion in their forums that closely but
reference to the issues may still be there.

Funnily enough 16Mhz the frequency that the arduino's use was found to
be a good match.

I have had acceptable results with 20Mhz xtals as well.

Cheers

Andy Kirby

On 08/07/10 05:33, Leon Nathaniel Maurer wrote:
> It looks like I've got amforth working (photographic evidence: 
> http://tinyurl.com/2d7cddx) -- thanks for your help!
> 
> To avoid future problems, I do have a couple related quick questions. The FAQ 
> notes the default 1MHz clock (8 MHz internal RC clock divided by 8) can be 
> unreliable and suggests: "Try to maximize the CPU frequency." What are the 
> symptoms of this problem? Just not being able to get the serial communication 
> to work? Does it help to use the internal clock but not divide by 8 (giving an 
> 8MHz clock), or is inaccuracy with the internal clock part of the problem?
> 
> Thanks.
> -Leon
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Hi.
..
> Funnily enough 16Mhz the frequency that the arduino's use was found to
> be a good match.
>
> I have had acceptable results with 20Mhz xtals as well.

I'm running boards with atmega168 using 8, 16 and 20 Mhz with no  
problems.
Michael 

Leon,

> To avoid future problems, I do have a couple related quick questions. The FAQ 
> notes the default 1MHz clock (8 MHz internal RC clock divided by 8) can be 
> unreliable and suggests: "Try to maximize the CPU frequency." What are the 
> symptoms of this problem?

You get no terminal prompt or (too much) garbage there.

> Just not being able to get the serial communication 
> to work? Does it help to use the internal clock but not divide by 8 (giving an 
> 8MHz clock), or is inaccuracy with the internal clock part of the problem?

Using the full 8MHz may solve some or most of the problems, the better
solution is a so called baud rate quartz (e.g. 14,... MHz)

Matthias

PS: What terminal app do use use on you Mac? looks funny

Hi Leon,
the accuracy of an internal RC oscillator according to atmel is +/- 3%.
You may calibrate it (see atmega docs) to get better. There is also
a dependency on voltage and temperature, what can be another few percent
with RC. The recomended precision for 8N1 communication is +/- 4.5%
for a given baudrate. So you may get problems. It does not matter whether
you use 1,4,or 8MHz internal RC oscillator.
As a rule of thumb the RC oscilator stability is 10^-2, cheapo Xtals
10^-5, good Xtals 10^-6, thermostated (ovenised) 10^-7, rubidum source
10^-10, cesium 10^-13. Short time stability 10x better (e.g. for 10sec).
However, there is "aging" factor as well. With cheapo Xtals 100ppm per
annum. So you have the choice...
Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Leon Nathaniel Maurer" <leo...@gm...>
Komu: amf...@li...
Předmět: [Amforth-devel] Thanks
Datum: 8.7.2010 - 6:33:35

> It looks like I've got amforth working (photographic
> evidence:
> http://tinyurl.com/2d7cddx) -- thanks for your help!
> 
> To avoid future problems, I do have a couple related
> quick questions. The FAQ
> notes the default 1MHz clock (8 MHz internal RC clock
> divided by 8) can be
> unreliable and suggests: "Try to maximize the CPU frequency."
> What are the
> symptoms of this problem? Just not being able to get
> the serial communication
> to work? Does it help to use the internal clock but
> not divide by 8 (giving an
> 8MHz clock), or is inaccuracy with the internal clock
> part of the problem?
> 
> Thanks.
> -Leon
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Thread: [Amforth] Thanks

amforth is an extendible interpreter on microcontrollers

amforth-devel