Vom PIC zum AVR

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Moin,

ich wollte mal nen AVR ausprobieren, bin aber PICmäßig vorbelastet...

Was ist denn "anders" und welche Fehler sollte ich nicht machen?

Haben alle AVRs interne Pullups?
"Self-Programming" (für Bootloader) können aber nur einige wenige?

MfG,
Bernd


Re: Vom PIC zum AVR
Quoted text here. Click to load it

Ja.


Vereinfacht gesagt: Alle neueren Modelle, die mindestens 8KB Flash
haben. Eine Übersicht gibts hier (zweitletzte Spalte):
http://www.atmel.com/dyn/products/param_table.asp?family_id60%7&OrderBy=part_no&Direction=ASC

Markus

Re: Vom PIC zum AVR
Hallo!

Etwas, das zu beachten ist, weil ich auch drauf reingefallen bin: ;-)

AVRs haben Fuses, mit denen man Dinge wie den Oszillator einstellt. Man
stellt aber auch andere Dinge ein, z.B. Art der Programmierung, etc.
Man sollte da keinen Fehler machen, denn wenn man z.B. den Oszillator falsch
einstellt und seriell programmiert, wird das nicht mehr funktionieren, weil
man zum Programmieren den Takt braucht und der dann ja nicht mehr da ist,
weil er falsch eingestellt wurde.
Das ganze ist dann auch noch ein wenig knifflig, da bei einer Fuse '0'
programmiert bedeutet, '1' dagegen unprogrammiert.

Vielleicht ist es besser, nicht PonyProg zum Programmieren des AVRs zu
benutzen.

Als Umgebung ist das WinAVR ganz nett - es ist eine Sammlung von
nicht-kostenpflichtigen Programmen inkl. C compiler (avr-gcc).

LG,
Simone

Quoted text here. Click to load it



Re: Vom PIC zum AVR

Quoted text here. Click to load it

Das genialste an den AVRs ist (neben der hohen Geschwingkeit...),
meiner Meinung nach, der BASCOM-AVR Basic-Compiler,
den man kostenlos downloaden und benutzen darf.
Zwar kann die freie Version nur max. 2 K Code erzeugen, der Code
ist aber schnell und effizient - das reicht also für kleine Projekte.
Das Programm hat auch einen eingebauten Simulator, mit dem man
den Code auf Basicebene testen kann.

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !




Re: Vom PIC zum AVR

"Manfred Walker" schrieb:

Quoted text here. Click to load it

Nö, ich bin der Meinung, dass man C benutzen möchte (ausser, man muss
gewisse Ausfall-Sicherheitsstandards erfüllen, dann ist C natürlich
"verboten"). Ansonsten trifft man in kritischen Bereichen tatsächlich oft
Pascal und BASIC an.
Aber wenn ich meinen Code jetzt in BASIC mache, wird die Migration auf
andere µCs unmöglich.

Also falls ich wirklich auf AVRs umsteige, dann nur wegen der Verfügbarkeit
eines freien C-Compilers - da siehts bei den PICs nämlich nicht gut aus.
Ansonsten komme ich mit den PIC18 sehr gut klar.

MfG,
Bernd


Re: Vom PIC zum AVR
Hallo Bernd,

Quoted text here. Click to load it

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !? Code ist besser lesbar und auf
jeden Fall leichter zu pflegen als ASM. ASM einfügen aber auch kein Problem.

Quoted text here. Click to load it

Ich mache sehr viel mit PIC's. Was dabei aber immer nervt ist das Code- und
RAM-Banking. Das gibt es bei AVR's einfach nicht. Bei ATMega32 kann man sich
mit AVR-GCC mal eben so ein zusammenhängendes 1kB RAM Array reservieren.

Deshalb liebe ich die AVR's oder besser
ATMegas. Mit AVR's sollte man nichts mehr machen. Wird einer nach dem anderen
abgekündigt. Nimm gleich einen ATMega oder ATiny.

Leider sind die Atmel Viecher manchmal nicht so leicht zu bekommen. Auf die
letzten ATMega8 habe ich 3 Monate warten müssen. Bei PIC's ist mir sowas noch
nicht passiert. Die Verfügbarkeit scheint besser zu sein.

