Gibt's hier eigentlich sonst noch Microcontroller-Entwickler?

Gibt's hier eigentlich sonst noch Microcontroller-Entwickler? (15 Beiträge, 636 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich frag einfach mal in die Runde ob ich hier der einzige bin.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Hier.

hier, aber vor über 15 jahren war schluss damit.
hach die gute alt msc-51 familie...

Manchmal privat ... Kleinigkeiten, die man so braucht...

Nein, bist nicht

.

Ich bastel aber nur mit simple PICs rum... EZ80 wären spannender, aber schaltungstechnisch komplizierter für Grobmotoriker wie mich

.

Welche magst Du?

Die anderen.

Ich hab mich mehr auf Atmel eingeschossen.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Warum die Atmel? Was sind die Vorteile?

Beim Energieverbrauch sind IMHO die PICs vorne (Nanowatt), bei der Anzahl der unterschiedlichen Modelle ebenso, ...

Bei EZ80 wiederum hast einen TCP/IP-Stack in HW - was ist der Vorteil von AVR?

Als ich anfing damit gab's sehr gute Gründe für Atmel.

Der erste und für mich wichtigste war die sehr problemlose Adressierung (bei PIC afaik erst ab PIC16, vorher war's oft ein Krampf da größere Rampuffer zu besorgen) und die wesentlich einfachere Handhabung in Assembler.

Damals gab's auch noch keinen freien C-Compiler für PIC (gibt's jetzt eigentlich einen? Weiß ich gar nicht). Damals war's jedenfalls ein Krampf für PIC Programme zu schreiben, entweder man kämpfte gegen einen umständlichen Assembler oder eine umständliche C-Compiler Implementierung.

Die Programme sind meist ohne Anpassungen über verschiedene MC Typen portierbar, die verschiedenen Modelle haben nahezu den identen Befehlssatz und sind fast immer 100% abwärtskompatibel, alten Code in neue Chips zu flashen geht üblicherweise gut (bei Wechsel der Architektur ist u.U. eine Neuübersetzung aber keine Codeanpassung notwendig). Stellt man also erst mitten im Projekt fest dass einem der Programmspeicher ausgeht wechselt man einfach den MC auf das nächstgrößere Modell und macht weiter.

Auch das Portieren von Schaltungen ist recht simpel, viele baugleiche ATMegas sind auch pingleich.

Die Programmierung von AVRs ist im Endeffekt recht einfach, alle sind über ISP programmierbar. Der dafür notwendige Programmer ist simpel herzustellen (im Minimalfall: ein Parallelstecker, ein Chiphalter und 5 Widerstände) und idiotensicher zu bedienen. Bootloader o.Ä. verhalten sich ident wie herkömmliche Programme, benötigen keine zusätzliche Schaltung (nur eine Änderung der Fuses).

In-System Debugging geht bei den meisten aktuelleren MCs über JTAG, die entsprechende Schnittstelle dazu kann man sich ebenfalls selbst herstellen.

Damals gab's glaub ich auch noch keine PICs die ohne externen Quarz auskamen.

AVRs sind afaik auch spannungsfester als PICs, Pegelumsetzer bei kleinen Spannungsdiffernezen können so entfallen. Die meisten modereren Atmels kann man auch mit so ziemlich jeder Spannung zwischen 2 und 5.5V betreiben (allerdings im Niedrigspannungsbreich nicht mehr zwangsläufig mit voller Geschwindigkeit).

AVRs hatten auch früher eher als PICs zusätzliche Peripherie am Chip integriert. Ich wüßte jetzt keine (alten) PICs die bereits UART oder ADC on-chip hatten.

