Hallo, ich bin Mitglied beim Robocup-Team an der TU Graz, da bauen wir Roboter (middle-size-league) die Fußballspielen. Dort wollen wir jetzt einen komplett neuen Roboter bauen (die nächste Evolutionsstufe), da fallen natürlich ein paar Platinen an die neu gezeichnet werden müssen: Motorplatine, Akkuplatine, SmartBattery-System, Kickerplatine, ... Zur Zeit verwenden wir 2 µC-Architekturen: C166v2 und AVR, in Zukunft wollen wir natürlich nur eine verwenden. Leider weiß ich nicht so recht, auf welche Architektur ich setzen soll. Entweder bei AVR bleiben oder umsteigen. Wenn wir umsteigen bietet sich Microchip an, da gibts µC in allen Größen und sie haben spezielle µC für die Ansteuerung von BLDC/PMSM-Motoren. Ich bin verantwortlich für die elektronischen Entscheidungen und bin mir noch etwas unsicher bei der Wahl der Architektur. Könnt ihr mir bitte schreiben/helfen, welche Erfahrungen habt ihr mit PIC und AVR, gibt es irgendwelche Stolpersteine, wie schauts aus mit Toolchain beim PIC, stabilität? Danke im Vorraus für eure Hilfe ... lg Roland
ich sag mal frech microchip :) aber das ist ne religionsfrage, was erwartest du da denn für eine Antwort? btw trennt ihr euch vom Technikum oder hab ich da was falsches im kopf von wegen partnerschaft?
Hi, meiner Ansicht nach tun sich beide nicht viel. Ich habe mit beiden schon gearbeitet und habe für beide die entsprechende Toolchain zu Hause. Beim PIC gefällt mir die "Programmier-Art" etwas besser, dafür ist der Compiler nicht kostenlos wie beim ATMEL. PICs haben viele schöne kleine Devices, teilweise für Speziallösungen. ATMELs hingegen gibt es in "Bastelfreundlichen"-Gehäusen. In den letzten Jahren hat ATMEL stark zugelegt, wie ich finde. Deren Controller sind heute sehr "vollgepackt" mit interner Peripherie und trotzdem noch billiger als die PICs... Aber das ist nur meine persönliche Erfahrung, kann sein, dass andere dies ganz anders bewerten...
ja, der compiler ist für seine zwecke gratis ;) aber sonst geb ich dir recht
Je nun, nimm niemals einen zu kleinen Hammer... Da gibt es so schöne ARM's, ATXMegas, usw. Mit Speicher, Ausstattung, Rechenleistung, etc. satt. Such dir was aus. Oliver
Roland schrieb: > Wenn wir umsteigen bietet sich > Microchip an, da gibts µC in allen Größen Also die Skalierbarkeit ist gerade nicht die Stärke der PICs. Bei den kleinen PICs muß man schon erhebliche Abstriche machen. Deshalb empfehlen hier oft die PIC-Benutzer, nur ab PIC18 aufwärts zu verwenden. Bei den AVRs hast Du dagegen schon ab den 8-Pinnern eine Menge schnuckeliger Ressourcen (2 Timer, PWM, ADC, vektorisierte Interrupts, Pointer, Sleepmode mit Pinchange Aufwachen, flat Memory, 3 Pointer, ...). Man kann also die AVRs voll nach Bedarf skalieren, d.h. wieviel Pins man gerade für eine Anwendung braucht. Die Codeanpassungen bei Typwechsel sind minimal. Und Assemblerprogrammierung ist überhaupt nicht mehr nötig. Peter
Erfahrungen mit pic: schlechte... Erfahrungen mit avr: gute für deine Aufgabe würde ich eher zum Cortex M3 greifen.
Wenn ihr schon etwas tiefer in der Materie seid würde sich wirklich ein Cortex M3 anbieten. Bei den Preis/Leistungsverhältnissen sehen die 8 bit MCUs alt aus. NXP z.B. hat auch Typen mit Powercontrollern etwa für BLDc Motoren integriert. Die Einarbeitungszeit ist allerdings nicht unerheblich!
guest schrieb: > Erfahrungen mit pic: schlechte... > Erfahrungen mit avr: gute Erfahrung mit PIC: sehr gut Erfahrung mit AVR: zum kotz*n Ömmm das ist so eine Grundsatzdiskussion. Ist Geschmackssache. Es gibt nur in Spezialfällen wirklich konkrete Entscheidungskriterien ^^ Kleiner Tipp: Wir ne Münze =) Nein Spaß =)
Hier mal ein Link der zu dieser Unterhaltung passt: EEVBlog #63 http://www.youtube.com/watch?v=DBftApUQ8QI
wt schrieb: > Erfahrungen mit pic: schlechte... > Erfahrungen mit avr: gute Diese Aussage ist mMn noch an der Grenze aber sowas Lehrmann Michael schrieb: > Erfahrung mit PIC: sehr gut > Erfahrung mit AVR: zum kotz*n sagt eigentlich nur etwas über die Engstirnigkeit des Autors aus. Ich persönlich hab zwar noch nicht mit PICs gearbeitet (dafür schon viel mit AVR µCs) aber wenn man das Datenblatt durchliest, eine korrekte Schaltung aufbaut und sich kurz in die Toolchain einliest, dann sollte man immer ein funktionnierendes Design vor sich haben. Spätestens nach ein paar Versuchen. Wer die Toolchain Programmierung Beschaltung bei den AVR µCs zu kompliziert findet, der muss aber wirklich ein blutiger Anfänger sein. So, jetzt zum Thema. Bei uns auf der Uni (TU Wien) hab ich im 8-bit Segment nur AVR Atmegas gesehen. Freie, bekannte Toolchain und viel On-Chip-Peripherie. Ich weiß aber nicht was unser Robo-Cup Team verwendet.
ALLE CPUs haben Vorteile. Es ist dann nur noch die Frage, welche hat die Meisten Vorteile um dieses Projekt realisieren zu können. Ich tippe auf den STM32F103. - Umfangreiche Pheripherie eingebaut - Pins von 36 ... 144 - Betriebsspannung 2..3,6V, also auch mit 2x Akku 1,2V - Wenig externe Bauteile nötig - FW-Lib und sehr viele Demos dazu - hier im Forum breite Unterstützung - Großer Frequenzbereich für den System-Takt (Strom sparen | Geschwindigkeit) - Verfügbarkeit - Flash von 32Kb bis 512Kb, Pin und Softwarekompatiebel untereinander - Diese Entscheidung wird die nächsten Jahre garantiert halten. Ich kenne sehr viele CPUs, auch den AVR und PIC. Bin seit einem Jahr überzeugt vom STM32F103. Die Cortex-M3 von NXP haben nicht ein so breites Spektrum an Funktionen und PIN-Counts, da ist ST schon weiter. Ein AVR ist schon sehr begrenzt von der Leistungsfähigkeit. Mit einem einzigen Cortex-M3 könnte man so viel machen wie mit 4 AVRs (Rechenleistung).
Hallo Roland, ein mir bekanntes Robo-Team setzt einen Verbund von AVR's ein, denkt aber auch über einen ARM nach. Ich achte immer darauf, daß ich Werkzeuge bekomme, die auf mehr als einer Plattform laufen. Mit der Unterstützung von Eclipse und gcc sehe ich da einen Vorteil für Atmel. Letztlich ist die Toolchain Geschmackssache, das musst Du selbst ausprobieren/entscheiden. Persönlich nutze ich einen Editor, make, gcc, avrdude und kann damit auf jeder Plattform arbeiten, sogar - und am liebsten! - auf meinem Mac. Viel Erfolg, Jörg
>> Erfahrungen mit pic: schlechte... >> Erfahrungen mit avr: gute > Erfahrung mit PIC: sehr gut > Erfahrung mit AVR: zum kotz*n ich persönlich habe auch letztere erfahrung gemacht. für euer vorhaben, würde ich mindestens zu den PIC24H greifen: geschwindikeit, ausstattung und preis sind unschlagbar. jenachdem wie ressourcenintensiv eure roboter sind, zu einem PIC32 oder wie erwähnt Cortex-M3 (wobei zu den letzteren ich keine erfahrung habe). ach ja, die entwicklungsumgebung und die compiler für die PIC18, PIC24, PIC30, PIC33, PIC32 gibt's von Microchip gratis (nach 60 tagen werden in der demoversion gewisse optimierungen abgeschalten, die aber in 98% aller fälle nicht stören)
Wieso nur eine Architektur? Die Namen sagen es doch schon, Mikroprozessor zum prozessieren (z.B. Kamera-Daten auswerten/High Level strategien) und Mikrocontroller zum steuern (Motoransteuerung zum Laufen/Fahren, Kollisionserkennung...). Ist doch in der Natur auch nicht anders. Ich weiß, er ist hier nicht sonderlich populär, aber ich würde als Controller zum Propeller greifen. Ich hab vor nem halben Jahr mit dem Propeller angefangen. Man bekommt so ziemlich alles recht schnell zum laufen, weil für vieles schon Objekte verfügbar sind. Die multicore Architektur ist wesentlich einfacher zu handhaben, als Interrupt-getriebene Architekturen. Für nen Mikroprozessor ist es ratsam einen zu nehmen, für den auch mind. ein Betriebssystem existiert. In diesem Bereich möglichst eines mit Echtzeit-Fähigkeit. Das BS nimmt einem die lästige Handhabung von Peripherie ab (LCD? USB?) Hier ist wohl in der Tat ein ARM eine gute Wahl. Die haben das wohl so ähnlich gemacht: http://www.parallax.com/tabid/773/Default.aspx
danke, ich hätte nicht mit so vielen Antworten gerechnet. Mir ist klar das es hier keine richtige Entscheidung geben kann und das es quasi eine Art "Religionsfrage" ist. Aber es ist jetzt eine Entscheidung die Jahre halten muss weil später wechseln is nicht drinnen (der aktuelle Roboter hat 4 Jahre gehalten). wir wollen bis kommende Weihnachten alles fertig haben (jetzt wirds schon stressig) damit wir nächstes Jahr Jänner, Februar, März fünf solche Roboter bauen können. Wir wollen uns nicht unbedingt von avr trennen, aber falles es für uns eine günstigere/bessere Architektur gibt können wir nur jetzt wechseln. am neuen Roboter wollen wir mehrere µC's einsetzten und einen IndustriePC, beim PIC is der Vorteil, da haben fast alle µC eien CAN-Bus drauf und ich finde es gibt auch schnelle µC in kleinen Gehäuseformen beim AVR gibt auch µC in allen Größen (mit den Gehäuseformen bin ich nicht ganz zufrieden) das große Plus ist, es gibt eine sehr gute Toolchain mit eclipse avr-libc avrdude MagIO schrieb: > Wieso nur eine Architektur? weil ich dann nur eine Toolchain brauch, und man nicht für mehrere Verschiedene Arch. coden muss mehr architekturen find ich unnötig kompliziert Lehrmann Michael (ubimbo) schrieb: > Kleiner Tipp: Wir ne Münze =) Nein Spaß =) g so werden wir uns dann glaub ich entscheiden
Das große Plus Eclipse hat STM32F103 auch. Wie schon oben beschrieben, ein STM32 packt so viel wie 4 AVRs! Serienpreis für einen kleinen STM32F103 ist günstiger als ein AVR!
Thomas Burkhart schrieb: > Hast Du Dir den STM32F103 > > Mal angeschaut? hab glaub ich alle uC-Hersteller angeschaut, und es wird eine Entscheidung zwischen PIC und Atmel, weil es hier viele Hobbyprojekte gibt und studenten sich da vl schon auskennen Plan schrieb: > Wie schon oben beschrieben, ein STM32 packt so viel wie 4 AVRs! > Serienpreis für einen kleinen STM32F103 ist günstiger als ein AVR! das brauchen/wollen wir nicht, damit sich die einzelnen Projekte (source-code-teschnisch) nicht in die Quere kommen, war zu beginn eine Designentscheidung: one job one tool das heißt für jedes Modul ein µC
Roland schrieb: > Plan schrieb: >> Wie schon oben beschrieben, ein STM32 packt so viel wie 4 AVRs! >> Serienpreis für einen kleinen STM32F103 ist günstiger als ein AVR! > das brauchen/wollen wir nicht, damit sich die einzelnen Projekte > (source-code-teschnisch) nicht in die Quere kommen, war zu beginn eine > Designentscheidung: one job one tool > das heißt für jedes Modul ein µC Das ist auch meine Philosophie, intelligente Sensoren und Aktoren. Man gewinnt dadurch eine Menge an Flexibilität und Sicherheit. Und obendrein werden Verdrahtung und Layout wesentlich einfacher. Z.B. wenn ich nen Temperatursensor an nen ADC der Haupt-CPU anschließe, weiß ich nicht, ob durch Leitungs- oder Steckerprobleme Mumpitz eingelesen wird. Habe ich dagegen einen MC direkt am Sensor, kann ich genau feststellen, ist der Wert gültig oder ist der Datenbus gestört. Ein gemeinsamer serieller Datenbus läßt sich auch wesentlich leichter überprüfen, es sind ja nur 1..4 Leitungen und keine 100. Peter
Peter Dannegger schrieb: > Deshalb empfehlen hier oft die PIC-Benutzer, nur ab PIC18 aufwärts zu > verwenden. Stimmt, das hört man öfter. Trotzdem ist es kein weiser Rat, da PIC18 mitnichten die Nachfolger von PIC16 sind. Es handelt sich definitiv um eine eigenständige Familie. @Roland Auf deine Frage kann ich leider nicht weiter eingehen, da es dafür keine eindeutige Antwort geben kann. Du musst für dich entscheiden womit du arbeiten möchtest. Sinnvoll ist vielleicht, dabei einfach in die Datenblätter zu schauen und dann einen Typen zu nehmen, der umfassend dokumentiert ist und eine gewisse Verbreitung hat - dann kannst du eher mit Hilfe rechnen wenns irgendwo hakt. Grüße, Edson
Servus Meister Eder schrieb: > Peter Dannegger schrieb: > >> Deshalb empfehlen hier oft die PIC-Benutzer, nur ab PIC18 aufwärts zu > >> verwenden. > > > > Stimmt, das hört man öfter. Trotzdem ist es kein weiser Rat, da PIC18 > > mitnichten die Nachfolger von PIC16 sind. Es handelt sich definitiv um > > eine eigenständige Familie. Doch, das ist schon ein weiser Rat. Microchip's PIC16 sind sowas wie die Grossväter aller Mini-Microcontroller. Die PIC16 werden zwar immer noch von Microchip gepflegt - auch weil sie günstiger sind als die PIC18-Familie. Aber die PIC18 sind aufgrund ihrer Ausrüsung mit Resourcen für die Programmierung unter C sehr viel besser geeignet - die PIC16 dagegen nur sehr eingeschränkt. Ich würde auch keinem uC Anfänger mit einem PIC16 zu beginnen. Gerhard
Die Verfügbarkeit der Toolchain sollte man nicht unterbewerten. Gerade wenn ein Haufen wechselnder Studenten mit jeweils eigenen Erfahrungen und Vorlieben, Betriebssystemen und Computern daran arbeiten soll, ist "kostenlos" meiner Meinung nach nicht gut genug, die sollte frei sein. Mirko
Das Roboter-Lern Projekt sollte Prozessoren beinhalten, die in der Industrie Verwendung finden. Als Student sollte man doch für das Arbeitsleben vorbereitet werden. Daher unbedingt ein Chip der ARM Reihe verwenden! Studenten die nach dem Studium nichts praktisches können und auf Jobsuche sind gibt es genung!!!! Also liebe Studenten, würde es sich nicht toll in Bewerbungsunterlagen machen, wenn da drin stehen würde: "Praktische Erfahrung mit 32-Bit ARM Architektur (Cortex-M3)" Das muss unbedingt bei der Auswahl des Prozessors berücksichtigt werden!!!
Da bin ich anderer Meinung! Im Studium kann man nicht alles lernen, was jeder beliebige Arbeitgeber irgendwann mal brauchen könnte. Und es gibt auch etliche Arbeitgeber, die noch ohne ARM auskommen. Viel wichtiger ist es im Studium zu lernen, wie man in völlig unbekanntem Terrain möglichst schnell (also in einem Semester) das nötige Wissen erlernt UND damit ein Projekt abschließt. Also würde ich mich als Robo-Cup-Robot-Bau-Projektleiter durchaus an Exoten ranmachen, denn ARM und AVR kann ja jeder. Lieber XMOS oder Propeller .... Roland schrieb: > das brauchen/wollen wir nicht, damit sich die einzelnen Projekte > (source-code-teschnisch) nicht in die Quere kommen, war zu beginn eine > Designentscheidung: one job one tool > das heißt für jedes Modul ein µC Und mit der Aussage verstehe ich auch die Toolchain-Anforderung nicht. Wenn doch sowieso das Projekt aus mehreren kleinen Teilprojekten besteht, die sich nicht in die Quere kommen sollen.
Plan schrieb: > Also liebe Studenten, würde es sich nicht toll in Bewerbungsunterlagen > machen, wenn da drin stehen würde: > > "Praktische Erfahrung mit 32-Bit ARM Architektur (Cortex-M3)" Es macht sich garnicht gut, gleich mit einer Lüge anzufangen. Als Student hat man keine praktischen Erfahrungen. Die hat man erst nach dem ersten längeren (>2 Jahre) Job. Es klingt dagegen viel besser, wenn man sagen kann, man hat dieses und jenes Projekt fertiggestellt. Welche Architektur ist dabei vollkommen wurscht. Aber sagen zu müssen, ich hab für nen hippen Boliden 10.000 Zeilen Konfigurationscode und RTOS geschrieben, zum eigentlichen Projekt bin ich deswegen nicht mehr gekommen, öffnet einem keine Türen. Peter
Es ist auch nicht der Sinn eines Studiums, eine bestimmte Plattform zu erlernen. In dem Kurs wird es um Kenntnisse wie KI- und Bildverarbeitungsmethoden gehen, die Plattform ist Mittel zum Zweck und eigentlich egal. Die Roboter sind die praktische Anwendung und im wesentlichen Motivationshilfe. Programmiersklaven müssen sich die Unternehmen schon selber ausbilden. Mirko
@ Peter Dannegger (peda) >> "Praktische Erfahrung mit 32-Bit ARM Architektur (Cortex-M3)" >Es macht sich garnicht gut, gleich mit einer Lüge anzufangen. Ja, aber . . > Als >Student hat man keine praktischen Erfahrungen. Die hat man erst nach dem >ersten längeren (>2 Jahre) Job. Nana, das halte ich für Unsinn. Man hat Praktikas gemacht, und wenn man da nicht nur Kaffee gekocht hat, dann hat man durchaus praktische Erfahrungen. Und wer neben dem Studium noch gebastelt hat, der hat sie erst Recht! >Es klingt dagegen viel besser, wenn man sagen kann, man hat dieses und >jenes Projekt fertiggestellt. Welche Architektur ist dabei vollkommen >wurscht. Nicht ganz. Man muss ja schliesslich auch Butter bei die Fische bringen und nicht nur abstrakt faseln. >Aber sagen zu müssen, ich hab für nen hippen Boliden 10.000 Zeilen >Konfigurationscode und RTOS geschrieben, zum eigentlichen Projekt bin >ich deswegen nicht mehr gekommen, öffnet einem keine Türen. Davon redet keiner. MFG Falk
Falk Brunner schrieb: > Nicht ganz. Man muss ja schliesslich auch Butter bei die Fische bringen > und nicht nur abstrakt faseln. Abstrakt ist, wenn man nur ganz allgemein von CPU-Typen faselt. Wenn man dagenen ein abgeschlossenes Projekt vorzeigen und es auch erklären kann, ist das was konkretes. Ein Bäcker, der ne Torte bäckt, wird eher genommen, als der, der nur das Rezept aufschreibt. Peter
> hippen Boliden 10.000 Zeilen Konfigurationscode Hier sieht man mal wieder wie wenig Ahnung ihr überhaupt von einem 32 Bitter habt !!!! Ich habe oben schon den STM32F103xx empfohlen, samt FW-Lib von ST. Damit reduziert sich das ganze auf sehr wenige Zeilen. Dazu gibt es Haufenweise Demo-Codes von ST, die alle diese eine FW-Lib verwenden. Muss ich das denn nochmals schreiben. Der Cortex-M3 von ST ist ca. 30-50% schneller programmiert als alles andere, gerade wegen der FW-Lib!!!! > um Kenntnisse wie KI- und Bildverarbeitungsmethoden gehen Na dann viel Spass mit einem PIC16. > durchaus an Exoten ranmachen Wiso dann nicht gleich einen Z80CPU verwenden, dann ein RAM dazu löten, dann ein EPROM dazu, eine Z80PIO und ein Z80CTC Chip. Dann sieht man ganz genau was das für Teile sind. Das ist echt exotisch. Nochmal, für alle die es nicht kapieren dürfen: Die Lehrer/Pfofessoren müssen dafür sorgen, dass die Studenten möglichst viel lernen das die Studierenden niemals im Leben gebrauchen können. Nur so ist sichergestellt, dass das Volk effektiv verdummt ohne dass es dies merkt. Also geht zur Schule, lernt und wehe die Noten sind schlecht. Wir sind ein Volk das schon seit Jahren immer dümmere Schulabgänger produziert, was immer weiter vortgesetzt wird. Niemand steuert dagegen. Wie wäre es eigentlich mit einer Umfrage in den Betrieben, bei denen die Studierenden Praktikum machen, welche Prozessoren diese am liebsten/in der Zukunft einsetzen werden? Anstatt hier im Forum unkonstruktiv den STM32 Cortex ohne Ahnung zu haben nieder zu machen. Ich habe schon Z80, HC11, M16C, PIC16, PIC18, PIC24, dsPIC30, ATMEGA, BasicTiger, LPC2000, STM32 programmiert und wenn ich schreibe 30-50% weniger Aufwand, dann ist dies eine fundierte Aussage mit 20 Jahren Programmiererfahrung. Hier will wohl irgend wer sein eigenes EGO aufpollieren.
Sorry, zu viele Posts. Irgendwie wollte das Forum mein Text nicht annehmen, sowas hatte ich noch nicht. @Admins, Ihr könnte das doppelte löschen und nur den Beitrag von 19:37 belassen.
Peter Dannegger schrieb: > Ein Bäcker, der ne Torte bäckt, wird eher genommen, als der, der nur das > Rezept aufschreibt. Und der, der beides beherrscht ist noch besser dran. Das Ziel bei einer Uni ist (sollte sein), dass man etwas lernt (hier z.B. über KI) und dann auf eine Art löst / auf einer Plattform implementiert. Das Ergebnis soll aber plattformunabhängig sein, d.h. wenn die Plattform geändert wird sollte man trotzdem das gewünschte Resultat hervorbringen können, da der Schwerpunkt der Ausbildung auf der Theorie hinter der Sache liegt (liegen sollte). Leider muss ich auch bei meiner Uni (TU Wien) eine immer stärker vordringende Verschulung feststellen, wodurch die Uni zu einer FH "degradiert" wird. Nicht falsch verstehen, ich finde FHs sinvoll und gut aber ich habe mich für die Uni entschieden, weil ich eben keine schulähnliche Ausbildung wollte. Ich hab zwar selber bisher nur mit Atmegas gearbeitet (auf der Uni) aber würde sie für dieses Vorhaben als relativ gut geeigneten Kandidat empfinden. *) Die freie Toolchain läuft auf den gängisten OS (bei meinen Kollegen hauptsächlich versch. Linux Distris, Windows XP - 7, Mac OS), was bedeutet, dass die Studenten in ihrer vertrauten Umgebung programmieren können. *) Die Datenblätter sind äusserst detailliert (muss jedoch zugeben, dass ich mich noch nicht mit einem PIC Datenblatt auseinandergesetzt hab da noch nicht damit gearbeitet). Ich habe vor der LVA, welche mich in die Mikrocontrollerwelt eingeführt hat, noch nie auf dieser Ebene gearbeitet und dann innerhalb eines Semesters von einfachen Assemblerprogrammen bis etwas aufwendigeren C Programmen (Integer Taschenrechner (Punkt vor Strich) mit Matrixtastatur Eingabe, multiplexed 5x7-seg Anzeige) nur mit Hilfe des Datenblatts und den Schematics unseres I/O Boards geschafft. Natürlich habe ich einige Stunden im Labor verbracht aber wer keinen Spass dran hat, braucht die LVA nicht zu besuchen bzw studiert evtl das Falsche. *) In vielen Foren (z.B. hier) findet man auch genügend Hilfe, sollte man ausserhalb der Laborzeiten Probleme haben. Das wären mMn ein paar Pluspunkte für die AVRs (wenn on Chip Peripherie nicht mitgerechnet wird) aber ich habe wie gesagt noch keine weiteren Erfahrungen, womit ich die bisherigen vergleichen kann. Edit: Plan schrieb: > Wie wäre es eigentlich mit einer Umfrage in den Betrieben, bei denen die > Studierenden Praktikum machen, welche Prozessoren diese am liebsten/in > der Zukunft einsetzen werden? Ich würde auch am liebsten jeden Tag mit dem Heli auf die Uni fliegen und trotzdem fahr ich mit dem Rad und der Bahn. Ein MSc (was fänt man denn schon mit dem Bachelor an? (leider)), der sich nicht in eine neue Architektur einarbeiten kann hat den Titel nicht verdient. Auch derjenige, der sich die Hardware zusammenschustert und sich dann Gedanken über die Software macht sollte seinen Titel gleich wieder abgeben.
Gerhard schrieb: > Doch, das ist schon ein weiser Rat. Microchip's PIC16 sind sowas wie die > Grossväter aller Mini-Microcontroller. Ein altes Sprichwort besagt, dass man auf alten Drahteseln das Radeln lernt. ;) > Die PIC16 werden zwar immer noch > von Microchip gepflegt - auch weil sie günstiger sind als die > PIC18-Familie. PIC16 wird nicht nur gepflegt, sondern es werden immer noch neue Typen entwickelt. In Sachen "Low Power" und Peripherie tut sich immer was. > Aber die PIC18 sind aufgrund ihrer Ausrüsung mit > Resourcen für die Programmierung unter C sehr viel besser geeignet - die > PIC16 dagegen nur sehr eingeschränkt. Das mag in manchen Aspekten ja stimmen, aber für eine Implementierung auf einem uC mit sagen wir mal 64 Byte RAM und 512 Worten Programmspeicher ist C nicht unbedingt das Mittel der Wahl. Eine gut sortierte Makro-Bibliothek hilft da schon eher. > Ich würde auch keinem uC Anfänger > mit einem PIC16 zu beginnen. Du meinst, du würdest es nicht empfehlen, ok. Ich will niemandem meine Meinung aufdrängen. Ich glaube aber, dass es vollkommen egal ist auf welcher Plattform man sich zuerst einarbeitet. Plan schrieb: >> um Kenntnisse wie KI- und Bildverarbeitungsmethoden gehen > Na dann viel Spass mit einem PIC16. So ein Beispiel als Anwendung für einen PIC16 zu nennen ist halt schon daneben. Ich kenne die STM32 und finde die seit den letzten Revisionen auch schwer in Ordnung. Man muss aber auch zur Kenntnis nehmen, dass der Hersteller ST wieder 8-Bit Controller auf den Markt bringt. Wenn also die 8-Bitter aussterben und überall STM32 eingesetzt werden, warum setzt der Hersteller selbst auf ein "lahmes Pferd"? Grüße, Edson
Meister Eder schrieb: > Plan schrieb: >>> um Kenntnisse wie KI- und Bildverarbeitungsmethoden gehen >> Na dann viel Spass mit einem PIC16. > > So ein Beispiel als Anwendung für einen PIC16 zu nennen ist halt schon > daneben. Wenn Ihr Euch mal durchlesen würdet, was ich geschrieben habe, dann wüsstet Ihr, dass ich das auch gar nicht gemacht habe. Mirko
@m1rk0 Da hast du was falsch verstanden. Ich habe den User 'Plan' gemeint, nicht dich.
Hallo Leute, ich habe bislang ausschließlich mit AVR gearbeitet. Aufgrund dieses Threads habe ich mich mal bei den PICs umgeschaut. Die haben für ihr Geld doch erstaunlich viel Funktionalität, vor allem die PIC18F. Es gibt auch einige Typen mit USB, wohingegen man bei Atmel mit der Lupe nach USB suchen muss (Und wenn man mal schaut, was die FTDI-"Krücken" schon alleine kosten...) Wie gesagt, ich habe mir mal ein Datenblatt von einem 18er angeschaut, und war doch ein wenig überrascht. Auf den ersten Blick kann Atmel da nicht so richtig mithalten. Aber vielleicht täuscht der erste Eindruck. Leider gibt es ja anscheinend keine freie GNU-Toolchain für die PICs, ja man muss sogar mei manchem Compilerhersteller mehrfach bezahlen, wenn man verschiedene Familien verwenden möchte. Irgendwo habe ich gelesen, man könne das Backend für den gcc schlecht für die PICs konfigurieren. Das widerspricht allerdings dem Werbetext von Microchip, dass sich die PICs gut für die Programmierung in C eignen sollen. Wie ist Eure Meinung?
- PICs haben maximal 2 oder 3 Breakpint-Register. Zum Debuggen etwas mühsam. - Erratas sind auch gut gefüllt mit Bugs. - Wenn man konstanten aus dem Flash verarbeiten möchte braucht es spezielle Table Befehle/Register. - Zum Programmieren ist das echt ein Krampf - Benötigt einen teuren ICD2. Damit man flüssig Arbeiten kann ist ein Real-ICE empfohlen >> Teuer - Es gibt auch Selbstbaulösungen, sind aber relativ langsam - Software läuft nur unter Windows. - Nahezu jeder PIC-Chip hat etwas abgeänderte/Verschlimmbesserte Pherieperie drin, also Code für einen PIC-Chip muss für ein anderen angefasst werden weil da irgend was geändert wurde. (Neues Studium des Datenblattes) - Ich hatte schon PIC-Chips, die mussten erst mit einem PM3 gelöscht werden, damit die wieder mit einem ICD2 programmierbar waren :( - Gehäuse DIL/SMD Hingegen STM32 - 5/6 Breakpoints in der Hardware - Erratas sehr wenig - 4GB Adressraum Flash/RAM/Pheriperie, alles ein Adressraum, kein Banking/ Bankumschaltung - JTAG-Interface von vielen Firmen nutzbar, schon ab 25 EUR. - Kostenlose Software für Linux/Windows (Mac weiß ich nicht, denke aber geht auch) - Kann sich somit jeder Student auch Privat leisten und hat ein sehr leistungsfähiges System - Alle Pheriperiemodule sind bei allen Derivaten exakt gleich. - Gehäuse SMD Hingegen ATMEGA: - 2/3 Breakpoints - Erratas mittelmäßig gefüllt - Daten aus dem Flash umständlich lesbar - JTAG-Interface von vielen Firmen nutzbar, schon ab 25 EUR. - Kostenlose Software von Atmel/GCC - Kann sich somit jeder Student auch Privat leisten - Pheriperiemodule/deren Unterschiede kenne ich nicht so gut da ich nicht so viele Derivate in den Fingern hatte. - Gehäuse DIL/SMD Die Preise (Masse, je nach Distibutor unterschiedlich): PIC18: ca. 2,00 EUR STM32F103CB: ca. 3,60 EUR ATMEGA128: ca. 3,80 EUR Demoboards gibt es für alle Derivate ab 20 EUR aufwärts. Ich sehe immer noch keinen Nachteil für die STM32 Reihe. Die PICs sind nur dann interessant wenn man ein Massenprodukt machen muss wo man wirklich jeden Cent mit Multiplikationsfaktor sieht. Wegen der Pheriperie bin ich bei den PICs auch schon böse auf die Nase gefallen. Der UART des ATMEGAs kann unter Umständen empfangene Zeichen "verschlucken" (ca. 1-2 Zeichen in der Woche). Das hat mich auch mal viele Stunden/Tage Fehlersuchen gekostet. Beim STM32 habe ich solch negative Erfahrungen nicht erleben dürfen. Das Ding macht das was ich haben will.
Peter Dannegger schrieb: > Roland schrieb: >> Plan schrieb: >>> Wie schon oben beschrieben, ein STM32 packt so viel wie 4 AVRs! >>> Serienpreis für einen kleinen STM32F103 ist günstiger als ein AVR! >> das brauchen/wollen wir nicht, damit sich die einzelnen Projekte >> (source-code-teschnisch) nicht in die Quere kommen, war zu beginn eine >> Designentscheidung: one job one tool >> das heißt für jedes Modul ein µC > > Das ist auch meine Philosophie, intelligente Sensoren und Aktoren. > Man gewinnt dadurch eine Menge an Flexibilität und Sicherheit. Und > obendrein werden Verdrahtung und Layout wesentlich einfacher. > ... > Ein gemeinsamer serieller Datenbus läßt sich auch wesentlich leichter > überprüfen, es sind ja nur 1..4 Leitungen und keine 100. smart sensor und can-bus rulez :-) Plan schrieb: > Das Roboter-Lern Projekt sollte Prozessoren beinhalten, die in der > Industrie Verwendung finden. nein, nein, nein warum?? Plan schrieb: > Als Student sollte man doch für das Arbeitsleben vorbereitet werden. hmmm, ein student sollte "alles" können Theorie: lernt er eh, VO ... Praxis: (entspricht meiner Meinung nach "für das Arbeitsleben vorbereitet") für den Arbeitgeber interessant interessiet die Studenten aber nicht die wollen einfach das Studium durchbringen wenn es von einer Uni dann das Angebot gibt ist es ihnen egal weil sie bekommen den Aufwand nicht in Freistunden abgegolten Plan schrieb: > Studenten die nach dem Studium nichts praktisches können und auf > Jobsuche sind gibt es genung!!!! (siehe auch vorher) das stimmt, wir haben ca. 10'000 technische Studenten und Probleme!!, genug zu finden die so etwas überhaupt interessiert und denen man zutrauen kann was bauen zu lassen (Entwerfen, Zeichnen, mechanisch und elektronisch) zum ursprünglichen Thema: ich habe meine eierlegende WollMilchSau gefunden ATMega64M1 der Haken den kann man noch nicht kaufen :-(
äh wie wärs mit einer vernünftigen vorgehensweise, indem erstmal definiert wird was gemacht werden muss, was der controller können muss, und dann augrund von fakten ausgewählt wird... meine zwischen cortex und atmega besteht doch noch ein gewisser unterschied... nun ob jetzt pic oder avr ist wohl fisch wie vogel, die ewige glaubensfrage... (können wir genausogut fragen welcher fussballclub besser ist...)
Plan schrieb: > - PICs haben maximal 2 oder 3 Breakpint-Register. Zum Debuggen etwas > mühsam. > - Erratas sind auch gut gefüllt mit Bugs. > - Wenn man konstanten aus dem Flash verarbeiten möchte braucht es > spezielle Table Befehle/Register. > - Zum Programmieren ist das echt ein Krampf > - Benötigt einen teuren ICD2. Damit man flüssig Arbeiten kann ist ein > Real-ICE empfohlen >> Teuer > - Es gibt auch Selbstbaulösungen, sind aber relativ langsam > - Software läuft nur unter Windows. > - Nahezu jeder PIC-Chip hat etwas abgeänderte/Verschlimmbesserte > Pherieperie drin, also Code für einen PIC-Chip muss für ein anderen > angefasst werden weil da irgend was geändert wurde. (Neues Studium des > Datenblattes) > - Ich hatte schon PIC-Chips, die mussten erst mit einem PM3 gelöscht > werden, damit die wieder mit einem ICD2 programmierbar waren :( > - Gehäuse DIL/SMD Auch dir sei gesagt das es nach den 16er PICs noch eine Welt gibt. Keiner dieser Punkte trifft auf die Serien >(=)18 zu. Gerade mal die Errata-Sheets und da bin ich der Meinung das es besser ist Sie schreiben es offen und ehrlich! Denn Fehlerfrei ist wohl kaum ein Prozessor.
Christopher G. schrieb: > *) Die freie Toolchain läuft auf den gängisten OS Für mich ist auch die Toolchain ein Hauptpunkt für den AVR gewesen. Ohne den WINAVR würde ich ihn lange nicht in dem Umfang einsetzen. Es mag bessere Compiler geben, aber ich habe nicht dieses unsägliche Dongle-/Lizenzgeraffel am Bein. > *) Die Datenblätter sind äusserst detailliert Die AVR-Datenblätter finde ich auch vorbildlich. Man hat alles in einem Dokument. Man hat erst die ausführliche Prosa zu jeder Funktionseinheit und dahinter kurz und knackig die Registerbeschreibung. Aber die Atmel 8051-Datenblätter sind dagegen grauenhaft. Auch die NXP ARM7 Datenblätter sind ein Graus, es ist schon eine Wissenschaft für sich, erstmal alle nötigen Manuals zum Downloaden überhaupt zu finden. Und außer dem häßlichen I2C-Multimaster-Bug läuft der AVR auch wie dumm. Peter
Plan schrieb: > Der UART des ATMEGAs kann unter Umständen empfangene Zeichen > "verschlucken" (ca. 1-2 Zeichen in der Woche). Das hat mich auch mal > viele Stunden/Tage Fehlersuchen gekostet. Bloß komisch, daß ich bisher nie was darüber gelesen habe. Bei mir läuft die UART wie dumm, 365 Tage im Jahr. Es wird wohl ein Softwarefehler sein, z.B. ein volatile oder atomicity-Fehler. Wenn es wirklich ein Hardwarefehler wäre, dann hast Du bestimmt ein Testprogramm und eine Fehlerbeschreibung dafür, damit man es nachvollziehen kann. Keine falsche Bescheidenheit, publiziere ihn doch einfach. Peter
@Peter Dannegger Ist schon über ein Jahr her, aber ich habe das hier gepostet. Ich hatte sogar den gesammten Code komplett aueinandergerupft und hier rein gestellt. Wenn da tatsächlich ein SW-Fehler drin gewesen wäre, dann hätte man den gefunden. Nein est ist ein Problem mit dem Interrupt-Handler, der in nicht auszuschließenden Fällen einige kniffe braucht. Oder man kann es auch anders ausdrücken: Was genetisch versaut ist kann man mit Prügel allein nicht richten.
Plan schrieb: > Nein est ist ein Problem mit dem Interrupt-Handler, der in nicht > auszuschließenden Fällen einige kniffe braucht. Also war meine Vermutung richtig, daß es ein Softwarefehler ist. Einen 16Bit-Wert vom Interrupt mußt Du auf nem 8Bitter atomar zugreifen, sonst kann er ungültig werden. Das kann man daher nicht dem AVR ankreiden. Aber auch 32Bitter sind vor atomar-Problemen nicht gefeit. Read-modify-write Zugriffe müssen auch auf nem 32Bitter atomar gekapselt werden, z.B. "*ptr++;". Und auch bei Srukturzugriffen. Generell schadet es nichts, zu beachten, daß Interrupts jederzeit zuschlagen können. Will man bei mehrteiligen Zugriffen konsistente Daten, muß man das kapseln. Peter
nein, das war was anderes. Ich hab jetzt auch keine Lust den Thread zu suchen.
Habe einige Jahre mit PICs (10F, 12F, 16F) gearbeitet, nun bin ich auf AVR umgestiegen. Vorteile der AVRs (teilweise subjektiv!): - mehr Peripherie - besseres Interrupt Handling - Stack, Stack, Stack
>Nochmal, für alle die es nicht kapieren dürfen: >Die Lehrer/Pfofessoren müssen dafür sorgen, dass die Studenten möglichst >viel lernen das die Studierenden niemals im Leben gebrauchen können. Nur >so ist sichergestellt, dass das Volk effektiv verdummt ohne dass es dies >merkt. Also geht zur Schule, lernt und wehe die Noten sind schlecht. Was hast Du nur für absurde Verschwörungstheorien im Kopf? Was ist die Alternative: nicht zur Schule zu gehen und nichts zu lernen? >Wir sind ein Volk das schon seit Jahren immer dümmere Schulabgänger >produziert, was immer weiter vortgesetzt wird. Niemand steuert dagegen. Sorry, wenn ich das so drastisch sage: den Schülern gehört mal wieder gezeigt, wo der Hammer hängt. Dieses Verhätscheln und Tätscheln, das heute in den Elternhäusern stattfindet, bewirkt eine Entwicklung bei den Kindern und Jugendlichen, die äußerst bedenklich ist. Auch die Eltern sollten bitte mal wieder anfangen, ihre Kinder zu erziehen! Grausam, was da heute für Generationen von egozentrischen, motivations- und verantwortungslosen Selbstüberschätzern heranwächst. Es tut mir leid, wenn meine Worte etwas drastisch klingen, aber man muss es einfach so drastisch ausdrücken. Die Situation könnte schnell geändert werden, aber dafür müssten die Eltern mal wieder ihrer Erziehungsverantwortung nachkommen. Und die Gesellschaft dürfte sich nicht mehr von den jüngeren Generationen regelrecht terrorisieren lassen. Bitte nehmt mir die harten Worte nicht böse, aber ich habe momentan keine Lust, mir weniger aggressive Formulierungen auszudenken. Ansonsten: Was hast Du nur für absurde Verschwörungstheorien im Kopf?
Mein Text war ironisch gemeint. Oder vielleicht doch nicht? Oder ist es die Wahrheit? Oder hat meine Glaskugel einen Sprung? Ich war nie auf einer Studentenfabrik. Konnte schon mit 16 einen Mikrocontroller selbst zusammenlöten und programmieren. Nein, das können ist nicht angeboren, es wurde mit einem Kabel in der Steckdose mit einem Alter von etwa 4 Jahren injiziert.
**************Fred__ausgraben************************ während der langen winterabende kam ich auf eine idee - ich möchte auch einen roboter bauen... ;-) das teil soll sich im 1. schritt autonom(in der wohnung) spazieren fahren wobei ein von einen servo permanent drehender US sensor den kollisionsschutz bilden soll(nach bedarf IR in fahrtrichtung). mit der zeit soll das teil immer weiter wachsen - wenn mir halt grad irgendwas in den sinn kommt z. B. personenverfolgung etc. nun zum eigentlichen thema: ich habe schon umfangreichere projekte mit AVRs durchgeführt - z.B. steuerung von 4 schrittmotoren die abhängig voneinander si-wafer ausrichten - das ganze mit bremsen und beschleunigen um keine schritte zu verlieren, hohe und niedrige motorströme etc. ich mag die AVRs eigentlich recht gern und komm mit den "drum und dran" gut zurecht (hab da aber privat keinen debugger - außer ne led g) nun zur Frage: worin besteht nun (von der praktischen seite gesehen) der wesentliche unterschied zwischen z.B. einen AVR und z.B. Cortex Mx und mit welchen arm sollte man beginnen wenn man noch armjungfräulich ist - STM32F100RB oder LPC1343 beides als evalkit mit debugger (lpcexpresso und STM32 Discovery Kit) -OS z.B freeRTOS sinnvoll? -wo git es die bessere kostenlose IDE-lösung -sonstige vor-/nachteile bzw was ist zu beachten achja, ich habe mir gedacht den debugger abzubrechen und das targetboard mit stiftleisten zu versehen und dann auf das "Mainboard" mit teiber, verstärker, steckkontakte, anschlussbuchsen und sonstiger elektronik/HW zu stecken... danke schon mal
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.