AVR Umstieg auf ??

Hallo alle zusammen!

Wir setzen seit längerem die ATmegas in einer Messgeräte-Serie ein. Nun hat sich in letzter Zeit leider eine gewisse Unzufriedenheit sowohl mit Atmel als auch der AVR-Serie im allgemeinen eingeschlichen:

- Immer wieder massive Lieferschwierigkeiten

- Second-Source nicht vorhanden

- Produkte werden kurzfristig wieder vom Markt genommen

- Angekündigte Produkte werden monatelang verzögert, z.B. der ATmega256

- Zu kleine Gehäuse, um alle Hardware-Features nutzen zu können

- Produkte mit höheren Taktfrequenzen nicht verfügbar

- Fehlende Features wie z.B. externes Memory-Interface >64kB

Wir werden wahrscheinlich für die nächste Produktgeneration auf einen anderen Lieferanten bzw. eine andere Microcontroller-Serie umsteigen. Da wir ein kleines Büro sind, sollte eine günstige Einstiegs-Entwicklungsumgebung (C-Compiler, RTOS, ICE) verfügbar sein (max. ca. 2000 EUR).

Was wäre denn zu empfehlen und wo liegen die Stärken und Schwächen?

Schönen Dank im voraus Georg

Reply to
Georg Meister
Loading thread data ...

Wenn Du diese Probleme umgehen willst, bleibt Dir eigentlich nur Standard-8051.

Ebendiese Eigenheiten trefen auch auf PIC's zu, also vergiss die schnell wieder, falls Du damit liebäugeln solltest.

Da gibt es so viele Alternativen, dass ich sie garnicht aufzählen mag. Alle haben ihre Vor- und Nachteile. Zähl doch mal bitte auf, was Dir wichtig ist. Bist Du bereit, etwas mehr Arbeit zu investieren, dafür aber einen Gnu Compiler verwenden zu können? Brauchst Du einen echten ICE, oder reichen Dir auch uC's mit eingebautem Debugger, die meist etwas eingeschränkt sind? Welche Rechenleistungen benötigst Du? Wieviel Speicher? Ist Dir Code Kompatibilität zwischen 8/16/32 Bit Typen wichtig? Welche Peripherie brauchst Du? Usw.

Reply to
Erik Hermann

Benötigt wird:

- 64 bis 256 kB Flash

- EEPROM 4 bis 8 kB

- SRAM >=512 kB eingebaut oder extern

- 4x 8 Bit Ports

- Self-Programming

- 2 UARTS

- mehrere Timer 16 Bit, PWM

- mehrere Typen mit unterschiedlichen Features, v.a. Anzahl Ports, Gehäusegrössen.

Also in etwa so wie die grösseren ATmegas + ein bißchen mehr Wenn wir schon auf eine neue Serie umsteigen, sollte da noch etwas Luft drinnen sein.

GNU hab ich mir vor längerer Zeit mal angesehen, war nicht so begeistert. Für den AVR verwenden wir den CodeVisionAVR-Compiler, der sehr einfach ist und gut funktioiniert.

Eingebauter Debugger hat bisher gereicht. Ein paar Breakpoints halt. Timer müssen stoppen, wenn das Programm steht. Debuggen auf Source-Level natürlich, Variablen anzeigen und evt. ändern. Trace-Buffer ist nicht notwendig.

Bisher sind wir mit den 16 MHz der ATmegas ausgekommen, für die neue Serie sollte die Rechenleistung 3-5x so gross sein, d.h. es sollte schon ein 16 oder 32-Bit Kernel sein mit 30-50 MHz. Floating-Point wird auch benötigt, evt. reicht Emulation.

s.o.

Programmiert wird ohnehin in C. Für den ganzen Hardware-spezifischen Teil wäre natürtlich günstig, wenn die I/O-Einheiten gleich oder ähnlich sind.

Schöne Grüsse, Georg

Reply to
Georg Meister

Ist das generell ein Problem bei Mikrocontrollern? Ich möchte mir ein Datenerfassungsystem bauen, das vorallem eines erfüllen muss: es soll eine größere Anzahl von Messwerten speichern können, weil die Anbindung an den Host langsam ist (RS-232).

Grundsätzlich würde ich schon gerne einen AVR verwenden, da ich damit schon Erfahrung habe und leistungsfähige Entwicklungswerkzeuge für mein OS (Linux) vorhanden sind.

Da das nur ein Hobbyprojekt ist, ist für mich die Liefersituation nebensächlich. Rechenleistung braucht das Teil auch nicht, da die Auswertung auf dem Hauptrechner gemacht wird. Es soll also nur die Messwerte sammeln, abspeichern und auf Abruf übertragen.

