AVR Umstieg auf ??

G

Georg Meister

Guest
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
 
Georg Meister wrote:
- Immer wieder massive Lieferschwierigkeiten
- Second-Source nicht vorhanden
Click to expand...
Wenn Du diese Probleme umgehen willst, bleibt Dir eigentlich
nur Standard-8051.

- 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
Click to expand...
Ebendiese Eigenheiten trefen auch auf PIC's zu, also vergiss die
schnell wieder, falls Du damit liebäugeln solltest.

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).
Click to expand...
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.
 
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.
Click to expand...
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.

Bist Du bereit, etwas mehr Arbeit zu investieren, dafür aber einen
Gnu Compiler verwenden zu können?
Click to expand...
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.

Brauchst Du einen echten ICE, oder reichen Dir auch uC's mit
eingebautem Debugger, die meist etwas eingeschränkt sind?
Click to expand...
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.

Welche Rechenleistungen benötigst Du?
Click to expand...
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.

Wieviel Speicher?
Welche Peripherie brauchst Du?
Usw.
Click to expand...
s.o.

Ist Dir Code Kompatibilität zwischen 8/16/32 Bit Typen wichtig?
Click to expand...
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
 
Georg Meister wrote:
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.
Click to expand...
TLCS oder M16/32?

Robert
 
Erik Hermann <erikhermann@amacando.de> wrote:
Georg Meister wrote:

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

Ebendiese Eigenheiten trefen auch auf PIC's zu, also vergiss die
schnell wieder, falls Du damit liebäugeln solltest.
Click to expand...
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
 
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.
Click to expand...
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 <600Euro (http://www.accemic.de)

Versuche einmal ein Einsteigerseminar, z.B. bei http://www.glyn.de, da
erfolgt ein guter Einstieg in die Familie, was gerade für evt. Umsteiger
sehr angenehm ist.

mfg
Ralf
 
Martin Klaiber <martinkl@zedat.fu-berlin.de> schrieb im Beitrag <pjqqc1-9o1.ln1@martinkl.dialup.fu-berlin.de>...
Ebendiese Eigenheiten trefen auch auf PIC's zu, also vergiss die
schnell wieder, falls Du damit liebäugeln solltest.

Ist das generell ein Problem bei Mikrocontrollern?
Click to expand...
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: http://dse-faq.elektronik-kompendium.de/
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.
 
Matthias Weingart wrote:
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in
news:btefrr$j3g$1@news.tu-darmstadt.de:

Martin Klaiber <martinkl@zedat.fu-berlin.de> 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.

Per SPI-Bus in eine MMC Karte speichern.
Click to expand...
Leider will die MMCA bei Multimediacards Lizenzkosten sehen...
 
Martin Klaiber <martinkl@zedat.fu-berlin.de> 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 ----------
 
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in
news:btefrr$j3g$1@news.tu-darmstadt.de:

Martin Klaiber <martinkl@zedat.fu-berlin.de> 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.
Click to expand...
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:
http://www.sandisk.com/oem/mmc.asp
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.
 
"Georg Meister" <georg.meister@gmx.at> wrote in news:bte7jp$643uc$1@ID-
14890.news.uni-berlin.de:

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.
Click to expand...
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.
 
Andreas Schwarz <usenet@andreas-s.net> schrieb im Beitrag <slrnbvlj38.sm4.usenet@213-203-244-47.kunde.vdserver.de>...
Nur bei den alten AT90S.

Inwiefern ?
Click to expand...
Macht es bei ATmegas keine Probleme mehr,
oder haben die keins mehr ?
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
Andreas Schwarz schrieb:

Per SPI-Bus in eine MMC Karte speichern.

Leider will die MMCA bei Multimediacards Lizenzkosten sehen...
Click to expand...
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
 
- 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
Click to expand...
Vielleicht auf den ersten Blick nicht offensichtlich, aber was
Du suchst ist ein ARM7.
 
Martin Klaiber <martinkl@zedat.fu-berlin.de> schrieb:

Es gibt offenbar nur einen/wenige AVRs, die externes RAM unterstützen
und dann auch nur max. 64kB.
Click to expand...
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
 
"Ralf Neuber" <Ralf.Neuber_SCHEISSSPAM@gmx.de> schrieb:

[16Bit-ľC von Fujitsu]
- preislich absolut top
Click to expand...
hast Du ein Beispiel?

- C-Compiler kostenlos und gut

- Debugger <600Euro (http://www.accemic.de)
Click to expand...
gibt's da "Background"-Zugriff auf Speicher und Breakpoint-Register,
also während das Programm ausgeführt wird?

Servus

Oliver
--
Oliver Betz, Muenchen
 
Matthias Weingart <mwnews@pentax.boerde.de> schrieb im Beitrag <Xns9468AFF8348D8AlwLookOnTBrightSide@212.21.75.70>...
Naja leider ist das Problem bei dynamischen Rams dieser Größe, das die
kaum noch zu bekommen sind.

Du wolltest sagen,
Click to expand...
das man sie nicht kaufen kann,
sondern aus dem Keller holen muss,
oder ?
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
"MaWin" <me@privacy.net> wrote in
news:01c3d45f$ef766040$69e3b8d9@amdk6-300:

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.
Click to expand...
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.
 
Andreas Schwarz <usenet@andreas-s.net> wrote in
news:slrnbvljai.sm4.usenet@213-203-244-47.kunde.vdserver.de:

Matthias Weingart wrote:
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in
news:btefrr$j3g$1@news.tu-darmstadt.de:

Martin Klaiber <martinkl@zedat.fu-berlin.de> 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.

Per SPI-Bus in eine MMC Karte speichern.

Leider will die MMCA bei Multimediacards Lizenzkosten sehen...
Click to expand...
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.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top