Und ehrlich gesagt find ich das qtouch von Quantum/Atmel ausgereifter als das mtouch, aber das wär jetzt nur eine Randerscheinung.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Der erste und für mich wichtigste war die sehr problemlose Adressierung (bei PIC afaik erst ab PIC16, vorher war's oft ein Krampf da größere Rampuffer zu besorgen) und die wesentlich einfachere Handhabung in Assembler.

Ach, du meinst das Bank Switching bei den kleinen PICs (also den 14Bittern PIC12 und PIC14). Ich verwende zwar ausschließlich diese, für meinen Anwendungen reicht es aber. Hast aber Recht, das ist gewöhnungsbedürftig - ich komme bei meinen Anwendungen aber immer damit aus.

Damals gab's auch noch keinen freien C-Compiler für PIC (gibt's jetzt eigentlich einen? Weiß ich gar nicht). Damals war's jedenfalls ein Krampf für PIC Programme zu schreiben, entweder man kämpfte gegen einen umständlichen Assembler oder eine umständliche C-Compiler Implementierung.

Keine Ahnung... PICs wollen in ASSE programmiert werden

. Die Assembler sind aber nett - und Microchip lieferte glaublich schon immer einen freien mit. Unter Linux gibt es auch nette PIC-Entwicklungsumgebungen.

Die Programme sind meist ohne Anpassungen über verschiedene MC Typen portierbar, die verschiedenen Modelle haben nahezu den identen Befehlssatz und sind fast immer 100% abwärtskompatibel

Innert derselben PIC-Familie gilt das ebenfalls..

Damals gab's glaub ich auch noch keine PICs die ohne externen Quarz auskamen.

Wundert mich jetzt... Ich dachte, dass es PICs wie meinen Liebling (12F675) seit Ewigkeiten gibt... Und auch bei seinen Vorgängern klappt es mit internem Quarz.

Die meisten modereren Atmels kann man auch mit so ziemlich jeder Spannung zwischen 2 und 5.5V betreiben (allerdings im Niedrigspannungsbreich nicht mehr zwangsläufig mit voller Geschwindigkeit).

s.o. 12F675 und Vorfahren sind zwischen 2 und 5V betreibbar... Und immer mit vollem internem Quarz (wenn du mit externem Quarz arbeitest, geht es aber auch schneller - dann brauchst mehr als 2V).

AVRs hatten auch früher eher als PICs zusätzliche Peripherie am Chip integriert. Ich wüßte jetzt keine (alten) PICs die bereits UART oder ADC on-chip hatten.

Siehe 12F675...

Ich muss mal nachlesen, seit wann es den gibt... Auf die schnelle finde ich es nicht

. Edit: Seit ca. 2000...

Und ehrlich gesagt find ich das qtouch von Quantum/Atmel ausgereifter als das mtouch, aber das wär jetzt nur eine Randerscheinung.

Damit habe ich noch nie rumgespielt... Das kam erst mit den 16bittern, glaub ich...

06.04.2012, 13:45 Uhr - Editiert von kombipaket, alte Version: hier

Definiere Mikrocontroller ...

Angefangen beim PIC bzw. ATMEGA8 übern STM32 über div. DSPs bis hin zum Cortex-A9 MC hamma alles scho gesehen (und dran herumgepfuscht :D )

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Herzlichen Dank an Raydoo für die Fotos

Ein Gerät, üblicherweise in Harvard-Architektur, das ALU, Speicher (realisiert als Register und/oder SRAM), Programmspeicher (üblicherweise realisiert als Flash-EEPROM), ggf. nichtflüchtigen Speicher und je nach Ausführung verschiedene zusätzliche Funktionalitäten (USART, DAC, ADC, AC, ...) in einem Chip vereinigt.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Dann Ja

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Herzlichen Dank an Raydoo für die Fotos

ARM steht mir noch bevor, ich will unbedingt mal ausprobieren wie die sich "anfühlen", was mir dafür allerdings noch fehlt wär ein Projekt das ich nicht sinnvoll mit den (zugegebenermaßen SEHR eingeschränkten) AVRs umsetzen kann...

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Kommt drauf an ob'st dich Bare-Metal ran traust oder schon ein fertig vorbereitetes Linux nimmst. Dzt. bin ich ja ein Fan der TI-Dinger, nur was ich gehört habe hat da in letzter Zeit der Support etwas gelitten.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Herzlichen Dank an Raydoo für die Fotos

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung