Atmega 2560 - ADC Frequenz bei niedriger CPU Frequenz

Hallo zusammen,

ich programmiere zur Zeit einen Atmega 2560 (auf dem Arduino) direkt in C. Durch das Setzen der entsprechenden Bits im CLKPR Register konnte ich die Frequenz des Chips auf 62.500 Hz drosseln (mehr benötige ich nicht, und ich möchte gerne so viel Strom wie möglich sparen). Der ADC soll laut Datenblatt ( http://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf ) im Bereich 50-200 KHz betrieben werden, weshalb man diesem einen extra prescaler verpassen kann. Nun meine Fragen:

1.) Bezieht sich der ADC Prescaler auf die Frequenz des externen Quartzes oder auf die Frequenz des Systems (Quartz nach "system clock prescaler"?

2.) Gibt es eine Möglichkeit diesen prescaler auszuschalten/auf 1 zu setzen? Im Datenblatt (S. 285 ganz unten) steht nämlich sowohl für "000" als auch für "001" der Prescaler 2.

Mit freundlichen Grüßen Zipfel1

Zu 1: Auf die Frequenz, nach "system clock prescaler" Steht auch im Datenblatt so.

Zu 2: Nein!

auf 62.500 Hz drosseln

Warum tust du das?

Strom sparen kann es doch nicht sein? Denn da würde es klügere/bessere Methoden geben.

Was wären denn die besseren Methoden? Höherer Takt und Rest der Zeit im Sleep Mode? Wie stark schränke ich denn die Genauigkeit des ADC ein, wenn ich dessen Clock auf 31.250 Hz stelle (obwohl man ja anscheinend 50.000 Hz braucht)

Höherer Takt und Rest der Zeit im Sleep Mode?

Würde mal sagen: Ja! (kenne allerdings deinen Plan nicht)

Wie stark schränke ich denn die Genauigkeit des ADC ein,

Ich weiß nur das, was im Datenblatt steht. Das wird dir vom Hersteller garantiert.


Ich weiß nicht genau warum, aber Anfänger (darf ich dich so nennen?) neigen oftmals dazu, die Spezifikationen in den Wind zu schlagen. Ich denke, je niedriger der Kompetenzlevel, desto größer diese Neigung.

Der Hauptgrund, warum ich das mit dem Schlafen vermeiden möchte, ist, dass ich häufig ein Busy wait einsetze (Datenübertragung).

Also würdest du den doppelten Takt empfehlen? (und damit ADC Clock von 62.500 Hz)

dass ich häufig ein Busy wait

Du wirst das dann wohl gründlich überdacht haben....

Da du mir nicht verrätst, was du da tust, kann ich auch keine Gegenvorschläge machen.

(Datenübertragung).

Bei einem Systemtakt von ca 60kHz, was ist das denn für eine Datenübertragung?

Gut, dann muss ich aber etwas weiter ausholen:

Es geht darum eine Tastatur für den Raspberry Pi zu realisieren. Da ich keinen USB Port opfern möchte, mache ich das über einen der GPIO Pins. Um ein Busy Wait auf dem Raspberry Pi zu verhindern (kontinuirliches Abfragen des Pins), arbeite ich dort im Kernel Space mit Interrupts, was bis ca. 2000 Baud ausgezeichnet funktioniert. Ich messe also immer die Zeit zwischen den Interrupts und berechne daraus die Anzahl der Bits. Nun möchte ich gerne ein Byte übertragen, muss aber gleichzeitig am Ende der Übertragung nochmals ein Interrupt triggern, weshalb ich 9 bit benötige. Diese kann der Arduino UART aber nicht senden. Also Bit-Bange ich mir meine Schnittstelle selbst, wo es nun eben zu besagtem Busy-Wait kommt. (Ich warte immer auf einen der Timer). Da ich nur die Pins abfragen und die entsprechenden Daten dann Senden muss, reichen die 62.500 Hz locker. Den ADC benötige ich, um den aktuellen Stand eines Joysticks zu bestimmen, der auch übertragen wird. Das wird allerdings auf einen Wertebereich von 49 herunterskaliert (<6 bit), weshalb die Frage ist, ob die Auflösung des ADC dann trotzdem noch reicht.

Diese kann der Arduino UART aber nicht senden.

Halb wahr...

Die Serial Klasse kann das vielleicht nicht. Zumindest kann sie noch ein Paritätsbit anhängen, womit es dann 9 Bit sind.

Die Hardware UART eines AVR kann in den meisten Fällen (allen mir bekannten) sehr wohl 9 Bit senden. Ist halt nur nicht in der Serial Klasse implementiert. Mit Datenblatt lesen und etwas Handarbeit, dürfte sich das erledigt haben.

Vergleichbares gilt für den ADC. Auch dort findet sich eine Möglichkeit nur 8Bit auszulesen. Und der Spruch im Datenblatt, dass die Frequenz dann weiter herunter gesetzt werden kann. Mit Datenblatt lesen und etwas Handarbeit, dürfte sich das erledigt haben.


Warum verwendest du nicht I2C oder SPI für die Datenübertragung? OK, I2C ist etwas problematisch, auf dem RPI. Aber wenn man Clockstretching innerhalb eines Bytes vermeidet, stehen die Aussichten nicht so schlecht.


Da ich keinen USB Port opfern möchte,

Ein (passiver?) USB Hub und ein Arduino mit ATMega32U4 wäre sicherlich (aus meiner Sicht) die problemlosere Variante. Alternativ, ein Digispark.

combie:
Warum verwendest du nicht I2C oder SPI für die Datenübertragung?
OK, I2C ist etwas problematisch, auf dem RPI.
Aber wenn man Clockstretching innerhalb eines Bytes vermeidet, stehen die Aussichten nicht so schlecht.

Ich benötige die Schnittstellen des RPI anderweitig, deswegen wollte ich einfach eine normalle PIN nehmen (da ich auch nur einen geringen Datendurchsatz benötige).

combie:
Die Hardware UART eines AVR kann in den meisten Fällen (allen mir bekannten) sehr wohl 9 Bit senden. Ist halt nur nicht in der Serial Klasse implementiert.
Mit Datenblatt lesen und etwas Handarbeit, dürfte sich das erledigt haben.

Auf die Idee bin ich natürlich nicht gekommen, ich schaue da gleich mal das Handbuch durch.

combie:
Vergleichbares gilt für den ADC. Auch dort findet sich eine Möglichkeit nur 8Bit auszulesen. Und der Spruch im Datenblatt, dass die Frequenz dann weiter herunter gesetzt werden kann.
Mit Datenblatt lesen und etwas Handarbeit, dürfte sich das erledigt haben.

Ist mir bekannt, mir fehlt hier nur eine Abschätzung darüber, wie viel weiter ich das heruntersetzen kann.

combie:
Ein (passiver?) USB Hub und ein Arduino mit ATMega32U4 wäre sicherlich (aus meiner Sicht) die problemlosere Variante. Alternativ, ein Digispark.

Probleme gibt es so nicht, bis auf die Energieoptimierung (und da komme ich mit einem ganzen Arduino sicher nicht besser weg)

Ich habe gerade mal nachgemessen, und mit 125 KHz braucht er sogar 0.1 mA WENIGER Strom. Gibt es dafür eine sinnvolle Erklärung? Ich meine ich erhöhe den Takt, ohne Energiesparmodi zu verwenden.

Gibt es dafür eine sinnvolle Erklärung?

KA…

Wenn du den 128kHz Watchdog Takt verwenden würdest, könntest du noch billiger dabei weg kommen…
ungetestet

Wäre es besser den Hardware UART für das Senden der Daten zu verwenden, oder fahre ich da mit dem BitBanging Ansatz trotzdem ganz gut? Wie genau ist dieser Watchdog Takt denn? Der 8 Mhz interne Quarz scheint ja sehr ungenau und damit ungeeignet für die serielle Kommunikation zu sein.

Der 8 Mhz interne Quarz scheint ja sehr ungenau und damit ungeeignet für die serielle Kommunikation zu sein.

Es ist ein RC Oszillator, kein Quarz. Aber wenigstens ist der interne 8MHz Takt kalibrierbar und dann auch ganz gut für die Serielle Kommunikation geeignet.

Wie genau ist dieser Watchdog Takt denn?

Grottig, und nicht kalibrierbar.

Ok, dann bleibe ich doch lieber bei einem externen Quarz. Habe ich den Vorteile wenn ich den Hardware UART verwende (im Gegensatz zum Bitbanging ansatz?)

KA... Kann dir nur Alternativen zeigen. Die Entscheidungen musst du treffen.

Ok, vielen Dank für deine Hilfe. Habe mich jetzt für 125.000 Hz mit BitBanging entschieden. Dieser Thread wäre somit durch, kann ich den irgendwie als gelöst markieren?

Hi

Klar :) Ändere einfach den Titel Deines Anfangspost, indem Du ein [gelöst] oder Ähnliches voranstellst.

MfG