Gibts sowas? Ich habe nichts gescheites gefunden, außer Video oder Ethernet-Arrays.. das ist mir zuviel des Guten. Es sollen ganz simpel 16 analoge Signale auf 8 ADC's eines Atmel geführt werden, erst die einen 8, dann die anderen 8. Dabei sollen die Kanäle weder durch Massen getrennt werden, noch muss der Chip besonders schnell sein. Das man das auch mit Transistoren lösen kann, ist mir klar, jedoch sollte das nur Plan B sein.
Marcel F. schrieb: > Das man das auch mit Transistoren lösen kann, ist mir klar Mir nicht. 74HC4053. Triple 2-channel analog multiplexer/demultiplexer. mfg.
Thomas Eckmann schrieb: > Triple 2-channel analog multiplexer/demultiplexer. Über die bin ich auch schon gestoßen. 3 IC's sind mir zuviel, deshalb fragte ich nach 16 zu 8 :) Um deine Unklarheiten bezüglich der Transistoren zu klären: es kommen nur die Stufen 0,1,2 und 3 Volt vor.
Gast
#2353353
>74HC4053. Triple 2-channel analog multiplexer/demultiplexer. 74HC4051 8 Channel to 1 multiplexer;)
holger schrieb: > 74HC4051 8 Channel to 1 multiplexer;) alles nett, geht aber an der Fragestellung vorbei :O) die geposteten Varianten hab ich auch alle selbst gefunden. Googel kann ich bedienen, denk ich :)
holger schrieb: > 74HC4051 8 Channel to 1 multiplexer;) Und was soll das bringen? mfg.
Gast
#2353361
Gast
#2353368
>> 74HC4051 8 Channel to 1 multiplexer;) > >Und was soll das bringen? Er hat gesagt es muss nicht schnell sein. Spart dann auch noch 6 ADC Eingänge;)
holger schrieb: > Spart dann auch noch 6 ADC Eingänge;) falsch, würde 7 sparen :) jedenfalls wäre das auch nur plan b.
Thomas Eckmann schrieb: > holger schrieb: >> 74HC4051 8 Channel to 1 multiplexer;) > > Und was soll das bringen? Ganz einfach, der TO braucht zwar 16->8, vergisst aber dass der avr immer nur einen Kanal wandeln kann. D.h. 16->1 bringt genauso viel, bzw. ist besser da der interne Demux nicht gebraucht wird (soweit ich weiß braucht der zum umschalten auch seine Zeit). Außerdem könnte man mithilfe eines 4bit Zählers, die maximale Geschwindigkeit zum Einlesen der Daten erreichen, da HW-seitig umgeschalten werden kann (ADC dann im Freerunning-mode).
Samuel K. schrieb: > vergisst aber dass der avr > immer nur einen Kanal wandeln kann. das stimmt, an sowas hab ich nich gedacht! unter diesen bedingungen ist ja 16->8 wirklich sinnlos..
Gast
#2353387
> Ganz einfach, der TO braucht zwar 16->8, vergisst aber dass der avr > immer nur einen Kanal wandeln kann. Naja, es hat ja noch keiner gesagt fuer welchen Controller genau. vielleicht ist Atmel ja mittlerweile schon so schlau wie Renesas und hat auch Controller mit mehr als einem AD-Wandler die dann parallel arbeiten koennen? Olaf
Olaf schrieb: > fuer welchen Controller genau ich hab an einen kleinen gedacht, der 8 ADC's hat, zB der ATMEGA16
Marcel F. schrieb: > der 8 ADC's hat Der hat nur einen ADC mit vorgeschaltetem 8 zu 1 Mux. Da haben die anderen schon Recht. Mit einem 16 zu 1 Mux auf einen Eingang erreichst du das Gleiche. mfg.
Thomas Eckmann schrieb: > Der hat nur einen ADC mit vorgeschaltetem 8 zu 1 Mux. gut, wieder was gelernt. In welcher Preisklasse bewegt man sich denn, wenn man nen uC mit 8 parallelen ADC haben will? Gibts sowas überhaupt?
Marcel F. schrieb: > Gibts sowas überhaupt? Zwei sind nicht ungewöhnlich (Xmega). Aber acht?. mfg.
Gast
#2353442
>nen uC mit 8 parallelen ADC haben will?
Wozu brauchst du das denn?
Wenn du wirklich zeitgleich samplen willst, dann suche mal bei analog
devices. Es gibt Wandler, die können alle Kanäle zeitgleich samplen und
einzeln digitalisieren.
ne, so wichtig ist das nicht. Ich will die Werte einer Digitalwaage abfangen. Das geht nur darüber, die Signale des Displays abzufangen. Die Waage aktualisiert das Display ca 1 mal pro Sekunde. Das Display hat 4 Commons. Es wird 4fach multiplext und deshalb setzen sich die Signale aus den Werten 0,1,2 und 3 V zusammen. 16 Leitungen hat das Display. Naja, dann hol ich mir die Werte alle nacheinander, ist ja nich wild! Selbst dann hab ich immernoch genug Platz, um das Display mehrere hundert mal pro Sekunde abzufragen und nen gescheiten Wert zu mitteln.
Gast
#2353512
Marcel F. schrieb: > ne, so wichtig ist das nicht. Ich will die Werte einer Digitalwaage > abfangen. Das geht nur darüber, die Signale des Displays abzufangen. Du willst also ein gemultiplextes (vermutlich LCD) Display mit einem ADC mitlesen? sportlich ! MfG Klaus
Klaus schrieb: > sportlich was meinst du damit?
Er meint das ist schwer zu erreichen. Ich würde auf gar nicht tippen. Die Treiber sind alle sehr schnell im Multiplexen.
ich hab hier ne Periode von 75Hz und eine Periode besteht aus 8 verschiedenen "Zeitschlitzen", also 600Hz. In diesen 600Hz = 1,7ms muss ich alle 16 Leitungen möglichst mehrmals auslesen. Gehen wir von 5 mal pro Leitung aus. Macht 80 ADC-Umsetzungen pro 1,7ms, also pro Umsetzung 21us. Im Datenblatt steht "13 μs- 260 μs Conversion Time". Welche Zeit such ich mir jetz aus?
ok das ist sehr langsam. Meinen Lcd Treiber hier (PCF8577) würdest du nicht geloggt bekommen. Nimm doch einfach das schnellste, du kannst die Frequenz des ADC auch verdoppeln, dann kommst du auf 6,5us (dabei sinkt die Genauigkeit, aber du brauchst ja nur 2bit). Also das reicht dir aufjedenfall.
achso, der ADC brauch 260us bei 10bit und entsprechend weniger bei weniger bit? supi, passt mir ;)
Gast
#2353572
Ich bleib bei sportlich. MfG Klaus
Der ADC braucht wie im Datenblatt bei 10bit 13-260µs. Sobald man darunter geht (<13µs), gehen die Bits (Auflösung) runter. Klaus schrieb: > Ich bleib bei sportlich. Bei den Daten gehe ich zu einfach, wenn man kein Bascommer ist.
Klaus schrieb: > sportlich Erläutere mir deine Zweifel. Ich lerne gern dazu. @samuel: "Der ADC braucht wie im Datenblatt bei 10bit 13-260µs" Was bedeutet denn das genau? Kann ich nicht genau vorhersagen, wie lange der ADC brauchen wird? Es kann also sein, dass er mal nach 13us und mal nach 260us fertig ist, je nach Wetter?
Lies dir mal das Tut zum thema ADC durch. Der hat nämlich eine eigene Clock.
Gast
#2353605
OK, es geht nicht nur um die Geschwindigkeit, du mußt auch synchron mit der Multiplexfrequenz messen. Ansonsten bekommst du Werte, die du nicht den einzelnen Phasen beim Multiplexen zuordnen kannst. Dazu ist eine Synchronisation deines µC mit dem Display erforderlich. Außerdem ist eine volle Kontrolle der Timings des Sample and Hold und des ADC Moduls erforderlich. Ob das mit deinem µC klappt? Ich würde versuchen, die Wägezellen selbst auszulesen. Auch nicht ganz einfach, aber die chinesischen Waagenhersteller schaffen es auch. MfG Klaus
Da fällt mir gerade ein: Ist ein Lcd-Treiber auf der Platine? Falls ja wird er wahrscheinlich mit I2C angesprochen, da kann man mithören.
Klaus schrieb: > synchron mit > der Multiplexfrequenz messen Darüber hab ich mir auch schon Gedanken gemacht. Ich glaube, die Synchronität ist nicht so wichtig, denn ich bekomm nur im Umschaltmoment der Waage falsche Werte. Da die Waage aber nur aller Sekunde den Wert ändert, kann ich damit leben. Ich lese die Periode dann zwar versetzt aus, aber die Summe der einzelnen Spannungen bleibt gleich. Bsp: für ein aktiviertes Segment kommt diese Folge von Spannungen: Leitung 1: 2,2,0,1,1,1,3,2 Leitung 2: 1,1,3,2,2,2,0,1 Diff: -1,-1,3,1,1,1,-3,-1 Summe der Beträge: 12 (entspricht aktiviertem Segment, für ein deaktiviertes Segment beträgt die Summe 8) Ob ich nun beim ersten Wert anfange 8 Werte mitzuschneiden und die Differenz bilde, oder beim 5. anfange und 8 Werte mitschneide, das spielt keine Rolle. Die Fehler zu erkennen ist dann Softwaresache. Ein Treiber is nich drauf. Da ist ein schwarzer Klecks, dort geht alles rein und raus(LCD, Tasten, DMS).. noch nicht mal ein OPV ist da drauf..
Gast
#2353659
Marcel F. schrieb: > Die Fehler zu erkennen ist dann Softwaresache. Na dann mal los! MfG Klaus
Ich melde mich wieder, wenn mein Kopf raucht ;) Oder spätestens wenn das Ding läuft..
Möge ein mod mal bitte in der Überschrift ergänzen: "+ LCD auslesen", da der zweite Teil der Diskussion sich ja mehr ums Display dreht :)
So, ich habe mich entschieden, dass Synchronität doch wichtig ist, da ich nicht knallhart in ASM code und so Zeitvorhersagen schwierig sind. Die wären jedoch wichtig, um im Takt zu bleiben (ich muss sicherstellen, dass mit einem exakten Vielfachen der Displayfrequenz arbeite, da sich sonst recht schnell die Abtastzeitpunkte aus den entsprechenden Zyklen verschieben würden). Also werde ich einen externen Interrupt-Takt aus dem Displaytakt erzeugen und kann dann sicherstellen, dass immer zum richtigen Zeitpunkt gelesen wird. Kann der MC während einer AD-Umsetzung eigentlich sein Programm weiter ausführen oder ist er dann busy?
So, der halbe Weg ist geschafft. Auf dem Bild seht ihr in blau einen von 16 Kanälen der Displayansteuerung, dabei sind gut die 8 "Zeitschlitze" zu erkennen, die sich immer wiederholen. Darunter in gelb seht ihr die visuelle Ausgabe der AD-Umsetzungen. Habe einen Pin auf high gesetzt, solange der ADC beschäftigt ist. Ein gelber, dicker Peak steht für 16 AD-Umsetzungen (16 Kanäle müssen pro Zeitschlitz abgetastet werden), auf dem 2. Bild ist das besser zu erkennen. Die passende Multiplex-Hardware mit nem 4067 ist auch schon gebaut, wird vom MC angesteuert und funktioniert. Kleine Kinderkrankheiten sind noch zu beheben und die Auswertung bzw Ausgabe der gesampelten Daten muss noch gecoded werden. Aber jetz is erstmal WE :)
Angehängte Dateien:
-
7_adu_aktiv_vs_displaytakt.png
(2,9 KB)
-
9_adu_aktiv_vs_displaytakt_zoom2.png
(2,8 KB)
Mittlerweile erkennt der AVR das auf dem Display der Waage angezeigte Gewicht und speichert es in ner Variable, dh wenn zB 126g auf der Waage angezeigt werden, befindet sich in der Variable der Wert 126. Der Rest ist Kleinkram: - Auswerten von "g", "kg" etc - Ausgabe bereitstellen Damit darf ich mich dann also offiziell als sportlich bezeichnen?? ;O) Wenn das Projekt fertig ist (Doku, Schaltplan etc), werd ichs hier veröffentlichen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.