AVR Umstieg auf ??

[Georg Meister]

Vielen Dank für die Beiträge. Sind recht interessante Typen dabei, die es
noch zu studieren gilt.

Die 8051 habe ich allerdings gleich verworfen, obwohl es inzwischen auch
schnellere Versionen ohne den seltsamen 12er-Takt gibt. Der Grund ist, das
wir vor Jahren unsere Produktserie mit einem 8051-Derivat begonnen haben.
Aus dieser Zeit ist mir in qualvoller Erinnerung, dass wir uns in
wochenlanger Arbeit mit mit handgestricktem Assembler herumgeschlagen haben,
um eine _minimale_ Performance zu erreichen, bevor wir dann endlich den
Prozessor auf den Müll geworfen haben. Mir ist schleierhaft, wieso in Zeiten
von 0.12 um Prozessen und 100 Mio Transistor-Chips immer noch so viele
Halbleiterhersteller dieses elende Prozessordesign, technischer Stand 1980,
nicht nur im Programm haben, sondern sogar neue Chips damit entwerfen.
Soviele Aquariumtimer kann die Welt nicht brauchen und was anderes kann man
damit nicht bauen.

Aus den ganzen Vorschlägen hat sich bisher für mich der ARM7
herauskristallisiert, der anscheinend sowas wie ein de-facto-Standard im
16/32-Bit Segment ist. Die Prozessorfamilie hat ausreichende
Leistungsreserven und wird von mehreren Firmen mit teilweise beeindruckender
Peripherie geliefert, allerdings hat jede Firma wieder ihr eigenes Konzept.

Bleibt noch die Entwicklungsumgebung zu klären und inwieweit verschiedenene
Typen unterstützt werden.

Georg

 

[Ralf Neuber]

HC12 ist nicht schlecht, aber ich habe von früher her Vorurteile gegen
Motorola bekommen(mieser Support...) + somit sind die für mich derzeit nicht
in. Aber wenn du zufrieden bist -> ich bin erfreut, dass auch ein
Megakonzern wie Motorola aus Fehlern gelernt hat ;-)

Schönen Abend!
Ralf

 

[Oliver Betz]

"Ralf Neuber" <Ralf.Neuber_SCHEISSSPAM@gmx.de> schrieb:

HC12 ist nicht schlecht, aber ich habe von früher her Vorurteile gegen
Motorola bekommen(mieser Support...) + somit sind die für mich derzeit nicht
in. Aber wenn du zufrieden bist -> ich bin erfreut, dass auch ein
Megakonzern wie Motorola aus Fehlern gelernt hat ;-)

es bessert sich etwas, es gibt erträglichen direkten Online-Support
und eine gut funktionierende "Community" (die Mailinglisten).

Als kleiner Fisch (wir gehören zu der Kategorie) hat man aber immer
noch gelegentlich Probleme.

Aber das In-System-Debugging des HC(S)12 ist großartig, und die
Rechenleistung ordentlich, z.B. FP-Division in <10us.

Servus

Oliver
--
Oliver Betz, Muenchen

 

[Oliver Betz]

"MaWin" <me@privacy.net> schrieb:

[...]

(Es gab wohl bei Motorola 2 konkurrierende Fraktionen. Die die den
68HC11 und erfogreichen 68HC05 designten, und die durchgeknallten
Superklugen, die mit 68HC16 und 68HC12 Schiffbruch erlitten.)

Im Gegensatz zum HC16 ist der HC(S)12 erfolgreich.

Servus

Oliver
--
Oliver Betz, Muenchen

 

[Aguja]

- 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

*Diese* Probleme können bei allen Herstellern auftreten; vor allem das
mit dem Second Source.

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

Also mir haben die uC's meist ein zu großes Gehäuse...

- Produkte mit höheren Taktfrequenzen nicht verfügbar
- Fehlende Features wie z.B. externes Memory-Interface >64kB

.... aber Dir würde ich raten den Fujitsu-uC bei Glyn anzuschauen!

cu,

Aguja

::Update:: www.PROuC.de ==> Free AVR-, PIC- & 8051-Programmers, Apps & Tips

 

[Martin Klaiber]

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

Welche Geschwindikgeit brauchst du? (I2C per Software wird wohl
etwas langsamer als 1MBit/s werden oder du hats eine I2C unit onchip)

Wie gesagt: bis zu vier ADC mit ca. 100kHz Abtastrate. Die Bitbreite
ist noch nicht festgelegt, aber 8bit ist schon etwas knapp. Also zwei
Byte vorsehen. Sicherheitshalber plane ich noch einen DAC mit den
gleichen Daten ein, vielleicht brauche ich ihn mal.

Das wären dann also maximal 1MByte Daten je Sekunde, die gesichert
werden müssen. Aber mehr als eine Sekunde Messdauer werde ich auch
nie haben.

Die DataFlash-Bausteine von Atmel können IIRC mit bis zu 20Mbit/s
beschrieben werden (ich hoffe, ich habe das Datenblatt richtig in
Erinnerung). Mal hören, was Atmel zu der Anzahl der maximalen
Schreibzyklen sagt.

Das Gerät brauche ich nur hin und wieder für akustische Messungen. Ich
denke, wenn ich mit bis zu 250 Messungen pro Jahr rechne (10 Messungen
pro Tag an 5 Tagen im Monat über 5 Monate) sollte ich auf der sicheren
Seite liegen. Jede Messung benötigt bis zu 4096 Schreibzyklen, wenn ich
es richtig verstanden habe, wären also etwa 1Mio pro Jahr. Vielleicht
reichen die Schreibzyklen der DataFlashs ja für meine Zwecke, das wäre
dann vermutlich die einfachste Lösung.

Martin

 

[Matthias Weingart]

Martin Klaiber <martinkl@zedat.fu-berlin.de> wrote in
news:49ntc1-bk2.ln1@martinkl.dialup.fu-berlin.de:

Die von Matthias empfohlenen FRAMs gibt's leider nur bis maximal
256kB, und mehrere Bausteine kaskadieren geht wohl nicht, oder?

Doch I2C, da kannst du 8 Stück an einen Bus hängen und denen
über 3-Adresspins Adressen geben.

Welche Geschwindikgeit brauchst du? (I2C per Software wird wohl
etwas langsamer als 1MBit/s werden oder du hats eine I2C unit onchip)

Es gibt wohl noch serielle Rams, die für Diktiergeräte
vorgesehen sind; allerdings auch fraglich wielange und ob überhaupt
;-(.

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Matthias Weingart]

Martin Klaiber <martinkl@zedat.fu-berlin.de> wrote in
news:kvguc1-4si.ln1@martinkl.dialup.fu-berlin.de:

Das wären dann also maximal 1MByte Daten je Sekunde, die gesichert
werden müssen. Aber mehr als eine Sekunde Messdauer werde ich auch
nie haben.

Da sind die Frams dann zu langsam.

M.


--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Erik Hermann]

Oliver Betz wrote:

Eines der Argumente, weshalb ich immer noch beim HC(S)12 bleibe, ist
der leistungsfähige "Background Debug Mode", der Zugriff auf den

Wir setzen auch immer noch den in die Jahre gekommenen HC812A4 ein.
Demnächst wohl was grösseres vom Motorola.

 

[Erik Hermann]

Georg Meister wrote:

Prozessor auf den Müll geworfen haben. Mir ist schleierhaft, wieso in Zeiten
von 0.12 um Prozessen und 100 Mio Transistor-Chips immer noch so viele
Halbleiterhersteller dieses elende Prozessordesign, technischer Stand 1980,
nicht nur im Programm haben, sondern sogar neue Chips damit entwerfen.

1. das Copyright ist ausgelaufen und deshalb darf jeder 8051 nachbauen
2. das Design ist so alt, dass inzwischen auch die letzten esoterischen
Fehler ausgemerzt sind. Für sicherheitsrelevante Systeme interessant
3. jeder kennt's und hat einen Compiler in der Schublade liegen
4. in vielen Firmen riesige Codebasis und Erfahrung vorhanden
5. für viele Sachen voll ausreichend (z.B. intelligenter ADC)
6. es gibt auch sehr performante Typen, z.B. von Dallas und Cygnal

 

[Joerg Wunsch]

Martin Klaiber <martinkl@zedat.fu-berlin.de> schrieb:

In der Appnote steht was, das man nach 10000 Operationen der einen Art
dann ein komplettes page erase/rewrite machen müsse.

Hm, wenn ich einen 1MB-Chip mit einer Seitengröße von 256Byte komplett
beschreibe, habe ich also schon 4096 Operationen durchgeführt?

Nö, das bezog sich immer auf eine Page oder einen Sektor oder sowas.
Muttu nochmal genau nachlesen. Die Bemerkung mit den 10000
Operationen in der Appnote hat mich nur aufhorchen lassen,
möglicherweise haben sie so eine Art ,,Formatierung'' für ihre Zellen,
die nach dem normalen Reprogrammier-`wear out' dann den Speicher
komplett auf jungfräulich zurücksetzen kann oder was in der Art.

--
Jörg Wunsch

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

 

[Holger Veit]

Oliver Betz <OBetz@despammed.com> wrote:

"MaWin" <me@privacy.net> schrieb:

[...]

(Es gab wohl bei Motorola 2 konkurrierende Fraktionen. Die die den
68HC11 und erfogreichen 68HC05 designten, und die durchgeknallten
Superklugen, die mit 68HC16 und 68HC12 Schiffbruch erlitten.)

Im Gegensatz zum HC16 ist der HC(S)12 erfolgreich.

Wobei ich mich bei der kranken Memory-Management-Architektur des 12ers
immer wieder frage, warum. Der 11er haette ein schoene 09-Nachfolger
werden koennen, genau wie der 12er; die MMU-Funktion, in Verbindung mit

64K RAM des letzteren hoerte sich, ohne ins Datenblatt zu sehen,
vielversprechend an - nach dem Lesen des Datenblattes blieb da nur

noch ein vermurkstes Hardwarekonzept fuer Spezialfaelle uebrig. Bleibt,
wenn man einen "echten" Computer[1] im Motorola-Style (im Ggs. zur
8080/Z80/x86-Architektur) basteln will, ausser einem 68k nur noch
der HC16 oder auch der WD65816 (ein aufgebohrter 65xx - halbwegs noch
"Motorolalich") uebrig.

Holger

[1] kein embedded single chip system, sondern ein Teil im Stil der
8bit-HoCos der 80er Jahre, die man tatsaechlich noch bis zum letzten
NAND-Gatter selbst aufbauen und verstehen konnte - sowas fehlt leider
heutzutage (siehe auch Kosmos-Digital-Computer-Thread)

 

[Erik Hermann]

Aguja wrote:

Also mir haben die uC's meist ein zu großes Gehäuse...

Schau mal bei Cygnal nach...

... aber Dir würde ich raten den Fujitsu-uC bei Glyn anzuschauen!

Kann ich auch empfehlen. Sind preiswert und gut. Vor allem der
kostenlose professionelle Compiler ist ein Argument.
Allerdings sind die M16C auch nicht schlecht.

Bei den 16 und 32 bittern findet man jede menge Features, die
fast alle 8 Bitter vermissen lassen und von denen man garnicht
wusste dass man sie braucht. Ich denke da z.B. an DMA, Hardware-
multiplikation und Interrupts mit programmierbarer Priorität.
Schaur man sich dann die Gesamtperformance eines 16Bit 12MHz Cisc
Systems mit DMA, komfortabler Peripherie und linearem Speicher
an, dann fragt man sich warum man jemals einen 8Bit 32MHz RISC
(der auch nicht viel billiger ist) für schnell gehalten hat.

 

[MaWin]

Holger Veit <veit@ct-mail.citytraffic.de> schrieb im Beitrag <slrnbvqcqd.6o.veit@ct-poel.ct-net>...

ein Teil im Stil der
8bit-HoCos der 80er Jahre, die man tatsaechlich noch bis zum letzten
NAND-Gatter selbst aufbauen und verstehen konnte - sowas fehlt leider
heutzutage (siehe auch Kosmos-Digital-Computer-Thread)

Warum ? Gibt's doch reichlich:

http://www.homebrewcpu.com/
http://www.cs.uiowa.edu/~jones/arch/risc/
http://www.vttoth.com/vicproc.htm
(und vieles auf ePanorama)
--
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.

 

[Holger Veit]

MaWin <me@privacy.net> wrote:

Holger Veit <veit@ct-mail.citytraffic.de> schrieb im Beitrag <slrnbvqcqd.6o.veit@ct-poel.ct-net>...

ein Teil im Stil der
8bit-HoCos der 80er Jahre, die man tatsaechlich noch bis zum letzten
NAND-Gatter selbst aufbauen und verstehen konnte - sowas fehlt leider
heutzutage (siehe auch Kosmos-Digital-Computer-Thread)

Warum ? Gibt's doch reichlich:
http://www.homebrewcpu.com/
http://www.cs.uiowa.edu/~jones/arch/risc/
http://www.vttoth.com/vicproc.htm
(und vieles auf ePanorama)

*Ich* weiss. Allerdings hoeren die meisten dieser Teile dann auf, wenn
es um mehr als das uebliche 5-Chip-System CPU-EPROM-RAM-UART-PIO geht -
selbst die obligatorischen LS245/LS241 fuer die Daten- und Adressbus-
Pufferung entfaellt. Da doch schon lieber bei Mike Holley vorbeisehen,
auch wenn das Teil anderweitig nicht mehr so leicht nachbaubar ist.

Es geht allerdings nicht darum, ueberhaupt irgendwelche Schaltungen zu
finden, sondern ueberhaupt nachbausichere und verstaendliche[1]
Konstruktionen, bei denen nicht nur das Laden von Software oder das
Anstoepseln eines Netzteilsteckers im Vorderfrund steht. Das Basteln an
Computern (wenn man das Kartentauschen oder CD-Brenner-Einbauen in PCs
nicht dazurechnet) beschraenkt sich auf das Anflanschen irgendeiner
sinnfreien Warze an den Centronics-Port oder neuerlich eines monolithischen
USB-Controllers mit n-Bit-I/O an den USB-Stecker.

Holger

[1] nachbausicher:
1. Es kommen keine Gurkenchips vor, die der Entwickler noch aus dem
Jahre 1970 in der Schublade hatte
2. Man muss nicht als "Bootstrap" erst mal einen EPROM-Programmierer,
GAL-Programmer oder ein CPLD-Entwicklungssystem haben - ein
erforderlicher Riesen-Messgeraete- oder Werkzeugpark schreckt ab.
3. Die Schaltung sollte schon ein wenig professioneller designed sein
als viele der Bastelprojekte: Verzicht auf Pufferkondensatoren
zwischen Vcc/GND, Netzteil am unteren Limit, Spannungsversorgung
aus RS-232-Schnittstelle, froehliches Mixen von LS, S, AC, HCT, CD40,
je nachdem, was man gerade so zur Hand hatte, Nichtbeachten des
TTL-Fanouts, Offenlassen unbenutzter Eingaenge, ... (AoE lesen hilft
manchmal, aber Lesen ist ja out)
verstaendlich:
1. BIOS-Programm nicht nur als Binary oder Hexdump
2. Datenblaetter der verwendeten Schaltungen
3. Bezugsquellen (zumindest halbwegs aktuell, es werden ja immer wieder
Teile abgekuendigt)
4. Funktionsbeschreibung, zumindest Liste der I/O-Adressen

 

[Alfred Jäger]

Matthias Weingart wrote:

Doch I2C, da kannst du 8 Stück an einen Bus hängen und denen
über 3-Adresspins Adressen geben.

Bringt aber auch nix: mehr als 256kB gehen nicht. Die größeren Chips haben
weniger Adressleitungen (kannst mal bei Atmel reinschauen).
Anzahl der Progammierungen zählen: ich vermute, daß die interne
Bankaufteilung mit reinspielt, bei den größeren müssen zum Teil immer 8 Bytes
auf einmal geschrieben werden.

Gruß, ALF

 

[Martin Klaiber]

Joerg Wunsch <j@ida.interface-business.de> wrote:

Martin Klaiber <martinkl@zedat.fu-berlin.de> schrieb:

Hm, wenn ich einen 1MB-Chip mit einer Seitengröße von 256Byte komplett
beschreibe, habe ich also schon 4096 Operationen durchgeführt?

Nö, das bezog sich immer auf eine Page oder einen Sektor oder sowas.
Muttu nochmal genau nachlesen.

Beim Nachlesen und Nachdenken ist mir klargeworden, dass das Ganze vom
Timing her so überhaupt nicht hinhauen kann. Ich muss die Daten mit
bis zu 8Mbit/s in's Dataflash schicken. Ok, es ist mit bis zu 20Mbit/s
spezifiziert, aber die AVRs können offenbar den SPI-Ausgang mit max.
der halben Oszillatorfrequenz takten, das wären also genau diese 8MHz.
Aber dann habe ich nur die reinen Nutzdaten übertragen, ich muss dem
DataFlash ja aber auch Adressen, usw. schicken. Also geht's so nicht.

Am Sinnvollsten erscheint mir derzeit, jedem ADC seinen eigenen 256kB
PufferRAM zu spendieren und beide starr zu verkoppeln. Der Beginn der
Messung startet auch einen Adresszähler und der ADC schreibt so ohne
Zutun von außen das RAM voll. Zum Abholen der Daten kann ich ja dann
wieder einen AVR nehmen, dabei ist das Timing nicht kritisch.

Die Bemerkung mit den 10000 Operationen in der Appnote hat mich nur
aufhorchen lassen, möglicherweise haben sie so eine Art
,,Formatierung'' für ihre Zellen, die nach dem normalen
Reprogrammier-`wear out' dann den Speicher komplett auf jungfräulich
zurücksetzen kann oder was in der Art.

