Vom PIC zum AVR

Ja.

Vereinfacht gesagt: Alle neueren Modelle, die mindestens 8KB Flash haben. Eine Übersicht gibts hier (zweitletzte Spalte):

Markus

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

"Bernd Maier" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

"Bernd Maier" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

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 !

"Manfred Walker" schrieb:

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

Also, wenn man der Programmiersprache C mächtig ist, dann sollte man auf Basic auf jedenfall verzichten. Vor kurzem bekam ich auch mal eine kleine Statistik geschickt, bezüglich der Geschwindigkeit des Codes, der mit BASCOM-AVR erstellt wurde. Die Ergebnisse waren nicht sehr berauschend.

Ergebnisse des Tests: Bei nem Test des SPI Interface mit BASCOM dauerte das Senden von 64kByte Daten ~6 Sekunden -> was ca. 10kByte/s ausmacht. I2C hat da noch schlechter abgeschnitten: I2C 64 Kbyte lesen: sagenhafte 45 sekunden, was dann etwa 1400 bytes/sekunde

Soviel zu BASCOM!!

mfg Andreas

--

Andreas Auer                     aauer1 (at) sbox.tugraz.at
Student of Telematics            http://home.pages.at/aauer1
Graz University of Technology

Hallo Bernd,

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.

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

"Holger Klabunde" schrieb:

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

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

Hallo Bernd,

ich denke das hängt vom Einsatz des µP ab. Mit dem PIC kannst Du in sehr störanfälliger Umgebung (Geschaltete Stromversorgungen, Wechselrichter, Motorsteuerungen usw.)arbeiten. Die lassen sich, selbst von stärkeren Spannungsrückwirkungen im Störfall, nicht so schnell aus dem Takt bringen. Von AVR'S habe ich da schon einiges gehört, habe aber keine eigenen Erfahrungen damit. Das Ram Banking ist am Anfang zwar nervig, aber man gewöhnt sich dran. Programme für den (kleinen)PIC sind in der Regel kurz und daher auch in Assembler übersichtlich. Wer von der Hardware Seite zum PIC kommt ist da sehr gut aufgehoben! Noch was zu Compilern und deren assemblierte Code's. Alle mir bekannten Compiler (einschließlich TP- Compiler) erstellen den Code für einen 68HC811E2 ohne "INIT". Diese Vorgehensweise sorgt dafür, daß ich meine eigenen Assemblerprogramme, währen sie in TP geschrieben, niemals in den 2KB Speicher bekommen hätte. Diese Compiler jedenfalls gingen mit RAM und Zeit sehr verschwenderisch um.

MfG Manfred Glahe

Holger Klabunde schrieb:

Sonst würde es nicht alle 5 Minuten ein neues Sicherheitsloch in irgendwelcher Internet-Software geben, auch hätte niemand Ada erfinden müssen.

Auch ATmega und ATtiny /sind/ AVRs. Was Du meinst, sind die alten AT90 AVRs (auch die alten ATtinys und die ATmega103/163 gehören übrigens zur alten Garde).

Das scheint aber eher ein ATmega8-Problem (besonders der DIL-Version) zu sein als ein allgemeines ATmega-Problem. ATmega16 oder 128 gab's IMHO allzeit genügend. Liegt vermutlich daran, daß die 8er für die vielen gebotenen Funktionen einen recht attraktiven Preis haben.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc

Ich hab vor einigen Jahren mit AVR und BASCOM angefangen. Nach massiven Performanceproblemen und seltsamsten Fehlern bin ich nach kurzer Zeit auf den CodeVisionAVR C-Compiler umgestiegen und bin bis heute sehr zufrieden damit. Kann ich nur empfehlen und dazu auch gleich noch den JTAG-ICE, entweder von Atmel oder zum Bruchteil des Preises als Nachbau.

Möglich, dass vielleicht die aktuelle BASCOM-Version besser funktioniert und ich hab sogar noch die Lizenz dafür, aber ich hab einfach keine Lust, das nochmal auszuprobieren.

Georg

Joerg Wunsch schrieb im Beitrag ...

Gegen semantische Probleme hilft keine noch so strenge Programmiersprache, und syntaktische Probleme (z.B. der klassische Buffer Overrun) muss man ja nicht programmieren. Letztlich wird aus jeder Programmiersprache Assembler-Maschinencode.

Haette auch niemand, wie der Rest der Welt, abgesehen von den Militaers, weiss. Uebrigend findet nicht jede in Ada programmierte Rakete ihr Ziel, auch dort gibt es Softwareprobleme.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Der war gut. Internet-Software ist unsicher weil in C programmiert, das muss ich mir merken. Kann ich nun extrapolieren dass Micro$oft-Zeugs deshalb so schrottig ist, weil in C++ programmiert?

SCNR, Michael

Michael Hofmann schrieb:

Ja, zumindest zum Teil. (Zum anderen Teil, weil jeder dritte Programmierer bei M$ offenbar nicht mehr weiß, was die ersten beiden vor ihm gemacht haben, und stattdessen für dasselbe Problem das API komplett neu zimmert.) Ist aber nicht der einzige C++-Schrott, CDE beispielsweise fällt gut auch in diese Kategorie.

Soll ja nicht heißen, daß man nicht auch in C vernünftig programmieren könnte, aber C unterstützt halt die Faulheit der Programmierer, hie und da mal Fehlertests wegzulassen oder sich nicht so völlig exakt um die Grenzen der allozierten Arrays zu kümmern...

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc

"Holger Klabunde" schrieb:

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

Grüße, Bernd

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

mit Absturzgarantie

schreiben.

Von Vorsatz hat ja keiner geredet.

Assembler.

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

auch in Basic

Abbruchkriterium nie

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.

wie Win.

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

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

"Holger Klabunde" schrieb:

von C

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

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.

oft ab wie Win.

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