mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik welche µC-Architektur (AVR, PIC)


Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, der compiler ist für seine zwecke gratis ;) aber sonst geb ich dir 
recht

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erfahrungen mit pic: schlechte...
Erfahrungen mit avr: gute

für deine Aufgabe würde ich eher zum Cortex M3 greifen.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß =)

Autor: Ben ■. (bloxx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Link der zu dieser Unterhaltung passt:

EEVBlog #63

Youtube-Video "EEVblog #63 - Microchip PIC vs Atmel AVR"

Autor: Gast8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM, evtl. Cortex M3

Autor: Christopher G. (cbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Jörg Hermann (dr_coolgood)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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)

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich tippe auf den STM32F103.

jep, ACK!

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du Dir den STM32F103

Mal angeschaut?

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mirko Horstmann (m1rk0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mirko Horstmann (m1rk0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christopher G. (cbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mirko Horstmann (m1rk0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@m1rk0

Da hast du was falsch verstanden. Ich habe den User 'Plan' gemeint, 
nicht dich.

Autor: Mirko Horstmann (m1rk0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, sorry.

Mirko

Autor: Realist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- 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.

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ä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...)

Autor: morph1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, das war was anderes. Ich hab jetzt auch keine Lust den Thread zu 
suchen.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Realist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: robobbobter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
**************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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.