Ansonsten bin ich vom ehemals PIC-User schon fast komplett auf Atmel umgestiegen.
Es macht einfach mehr Spaß sich um RAM-Banking nicht mehr kümmern zu müssen.
Auch wenn behauptet wird das es das bei PIC18 nicht mehr gibt habe ich bis heute
noch nicht
herausgefunden wie man den C18 Compiler von Mchip dazu überredet ohne
RAM-Banking zu
arbeiten bzw. 512Byte RAM am Stück für ein zusammenhängendes Byte Array zu
bekommen.

PIC benutze ich nur noch in Sonderfällen weil z.B. bei PWM feinere Abstufungen
drin sind,
oder wenn es ein Chip in DIP18 oder kleiner sein soll.

Gruß
 Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: Vom PIC zum AVR

"Holger Klabunde" schrieb:

Quoted text here. Click to load it
Problem.

Ich schrieb auch nicht "schlechter" als ASM, sondern "schlechter" als z.B.
Pascal. C-Code ist z.T. kryptisch und schlecht lesbar, und Pointer sind
immer kritisch, z.B. weil der Progger zwei Wochen später selber nicht mehr
durchsteigt und herrenlose Pointer die übelsten Fehler verursachen. (Dafür
gibt es haufenweise empirische Belege.) Man kann im Fehlerfall keinen
definierten Zustand erreichen, wenn ein Pointer quer durch den Speicher
ballert.

(Trotzdem benutzte ich gerne C ;)

Irgendwelche us-amerikanischen Richtlinien für Rüstungsaufträge verbieten
sogar explizit den Einsatz von C. Google weiß sicher mehr.

Für die Software von Verkehrsleitsystemen wird übrigens sehr oft
Pascal/Turbo-Vision von Borland eingesetzt.

Grüße,
Bernd


Re: Vom PIC zum AVR
Quoted text here. Click to load it

das ist aber kein Fehler von C sondern der Fehler der Programmierer.
C ist nicht kryptisch wenn man sich nicht am Wettbewerb "wie schreibe ich
ein komplettes Programm in nur einer einzigen Zeile" beteiligt.
C Codes sind genauso gut lesbar wie Pascal wenn man nicht mehrere Operationen
in einem unübersichtlichen Konstrukt programmiert. Man muß sich nur einen
guten Programmierstil zulegen. Dann kann auch ein Pascal Programmierer meinen
C-Code
ohne Probleme lesen so wie ich den Pascal Code von ihm lesen kann.

Wenn ein Programmierer nach zwei Wochen nicht mehr weiß was er da
programmiert hat liegt das nur daran das er, wie es eigentlich sein sollte,
das Programm nicht mit den nötigen Kommentaren versehen hat.

Pointer geraten nur außer Kontrolle wenn der Programmierer zu faul/blöde war
die Grenzen selbst festzulegen. Bei ASM dürfte das Problem aber noch schlimmer
sein !

Und auch bei Basic/Pascal muß man sich darauf verlassen das der
Interpreter/Compiler wirklich alles
richtig macht. Ich habe schon oft erlebt das nicht mein Programm falsch war
sondern das was der
Compiler daraus gemacht hat ;) Damit muss jeder leben der eine Hochsprache
benutzt.

 Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: Vom PIC zum AVR

"Holger Klabunde" schrieb:


Quoted text here. Click to load it

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften von C
provozieren diese Probleme.

Grüße,
Bernd


Re: Vom PIC zum AVR
Quoted text here. Click to load it

das ist der größte Schwachsinn den ich je gehört habe. Ich kann ein Programm mit
Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran und was es da sonst noch gibt
schreiben.
Das liegt nicht an der Hochsprache sondern am Programmierer. Wenn es
eine Sprache gibt die unübersichtlich ist und zu Fehlern neigt dann ist das
Assembler.
Und ALLE Hochsprachen erzeugen im Endeffekt Assembler. Du kannst dein Programm
auch in Basic
oder Pascal zum hängen bringen wenn du Schleifen programmierst deren
Abbruchkriterium nie
erreicht wird. Liegt der Fehler dann bei deinem Compiler ? Nein, DUUUU hast den
Mist programmiert.

