Timer als SPI Clock möglich?

[Martin W. (tschini)]

Hallo,

bei meinem Projekt habe ich einen externen ADC (MCP3002) an einen 
Arduino Nano (Atmega328p) angehängt um 480 resistive Sensoren mit 100 Hz 
zu wandeln. Da das Timing bei dieser Datenmenge sehr strikt ist möchte 
ich den ADC mit maximaler Geschwindigkeit betreiben (SCK = 3,2 MHz). 
Mein Arduino wird mit 16 MHz betrieben. Mit einem Vorteiler von 8 
erreiche ich 2 MHz und bekomme timing Probleme, mit einem Vorteiler von 
4 erreiche ich 4 MHz und übertakte den ADC wodurch dessen Funktion nicht 
mehr garantiert wird. Optimal wäre ein Prescaler mit dem Wert 5.

Da es möglich sein sollte, mit einem Timer ein Rechtecksignal mit 3,2 
MHz zu erstellen, wollte ich fragen, ob es möglich ist Hardware SPI zu 
verwenden und einen externen Takt in dem Fall vom Timer zu übernehmen? 
Bzw. wäre es möglich mit Software SPI besagtes Protokoll und Datenmenge 
zu handeln? Oder soll ich einfach versuchen den ADC zu übertakten?

Mfg Martin

[holger (Gast)]

>Mein Arduino wird mit 16 MHz betrieben. Mit einem Vorteiler von 8
>erreiche ich 2 MHz und bekomme timing Probleme, mit einem Vorteiler von
>4 erreiche ich 4 MHz

Und mit einem 12MHz Quarz kommst du auf 3MHz.

[Martin W. (tschini)]

Ja klar leider kann ich beim arduino keinen externen quarz mehr 
anhängen; über die serielle schnittstelle übertrage ich die werte dann 
mit 2 Mbit/s, was ebenfalls auf die 16 Mhz abgestimmt ist und mit 12 MHz 
nicht möglich wäre.

[Axel S. (a-za-z0-9)]

Martin Walchshofer schrieb:
> bei meinem Projekt habe ich einen externen ADC (MCP3002) an einen
> Arduino Nano (Atmega328p) angehängt
...

> Da es möglich sein sollte, mit einem Timer ein Rechtecksignal mit 3,2
> MHz zu erstellen wollte ich fragen, ob es möglich ist Hardware SPI zu
> verwenden und einen externen Takt in dem Fall vom Timer zu übernehmen?

Ich hätte da eine ganz abwegige Idee: du könntest das Datenblatt des 
ATmega328 lesen; insbesondere das Kapitel über das SPI. Eventuell hat 
der Hersteller ja vielleicht rein geschrieben, welche Taktquellen für 
das SPI verwendet werden können.

OK, vergiß es. Ich sehe ein, daß es viel naheliegender ist, ein paar 
tausend Leute in einem Forum zu fragen ...


XL

[Filterkaffee (Gast)]

Unlustig, wie hier die Trolle gleich über den armen Kerl herziehen.
Hab das DB mal kurz überflogen - betreib doch den USART0 im 
SPI-Master-Modus. Dann kannst du mit UBRR deinen Takt einstellen.

[Leo B. (luigi)]

Entweder den UART nutzen, oder falls der schon für was andres benötigt 
wird, ein 3,2MHz 50% PWM mit einem Timer erzeugen und als Taktquelle 
nutzen. Das SPI stellst du dann als Slave ein, und schon ist der ATmega 
sein eigenes Slave.

Was Klügeres fällt mir grad auch nicht ein.

[Ralph (Gast)]

Und warum verwendest du nicht direkt den internen ADC des µC ?

Für so etwas wäre ein andere µc besser geeignet.
Dieser sollte soviele interne ADC Kanäle wie möglich haben und diese per 
DMA bedienen können.
Das also nach Wandlung die Daten direkt ins Ram geschrieben ohne 
zusätzliche Aktivitäten in der SW.


Andere Frage, wie machst du das Multiplexen der 480 Sensoren auf die 2 
Kanäle des MCP3002 ?  Ist das so synchronisiert das du wirklich mit 100 
Hz wandeln kannst ?

[Martin W. (tschini)]

Vielen Dank für die raschen Antworten. Viellecht kann ich einen Ansatz 
weiterverfolgen und umsetzen.

Ralph schrieb:
> Und warum verwendest du nicht direkt den internen ADC des µC ?
>
> .
> .
> .
>
> Andere Frage, wie machst du das Multiplexen der 480 Sensoren auf die 2
> Kanäle des MCP3002 ?  Ist das so synchronisiert das du wirklich mit 100
> Hz wandeln kannst ?

Der interne ADC ist leider zu langsam.

Die Sensoren sind in einer matte, matrixartig verbaut. die 480 
kombinationen schalten wir mit 4 externen Multiplexern durch. 
Initialisiert wird das ganze durch einen Timer Interrupt alle 0.01s. 
Danach wird der Multiplexer geschalten, danach AD-gewandelt und der Wert 
in einen Buffer geschoben. Über UART werden die Datenpakete dann an den 
PC geschickt und in Echtzeit angezeigt. Mit 200ksps sollte der 
AD-Wandler schnell genug sein; die hat er jedoch nur bei einer Taktung 
von 3,2 MHz. Mit den 2MHz sollte es sich auch ausgehen nur leider haben 
wir bei der Planung das Hardware SPI nicht so genau analysiert und 
Latenzzeiten nicht miteinbezogen. Auch wenn diese nicht lange sind 
Summieren sie sich (*480) und schmeissen das ganze Timing durcheinander. 
Desswegen haben wir nur die Optionen SPI schneller hinzubekommen oder 
die Abtastfrequenz niedriger zu machen, was vermieden werden sollte.