Atmega8

1) der mega8L kann nur mit 8 MHz betrieben werden (nur 3,3Volt)
2) Es spart Strom (sinnvoll bei Batteriebetrieb)

Gruß
Volker

Warum schneller machen als notwendig? Wenn du nicht gerade zeitkritische
Programme am laufen hast ist der Kontroller doch die meiste Zeit am
warten. Das kann er langsam auch, das spart Strom und erhöht die
Lebensdauer.

Der Motor meines Autos darf bis 6500 Umdreungen pro Minute hoch gedreht
werden. Wieso sollte ich dann schon bei 3500 schalten?

da spart man doch nur sprit ;)

Vielleicht kannst du dir sogar die externe Beschaltung ganz schenken und
schaltest einfach den interenen RC Oszillator ein.
Da sparst du noch mehr.
Falls du allerdings das UART nutzen willst, las lieber die Hände
davon.

Gruß

Hallo,

"schaltest einfach den interenen RC Oszillator ein"
--> das ist der Vorteil. Keine externen Oszillatorelemente

"Falls du allerdings das UART nutzen willst, las lieber die Hände
davon."
Ich benutze den internen Oszillator und den USART -> hatte nie Probleme
damit.

Gruß

Wolfgang
--
www.ibweinmann.de
Brushless Development Kit

>hatte nie Probleme damit.

Bei 110Baud wird es da auch noch keine grösseren geben.
Aber lass das Ding mal mit 115kBaud laufen und halte einen Föhn dran...

@Rahul:
Wenn man eine hohe und eine wesentlich niedrigere Baudrate mit gleicher
'Basisabweichung' einstellen kann und es funktioniert mit der hohen
Baudrate nicht, dann wird es i.d.R. auch mit der niedrigeren nicht
laufen, da der Fehler, der durch den Temperaturgang des Oszillators
entsteht, relativ ist und nicht absolut! Wenn man im Baudratengenerator
einen anderen Teilerfaktor einstellt, teilt man auch den Fehler mit...

"Jetzt sage nicht "bei mir klappt es aber"."
Warum soll er das nicht sagen wenn es für seinen Fall stimmt? Ich denke
mal die meisten hier im Forum entwickeln wahrscheinlich nur für sich
selbst - nicht kommerziell. Da interessiert es nicht ob in Mexico oder
auf dem Mond eine andere Temperatur herrscht wenn man dafür nicht
entwickeln. Natürlich gibt es bestimmt auch Bauteistreuung aber
vielleicht hat es bisher immer geklappt...

Sollte man kommerziell entwickeln muß man das natürlich alles mit
berücksichtigen (den Mond vielleicht nicht^^).

@Johnny: Stimmt. Sonntag Morgen...

@Wolfgang
"Ich benutze den internen Oszillator und den USART -> hatte nie
Probleme damit."

Super!!

@Simon

Hallo, nur nicht verkrampfen ... das ist ungesund ..

"Bei 110Baud wird es da auch noch keine grösseren geben.
Aber lass das Ding mal mit 115kBaud laufen und halte einen Föhn
dran..."

Genau das mache ich: 115 kB. Und die Temperaturen sind auch nicht
konstant. Und ich habe schon einige Sysdteme damit betrieben.

Gruß

Wolfgang
--
www.ibweinmann.de

OT
@Wolfgang:
da scheinbar neulich den thread nicht weiterverfolgt hast, indem du
gesagt hast, du wuerdest aufhoeren deine signatur zu posten, wenn
jemand dir zeigt, wo steht, dass urls etc unerwuenscht sind, hier
nochmal ein versuch, genau dies zu tun.

@Wolfgang:
> ...die Temperaturen sind auch nicht konstant...

'nicht konstant' ist ziemlich unpräzise (und das von einem
Ingenieur...)! In welchem Rahmen bewegen sie sich denn? Bei +-1°C ist
es wahrscheinlich, dass es noch funktioniert, bei +-30°C eher nicht!
Wenn man sich die Temperatur-Frequenz-Kennlinien im Datenblatt
anschaut, dann sieht man recht schnell, dass unter gewissen Bedingungen
das ganze ohne temperaturabhängige Nachkalibrierung nicht mehr
funktionieren kann. Die Fehler liegen bereits bei Schwankungen um 10°C
in einem Bereich, der sicher nicht mehr vernachlässigbar ist!

Da stellt sich die Frage, ob es weniger aufwändig ist, einen
Temperatursensor zu benutzen (den man softwaremäßig auswerten muss), um
den Oszi während des Betriebes nachzukalibrieren, oder lieber doch
gleich einen externen Quarz, der keine weitere Arbeit macht.