Ich habe den Absatz inzwischen gefunden:

Each page within a sector must be updated/rewritten at least once
within every 10,000 cumulative page erase/program operations in
that sector.

Hm, verstehe ich auch nicht. Hört sich für mich wie eine Art Refresh
an. Das Ganze gehört zum Auto-Page-Rewrite-Mode:

AUTO PAGE REWRITE: This mode is only needed if multiple bytes within
a page or multiple pages of data are modified in a random fashion.

Damit kann man automatisch pages in den SRAM-Puffer und wieder auf die
gleiche Adresse zurückschreiben lassen. Ich frage mich allerdings,
wozu das gut sein soll. Atmel hat sich übrigens noch nicht gemeldet,
aber mit den Dataflashs wird das bei mir vermutlich sowieso nicht
klappen.

Martin

 

[Michael Eggert]

On Thu, 8 Jan 2004 18:48:14 +0100, Martin Klaiber
<martinkl@zedat.fu-berlin.de> wrote:

Hi!

Beim Nachlesen und Nachdenken ist mir klargeworden, dass das Ganze vom
Timing her so überhaupt nicht hinhauen kann. Ich muss die Daten mit
bis zu 8Mbit/s in's Dataflash schicken.
[...]
Am Sinnvollsten erscheint mir derzeit, jedem ADC seinen eigenen 256kB
PufferRAM zu spendieren und beide starr zu verkoppeln. Der Beginn der
Messung startet auch einen Adresszähler und der ADC schreibt so ohne
Zutun von außen das RAM voll. Zum Abholen der Daten kann ich ja dann
wieder einen AVR nehmen, dabei ist das Timing nicht kritisch.

Hab ichs doch gerochen

Kannst natürlich auch nur _ein_ RAM nehmen und die unteren
Adressleitungen per Decoder auf die output enables der Wandler (bzw
latches, damit die Wandler wieder wandeln können) geben.

Gruß,
Michael.

 

[Oliver Betz]

Holger Veit <veit@ct-mail.citytraffic.de> schrieb:

[...]

(Es gab wohl bei Motorola 2 konkurrierende Fraktionen. Die die den
68HC11 und erfogreichen 68HC05 designten, und die durchgeknallten
Superklugen, die mit 68HC16 und 68HC12 Schiffbruch erlitten.)

Im Gegensatz zum HC16 ist der HC(S)12 erfolgreich.

Wobei ich mich bei der kranken Memory-Management-Architektur des 12ers
immer wieder frage, warum. Der 11er haette ein schoene 09-Nachfolger

Ack, das ist kompletter Blödsinn. Meine Anwendungen kommen bis jetzt
aber mit 64K Adressbereich aus, von daher kein Problem.

Servus

Oliver
--
Oliver Betz, Muenchen

 

[Matthias Weingart]

Martin Klaiber <martinkl@zedat.fu-berlin.de> wrote in
news:unh0d1-153.ln1@martinkl.dialup.fu-berlin.de:

Ich habe den Absatz inzwischen gefunden:

Each page within a sector must be updated/rewritten at least
once within every 10,000 cumulative page erase/program
operations in that sector.

Hm, verstehe ich auch nicht. Hört sich für mich wie eine Art
Refresh an. Das Ganze gehört zum Auto-Page-Rewrite-Mode:

AUTO PAGE REWRITE: This mode is only needed if multiple bytes
within a page or multiple pages of data are modified in a
random fashion.

Damit kann man automatisch pages in den SRAM-Puffer und wieder auf
die gleiche Adresse zurückschreiben lassen. Ich frage mich
allerdings, wozu das gut sein soll. Atmel hat sich übrigens noch
nicht gemeldet,

Vielleicht müssen ja die Inhalte "alle paar Jahre" mal wieder neu
"reingebrannt" werden? Die Beschreibung klingt fast wie ein DRAM.
Oder da werden die Ausleseschwellwerte für die Speicherzellen neu
kalibriert? Naja jeder Digitalspeicher ist ja eigentlich
ein Analogspeicher ...

Btw. deine Speed ist von einem Controller nicht zu schaffen.
Wie du schon sagst, per Hardware zu puffern, also ADC->RAM per
hartverdrahtete Logik (und Zähler) gesteuert (z.B. PLD).
Vielleicht helfen ja FIFO-RAM's (obwohl die dann eigentlich schon
wieder "zu schnell" und recht teuer sind. Willst du die Daten sofort
zum PC senden (ist der immer angeschlossen?). Dann gleich aus dem FIFO
per Cypress FX2 (USB2) und dessen DMA auf den PC "rüberschieben".
Leider ist das nicht kontinuierlich (immer in Blöcken von 64 bytes),
und der Rechner blockiert auch öfters mal (hoffentlich <100ms, hängt
sehr von der Qualität der installierten (windows-)Treiber ab), aber
damit ist dann nicht mehr soviel Puffer (1s) nötig.

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.