Forum: Offtopic Was wäre wenn es keine Atmegas mehr gäbe.


von Rumpelstilzchen R. (rumpelstilz)


Lesenswert?

Hallo,
ich hab derletzt mal wieder gelesen, dass Microchip interesse daran 
hatt/hatte ATMEL aufzukaufen.

Auf was würdet ihr umsteigen wenn es keine Atmegas mehr gäbe?

Für wie groß haltet ihr zur Zeit die Gefahr dass sowas in der Art 
passieren wird? Ich möchte mir eigentlich ein JTAG ICE mkII kaufen - das 
gibts ja für Studenten echt günstig.

Bei der Gelegenheit: Ist eproo-student.de vertrauenswürdig?

Danke für euere Antworten...

: Verschoben durch User
von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Der Schluss, daß ein Aufkauf von Atmel durch Microchip das Verschwinden 
der AVR-Reihe zur Folge hätte, ist etwas sehr gewagt.

von David .. (volatile)


Lesenswert?

ARM bedraengt den uC-Bereich immer mehr, mittlerweile kriegt man ARM 
doch ab ca 50 MIPS. Ich wuerde (und werde auch irgendwann demnaechst) 
vollstaendig auf ARM umsteigen ;)

von (prx) A. K. (prx)


Lesenswert?

Rumpelstilzchen Rumpel schrieb:

> Auf was würdet ihr umsteigen wenn es keine Atmegas mehr gäbe?

Für die Mega8-Klasse: PIC24. Darüber tendiere ich bereits jetzt zu 
STM32.

von Sven P. (Gast)


Lesenswert?

Wenn es stattdessen ähnlich brauchbare PIC gibt, ists mir relativ egal. 
Nur hätte ich gerne:
- freien C-Compiler (ok, verschmerzbar)
- freien Assembler
- aktuellen Befehlssatz, bei man nich alles durch ein W-Register prügeln 
muss...
- keine Speicherseiten.

von Benedikt K. (benedikt)


Lesenswert?

Das trifft alles auf die PIC24 zu. Die wären auch meine Wahl (bzw. sind 
es wenn die AVRs zu klein werden). Mit den ARMs konnte ich mich bisher 
nicht anfreunden, da ich nur selten echte Rechenleistung brauche, 
stattdessen eher schnelle IOs.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Naja, dann könnte man ja auch auf die MSP430 von TI umsteigen ...

Keine Harvard-Architektur, also kein "PROGMEM"-Geraffel, 
16-Bit-Architektur, stromsparend, sehr flexible Takterzeugung, kein 
Bedarf für "Baudratenquarze" dank flexibler UART-Baudratengeneratoren 
...

Recht brauchbare Dokumentation, einheitliche Peripherie (was bei einer 
Variante Timer_A heißt, und bei einer anderen auch so genannt wird, wird 
genauso programmiert), und mit mspgcc gibt's auch 'ne freie Toolchain.

JTAG ist auch mit spottbilligem Parallelportadapter möglich. Das 
Leitungen sparenden SpyBiWire allerdings nicht, das benötigt ein 
USB-JTAG-Interface wie das MSP-FET430UIF oder das EZ2013. Oder den 
Olimex-Nachbau.

Neuere Varianten wie der 'F5438 ermöglichen echte 16-Bit-Ports, d.h. mit 
einem einzigen Zugriff auf ein Portregister können 16 I/O-Leitungen 
gleichzeitig manipuliert werden.
Der '5438 hat obendrein ziemlich viele serielle Schnittstellen, damit 
lassen sich bis zu vier UARTs und gleichzeitig vier SPI- oder 
I2C-Schnittstellen betreiben.