Abgefragt werden konkret ein bis vier AD-Umsetzer mit je ca. 100kS/sec. Die Auflösung ist noch nicht festgelegt, 8bit werden evtl. etwas knapp sein. Die Messzeit wird bis zu einer Sekunde betragen. Im worst case muss ich also mit ca. 800kB Daten rechnen, die ich zwischenspeichern muss. Als RAM will ich CMOS Speicher nehmen.

Für den Anfang reicht mir sicher auch eine kleinere Ausbaustufe, aber ich will nicht nach ein paar Monaten wieder was Neues bauen müssen. Das Ganze wird modular aufgebaut werden, also ein Bussystem, mit dem Controller und den AD-Umsetzern auf je einer eigenen, kleinen Platine.

Es gibt offenbar nur einen/wenige AVRs, die externes RAM unterstützen und dann auch nur max. 64kB. Eine Alternative wäre, mit Hilfe der IO Ports und etwas externer Logik den Speicher anzusprechen. Oder sollte ich davon Abstand nehmen und einen Controller verwenden, der das RAM direkt ansprechen kann? Wenn ja, was empfiehlt sich da?

Danke, Martin

Reply to
Martin Klaiber

trifft zu auf 16Bit-µC von Fujitsu:

- Leider kein Second-Source verfügbar, jedoch sitzt das Design-Center für µC in Deutschland -> kein Problem, dass Europa als nebensächlich erachtet wird.

- preislich absolut top

- C-Compiler kostenlos und gut

- Debugger

Reply to
Ralf Neuber

Martin Klaiber wrote: ... : Abgefragt werden konkret ein bis vier AD-Umsetzer mit je ca. 100kS/sec. : Die Aufloesung ist noch nicht festgelegt, 8bit werden evtl. etwas knapp : sein. Die Messzeit wird bis zu einer Sekunde betragen. Im worst case : muss ich also mit ca. 800kB Daten rechnen, die ich zwischenspeichern : muss. Als RAM will ich CMOS Speicher nehmen.

Mit USB2 und z.B einem Cypress FX2 Controller kannst Du die Daten diekt in den PC pumpen. Viele neue Laptops haben einen seriellen Eingang mehr.

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes

Martin Klaiber schrieb im Beitrag ...

Du hast ganz andere Anforderungen als Georg, der den klassischen Fehler bei kommerzieller Elektronikentwicklung gemacht hat, und Second Source, 'zu neuen und zu alte Teile meiden', ignoriert hat. Wie die de.sci.electronics FAQ:

formatting link
schreibt sind AVR und PIC fuer Hobbyisten durchaus geeignet.

Ein uC muss kein extra Speicherinterface haben, wenn Geschwindigkeit keine Rolle spielt und genuegend I/O-Pins frei sind (wenn nach serieller Schnittstelle und A/D-Eingaengen zu wenig I/O-Pins uebrig sind, steigt halt der Hardwareaufwand unsinnig an). Beim AVR macht das Speicherinterface eh Probleme, siehe FAQ, so das man den externen Speicher lieber langsam in Software bedient. Insofern nimm einen 40-Pin AVR, 24 Pins fuer Speicher, 1 Pin A/D, 2 Pins fuer seriell, bleibt noch was uebrig. Bei mehr Speicher oder mehr A/D kann ein externes Adresslatch zum Speicher dazukommen.

Es gibt auch die beruehmte AN417 von Philips, in der externe 256k dyn RAM an einem 80C51 angeschlossen werden, die wohl noch auf deren WebServer liegt, aber nicht mehr verlinkt ist. Die machen das per Software, was sich sicher auf den AVR umschreiben laesst. Allerdings ist der uC in der Programmhauptschleife mit Refresh beschaeftigt.

Natuerlich kannst du auch einen 68HC11 (nur 8 bit A/D aber seriell und Speicherinterface eingebaut und selbst 512 byte Programmspeicher reichen gerade aus) oder 8051 (T89C51 von Atmel/Temic, bei Reichelt, hat 10 bit A/D) oder PIC oder M16 oder sonstwas nehmen, aber wenn du fuer AVR schon alles zusammen hast...

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Reply to
MaWin

Uwe Bonnes wrote in news:btefrr$j3g$ snipped-for-privacy@news.tu-darmstadt.de:

Per SPI-Bus in eine MMC Karte speichern. Der MMC-Bus ist sehr ähnlich zu SPI bzw. es gibt auch MMC Karten die direkt mit SPI funktionieren. Die Schreibgeschwindigkeit von vielleicht 1MB/s oder mehr, sollte für deinen Zweck noch ausreichen. Volle Spez hier:

formatting link
Einziger Mehraufwand wäre die Implementierung von FAT32, falls du das direkt mit einem PC-Reader auslesen willst, ansonsten kannst du natuerlich einfach raw-linear die Daten abspeichern.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

"Georg Meister" wrote in news:bte7jp$643uc$1@ID-

14890.news.uni-berlin.de:

Vielleicht wird ja mal die LPC2100 Familie von Philips da recht interessant. Ist ein ARM7, also gibt es schon viele etablierte Entwicklungsumgebungen und das bei uC's fast unmögliche second source ist dann in der Zukunft vielleicht auch nicht mehr ganz so problemlos. Wenn schon nicht pinkompatibel kann man vielleicht mit einer kleinen Layoutänderung wenigstens die Firmware auf den neuen Prozessor problemloser übernehmen. Besonders interessant ist auch der niedrige Preis, da (bisher) nur einfache - etablierte - Gehäuse verwendet werden.

Zur Zeit gibt es nur die LPC2104-6 mit 128kFlash, 64k RAM intern, aber neuere Typen stehen schon kurz vor der Geburt. Die Teile haben 54MIPS bei 60MHz Takt und nur 30mA Stromaufnahme (3.3V und 1.8V).

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Nur bei den alten AT90S.

Reply to
Andreas Schwarz

Leider will die MMCA bei Multimediacards Lizenzkosten sehen...

Reply to
Andreas Schwarz

Andreas Schwarz schrieb im Beitrag ...

Inwiefern ? Macht es bei ATmegas keine Probleme mehr, oder haben die keins mehr ?

-- Manfred Winterhoff, reply-to invalid, use mawin at despammed.com homepage:

formatting link
de.sci.electronics FAQ:
formatting link
Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Reply to
MaWin

Martin Klaiber schrieb:

Siehe AVR Butterfly: dort ist ein dataflash via SPI angeklemmt.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc
Reply to
Joerg Wunsch

Andreas Schwarz schrieb:

Martin wollte das doch nur für ein Hobbyprojekt. Georg war das mit dem Serienprodukt.

Gruß Henning

--
henning paul home:  http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
Reply to
Henning Paul

"MaWin" wrote in news:01c3d45f$ef766040$69e3b8d9@amdk6-300:

Naja leider ist das Problem bei dynamischen Rams dieser Größe, das die kaum noch zu bekommen sind.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Andreas Schwarz wrote in news: snipped-for-privacy@213-203-244-47.kunde.vdserver.de:

Ja anscheinend leider, und wie teuer ist dann so eine Lizenz? Für FAT32 will ja auch M$soft Geld sehen. Stellt sich aber die Frage, ob sich das für die - bei kleinen Stückzahlen - überhaupt rechnet (und Bastler interessiert das wohl gar nicht).

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Vielleicht auf den ersten Blick nicht offensichtlich, aber was Du suchst ist ein ARM7.

Reply to
jetmarc

"MaWin" wrote in news:01c3d45f$ef766040$69e3b8d9@amdk6-300:

Mhh, "second source" bei Mikrocontrollern. Gibt es da überhaupt welche? (Mal die Uralt 8051 40 pin-DIP's ausgenommen). Man kann imho da nur auf solche Hersteller setzen, die regelmässig und zuverlässig liefern. Ganz auf der Negativ-Liste stehen bei mir Motorola (da gab es doch mal einen 68HC05 nicht, weil der in einem Gameboy verwendet wurde?), Maxim (zuviele Chips, die eigentlich fast alle dasselbe machen) und auch Atmel (siehe diese Posting ;-), Philips (die schnelle Auflösung der XA51 Familie). Positive sind selten; vielleicht TI und Linear, Analog Devices; bei Siemens wundert mich, das die 80535 usw Familien noch im Programm sind; naja.... Man kann auch noch auf solche Chips setzen, die bei vielen Distributoren gelistet sind; da ist sind dann die Lagerbestände insgesamt größer um "Löcher" zu überbrücken.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.
Reply to
Matthias Weingart

Matthias Weingart schrieb im Beitrag ...

Du wolltest sagen, das man sie nicht kaufen kann, sondern aus dem Keller holen muss, oder ?

-- Manfred Winterhoff, reply-to invalid, use mawin at despammed.com homepage:

formatting link
de.sci.electronics FAQ:
formatting link
Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Reply to
MaWin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.