AVR Umstieg auf ??

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

Martin Klaiber wrote in news: snipped-for-privacy@martinkl.dialup.fu-berlin.de:

Da sind die Frams dann zu langsam.

M.

Martin Klaiber schrieb:

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.

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

Schau mal bei Cygnal nach...

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.

Holger Veit schrieb im Beitrag ...

Warum ? Gibt's doch reichlich:

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

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.

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

Hi!

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.

Holger Veit schrieb:

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

Servus

Oliver

Martin Klaiber wrote in news: snipped-for-privacy@martinkl.dialup.fu-berlin.de:

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

Ein Problem bei Fujitsu ist leider Verfügbarkeit. Irgendwie bringt es Fujitsu immer mal wieder fertig, dass einzelne uC sehr lange Lieferzeiten (>26Wochen) haben. Mal hat ein Grosskunde alles aufgekauft, dann ruettelt ein Erdbeben die Fabrikin Japan durch und im Augenblick gibt es Probleme bei der Umstellung des Produktionsprozess. Naja, diese Sammlung von Lieferproblemen hat sich bei mir in den letzten 5 Jahren angesammelt, ist also nicht so untypisch für die allgemeinen Probleme bei der Chipbeschaffung. Wahrscheinlich hätten wir bei einem anderen Hersteller die gleichen Probleme gehabt...

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

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.

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

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

Martin

Hi Thomas und der Rest der News.

=20

Die von Euch verwendeten =B5Cs sind aber wieder lieferbar. Ich habe=20 neulich eine Ecke der Fujitsu MB90F594A bekommen und der Distri hat noch =

das ganze Lager voll...

Ciao Dschen

--=20 Dschen Reinecke

=3D=3D=3D der mit dem Namen aus China =3D=3D=3D