Ich programmiere zurzeit PICs und bin zufällig auf AVR-RISC Controller von ATMEL getrofen. Ich will später auch Robotter programmieren, oder Haussteuerungen reaslisieren. Auf spruth.de steht ja auch, das man sich auf einen einzigen Controllertypen spezialisieren soll, und nicht bei jeden neuen Projekt auf ein anderes "Pferd" setzt. Ich möchte daher wissen, in welchen Programmiersprachen die Controller programmierbar sind, welche Vorteile und Nachteile sie haben und Erfahrungen währen auch nicht so schlecht. Ich wäre dankbar, wenn mir bei diesen "Problem" geholfen wird
:
Gesperrt durch Moderator
http://electricstuff.co.uk/picvsavr.html PS: Ich tippe auf maximal 5 Minuten, bis die erste Schlägerei hier los geht. PSS: Ich bin für AVR, da billiger.
http://www.mikrocontroller.net/articles/Entscheidung_Mikrocontroller Meiner Meinung nach sind AVRs (dank des gcc) einfacher zu handhaben.
nee. Atmel und PICs sind praktisch dasselbe. Und ja, wenn man mal eine Familie hat sollte man bei der bleiben. Dh bleib bei den PIC - die sind schon gut. Moeglicherweise haben die auch eine bessere Auswahl an Compilern. Die IDE (MPLAB) ist besser, denn sie bindet fremede Compiler ein.
Bitte keine Englischen Seiten, ich kann nicht so gut Englisch was meinst du mit gcc?
Der Microchip-Mensch kam mir am Telefon recht arrogant vor ("Wir sind
die Größten und deshalb so gut!").
Bleibe deshalb beim guten alten ATmega.
aha wrote: > Die IDE (MPLAB) ist besser, denn sie bindet fremede Compiler > ein. Häh? das AVR-Studio bindet doch auf fremde Compiler ein, z.B. den GNU-GCC aus dem WINAVR-Paket.
Oh, nicht schon wieder... > PS: Ich tippe auf maximal 5 Minuten, > bis die erste Schlägerei hier los geht. Vertippt: es waren 8 Minuten ;-)
Ich besitze MBLAB schon, aussagen darüber könnt ihr treffen, ich beachte sie aber nicht. Warum auch, ich kenne die Vorteile und Nachteile.
> in welchen Programmiersprachen die Controller programmierbar
sind,
In KEINER.....
Ich kenn fuer beide einen Pascal compiler
Also einen großen Vorteil der ATmel kann ich schon nennen: der Takt wird nicht wie beim PIC/4 geteilt. Das ist beim PIC so eine konstruktive Unart - einerseits hat man eine Pipeline eingebaut, andererseits hebt man deren Hauptvorteil (hoher Durchsatz durch Fließbandverarbeitung) dadurch wieder auf das man wg. Datenkohärenzproblemen die Pipeline eben nicht als Fließband verwendet.
PICs kann man z.b. in Asembler und C Programmiern. Ich suche hauptsächlich Prozessoren, die sich in Assembler, C, Basic, villeicht auch Virtual Basic oder andere Programmiersprachen die leicht erlernbar sind. Ich behersche schon: Assembler (relativ gut: ich programmiere zurzeit PICs in Assembler) C (mache noch viel Fehler) und Basic (kann die Programme noch nicht am Computer ausführen (nur teroretisches Wissen) (zu spät ins Forum gegeben!!!)
Mir ist KEIN Controller bekannt, der in z.B C programmierbar wäre. Es gab mal einen, der verstand Basic. Alle Controller werden mit Binärcode programmiert.
Soso, Du schiebst die Nullen und Einsen also noch von hand darein?
@pointhi: Der AVR-gcc ist auch nicht einfacher zu bedienen als der CC5x, falls Du verstehst, auf was ich anspiele...
@Thomas Pointhuber: Mein Rat, wenn du dich an die Controller gewöhnt hast und mit der Architektur gut klar kommst, dann bleib' dabei. Zumal zur Gewöhnung nicht nur die Controller selbst zählen, sondern auch der Umgang mit der Entwicklungsumgebung. Ein Wechsel der Architektur verlangt nicht nur neue Controller, sondern auch neues Programmiergerät, neue Entwicklungssuite, neue Libraries, neues Einarbeiten. Der Wechsel lohnt nur, wenn dieser wirklich einen signifikanten Vorteil bringen würde, diesen Vorteil sehe ich aber hier nicht, mann bekommt auch mit PICs so ziemlich jedes Problem erschlagen, es sei denn, die Rechenleistung reicht hinten und vorne nicht. Aber in so einem Falle wäre ein Wechsel zum AVR wenig sinnvoll, da gibt es bei ARM-kompatiblen Controllern wesentlich mehr Leistung. Solange das nicht gebraucht wird, kannst du beim PIC bleiben. Gruß Jadeclaw.
Thomas Pointhuber wrote: > PICs kann man z.b. in Asembler und C Programmiern. Ich suche > hauptsächlich Prozessoren, die sich in Assembler, C, Basic, villeicht > auch Virtual Basic oder andere Programmiersprachen die leicht erlernbar > sind. Virtual Basic ????? Was ist denn das? Mein Tipp: Lerne C beherrschen und bleib bei der Dir vertrauten Controller-Familie, solange die Typen Deine Anforderungen erfüllen. Es geht ja nicht nur darum, PIC-Assembler oder AVR-Assembler zu lernen, sondern auch um das Anschaffen und Lernen der Werkzeuge wie Programmer, Debugger etc. Und wenn Du Werkzeuge von Microchip hast, kannst Du sie für ziemlich alle PICs von PIC10 über PIC18 bis dsPIC33 und PIC32 verwenden.
Thomas Pointhuber wrote: > Ich wäre dankbar, wenn mir bei diesen "Problem" geholfen wird Es gibt schon reichlich Threads zu diesem Thema hier, lies sie. Helfen kann Dir keiner bei der Entscheidung, die mußt Du ganz alleine treffen. Wenn Du aber schon fragst, muß es ja Sachen geben, die Dir beim PIC nicht so gut gefallen und die andere MCs wesentlich besser machen. Mir hat am PIC der extrem magere Befehlssatz mit Abstand am schlechtesten gefallen. Andauernd fehlen wichtige Instruktionen und man muß sie sich erst mühsam zusammenbasteln. 8051 und AVR lassen sich da deutlich bequemer in Assembler programmieren. Ich beneide auch die armen PIC-Compilerbauer nicht, die haben schon nen verdammt harten Job. Oftmals sind die PIC-Compiler deswegen auch etwas eingeschränkt. Das mit dem ein Interruptvektor für alle ist auch kein Ruhmesblatt. Da ich sehr gerne mit Interrupts arbeite, will ich nicht immer erst mühsam die Quellen auseinanderpfitzeln müssen, das kostet ja auch wertvolle CPU-Zeit. Der AVR-GCC ist leider auch etwas eingeschränkt, er kann kein double (64Bit-float). Peter
Oft ist es ja auch so, dass man auf vorhandenen Projekten aufbaut und sich in Foren austauschen möchte. Ich würde einfach mal schauen, welche Controller in der Roboter-Community bzw für Haustechnik bevorzugt werden. Ansonsten kommt es halt immer drauf an, was man machen möchte und in welchen Dimensionen. Ich brauche z.B. einen Controller mit extrem niedrigem Stromverbrauch und da sind die PICs halt etwas sparsamer. Dann möchte ich das Projekt eventuell in kleiner bis mittelgroßer Serie fertigen, da spielt es dann schon eine Rolle, ob so ein Teil 0,50 € (PIC12F) oder 1,- € (ATTiny) kostet. PICs kann man außerdem direkt bei Microchip bestellen und es gibt einen Programmierservice (vielleicht gibts das bei Atmel auch, auf der Webseite ist davon aber nichts zu sehen).
Na wenn es extrem stromsparend sein soll dann wäre doch ein MSP430-Derivat das Richtige? Bei der Beurteilung des Stromverbrauchs sollte man immer auch berücksichtigen, das ein PIC mit dem 4-fachen Takt laufen muß um die gleiche Leistung zu haben wie ein AVR!
> Ich brauche z.B. einen Controller mit extrem > niedrigem Stromverbrauch und da sind die PICs halt etwas sparsamer. Extrem niedriger Stromverbrauch, da nehme ich einen MSP430. > ob so ein Teil 0,50 € (PIC12F) oder 1,- € (ATTiny) kostet. Solche Preise gibt es nicht. Das sind eher 0,5135 € oder 1,0187 €. > es gibt einen Programmierservice (vielleicht gibts das bei Atmel auch, > auf der Webseite ist davon aber nichts zu sehen). Das wird von des Distris (bzw. beauftragten Unternehmen) erledigt. Oder Just-In-time im Bestückungsautomaten.
Wenn man halbwegs wie ein richtiger Programmierer arbeiten will lautet die Frage richtige: Was kostet das Entwicklungssystem, einschließlich Debugger? Bei Microchip bekommt man das günstiger wenn man auf Codeoptimierung des C-Compilers verzichtet. http://www.mikrocontroller.net/articles/Entscheidung_Mikrocontroller
nabeshima wrote: > Dann möchte ich das Projekt eventuell in kleiner bis mittelgroßer Serie > fertigen, da spielt es dann schon eine Rolle, ob so ein Teil 0,50 € > (PIC12F) oder 1,- € (ATTiny) kostet. Welchen PIC hast Du denn mit welchem AVR bei welchem Lieferanten verglichen? In der Regel sind die AVRs billiger, z.B. Reichelt: ATTiny13: 0,80€ PIC12F508: 0,95€ Peter
>Und ja, wenn man mal eine Familie hat sollte man bei der bleiben. <SNIP> tausen ähnliche, gute Argumente </SNIP> Und trotzdem: Wenn ich hier die Beiträge von Thomas Pointhuber verfolge, tippe ich auf engagierten Amateur mit (sehr) ausbaufähigen Kenntnissen. Auf welcher Hardware man Programieren lernt, ist egal. Natürlich hat jeder Mikrocontroller seine Eigenheiten, und die Entwicklungsumgebungen verhalten sich auch alle (etwas) anders. Trotzdem gibt es da zwischen PICs und AVRS mehr Gemeinsamkeiten als Unterschiede. Hat man erst einmal einen gemeistert, fällt der Umstieg auf einen anderen nicht mehr so schwer. Über einen etwas längeren Zeitraum gesehen, muß man sowieso umsteigen. Die Hardwarezyklen dauern nicht ewig. Ich habe mal, noch zu Schulzeiten, Assembler auf einem 6809 gelernt. Dem trauere ich heute noch nach, nutzt aber nichts, gibts halt nicht mehr. Natürlich gibt es heute in einem Chip für 1,50 Funktionen, für die vor 20 Jahren noch kühlschrankgroße VME-Bussysteme erforderlich waren. Die alle zu beherrschen und möglichst effizient einzusetzen, erfordert schon die Konzentration auf ein- oder zwei Controllertypen. Solange aber mehr die "Basics" im Vordergrund stehen (Zitat: >Ich will später auch Robotter programmieren, oder >Haussteuerungen reaslisieren. Auf spruth.de steht ja auch, das man sich >auf einen einzigen Controllertypen spezialisieren soll, ) ist völlig egal, ob PIC oder AVR. Meine Meinung Oliver
> Na wenn es extrem stromsparend sein soll dann wäre doch ein > MSP430-Derivat das Richtige? Bei der Beurteilung des Stromverbrauchs > sollte man immer auch berücksichtigen, das ein PIC mit dem 4-fachen Takt > laufen muß um die gleiche Leistung zu haben wie ein AVR! Der MSP430 ist aber wesentlich teuer, oder? Im Sleep verbraucht ein ATTiny mehr als doppelt so viel wie ein PIC, das mit dem 1/4 Takt ist aber in der Tat ärgerlich. Leider steht in den Atmel-Datenblättern nicht, wieviel im Betrieb mit dem internen 128 kHz-Oszillator oder einem Uhrenquartz verbraucht wird. > Solche Preise gibt es nicht. Das sind eher 0,5135 € oder 1,0187 €. Das war natürlich gerundet, es kommt ja eh auf das einzelne Modell, Bauform, Menge usw an. > Welchen PIC hast Du denn mit welchem AVR bei welchem Lieferanten > verglichen? Hab einfach bei Farnell nach dem jeweils günstigstem geschaut. Am besten wäre natürlich, man könnte die Preise direkt beim Hersteller vergleichen, aber die gibt's ja nicht bei Atmel..
nabeshima wrote: > Im Sleep verbraucht ein ATTiny mehr als doppelt so viel wie ein PIC,... Allerdings haben die Sleep-Ströme kleiner Controller eher akademischen Wert, da die Selbstentladeströme entsprechender Batterien in der Regel um einiges größer sind. > Leider steht in den > Atmel-Datenblättern nicht, wieviel im Betrieb mit dem internen 128 > kHz-Oszillator oder einem Uhrenquartz verbraucht wird. Doch, natürlich, unter "Typical Characteristics" gibt es Kurven dafür. 32 kHz muss man extrapolieren, aber 128 kHz sind angegeben. > Hab einfach bei Farnell nach dem jeweils günstigstem geschaut. Am besten > wäre natürlich, man könnte die Preise direkt beim Hersteller > vergleichen, aber die gibt's ja nicht bei Atmel.. Jeder Kunde bekommt wohl letztens bei jedem Hersteller einen ausgehan- delten Preis, der sich an seiner Gesamt-Abnahmemenge orientiert.
> Bensch (Gast) > Datum: 09.03.2009 14:47 > Mir ist KEIN Controller bekannt, der in z.B C programmierbar wäre. Es > gab mal einen, der verstand Basic. Alle Controller werden mit Binärcode > programmiert. Beitrag "AVR-ChipBasic2 - BASIC-Computer mit ATMega 644" :)
@Z8 Aha, der war mir nicht bekannt, offensichtlich ein "Nachfolger" des alten 8051Basic, den ich meinte. Aber ansonsten- Controller, die Hochsprache können- tote Hose... Ein RISC-uC, der C kann, macht auch irgendwie keinen Sinn.
Hi Bensch, der Thread ist sinnlos! :)
Hallo, wenn es um die Vor- bzw. Nachteile von PICs bzw. Atmels geht kommen bei einer solchen "was ist besser Frage" eigentlich immer die selben Antworten. Als erstes ist da immer das Argument, der PIC teilt den Takt durch vier. Das ist erst mal richtig, ABER: die 10F, 12F und 16F PICs benötigen dann auch nur EINEN solchen geteilten Takt pro Befehl (außer die Sprungbefehle, die brauchen meist zwei). Bei den ATmels verbrauchen viele Befehle 2, 3 oder 4 Takte und damit ist der Geschwindigkeitvorteil schon höchstens noch das doppelte und nicht mehr das vierfache. Die 18F und höher haben eine interne PLL. Den Multiplikator der PLL kannst du einfach auf 4 stellen und schon sind die PICs rein äußerlich genauso schnell (oder schneller) wie die ATmels (Du schließt also einen 8 MHz Quarz an und arbeitest intern mit 32 MHz. Dadurch, dass der PIC dann wieder durch 4 teilt bist du also genauso schnell wie ein ATmel mit 8MHz bzw. schneller, wenn man das in erstens mit berücksichtigt). Dann das Vorurteil mit den wenigen Befehlen. Die 18F und höher haben bedeutend mehr Befehle. Sind es bei den 10F, 12F und 16F nur 35 (von denen man aber nur ca. 30 benutzt) sind es bei den 18F schon über 80. Hier ist dann eigentlich auch vieles dabei, was man bei den <18F vermisst. So gibt es zum Bsp. 3 Zeigerregister und nicht nur eins. Oder komfortable Tabellen Befehle. Auch Multiplikation ist integriert. Die 18F+ können mit den ATmels durchaus mithalten. Und die >18F (24F, 32F 33F...) erst recht. Argument Interrupt: Was bitte ist so schlimm daran, das es nur einen Eintrittspunkt bei den <18F gibt? Sicher, man muss in der ISR erst mal eine kleine Abfrage einbauen, um den auslösenden Interrupt zu ermitteln. Aber das sind genau zwei Befehle pro benutztem Interrupt. Bei dem ATmel ist es ein Befehl. Ich sehe darin keinen großen Nachteil. Was kommt noch? Ach ja das Banking und Paging. Das ist wirklich nervig bei den <18F. Ab den 18F PICs wurde das Banking etwas besser gelöst und das Paging ganz abgeschafft. Solltest du in C programmieren, muss dich das aber nicht interessieren, da dass der Compiler erledigt. Der Preis: Als Amateurbastler in meinen Augen eher uninteressant. Mir ist es eigentlich egal ob ich 3,- € oder 5,-€ im Monat bezahlen muss. Denn mehr wie einen µC im Monat verbau ich eh nicht. Und wenn du ähnlich wenig baust, kannst du dir auch mal Samples von Microchip schicken lassen. Dann kostet es nix. Sollte man aber nicht übertreiben... Das sieht natürlich anders aus, wenn man Serien produzieren will. Da spielt der Preis schon eine große Rolle... Nun aber noch das einzige Argument, welches in meinen Augen wirklich für die ATmels spricht: Die Fangemeinde. Es gibt im Internet deutlich mehr deutschsprachige Unterstützung bei den Atmels als bei den PICs. Hier steht man als PIC Anwender doch etwas allein gelassen dar. Nicht das es keine Hilfe gibt. Die ist schon auch da, aber die Auswahl an fertigen Projekten wo man sich etwas abschauen kann ist bei den ATmels deutlich größer. Fazit: Ich habe mit PICs <18F in Assembler angefangen und programmiere die so bis heute. Auch inzwischen recht umfangreiche Projekte mit über 4000 Programmzeilen. Die 18F würde ich gerne auch mal programmieren. Dann aber wohl in C. Bis jetzt hab ich mich aber weder an die 18F ran getraut noch an C. Auf die Atmels hab ich immer mal geillert und mit der Anschaffung eines AVR-NET-IO von Pollin auch ein wenig damit rumgespielt. Einen Grund bei den PICs die Scheidung einzureichen um mich mit ATmels zu verheiraten sehe ich aber nicht. Letztendlich musst du es aber selbst entscheiden. Gruß Sven
Sven Stefan wrote: > Bei den ATmels verbrauchen > viele Befehle 2, 3 oder 4 Takte und damit ist der Geschwindigkeitvorteil > schon höchstens noch das doppelte und nicht mehr das vierfache. Erstens: Es gibt nicht die Atmels. Was du meinst nennt sich AVRs. Zweites: Wenn du schon damit anfängst, dann mach es auch richtig: Was mehr als 1 Takt benötigt, sind 16bit Operationen oder Spungbefehle. 16bit Operationen gibt es bei den von dir genannten PICs nicht. Also kann man das nicht vergleichen. Weiterhin benötigen ansonsten vor allem die Sprung und Branchbefehle mehr als einen Takt. Dies ist bei den PICs aber auch der Fall. Das einzige wo die 18F wirklich schneller sind ist die Multiplikation. Alle anderen Befehle benötigen genau 1 Takt. > Die 18F+ können mit den ATmels durchaus mithalten. Da stimme ich dir zu. Je nachdem wonach man schaut sind mal die einen, mal die anderen minimal besser. Aber letztendlich vergleichbar. > Und die >18F (24F, 32F 33F...) erst recht. Wenn du schon vergleichst, dann vergleiche richtig: Die 33 und 32F haben mit den <18F genausoviel gemeinsam wie AVR und AVR32. Jetzt vergleiche also mal AVR32 und 32F... Davon mal abgesehen: Die 24F/30F/33F (alle mit mehr oder weniger dem selben Befehlssatz) sind echt schöne µC. Je nach Anwendung sind die durchaus mit einem ARM7 vergleichbar von der Rechenleistung und vor allem den IO Zugriffen die alle in 1 Takt erledigt werden. Es wird Zeit dass Reichelt die mal zu akzeptablen Preisen ins Programm aufnimmt. > Der Preis: Als Amateurbastler in meinen Augen eher uninteressant. Mir > ist es eigentlich egal ob ich 3,- € oder 5,-€ im Monat bezahlen muss. > Denn mehr wie einen µC im Monat verbau ich eh nicht. Du vielleicht nicht, ich schon. Und ob ich nun 10€ im Monat für µC ausgebe oder 30€ macht schon einen Unterschied. Microchip kündigt nie Controller ab ohne einen direkt kompatiblen Ersatz zu bieten. Das lassen die sich aber gut bezahlen. Ist auch klar: Kleine Stückzahlen kosten Geld. > Und wenn du ähnlich > wenig baust, kannst du dir auch mal Samples von Microchip schicken > lassen. Dann kostet es nix. Auch hier liegst du falsch: Samples gibts nur noch gegen Bezahlung (7,5$ Versandkostenpauschale). Sorry, eigentlich wollte ich mich nicht in dieses Bashing einmischen, aber wenn jemand Mist schreibt, dann korrigiere ich das gerne.
Hi Sven Stefan, > 3 Zeigerregister und nicht nur eins. HL, IX, IY beim Z80 (1975?) oder Z, Y, X bei den Tinys von von AVR? tolle Sache von µChip! Ich halt micht jetzt aber wirklich raus. "Aber ich liebe euch doch alle" E. Milke :)
Nachtrag: außer den MP430! :(
Benedikt K. wrote: > Davon mal abgesehen: Die 24F/30F/33F (alle mit mehr oder weniger dem > selben Befehlssatz) sind echt schöne µC. Je nach Anwendung sind die > durchaus mit einem ARM7 vergleichbar Leider auch was die eklatante Liste an Bugs angeht. Von dem Dataspace-Mapping des Code-Flash könnte Atmel sich allerdings eine Scheibe für die AVRs abschneiden. Die Architektur hat jedoch gewisse Designaspekte, die Einsatz im stromsensiblen Bereich wohl auch in Zukunft etwas erschwert. Der Core ist dadurch aufwendiger als nötig wäre. Beispielsweise verwirft man Ergebnisse indem man sie ins RAM schreibt und löscht 2 Register per Multiplikation. Oder geradezu zwanghaft eine Laufzeit von einem Takt für Befehle vorzuschreiben auch wenn darin mehrere Speicherzugriffe stecken. DSP lässt grüssen, klar, aber für Normalanwendung ist das übertrieben. > Es wird Zeit > dass Reichelt die mal zu akzeptablen Preisen ins Programm aufnimmt. Kriegt man bei TME. Sind allerdings teils deutlich teurer als die konkurrierenden ARMs (C-M3).
Benedikt K. wrote: > Auch hier liegst du falsch: Samples gibts nur noch gegen Bezahlung (7,5$ > Versandkostenpauschale). Da war es ja gut, dass ich mich voriges Jahr noch eingedeckt hatte ;-) > > Sorry, eigentlich wollte ich mich nicht in dieses Bashing einmischen, > aber wenn jemand Mist schreibt, dann korrigiere ich das gerne. Ich lasse mich gerne korrigieren. Aber es war ja auch nicht nur Mist, den ich geschrieben habe. Mir gehen halt nur die Vorurteile gegen die PICs ein wenig auf den Zeiger. Die meisten plappern das nur nach, was sie irgendwann zu 16F84 Zeiten mal gelesen hatten und denken, dass sich bei Microchip in den letzten 20 Jahren nichts geändert hat. Na egal. Der OP wird seine Entscheidung schon treffen und sicherlich mit seiner getroffenen Wahl auch glücklich werden. Man lernt ja nicht duzende Befehle, 100e Register und 1000e Stolperfallen nur, um das dann alles über Board zu werfen und mit einem anderen µC neu anzufangen der im Großen und Ganzen auch nicht besser oder schlechter ist. Schönen Abend Sven
Der größte Nachteil bei beiden Controller-Familien ist doch, dass man sie erst programmieren muß, damit das herauskommt, was man haben will... ;)
Für mich haben PIC und AVR ihre Daseinsberechtigung! Meine Diplomarbeit entstand mit einem PIC16C72 (Drehzahlregelung, 2 KW Motor, lang her). Später Wechsel auf AVR da besser für C (hier hat PIC aufgeholt). Heute sowohl als auch (und manchmal noch 8051). Alles C und/oder Asembler. Die Mini-PIC (10F2xx im SOT23-6) sind z.B. für kleine Timingaufgaben echt klasse. Daher "Leben und leben lassen"! gruß hans
Im letzten Jahr stand ich auch vor der Wahl: AVR oder PIC. Meine Entscheidung fiel auf PIC. Warum?.. Mit einem PIC kann ich einfach eine dezentrale Intelligenz aufbauen mit dem genialen CAN-Bus. Ich will meine kleinen Platinen selber entwickeln. „AVR-NET-IO von Pollin“ ist für mich … etwas übertrieben. Dazu kaufe ich lieber einen PC bei Ebay oder bei Aldi. Meine Testplatinen laufen schon mit dem CAN-Bus. Verbindung von PC mit allen Busteilnehmer über eine PIC Schaltung mit RS232 und CAN. Zeit Flanken werden in Interrupt generiert (delay ist etwas Primitives). Als nächste kommt Einbindung von einem LCD und Tastatur. Das lässt sich auch mit dem CAN-Bus machen. Jeder Erweiterung (Z.B. dezentrale I/O) dankt dem CAN ist kein Problem. Übrigens meine Entwicklungen mache ich unter C-Compiler – parallel mit dem C18 von Microchip und dem SDCC . So teste ich die Tauglichkeit von dem freien SDCC. Unter SDCC muss man den Pointer auf SFR-Variable so definieren: (__data BYTE*)some_sfr . Dieser Fehler wird auch bald behoben.
> „AVR-NET-IO von Pollin“ ist für mich … etwas übertrieben. Dazu kaufe > ich lieber einen PC bei Ebay oder bei Aldi. Ich finde das immer noch etwas übertrieben und kaufe liebe eine Cray ;-)
Komische Logig. Ein kleines Board für 20,-€ ist übertrieben. Aber ein PC ist ok für einfache Schaltaufgaben. Da verheizt man die 20,- ja schan an Stromkosten die der PC frisst. Sven
A. K. wrote: > Beispielsweise verwirft man > Ergebnisse indem man sie ins RAM schreibt und löscht 2 Register per > Multiplikation. Oder geradezu zwanghaft eine Laufzeit von einem Takt für > Befehle vorzuschreiben auch wenn darin mehrere Speicherzugriffe stecken. > DSP lässt grüssen, klar, aber für Normalanwendung ist das übertrieben. Nur noch interessehalber: Wo hast du denn das her? Also ersteres mein ich. Das mit der Laufzeit von einem Takt ist doch schön :-]
Sven P. wrote: > Nur noch interessehalber: Wo hast du denn das her? Aus Microchips eigenem Compiler. Der macht das so. Er hat ja auch recht. Der Multiplikationsbefehl braucht einen Takt, schreibt 2 Register und wenn man das richtige der beiden mit 0 multipliziert steht hinterher in beiden 0 drin. Und vergleichen tut man bei PIC30, indem man subtrahiert und das Ergebnis nach [SP] schreibt. Der Assembler-Befehl CP ist ein Synonym für SUB. > Das mit der Laufzeit von einem Takt ist doch schön :-] Nicht unbedingt wenn man als Chipdesigner das umsetzen und dabei unbedingt Strom sparen muss.
Ich finde auch - das macht das Taktzählen und somit die Konzipierung extrem zeitkritischer Routinen recht einfach, ebenso das "Ausbalancieren" von Ausführungs-Pfaden. Ich weiß nicht - bei den PIC's hat mich schon die beschränktere Struktur gestört. Zum einen die Taktherunterteilung, welche die PIC's für einige Sachen zu langsam machen (bsp. ASK-Modulation im MHz-Bereich), zum anderen ist der Befehlssatz der AVR's doch angenehmer. Zudem die Sache mit dem Working-Register W - das hört sich eher nach Z80 CISC an statt einem modernen RISC.
A. K. wrote: >> Das mit der Laufzeit von einem Takt ist doch schön :-] > > Nicht unbedingt wenn man als Chipdesigner das umsetzen und dabei > unbedingt Strom sparen muss. Letztendlich sind das doch alles nur positive Features. OK, der Stromverbrauch ist nicht wirklich für Batteriebetrieb geeignet, aber wenn man sich die dsPICs so anschaut, dann zielen die eher in den Bereich Industriesteuerung und ähnliches. Und all diese Features verhelfen dem dsPIC zu enorm mächtigen Befehlen: Effektiv ist dieser also locker mal Faktor 2-10 schneller als ein normaler 16bit µC. Ein Beispiel das ich selbst ausprobiert habe: Ein JPEG Bild von SD Karte laden, dekodieren und an einen Displaycontroller schicken. Obwohl die Software in C geschrieben war, und daher nichtmal die DSP Befehle des dsPICs genutzt werden, war dieser trotzdem mehr als 3x so schnell wie ein mit gleicher Taktfrequenz getakteter R32C (32bit CPU), der sogar noch über einen Hardwarebus verfügt an dem der Displaycontroller angeschlossen ist (der dsPIC macht das per Software). Davon abgesehen lässt sich der dsPIC sehr einfach Programmieren: Die Einarbeitungszeit ist sehr viel kürzer als z.B. bei den ARMs mit den komplizierten Interrupts usw.
Yep, als Bitwackler sind die phänomenal. Ich will die damit übrigens nicht verdammen. Ist die erste Architektur, die MC nicht versemmelt hat. Nur haben sie sich damit beim Weg nach unten etwas behindert. Bei den Interrupts - so schnell und einfach wie sie sind - stört mich allerdings, dass man nur sehr umständlich in generischer Weise im Treiber für ein evtl. mehrfach vorhandenes Funktionsmodul wie UART das ganze sauber mit der Interruptsteuerung koppeln kann. Die Register liegen ja hübsch im Block, aber die Interruptsteuerung leider wenig systematisch quer verteilt in einem Haufen Bitfelder im Interrupt-Controller. Will man den selben Code für alle UARTs verwenden, ist der Zugang zur Interruptsteuerung des jeweiligen Kanals arg umständlich.
> Aber nur grosse 64er. Bei den PICs gibt's auch 28er. Am Anfang waren meine Gedanken bei AVR. Aber das war der entscheidende Faktor für mich. Ich kann meine Platinen selber entwickeln und zusammen löten…
>> Aber nur grosse 64er. Bei den PICs gibt's auch 28er. >Am Anfang waren meine Gedanken bei AVR. Aber das war der entscheidende >Faktor für mich. Ich kann meine Platinen selber entwickeln und zusammen >löten… Stimmt. Das geht mit 64ern natürlich nicht....
@ Matthias Lipinsky (lippy)
>Stimmt. Das geht mit 64ern natürlich nicht....
Klar, für den C64 muss man schon ziemlich viel löten ;-)
skorpionx wrote: >> Aber nur grosse 64er. Bei den PICs gibt's auch 28er. > > Am Anfang waren meine Gedanken bei AVR. Stimmt, CAN scheint Atmel nicht zu mögen. Die haben auch nur das alte ATmega128-Design mit CAN gepimmt und nicht die besseren ATmega2560. Ich hab daher nen ATmega2560 + SJA1000 benutzen müssen. Für kleine CAN-Knoten wird gerne der ATmega8 + MCP2515 genommen. Peter
>Davon abgesehen lässt sich der dsPIC sehr einfach Programmieren: Die >Einarbeitungszeit ist sehr viel kürzer als z.B. bei den ARMs mit den >komplizierten Interrupts usw. Kannst Du das mal näher erläutern? Ich habe gerade das erste Wochenende mit einem Luminary ARM Cortex M3 hinter mir (LM3S1968). Ehrlich gesagt, kann ich mir ein einfacheres Interrupthandling nicht vorstellen. Simple C-Routinen, ein Eintrag in die Vectortabelle, der Interrupt aktiviert, das wars. Auch verschachtelte Interrupts sind nicht aufwendiger. Wie geht das noch einfacher?
Dietmar wrote: > Kannst Du das mal näher erläutern? > Ich habe gerade das erste Wochenende mit einem Luminary ARM Cortex M3 > hinter mir (LM3S1968). Ich habe bisher nur mit den NXP und Atmel ARMs gearbeitet, ist aber schon etwas her, da ich mich mit denen nicht so richtig anfreunden konnte. Bei den NXP gibt es den Vectored Interrupt Controller, da gibt es irgendwie schnelle und langsame Interrupts, Addresse zuordnen, noch irgendwas anderes einstellen usw. Ganz habe ich das nie verstanden. Bei den dsPICs ist es im Prinzip so wie bei den AVRs: Der Interrupthandler hat einen bestimmten Namen, dann plaziert der Compiler den automatisch an der richtigen Stelle. Dann nur noch Interrupt freigeben, fertig. Der Rest ist optional über irgendwelche zusätzlichen Attribute.
@Benedikt K.: Du meinst die ARM7 bzw. die einfachen ARM9 Controller. Die haben in der Tat eine sehr unglückliche und umständliche Interruptstruktur. Mit dem Cortex-M3 hat ARM da aber mächtig aufgeräumt und einen sehr schönen Controllerkern entwickelt. In der Tat ist der von der Interruptbehandlung noch einfacher als beim hier beliebten Atmel AVR und auch beim dsPIC. Einige Register werden schon von der Hardware gerettet, alle anderen lassen sich mit einem einzigen ASM-Befehl sichern. Insofern ist der M3 sicherlich besser durchdacht als ein dsPIC.
Carsten wrote: > Du meinst die ARM7 bzw. die einfachen ARM9 Controller. Ja, genau. Der Cortex-M3 ist relativ neu, wenn ich das richtig sehe. Ich habe jetzt mal das Datenblatt überflogen: Der sieht nicht schlecht aus. Ein weiteres Problem das ich mit den ARMs habe: Es gibt keine fertige GCC Toolchain für Windows, so wie es bei den AVRs ist. Weiterhin muss man oft die Startup Codes und Linkerscripte selbst schreiben. Sowas hält vor allem Anfänger schön ab. Oder hat sich das mittlerweile gebessert?
hat sich gebessert. codesourcery bietet eine gcc toolchein auch für windows. wer damit kostengünstig anfangen will soll sich einen stm32 primer 1 besorgen. kommt mit ride7 und gcc und 32k debug limit (grüße aus der marketingabteilung). primer 1 läuft natürlich auch unter linux, mit openocd und ohne debug limit :-) gcc toolchain kann man die von codesourcery nehmen oder selber gcc kompilieren, funktioniert beides gut. von der hardwareseite ist der primer 1 ok, der primer 2 hat ein paar hardwarebugs.
> Was sind die Vorteile und Nachteile von PICs und ATMEL Controller?
Was für eine Trollfalle...
Der Threadposter hat nicht eine sinnvolle Frage gestellt...Und Schon
gibts 60 Posts in 2 Tagen.
Was ist eigentlich besser: Windows oder Linux?
Für was kann ich in welcher Programmiersprache programmieren?
So, jetzt erwarte ich richtig Posts bis übermorgen!
Benedikt K. wrote: > Ein weiteres Problem das ich mit den ARMs habe: Es gibt keine fertige > GCC Toolchain für Windows, so wie es bei den AVRs ist. Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr?
Karl-heinz Strunk wrote:
> Was für eine Trollfalle...
Überraschenderweise bist du der erste. Der Rest vom Thread ist bisher
eher sachlich. Das dieser Thread dis Diskussion fördert ist ja per se
kein Problem, auch wenn's den Initiator vielleicht nicht mehr
interessiert. Andere schon.
Wie verhält sich das eigentlich mit dem Gedöhns von codesourcery und der Lizenz, unter der das GNU-Zeugs steht? Müssten die da nicht eigentlich die Quelltexte der Tools mitliefern...?
>> Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr?
Doch, doch, bleibt trotzdem das Problem "Linkerscript". Will oder kann
niemand schlüssig erklären.
Jörg Wunsch wrote: > Nanu, funktioniert Martin Thomas' WinARM denn nicht mehr? Die letze Version die ich hatte lief nicht, keine Ahnung was da los war. Irgendwas mit der echo.exe hat nicht gepasst. Am Ende habe ich alles auf meinem alten Rechner compiliert, auf dem noch eine ältere Version installiert war, die ging. OK, das Problem lag letztendlich irgendwie an dem Rechner, (es soll da ein paar Probleme mit einer bestimmten Version der echo.exe gegeben haben), aber das hat letztendlich dazu gereicht (zusammen mit den Problemen mit den Startup Files usw.) mich komplett von den ARMs fernzuhalten. Vor allem da ich eher schnelle IOs und Peripherie brauche als reine Rechenleistung.
>das Problem lag letztendlich irgendwie an dem Rechner Was für ein Rechner ist das? auf meinem XP SP3 32-bit lief es ohne Probs!? zur eigentlichen Frage: Atmel ist besser, das sieht man schon daran dass das fav-icon hier vom Forum ein AVR beinhaltet :p
>Weiterhin muss man oft die Startup Codes und Linkerscripte selbst >schreiben. Beim Cortex M3 beschränkt sich der Startupcode allenfalls aufs Kopieren der initialisierten Daten vom Flash ins RAM (in C!) sowie das Löschen des .bss-Segments. In letzterem Fall sind das genau 7 Assemblerbefehle, die für alle Programme gleich sind. Das sollte keinen abhalten. Z.B. so:
1 | void
|
2 | ResetISR(void) |
3 | {
|
4 | unsigned long *pulSrc, *pulDest; |
5 | |
6 | pulSrc = &_etext; |
7 | for(pulDest = &_data; pulDest < &_edata; ) |
8 | {
|
9 | *pulDest++ = *pulSrc++; |
10 | }
|
11 | |
12 | __asm(" ldr r0, =_bss\n" |
13 | " ldr r1, =_ebss\n" |
14 | " mov r2, #0\n" |
15 | " .thumb_func\n" |
16 | "zero_loop:\n" |
17 | " cmp r0, r1\n" |
18 | " it lt\n" |
19 | " strlt r2, [r0], #4\n" |
20 | " blt zero_loop"); |
21 | |
22 | main(); |
23 | }
|
Auch das "Linkerskript" kann man - insbesondere als Anfänger - klein und überschaubar halten und auch immer wieder verwenden. Hier ein Beispiel für einen Luminary LM3S1968 mit 256KiB Flash und 64KiB Ram:
1 | MEMORY
|
2 | {
|
3 | FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K |
4 | SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 64K |
5 | }
|
6 | |
7 | SECTIONS
|
8 | {
|
9 | .text : |
10 | {
|
11 | KEEP(*(.isr_vector)) |
12 | *(.text*) |
13 | *(.rodata*) |
14 | _etext = .; |
15 | } > FLASH |
16 | |
17 | .data : AT (ADDR(.text) + SIZEOF(.text)) |
18 | {
|
19 | _data = .; |
20 | *(vtable) |
21 | *(.data*) |
22 | _edata = .; |
23 | } > SRAM |
24 | |
25 | .bss : |
26 | {
|
27 | _bss = .; |
28 | *(.bss*) |
29 | *(COMMON) |
30 | _ebss = .; |
31 | } > SRAM |
32 | }
|
Mehr braucht kein Anfänger.
Keine Meinung, nur mein persönlicher Erfahrungsbericht: Ich mache seit 1980 Assembler - zunächst 6502, bald auch in grösserem Stil, dann ab 1986 Motorola 68k, mit Derivaten (93C100, 68332) bis in die späten 90er Jahre. Als man damit kein Geld mehr verdienen konnte, bin ich auf C++ umgestiegen. Vor einem Jahr habe ich wieder mit uControllern angefangen und mir auch die Frage gestellt, PIC, Atmel oder TMS430. Eigentlich gefällt mir der TI am Besten (ich hatte 98 mal einen Kurzausflug zum TMS 370 gemacht, dann aber abgebrochen - heute kennt ihn keiner mehr), die Architektur ist sehr geradlinig, geringer Stromverbrauch, sympathische Mnemonics, irre viel Peripherie und vor allem: Die sprichwörtlich gute TI-Dokumentation. Allerdings möchte ich eine halbwegs vernünftige Auswahl an Chips im DIL-Gehäuse, da ich für Hobbyprojekte kein SMD will. Die Pics habe ich wegen der Banking-Sache und des kruden Befehlssatzes früh ausgeklammert, und letztlich habe ich mich für Atmel entschieden. - gute kostenlose Entwicklungsumgebung für ASM und C - ordentlicher Befehlssatz - viele DIL-Packages - weit verbreitet, daher viel support im Netz zu finden - leicht erhältlich Um keine Zeit zu verlieren, habe ich das STK500 gekauft und in sehr kurzer Zeit meine ersten kleineren Sachen in ASM gemacht. Mit dem C-Compiler bin ich auch sofort gut zurecht gekommen (das war auf dem 68k mit einer richtig teuren "professionellen" Entwicklungsumgebung doch deutlich schwieriger). Ich bin mit dieser Wahl sehr zufrieden und bin froh, nach 10 Jahren Pause wieder embedded Entwicklung zu machen.
Beitrag #5967815 wurde von einem Moderator gelöscht.
Beitrag #5967818 wurde von einem Moderator gelöscht.
Beitrag #5967852 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten