AVR "Netzwerk" für Daisy Chain use: Wie anstellen

[Alex V. (bastel_alex)]

Hallo,

folgendes Scenario:

Ein AVR(zB 644) ist über UART (Bluetooth SPP) mit dem PC verbunden und 
nimmt Benutzereingaben entgegen und schickt gemessene Daten zurück.

Bis zu 4(?) AVR (auch 644 o.Ä.) sitzen auf identischen Modulen, die DAQ 
Hardware (PGAs, 8CH 16Bit ADC,...) bereitstellen und holen sich hier vom 
ADC mit sagen wir 1ksps/channel daten. Interface auf den Modulen ist 
SPI.

Nun die Frage/das Problem:

Die Datenraten sind erheblich (pro DAQ Modul sagen wir 6ksps à 16 Bit + 
package info (8Bit) ~ 18kbyte/s). Die müssten nach dem obigen Scenario 
erst vom ADC an den Modul-µC und dann vom Modul-µC an den Main-µC. 
Dieser allerdings bekäme von bis zu drei anderen Modulen ja auch noch 
Daten "gleichzeitig".

1. Ist es überhaupt möglich das ganze lediglich über SPI zu lösen? Im 
Prinzip wäre ja der Main-µC der Main Master, die Modul-µCs die Master 
für die Peripherie aber Slaves für den Main-µC. Kann man bei solchen 
Datenraten (oder überhaupt) so einfach wechseln zwischen den 
Zuordnungen?
Problem dabei: Für jeden "Get" zum ADC müsste der Modul-µC Master 
spielen, für jeden "Get" vom Main-µC aber Slave (und zwar 
abwechselnd)...

2. Fallen euch gute Alternativen (Schnittstellen, µC Technologien, 
andere Modelle oder Hersteller  z.B. PICs) ein?

Ehrlich gesagt: Ich habe so etwas bisher noch nicht gemacht - möchte 
aber ungern daran scheitern ;)

[Alex V. (bastel_alex)]

War die Frage doof, weils so nicht geht?

[Pudel (Gast)]

Alex v. L. schrieb:

> War die Frage doof, weils so nicht geht?

Wozu sind die "mittleren" µC (Slave/Master) gut? Nur um die Daten 
abzuholen, zu bündeln und an den Main-µC weiterzureisen?

[Alex V. (bastel_alex)]

a) zum abholen
b) zur Kontrolle der Hardware auf den Modulen.
c) (vielleicht) zur digitalen Filterung (Lock in demodulation zB)
d) Zur Bereitstellung einer PWM Referenz...

Spielt deine Frage darauf an, dass man die auch einfach weglassen könnte 
und alles über den Main-µC ansteuern?

Darüber hinaus habe ich eben im DB den "USART in SPI Mode" gefunden.
Bedeutet das, dass ich mit dem zusätzlich zum nativen SPI ein "zweites" 
SPI interface aufmachen kann? Dann wäre es ja vielleicht möglich 
gleichzeitig Slave und Master zu Spielen, je nach Interface...?

[Pudel (Gast)]

Alex v. L. schrieb:
> a) zum abholen
> b) zur Kontrolle der Hardware auf den Modulen.
> c) (vielleicht) zur digitalen Filterung (Lock in demodulation zB)
> d) Zur Bereitstellung einer PWM Referenz...
>
> Spielt deine Frage darauf an, dass man die auch einfach weglassen könnte
> und alles über den Main-µC ansteuern?

Ja (z. B. über einen ARM-µC). Es stellt sich die Frage, ob das 
Umschalten (Slave/Master) notwendig ist oder ein µC mit 2 
SPI-Schnittstellen besser geeignet ist.

Du solltest deine Beschreibung erweitern, so dass man den Aufwand 
abschätzen kann.

- welche Aufgaben die Controller in der höchsten Ausbaustufe haben
- die max. Datenraten in die Zweige deines Überblicks einzeichnen

[Alex V. (bastel_alex)]

Habe mich bemüht die Übersicht zu erweitern.

Pudel schrieb:
> Ja (z. B. über einen ARM-µC).

Wieso ARM? Weil fixer?

Ich ziehe momentan schon auch noch ernsthaft in Betracht alles über 
einen µC laufen zu lassen. Doof daran ist, dass dann schon einige Lines 
zu einem Modul laufen müssten (die SPI Data+Clk, min. 4, eher 6 Slave 
selects, Power, Gnd, ...) und ich die Arbeitslast verteilen wollte. 
Deshalb aber gerne auch Alternativ-Vorschläge!

[Martin S. (led_martin)]

Hallo,

nur so als Hinweis, die meisten ATmega Controller können den UART 
alternativ als Master SPI betreiben, so könntest Du, in der mittleren 
Ebene, die 'echte' SPI-Schnittstelle als Slave betreiben, und die 
Sensoren (A/D-Wandler, ...) an den als Master-SPI konfigurierten UART 
hängen, so sparst Du die zeitintensive, und von der Hardware aufwendige, 
Umschalterei, und hast, auf beiden Seiten, die volle Bandbreite zur 
Verfügung, dann sollte das auch mit AVRs machbar sein.

Mit freundlichem Gruß - Martin

[Marc V. (Firma: Vescomp) (logarithmus)]

Alex v. L. schrieb:
> Ich ziehe momentan schon auch noch ernsthaft in Betracht alles über
> einen µC laufen zu lassen.
 Die Idee finde ich nicht so gut.
 Von der Geschwindigkeit her wirst du wohl keine Probleme haben, SPI
 kann beim 644 theoretisch mit 10Mb laufen. Aber die Datenverwaltung
 und Aufbewahrung könnte zum Problem werden.
 Andererseits ist ein M644 für 1ADC, 1DAC etc. etwas überdimensioniert.

> Deshalb aber gerne auch Alternativ-Vorschläge!
 Main-µC bleibt, 1 Slave/Master-µC verwaltet SPI Bus (verfügbare Pins
 voll ausnutzen), 1 Slave-µC verwaltet den Rest (Parallel, I2C, RS485),
 der kriegt auch eine INT-Leitung zum Main-µC, falls etwas wichtiges
 über RS485 oder sonstwoher kommt.

[Pudel (Gast)]

> Wieso ARM? Weil fixer?

Rechenleistung mit 32-Bit, SPI via DMA, mehr RAM, ....

Vorschlag:

Die mittlere Ebene rauswerfen und die max. 16 SPI-Slaves an einen 
ARM-Controller (STM32Fxxx)anschließen. Deine Nettogesamtdatenrate liegt 
bei 600 KBits/s, was bei einem SPI-Takt von 10 MHz/20 MHz kaum ins 
Gewicht fällt. Die optionalen Aufgaben (digitale Filterung, solltest du 
noch näher spezifizieren) übernimmt der ARM.

[Alex V. (bastel_alex)]

Alex v. L. schrieb:
> Darüber hinaus habe ich eben im DB den "USART in SPI Mode" gefunden.
> Bedeutet das, dass ich mit dem zusätzlich zum nativen SPI ein "zweites"
> SPI interface aufmachen kann? Dann wäre es ja vielleicht möglich
> gleichzeitig Slave und Master zu Spielen, je nach Interface...?

Martin Schlüter schrieb:
> nur so als Hinweis, die meisten ATmega Controller können den UART
> alternativ als Master SPI betreiben, so könntest Du, in der mittleren
> Ebene, die 'echte' SPI-Schnittstelle als Slave betreiben, und die
> Sensoren (A/D-Wandler, ...) an den als Master-SPI konfigurierten UART
> hängen

Das beantwortet ja meine Frage ob das ginge, vielen Dank!

Marc Vesely schrieb:
>> Deshalb aber gerne auch Alternativ-Vorschläge!
>  Main-µC bleibt, 1 Slave/Master-µC verwaltet SPI Bus (verfügbare Pins
>  voll ausnutzen), 1 Slave-µC verwaltet den Rest (Parallel, I2C, RS485),
>  der kriegt auch eine INT-Leitung zum Main-µC, falls etwas wichtiges
>  über RS485 oder sonstwoher kommt.

Danke. Ich habe nur das Anliegen, dass es eine Central Unit und 
optionale Acquisition units gibt - die bräuchten ja in jedem fall je 
einen Slave µC.
Ich verstehe noc nciht ganz, was der zusätzliche Slave/Maste µC zum Main 
µC bringen soll?

Pudel schrieb:
> Die optionalen Aufgaben (digitale Filterung, solltest du
> noch näher spezifizieren)

Das, was an Processing anstünde ist schnell und leicht beschrieben - 
wobei ich  bei digitaler Lock in Demodulation die Abtastrate von zwei 
Channeln (und damit die SPI Datenrate) hochkorrigieren muss (s.u.)

Also kurz einmal Details zu den ADC Daten, die je nach Konzept eben auf 
dem Modul vorverarbeitet (gefiltert) werden oder zentral. Modular wäre 
mir eben lieber:

Ein Modul:
6 ADC Channel, 4 davon werden mit 1ksps gelesen, 2 mit bis zu >6ksps 
(noch nicht klar was nötig/sinnvoll ist).
- Die 4 1ksps channel sind oversampled und werden auf je 250sps für 
besseres SNR gemittelt. Also 4*250*16Bit/s = 2kByte/s+ 1kByte/s package 
Info auf die SPI lane.
- Die 2 6ksps Channel beinhalten je ein 3 kHz PWM moduliertes Signal, 
das Lock-In demoduliert wird, d.h. pro sample eine +/- 1 Multiplikation. 
Danach eine digitale 2Hz Tiefpass FIR Filterung ca. 3. Ordnung. 
Übertragen werden müssen dann nur noch ca. 80*16Bit/s + 80*8Bit Package 
Info = 240Bytes/s.

JEDOCH: Über den UART würde ich die 3,24kBytes/s am liebsten ASCII 
kodiert schicken. Das wäre also nochmal processing overhead (wie viel 
kann ich nicht einschätzen) und erhöht die Menge an Daten die in den 
UART buffer muss.

Zusammengefasst sind die haupt Processing aufgaben also:

a1) (Lock-In) Filtering: +-1 Multiplikation, 3.order FIR TP
a2) Averaging (4 channel von 1ksps oversampled auf je 250 sps)

b) Alle Daten ASCII codieren + in den UART Buffer an das BT Modul 
schieben

c) Steuerung der Module (Channel Control)

[Alex V. (bastel_alex)]

Nur kurz nochmal zu der 2xSPI Idee (über den optionalen USART SPI):

Ich finde das hätte den schönen Beigeschmack, dass die 
Signalverarbeitung komplett auf den modulen passiert.

Gesendet an (beliebige Hardware, in diesem Fall den main µC) müssten nur 
noch die bereits gemittelten Werte aus dem oversampling (250sps pro 
channel) und die bereits lock-in demodulierten zwei anderen kanäle 
(80sps pro channel) + channel jeweilige info packages.

Dann wäre auch die funktionale struktur eingehalten: Die module erfassen 
und verarbeiten die Signale, das mainboard steuert die module, holt sich 
die signale und kommuniziert mit dem PC.

[Marc V. (Firma: Vescomp) (logarithmus)]

Alex v. L. schrieb:
> Ich verstehe noc nciht ganz, was der zusätzliche Slave/Maste µC zum Main
> µC bringen soll?

 Der soll die ganzen Module die uber SPI kommunizieren, verwalten.
 Alles, was über SPI läuft, wird da angeschlossen.
 Warum sollte jeder Modul seinen eigenen µC haben ?
 Ein ARM kommt mit 4-5 Modulen nicht mal ins schwitzen.

[Alex V. (bastel_alex)]

Marc Vesely schrieb:
> Warum sollte jeder Modul seinen eigenen µC haben ?

Weil dann auf jedem µC jedes Moduls auch die anderen Aufgaben (Filter 
etc) übernommen werden können und das Modul eine abgeschlossene DAQ 
einheit wär.

Und weil ich dann Leitungen sparen könnte (nur einmal SPI zum Modul + 
Spannungsversorgung).

Ich denke das ganze wäre dann einfacher Skalierbar!

[Marc V. (Firma: Vescomp) (logarithmus)]

Alex v. L. schrieb:
> Weil dann auf jedem µC jedes Moduls auch die anderen Aufgaben (Filter
> etc) übernommen werden können und das Modul eine abgeschlossene DAQ
> einheit wär.
 Ein ARM-M4 ist ungefähr um den Faktor 15-30 schneller als M644, in
 jeder Disziplin. Manches ist bis zu 50-60 Mal schneller.
 Flash ist 3 Mal so gross, RAM ist 50 Mal so gross...

Alex v. L. schrieb:
> Und weil ich dann Leitungen sparen könnte (nur einmal SPI zum Modul +
> Spannungsversorgung).
 Warum sollten hier mehr Leitungen vorhanden sein ?

 Ich liebe meine M328 und Tiny85, benutze die, wo immer nur möglich,
 aber es gibt Aufgaben, da sind die beiden einfach zu schwach. Genauso
 ist es bei dir. M644 ist sogar teuerer als ARM, langsamer, hat nicht
 genug RAM, er ist ganz einfach die schlechtere Wahl.
 Du kannst es natürlich machen, wie es dir beliebt.

[Alex V. (bastel_alex)]

Ich glaube ich bin langsam überzeugt ;)
Wenn ich Atmel ARM Implementierungen nehme, kann ich die ja auch über 
Atmel Studio in C programmieren, so wie es aussieht - d.h. bis auf evtl 
andere Registernamen müsste für mich ja ansonsten alles beim Alten 
bleiben.

Lassen sich die ARM based AVR controller auch mit meinem ISP mkII 
programmieren oder brauche ich da einen neuen Programmer?

Und: Jetzt habe ich natürlich das Problem, dass ich mich mit der 
ARM-Reihe noch gar nicht auskenne...
Bezüglich Externem Quarz (und Cs) etc. lassen sich die Dinge so 
handhaben wie bei den AVRs - oder gibt es da viele neue kleine 
Baustellen?

Und danke für die ARM-M4 Empfehlung! Ich schaue mir gerade die Atmel ARM 
Modelle an (vorallem M4) und muss zugeben: Die stehen ja in keinem 
Verhältnis zu den AVRs!

Meine Sorge nur: Wie viel Umstellung ist es von AVR auf ARM? Gibt es da 
Kleinheiten und Tücken, die man kennen muss damit das erste Projekt mit 
ARM kein Desaster wird?