Nachteil: Kein externer Speicherbus, daher nicht mehr als 16 kiB RAM 
möglich (das ist das derzeitige Maximum z.B. im 'F5438).

Weiterer Nachteil: Mit Ausnahme einiger sehr kleiner Varianten kein 
DIP-Gehäuse (nur bei 'F2013 und kleineren "Geschwistern", und dann auch 
nur 14polig).

Noch ein Nachteil: Wird im Einzelhandel zu Mondpreisen verkauft, neuere 
Varianten wie o.a. 'F5438 sind nur schwer zu bekommen. Auch Olimex kennt 
den nicht, stellt also keine Evaluation Boards her.

von (prx) A. K. (prx)


Lesenswert?

Genau diese Gründe haben mich daran gehindert, mit den MSP430er warm zu 
werden. Ich bin kein Freund von getrennten Adressräumen. Microchip hat 
das bei den PIC30 mit der ROM-Einblendung richtig gemacht, warum Atmel 
das sogar noch bei den XMegas verweigert ist mir ein Rätsel.

von Sven P. (Gast)


Lesenswert?

A. K. schrieb:
> Ich bin kein Freund von getrennten Adressräumen.
Laut Rufus hat der MSP das doch auch nicht ('Keine 
Harvard-Architektur').

> warum Atmel
> das sogar noch bei den XMegas verweigert ist mir ein Rätsel.
Beziehst du das jetzt auf die Adressräume oder auf die Möglichkeit, den 
Programmspeicher im Betrieb zu verändern?
Für letzteres sehe ich eigentlich bei som Kleinkram keinen Grund, könnte 
vielmehr zur Katastrophe werden :-)

von (prx) A. K. (prx)


Lesenswert?

Sven P. schrieb:

> Laut Rufus hat der MSP das doch auch nicht ('Keine
> Harvard-Architektur').

Eben. Die Architektur ist ungemein elegant. Was mich stört: siehe die 
übrigen Kommentare von Rufus. Und die fehlende 5V-Kompatibilität der 
Pins.

> Beziehst du das jetzt auf die Adressräume oder auf die Möglichkeit, den
> Programmspeicher im Betrieb zu verändern?

Die PIC30 (Familienbegriff für 24/30/33) haben zwar getrennte 
Adressräume, blenden aber 32KB ROM in den Datenadressraum ein. Damit ist 
der Zirkus mit verschiedenen Pointern für konstante und variable Daten 
vom Tisch und alle konstanten Daten liegen dort wo sie hingehören, im 
ROM.

Atmel hat mit den XMegas zwar das EEPROM eingeblendet und das könnte oft 
ausreichen (wenn man GCC dazu kriegt es für alle "const" Daten zu 
verwenden), aber es schwebt doch immer das Damoklesschwert "Platz" über 
einem. Die XMegas haben mich enttäuscht - auch die längst fällige 
atomare SP Manipulation fehlt noch immer. Gibt schlechtes Karma.

von Sven P. (Gast)


Lesenswert?

Joa, statt den 8bit-Kern so aufzublasen hätten sie m.M.n. lieber einen 
schicken 16bitter bauen sollen, quasi 16bit-AVR.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Die fehlende 5V-Kompatibilität mag ein Problem sein, aber andererseits 
ist es ja so, daß viele interessante Peripherie eh nur noch in 
3V-Technik vorliegt. Wenn ich mir die ganzen Diskussionen um 
Pegelwandler hier ansehe, die nur deswegen geführt werden, weil viele 
Leute nach wie vor an ihren 5V-Controllern festhalten, dann sehe ich das 
als nicht allzugroßes Defizit an. Sicher, 5V-tolerante Eingänge, wie 
sie Philips/NXP zumindest bei einigen der LPC2000-ARMe vorgesehen hat, 
wären nett gewesen.
Vielleicht aber benötigt die dann erforderliche Eingangsschaltung dann 
mehr Strom als die nicht-5V-tolerante; aber das ist nur eine sehr vage 
Vermutung.

Ein tatsächliches Manko ist die recht zurückhaltende Ausstattung mit 
RAM. Das ROM wurde bereits über die 64 kiB-Grenze gehievt (mit einer 
20-Bit-Adressraumerweiterung), was zumindest mit IAR und 
Rowley-Compilern angenehm transparent über die Bühne geht (ich nutze 
weder mspgcc noch CCE), aber maximal 16 kiB RAM sind halt manchmal zu 
wenig.

Ein Grund für die Entscheidung kann natürlich sein, daß bei den 
Geschwindigkeiten, mit denen der externe Speicherbus betrieben werden 
könnte/müsste, der Aspekt des Stromsparens etwas ins Hintertreffen käme. 
Moderne MSP430-Varianten können mit 25 MHz getaktet werden, und das wäre 
dann im Extremfall auch die Taktfrequenz des Speicherbusses.

RAMs mit 4 nsec Zykluszeit aber sind weder stromsparend noch besonders 
günstig; und ein 16-Bit Speicherinterface würde Pins bis zum Abwinken 
fressen. Ein pinsparender Adress/Datenbusmultiplex würde den Durchsatz 
reduzieren.

Denkbar wäre dann noch ein wirklich richtig schnelles SDRAM-Interface, 
aber das dürfte die Zielrichtung der MSP430 erst recht verfehlen.

von Benedikt K. (benedikt)


Lesenswert?

Rufus t. Firefly schrieb:

> Moderne MSP430-Varianten können mit 25 MHz getaktet werden, und das wäre
> dann im Extremfall auch die Taktfrequenz des Speicherbusses.
>
> RAMs mit 4 nsec Zykluszeit

Fehlt da nicht noch eine 0?
40ns RAMs sollten kein Problem sein zu bekommen.

von (prx) A. K. (prx)


Lesenswert?

Rufus t. Firefly schrieb:

> Die fehlende 5V-Kompatibilität mag ein Problem sein, aber andererseits
> ist es ja so, daß viele interessante Peripherie eh nur noch in
> 3V-Technik vorliegt.

Ok, CAN hat MSP m.W. sowieso nicht, aber mir ist's schon lieber, wenn 
RS485 und CAN Anschlüsse 5V abkönnen, denn 3,3V-Transceiver sind zwar 
verfügbar, aber vergleichsweise rar.

Bei Displays sieht es ähnlich aus. Die EA DOGs können 3,3V, der Rest 
will 5V. Zwar ist das was die Pegel angeht unproblematisch, jedenfalls 
bei R/W=0, und das bischen passiver Pullup im HD44780 stört nur im in 
diesem Zusammenhang eher unwahrscheinlichen Power-Down, aber um 
Mixbetrieb kommt man schlecht herum.

> als nicht allzugroßes Defizit an. Sicher, 5V-tolerante Eingänge, wie
> sie Philips/NXP zumindest bei einigen der LPC2000-ARMe vorgesehen hat,
> wären nett gewesen.

ST hatte sie bei den STR7 nicht. In späteren Versionen (STR9, STM32) 
dann doch. Wird vermutlich einen Grund haben.

> Vielleicht aber benötigt die dann erforderliche Eingangsschaltung dann
> mehr Strom als die nicht-5V-tolerante; aber das ist nur eine sehr vage
> Vermutung.

Wenn man es so versemmelt wie Luminary Micro, dann jedenfalls schon 
(excessive current).

> Denkbar wäre dann noch ein wirklich richtig schnelles SDRAM-Interface,
> aber das dürfte die Zielrichtung der MSP430 erst recht verfehlen.

Sind keine eierlegende Wollmilchsau und der Versuch wäre m.E. tödlich. 
Schon die 20-Bit Erweiterung ist eher schräg und zeigt vor allem, wo die 
Grenzen sind. Nö, es passt schon ganz gut, dass TI LM eingekauft hat, 
stopft das Loch oberhalb der MSPs.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Ich habe schon den ATMEGA, PIC24, STM32F103 und LPC2368 programmiert.

Alle haben Vorzüge (ausser ATMEGA).

Der größte Nachteil der PIC24 Reihe ist, dass die eingebaute Pheriperie 
von derivat zu derivat immer ein Tick anders ist. Nimmt man einen 
anderen, dann kann man sein Wissen über PIC24 weg werfen und das 
Datasheet neu studieren. (Das war bei Microchip schon immer so)

STM32F103 (ARM-Cortex M3 Kern) ist ein genial, schnelles und 
Stromsparendes Teil. Hat mich echt überzeigt. Kosten: Eclipse+GCC = 0 
EURO, Olimex JTAG 60 EUR.
Den STM gibt es bereits ab 48 Pins und ist untereinander komplett 
kompatiebel. Der Start-Up Code ist sogar in C geschrieben. Die IO-Pins 
sind mit allen Varianten konfigurierbar. STM liefert eine FW-Lib, die 
ist für alle STM32 Chips gleich -> ein mal lernen, vielmal einsetzen, 
das kann kein anderer CPU Lieferant!
Nachteil STM32: CAN Schnittstelle und USB lassen sich nicht gleichzeitig 
nutzen, dafür ist der Chip günstiger.

LPC2368 hat halt einen ARM7 Kern und braucht etwas mehr Strom als der 
STM32. Dafür hat der eine Ethernet-Schnittstelle und es gib jede Menge 
Demo-Codes. Sogar ein FAT Dateisystem für die MMC Card Schnittstelle. 
Programmierung geht ebenfalls mit Eclipse und dem gleichen Olimex JTAG.
Vorteil: Von NXP gibt es die LPC17xx reihe, die ist Pin-Kompatiebel mit 
dem LPC23xx, jedoch mit Cortex-M3 Kern. (Allerdings ohne 
MMC-Schnittstelle, leider)
Nachteil: CPU hat gleich mal 100 Pins.

Meine Meinung:
Als Hoppy-Bastler hat man nicht das nötige Kleingeld sich immer in eine 
neue CPU/Entwicklungsumgebung/Debugger usw. einzuarbeiten/anzuschaffen. 
Daher ist die kostenlose Umgebung sehr wichtig (Eclipse). Es kommt 
sicher die Zeit, wo man gerne mehr Power hätte oder einfach eine 
Funktion extra braucht. Also ein Pheriperiemodul, z.B. Timer, den mal 
als Encoder-Zähler mit irgend welchen Sonderfunktionen usw. bräuchte. In 
den dicken Chips (STM32 / LPC) sind echt gute Module integriert. Da gibt 
es kaum Einschränkungen.
Bei kleinen CPUs wird immer wieder an Funktionalität etwas eingespart, 
weil sich die Hersteller sagen, die ist nur für Mini Anwendungen 
ausgelegt.
Beispiel: Ich habe eine Tasten-Platine gebastelt mit 12 LEDs drauf. Jede 
einzelne kann ich ohne extra Hardware über 12 PWM Kanäle separat dimmen. 
Das geht nur mit einem STM32.
Ich empfehle den STM32 näher an zu schauen.

Der Lerneffekt:
In einer Firma hat man bedeutend mehr Chancen, wenn man einen ARM oder 
Cortex programmiert hat. Die 8-bit Hampelmänner kann ja jeder. Ausserdem 
ist es kein so großer Unterschied in C.

PS: die MSP430 sind nur dann interessant, wenn man ein mobiles Gerät wie 
z.B. ein Sender am Schlüsselbund bauen möchte, also extrem wenig Strom 
verbrauchen darf.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

>> RAMs mit 4 nsec Zykluszeit
>
> Fehlt da nicht noch eine 0?
> 40ns RAMs sollten kein Problem sein zu bekommen.

Argh. Ja, natürlich. Sonntag und so.

Trotzdem, wirklich sparsam sind auch welche mit 40 nsec Zykluszeit 
nicht.

> PS: die MSP430 sind nur dann interessant, wenn man ein mobiles Gerät wie
> z.B. ein Sender am Schlüsselbund bauen möchte, also extrem wenig Strom
> verbrauchen darf.

Ach, aufgrund der Schnittstellenvielfalt der neueren Modelle halte ich 
das für eine Fehleinschätzung. Sofern man mehr als reine 
8-Bit-Operationen durchführt, ist die Rechenleistung auch nicht zu 
verachten, 16-Bit-Operationen werden in einem Befehl durchgeführt und 
müssen nicht "von Hand" gebastelt werden. Hinzu kommt der "barrel 
shifter", der Schiebeoperationen um mehr als eine Stelle beschleunigt.

Naja, wenns um den Schwanzlängenvergleich geht, da hat TI ein Dokument 
vorbereitet, das sicherlich extrem unparteiisch ist:
http://focus.ti.com/lit/an/slaa205c/slaa205c.pdf

Kleinkram und mittleren Kleinkram erledige ich mit MSP430, für größere 
Aufgaben wird es dann wohl irgendein ARM werden, wenn's nicht gleich die 
Dose wird.

von Frank J. (rex_gildo-jr)


Lesenswert?

Moin!

> PS: die MSP430 sind nur dann interessant, wenn man ein mobiles Gerät wie
> z.B. ein Sender am Schlüsselbund bauen möchte, also extrem wenig Strom
> verbrauchen darf.

Das stimmt einfach nicht.

Ich habe eine komplette Messelektronik für einen Gaszählerprüfstand 
damit aus dem Boden gestampft. Inklusive Touchscreen und exzessiver 
Benutzung aller Timer und (fast aller) Schnittstellen ;)

Demnächst steht ein Produkt auf dem Smart Metering Segment an, wofür der 
MSP430 ja auch vorzüglich für geeignet ist.

Das einzige was mich stört ist, dass die Interrupt Prioritäten 
festgelegt sind. Da muss man bei Zeitkritischen Anwendungen schon bei 
der Hardware genau planen welche Interrupts benötigt werden.

Weiterhin ist natürlich störend, dass grade für den MSP430F5438  Lead 
Times von über 20 Wochen angegeben sind. Jetzt wo grade die erste 
Kleinserie fertig ist und erfolgreich beim ersten Kunden läuft ;)

Zum Glück gab es noch einen Distributor der bis Mitte Januar welche hat 
;)

Ich hoffe die Situation der Verfügbarkeit bessert sich.

Ist allerdings wohl bei allen Halbleiterherstellern so, dass Fabriken 
stillgelegt und Leute entlassen wurden. Ausserdem ist die Frage ob die 
Hersteller bei kurzfristigem Bedarf gleich wieder die Produktion 
hochfahren oder sogar eher daran interessiert sind den Markt knapp zu 
halten ;)

Gruß

Rex

von Peter D. (peda)


Lesenswert?

Mir sind die ATmega oftmals schon zu groß.

Ich nehme fast nur ATtiny25, 24, 261.

Wenns die nicht mehr gäbe, würde ich wieder die 8051-nehmen.
Z.B. NXP hat einige mit wenig Pins (P89LPC901).


Peter

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
Noch kein Account? Hier anmelden.