Linux z.B. ist zum größten Teil in C geschrieben. Stürzt lange nicht so oft ab
wie Win.
Und es soll ja Leute geben die behaupten Linux wäre ein stabiles System ;)

Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

Re: Vom PIC zum AVR

Quoted text here. Click to load it
mit Absturzgarantie
Quoted text here. Click to load it
schreiben.

Von Vorsatz hat ja keiner geredet.

Quoted text here. Click to load it
Assembler.

Daß Assembler noch schlimmer sei hat ja auch keiner bestritten.

Quoted text here. Click to load it
auch in Basic
Quoted text here. Click to load it
Abbruchkriterium nie
Quoted text here. Click to load it
den Mist programmiert.

Wenn Du in C Strings mit strcpy+strcat bearbeitest und dabei den
Längencheck vergißt, dann hast Du u.U. ein Sicherheitsloch. In
Pascal oder Java nicht.

Man kommt in Pascal ohne Pointer auch deutlich weiter als in C.
Als ich mit C angefangen habe sind meine Programme jedenfalls
deutlich häufiger abgestürzt als beim Pascal-Einstieg.


Quoted text here. Click to load it
wie Win.
Quoted text here. Click to load it

Natürlich *kann* man in C auch stabile Software schreiben. Die
Behauptung hier ist ja nur, daß dies schwieriger als in anderen
Sprachen sei. Auch im professionellen Umfeld wird Software nicht
nur von Leuten mit 10 Jahren Erfahrung geschrieben. Die
Wahrscheinlichkeit daß ein C-Anfänger fehlerhaften Code schreibt
ist IMHO größer ist z.B. bei den Pascal- oder Basic-Anfängern.

Markus


Re: Vom PIC zum AVR

Quoted text here. Click to load it
Assembler.

Einspruch, euer Ehren!

Bei überschaubaren Aufgaben im Embedded-Bereich ist Assembler IMO
immer noch das Mittel der Wahl, weil man nur damit wirklich die
100%ige Kontrolle über die Hardware und die korrekte Funktion der
Software hat.

*JEDE* Hochsprache bringt dagegen Unwägbarkeiten mit sich, weil man
sich zusätzlich von Laufzeitbibliotheken und eventuellen Compiler-
fehlern abhängig macht. Gerade Compiler für kleine Embedded-Systeme
sind da vergleichsweise anfällig, weil sich durch das kleine RAM und
nicht hochsprachenoptimierte Befehlssätze vieles nicht so umsetzen
lässt, wie sich die Väter der Sprache das gedacht hatten.

Hergen

Re: Vom PIC zum AVR



Quoted text here. Click to load it
von C

Also ich will mich jetzt nicht streiten. (gehört??? ;))
Vielleicht magst du ja mal ein Buch über Software Engineering lesen...


Quoted text here. Click to load it
schreiben.

Es ist schwer mit Pascal, Basic oder Fortran einen harten Crah zu
povozieren, in Java so gut wie unmöglich. Mit C passiert sowas regelmäßig
aus Versehen.


Quoted text here. Click to load it
oft ab wie Win.
Quoted text here. Click to load it

Wie gesagt, ich mag C, und auch Linux - aber wenn man sich mal die
Sicherheitsmeldungen (z.B. bei Debian.org anschaut), dann merkt man recht
schnell, dass die Sicherheit bei Linux z.T. eine Urban Legend ist. Und die
neuen Windows nehmen sich im Vergleich zu Linux nicht viel in der
Stabilität.
Ich habe gestern in einen Linux Server wieder (nach einem Monat seit dem
lezten Update!) 75MB Security Patches eingespielt, bei einer Distribution,
die seit 2 Jahren als 'Stable' eingestuft wird und kaum verändert wird. Und
dabei ist die ganze Installation gerade mal um 400MB groß.

Zum professionellen Umgang mit mit einer Technologie - sei es nun C, Linux
oder sonstwas - gehört eben auch, dass man ihre Schwächen kennt und
berücksichtigt.

MfG,
Bernd


Re: Vom PIC zum AVR

Quoted text here. Click to load it
Ich liebe diese Buecher.

Schon frueher kam mir der Inhalt immer etwas unpraktikabel vor.
Und vor allem so gaenzlich aus dem Nichts gesaugt.

War ja auch kein Wunder, da die Autoren meistens noch gar kein
grosses, kommerziell erfolgreiches Produkt geschrieben hatten,
sondern nach ihrem ersten gescheiterten Kleinprojekt gleich der
Meinung waren, ihre Unkenntnis in ein Buch schreiben zu muessen.

Die haben ihre Theorie nur aus Univorlesungen gesaugt. Die von
Theoretikern gehalten wurden, die ihrerseits noch nie ein echtes
Programm geschrieben hatten.

Wie erhellend war es, als man im Internet endlich mal die originalen
Sourcen von wirklichen zu ihrer Zeit kommerziell herausragend
erfolgreichen Programmen, wie CP/M, GEM oder **** finden konnte.

Strafen diese source codes doch all den Software Engineering Buechern
Luegen. Und zeigt das doch, das man nicht alles glauben sollte, was
irgendwelche Deppen zu Papier bringen.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff /
We've slightly trimmed the long signature. Click to see the full one.
Re: Vom PIC zum AVR



Quoted text here. Click to load it

Ja, genau. Und weil es mehr Arbeit macht und mehr kostet verzichten viele
darauf und gehen zum "Cowboy Coding" über. Und wenn sie damit die Klappe
fallen, müssen sie weinen.

Quoted text here. Click to load it

Wer solche Bücher kauft ist doch selbst Schuld.

Quoted text here. Click to load it

Einige erfolgreiche Projekte, die ohne SE-Techniken ausgekommen sind,
widerlegen doch nicht alle SE-Konzepte. Übrigens stammen die meisten dieser
Konzepte durchaus aus der Praxis. Das sind z.T. so triviale Dinge wie
Cross-Inspection, die die Qualität aber ungemein steigern. Sowas wird z.B.
am Linux-Kernel mit Erfolg praktiziert.

MfG,
Bernd


Re: Vom PIC zum AVR
Quoted text here. Click to load it
Zeig mir mal deine grossen, kommerziell erfolgreichen Programme, oder schwaetzt
du bloss ?
homepage: http://www.geocities.com/mwinterhoff /

Quoted text here. Click to load it

Es soll sogar Programme geben, die TROTZ Verwendung von SE-Methoden lauffaehig
waren.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de /
We've slightly trimmed the long signature. Click to see the full one.
Re: Vom PIC zum AVR


Quoted text here. Click to load it

Nur gegen NDA ;)

Aber schau dir doch mal z.B. die Produkte von SAP an. Glaubst du wirklich,
dass man dort auf Dinge wie Code Reviews, Prototyping, Anforderungsanalysen
oder konzeptionelle UML-Entwürfe verzichten kann? (und jetzt komm mir biite
nicht mit SAP ist aber sch**sse...)
Oder schau dir eine Bank an: glaubst du, dass die irgendwelche Programme
ohne genaue Analyse auf die Produktivdaten loslassen? (jaja, die Banken sind
auch alle... ;)


Quoted text here. Click to load it
lauffaehig waren.

Vielleicht reden wir nur aneinander vorbei, aber SE ist nicht besonders
esoterisch oder ideologisch geprägt...
Das sind zum größten Teil Basistechnologien:
Selbst wenn du dir ein doofes Flussdiagramm oder einen Ablaufplan aufmalst
betreibst du schon SE.

MfG,
Bernd


Re: Vom PIC zum AVR
Quoted text here. Click to load it
Kein Problem, schick her.

Quoted text here. Click to load it

Danke, die kenne ich. Inside-out. Die finde sogar ich uebel. Ohne das ich nun
auf Befolgung von SE-Techniken besonderen Wert legen wuerde.

Quoted text here. Click to load it

Doch, schon, das ist ja das Problem.

Quoted text here. Click to load it

Kindergartenhorizont.

Wie gross meinst du ist das Flussdiagramm eines ordentlichen kommerziellen
Programms ? So gross wie ein Fussballfeld ? Welchen Ueberblick gewinne ich,
wenn mir jemand ein vollgekritzeltes Fussballfeld ausrollt ?
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff /
We've slightly trimmed the long signature. Click to see the full one.
Re: Vom PIC zum AVR
MaWin schrieb:

Quoted text here. Click to load it

Du bist also der Meinung man sollte eine großes System (z.B. eine
Trägerrakte) ohne jegliche Pläne entwickeln? Einfach den Mechaniker an
die Fräßmaschine stellen und sagen: "Fräß mal eine Triebwerksglocke"
Bekommt er vielleicht auch hin. Aber wird diese Glocke auch noch bei den
üblichen Verbrennungstemperaturen stabil sein?

Man braucht Pläne um große Systeme zu erstellen. Niemand sagt das man
beim System-Entwurf einer Trägerrakete die Farbe der Tankisolierung
definieren muß. Es sollte aber im Hinblick auf die Anwendung geplant
werden ob es sich um ein ein- oder mehrstufiges Konzept mit Flüßig- oder
Feststoffantrieb wird.

SE ist nichts anderes als Pläne zu erstellen wie man ein Produkt
anschließend fertigt. In der Mechanik macht man das seit Jahrhunderten.
Und in der Software soll dieses Vorgehen sinnlos sein?

--
Matthias Weißer
snipped-for-privacy@matwei.de
We've slightly trimmed the long signature. Click to see the full one.
Re: Vom PIC zum AVR

Quoted text here. Click to load it

Die weitaus meisten Softwareprojekte haben nur einen winzigen
Bruchteil des Etats und der Entwicklungszeit im Vergleich zu einem
Raumfahrtprojekt. Du vergleichst Äpfel mit Birnen.

Btw.: Bei den Mondlande-Programmen der Amis und Russen ist so manches
wild zusammengeschustert worden, nach Plänen, die höchstens in den
Köpfen von einer Handvoll Genies existierten. Deshalb kann man diese
Trägersysteme heute auch nicht mehr nachbauen, selbst wenn man wollte.

Quoted text here. Click to load it

Nicht zwingend.

Gerade bei *wirklich* umfangreichen Systemen, die man nicht mehr als
Ganzes überschauen kann und bei denen die Projektleitung gar nicht
weiß, ob sie überhaupt in die richtige Richtung denkt, sind konkrete
Pläne sogar eher schädlich. Denn sie schränken die Kreaktivität der
Spezialisten massiv ein, und verhindern damit zweckmäßige Lösungen.

Wenn die Raketenentwicklung mit dem Ziel begonnen hätte, das
Sonnensystem zu erforschen, hätte vermutlich nie ein Mensch diesen
Planeten verlassen.

Wenn die Elektronik mit dem Ziel begonnen hätte, eine Maschine zu
konstruieren, die sich gleichermaßen als Schreibmaschine, als Archiv,
als Analysewerkzeug, als Kommunikationsmittel, und zur Unterhaltung
eignet und auf einen Schreibtisch paßt, hätten wir wohl heute keine
Computer.

Einfach weil beides aus damaliger Sicht nicht greifbar und damit nicht
planbar war.

bottom-up (also das Entwickeln und Kombinieren von Bausteinen mit
einem nicht oder nur vage formulierten Endziel) ist eine durchaus
anerkannte Entwicklungsphilosophie, die zwar nicht immer exakt zu dem
Ergebnis führt, was man anfangs im Sinn hatte, aber doch meist zu
etwas, das irgendwie nützlich und verkäuflich ist. Oft sogar weit
mehr, als die anfängliche Idee.

Quoted text here. Click to load it

In dem Umfang, wie es in der Mechanik üblich ist, wäre SE weder
bezahlbar, noch in vertretbarem zeitlichem Rahmen machbar, noch
sinnvoll.

Anders als bei mechanischen Produkten ist es bei Software nicht
erforderlich, der Fertigungsweg jederzeit mit identischem Ergebnis
nachvollziehen zu können.

Und ebenfalls anders als bei mechanischen Produkten steht bei Software
meist nicht ein klar umrissenes Ziel am Beginn der Planungen, sondern
ein Problem, dessen Lösung oft noch gar nicht bekannt ist.

Hergen

Site Timeline