>Und ich habe schon einige Sysdteme damit betrieben.
solang es nur fuer dich privat ist, und bei unerklaerlichen aufaellen
keine fehlfunktionen auftreten, werd gluecklich. aber erzaehl bitte
nicht, dass es ohne probleme und uneingeschraenkt empfehlenswert ist.

der naechste newbie, der das liest, wird sich naemlich drauf verlassen,
dass es immer so ist und man sich den quarz schenken kann. das ist aber
definitiv nicht der fall.

und wenn du mal was verkaufen willst mit dieser
"ich-spare-40cent-pfusch-loesung", dann solltest du dich nicht ueber
ruecklaeufer wundern.

Zitat von Wolfgangs Homepage:

> Die Feuerleitrechner-Anbindung beim Kampfhubschrauber Tiger an zwei
> Mil-Bus-Systeme wurde von mir durchgeführt...

Auweia, ich hoffe, er hat da nicht auch AVRs mit internem Oszillator
drin. Sonst gibts die Tage ein paar interessante Presseberichte über
Zwischenfälle mit besagtem Kampfhubschrauber...;-)

> Sonst gibts die Tage ein paar interessante Presseberichte über
> Zwischenfälle mit besagtem Kampfhubschrauber...;-)
ich will doch hoffen, dass die befehle checksummen enthalten...
insofern werden wohl eher leben verschont, als "aus versehen"
getoetet.

Haben 68020 nicht grundsätzlich externe Taktquellen?

Deshalb habe ich ja auch geschrieben: ich hoffe, er hat da nicht auch
AVRs mit internem Oszillator drin.

Dass das Ding an sich wahrscheinlich nicht mit AVRs läuft, sondern
auf einem etwas leistungsfähigeren System, sollte klar sein...

@xXx:
Naja, wenn ich angegriffen werde, feuern will, und mein Feuersystem
"verschont" eigenmächtig das Leben der Angreifer, dann finde ich das
auch nicht so lustig...

wenn man in einem kampfhubschrauber sitzt, sollte man sich nicht damit
rausreden, sich verteidigen zu wollen. das ist eine angriffswaffe. aber
gut, wie war das threadtopic? soll ja keine diskussion werden, ob krieg
ok ist, oder nicht. wollte halt nur zum ausdruck bringen, dass ich es
nicht gut finde, sachen fuers militaer zu entwickeln.

@xXx:
Gebe Dir in allen Punkten recht, auch im letztgenannten! Ich
meinerseits wollte eigentlich ursprünglich darauf hinweisen, dass es
manchmal sinnvoll sein kann, keinen Verweis auf die Homepage des
eigenen Ingenieurbüros anzubringen. Sollte vielleicht Werbung sein, ist
aber glaub ich (zumindest in diesem Fall) nach hinten losgegangen...

OT
eins muss ich zuruecknehmen. wolfgang hat den thread weiterverfolgt:
http://www.mikrocontroller.net/forum/read-1-385115.html

da ich es nicht getan hab, hier mein nachtrag dazu:
du willst doch nicht behaupten, dass du den sinn dieser zeile nicht
verstehst bzw. dass es so zweideutig ist? signaturen/urls nur in
anhaengen unerwuenscht? da es scheinbar so missverstaendlich ist, hier
mein interpretationsversuch:
1) sourcecode sollte angehaengt werden
2) signaturen/urls, die man stur an jeden seiner beitraege anhaengt,
und die nichts mit dem topic des threads zu tun haben, sind
unerwuenscht.

das heisst nicht, dass man nicht auch mal 5 zeilen code "inline" in
den beitrag packen darf, und auch nicht, dass urls generell verboten
waeren. das heisst vielmehr, dass man sich so verhalten soll, dass fuer
andere teilnehmer der lesefluss innerhalb eines threads nicht gestoert
wird. hat was mit gegenseitiger ruecksichtnahme zu tun. und das
schaffen komischerweise 99% aller ernsthaften diskussionsteilnehmer.
ich hab auch nichts gegen dich persoenlich, bist bestimmt nen netter
kerl, aber es faellt mir halt negativ auf.

ich finde es hier im forum naemlich sehr angenehm, dass sich alles auf
das wesentliche beschraenkt, und man nicht von avataren, signaturen und
grafischem gedoens von den beitraegen abgelenkt wird. und ich koennte
wetten, dass auch andere puristen genau das schaetzen.

man korregiere mich, wenn ich total daneben liege.