AVR Umstieg auf ?? - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

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 snipped-for-privacy@pentax.boerde.de antworten.

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

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

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

Da sind die Frams dann zu langsam.

M.


--
Bitte auf snipped-for-privacy@pentax.boerde.de antworten.

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

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


Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it


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."
We've slightly trimmed the long signature. Click to see the full one.
Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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

Re: Mikrocontroller und externes RAM
On Thu, 8 Jan 2004 18:48:14 +0100, Martin Klaiber

Hi!

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

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.

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

Ja. Aber die ADC sitzen sowieso auf einzelnen Steckplatinen, dann
bietet es sich an, jedem seinen eigenen Puffer zu spendieren.

Martin

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it

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 snipped-for-privacy@pentax.boerde.de antworten.

Re: Mikrocontroller und externes RAM

Quoted text here. Click to load it


Die Assoziation hatte ich auch. Nur dass der Refresh sich nicht an der
verstrichenen Zeit orientiert, sondern daran, wie oft in diesem Sektor
gelöscht wurde. Vielleicht werden benachbarte Blöcke/pages im gleichen
Sektor ja etwas 'mitangelöscht'.

Quoted text here. Click to load it

Ja. Und in meinem Fall kommen ja noch die Zeiten dazu, die ich für das
Adressieren der ADC und das Abholen der Messwerte brauche. Die hatte
ich noch gar nicht berücksichtigt.

Quoted text here. Click to load it

Ja, der Tip kam schon mal. Ist eigentlich eine gute Idee, aber in
meinem Fall ungünstig, da das Ganze auch mit Rechnern laufen soll,
die nur RS-232 haben. Aber da die Schnittstelle auch auf eine eigene
Platine kommt, kann ich diese Option ja noch später realisieren.

Martin

Re: Mikrocontroller und externes RAM (was: AVR Umstieg auf ??)
Quoted text here. Click to load it

Es gibt einige AVR Typen mit 24 Bit Adressraum.  Die oberen 8 Bit
werden dabei durch je ein Register (RAMPX/Y/Z/I) pro Zeiger ergaenzt.
Die Compiler wie der von IAR wissen das und erzeugen automatisch
passenden Code.  Wenn Du wirklich soviel Platz brauchst, bist Du
aber vielleicht mit einem richtigen 32bit Prozessor besser bedient.

Re: AVR Umstieg auf ??
Quoted text here. Click to load it

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

Re: AVR Umstieg auf ??
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




Re: AVR Umstieg auf ??
Quoted text here. Click to load it

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


Re: AVR Umstieg auf ??
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

... 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

Re: AVR Umstieg auf ??
Quoted text here. Click to load it

Schau mal bei Cygnal nach...

Quoted text here. Click to load it

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.


Site Timeline