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...
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
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ß =)
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
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
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
