ADC mit ATMega644 Assembler

> Kann mir jemand sagen, was da falsch läuft?

Vermutlich ja (nicht verifiziert)...

>  ldi     temp1, (1<<ADEN)|(1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0)

Und wo bleibt ADSC? Du schaltest zwar den ADC ein, startest aber keine 
Conversion.

...

Oh, sorry, hatte ich vergessen zu posten.
Ich arbeite das nacheinander ab;
erst Init, also nur Enable usw,
dann conversion-start,
(Hier:
sample_adc:
  lds   temp1, adcsra
  ori     temp1,(1<<ADSC)
  sts     ADCSRA, temp1        ; den ADC starten
)
und dann die Warteschleife wie oben gepostet.

Hab den Fehler aber schon gefunden, war genau in DIESER Startroutine!
Hatte vorher erst mit lds gelesen, dann mit ldi in temp1 NUR das 
ADSC-bit gesetzt , dabei aber alles andere im ADCSRA genullt und wieder 
zurück geschickt... Mit ORI läufts jetzt...(Nach vier Stunden rückwärts 
nachvollziehen; darauf muss man erstmal kommen, wenn der ganze Rest des 
Programms auch umgestellt werden musste!!)
Trotzdem danke!

Ist mir auch schon passiert, da kann man ganz schön suchen... ;-)

Tip am Rande: Versuche Dich mal mit SBR anzufreunden, das ist zwar auch 
nur ORI, hat aber den Gegenpart CBR (ANDI mit Einerkomplement). SBR 
setzt die angegebenen Bits (also die Einsen in der Bitmaske), CBR löscht 
die Bits, die in der Bitmaske 1 sind. Das erspart das lästige Umdenken 
bei ANDI zum Löschen von Bits.

...

Guter Tipp!
Das wäre dann

SBR temp1, (1<<ADSC)

oder??

> Das wäre dann

> SBR temp1, (1<<ADSC)

Ja...

Ist meiner Meinung nach besser (intuitiver) lesbar (Set Bit in 
Register), besonders beim Löschen von Bits (CBR statt ANDI), da man auch 
da nur die betroffenen Bits (als Einsen) angeben muss, anstatt (bei 
Verwendung von ANDI) die Bits angeben zu müssen, die nicht gelöscht 
werden sollen.

Ich fordere aber nicht zum Boykott von ORI und ANDI auf, es gibt auch 
Situationen, in denen diese sinnvoller sind. ;-)

...

Du musst bei ANDI nicht die "anderen" Bits angeben.

1

 ANDI ~(1<<PB1|1<<PB0)

ich halte das für die "logischere" Operation, da sie eine logische 
Grundfunktion verwendet, aber das  sicher Geschmackssache.  (Mir spart 
das einen einzelnen Knoten im Hirn, da ich CBR erst in eine logische 
Grundfunktion umrechnen muss.)  Ich wollte nur darauf eingehen, dass man 
nicht die Bits, die stehenbleiben, angibt, sondern das, was man 
wegmaskieren möchte.

So, hab jetzt alles am laufen und gebe die ersten Frequenzen auf meinem 
GLCD aus.

Habe jetzt schon wild herum gesucht und gerechnet aber komm nicht drauf:

Welche maximale Frequenz (zb Sinus) ist mit dem ADC vom ATMega644 zu 
messen(max 15kSps)?
Wie war das noch mit Shannon und Nyquist usw??
Steh da grad ein bißchen auf dem Schlauch...

Wie kann man "mehr" heraus holen?
Quarz auf 20MHz erhöhen oder noch höher??
ADC in free run und dann per Interrupt oder single conversion?

Habe schon das Programm so umgeschrieben, dass erstmal die (zB250) Werte 
NUR abgespeichert werden und danach auf GLCD ausgegeben werden...

Hi Leute!

Hab jetzt mein Oszi am laufen aber mir reichen die Mess-Samples nicht 
mehr.
Habe mir jetzt ein paar ADC-Samples bei Maxim bestellt und will mal 
sehen, wie schnell ich die Messungen damit kriege.
Allerdings hab ich jetzt mit gekriegt, dass es wohl für bessere 
Geschwindigkeit schon fast Standart ist, die ADC-Daten zuerst schnell in 
einen ext Speicher zu schieben und dann in aller Ruhe auszugeben.
Hab mir überlegt, SD-Card zu nutzen.
Habt ihr da nen Tipp für mich? Ist ein (anderer) Flash-Speicher 
vielleicht schneller/ einfacher zu handeln? Wie läuft denn die 
Übertragung von ADC zu Karte ohne uC? Man init. erst ADC und Karte, 
lässt die Messungen dann per Takt am ADC laufen und hat die 
Datenleitungen direkt an der Karte und taktet die dann im gleichen 
Sinne, oder?
Dazu muss dann wohl der ADC mit SPI laufen, oder?
Hat evtl jemand nen Anschlussplan für diesen Fall für mich??

Schöne Weihnachtszeit wünsche ich allen hier im Forum...

Hallo,

also wenn du schnell was wegschreiben willst (Oszi) dann ist eine 
SD-Karte zuusammen mit einem ATMega sicher nicht die geeignete Lösung. 
Die SD-Karte musst du immer mit 512Byte Blöcken beschreiben. Also im RAM 
puffern und das schreiben, was aber seine Zeit dauert - für einen 
Echtzeitanwendung zu lang!

Sascha

Sven B. schrieb:
> Hab heute den Umstieg von ATMega32 auf AtMega644P gewagt. Hab schon
> alles auf diese Memory-Mapped Register umgestellt, aber komischerweise
> kriege ich den ADC nicht zum laufen... Ich programmiere in ASM:

Wow, Du hast schon 32kB in Assembler geschafft, ich hätte da längst den 
Überblick verloren.
Meine Schmerzgrenze für Assembler ist 2kB, darüber geht nur noch C.

Wenn jemand 8kB noch in Assembler schafft, da zieh ich den Hut.
Aber ich bin ja auch schon älter, da kann man sich nicht mehr soviel 
merken.
Da brauchts eben C, um Projekte >2kB zu wuppen.
C nimmt einem ja ne Menge Arbeit ab, unter anderem ist da vollkommen 
schnurz, wo welche IO-Adressen liegen.


Peter

@ Sascha: Hmmm... das hatte ich auch mal irgedwo gelesen, richtig.

Welchen Speicher würdest du mir denn raten?
Welcher wäre denn leicht zu beziehen (zB Reichelt) und praktikabel?

ADC und Speicher in SPI, oder?
Danke für die Antwort.