Forum: Mikrocontroller und Digitale Elektronik mehrere analoge Eingänge wandeln


von jan (Gast)


Lesenswert?

hallo,
bin anfänger in sachen assambler programmierung und MC.

meine frage ist wie ich es anstelle 3 analoge eingänge schnell zu
wandeln.
ich weiss das ein a/d wandler im MC wie ein multiplexer funktioniert
aber wie ich das in assambler umsetze?
klar ist ich schreibe die gewandelten werte in bestimmte register und
mache was damit.......
wie ist das den mit abfragen der werte? reicht das schon wenn ich die
ports bzw pins auf input umstelle? und die werte kommen automatisch
rein???
das problem ist auch das es viele daten sind. abtastfreqenz der analog
aufnehmer ist bis 30 kHz (wegsensoren) möglich und das 3 mal kann man
sowas hinbekommen?
man bräuchte ein schnellen MC aber ich kann das irgendwie nicht
ausrechnen wieviel an daten (f abtast) möglich wäre mit welcher
taktfrequenz des MC, wieviel die befehle in anspruch nehmen würden
usw.?

hoffe mir kann jemand helfen, wie man das mit den multiplexer bzw.
daten codetechnisch verwaltet. habe noch kein MC ausgesucht, habe mich
mit assambler programmierung allgemein auseinander gesetzt.

mfg
jan

von Tobi (Gast)


Lesenswert?

Da du keinen uC Typ genannt hast kann man dir nur einen Blick ins
Datenblatt ans Herz legen dann würden viele deiner Fragen beantwortet
sein. Sonst gibts hier in der Codesammlung auch schon haufenweise
Beispiele zum adc.

von Martin S. (Gast)


Lesenswert?

Also erst mal ohne einen exakten Prozessortyp betrachtet:

Wenn du 3 Sensoren hast, und 30 KHz Abtastfrequenz, dann hast du (bei 1
byte pro AD-Wandlerwert) grob gerechnet 100 Kilo-Bytte pro Sekunden die
da anfallen.

Was machst du mit diesen Daten? Sollen die im MC weiter
"verlustbehaftet verdichtet" werden (z.B. Mittelwert-Bildung), oder
gehen die ohne Verluste (1:1 oder verlustfrei komprimiert) an irgendein
externes Interface (serielle Schnittstelle????) zur Verwertung durch
nachgelagerte Systeme?

Das Problem ist dann möglicherweise nicht mehr die maximale
Sampling-Frequenz des oder der AD-Wandler, sondern dei grundsätzliche
Architekturfrage: Wohin mit den gesampelten Zeugs ??

von jan (Gast)


Lesenswert?

moin,
also die daten sollen weiter über eine serielle schnittstelle zum pc.
wie kann ich die daten den kompriemieren ohne verluste? was gibt es den
da überhaupt für möglichkeiten, höre zum erstenmal davon.

das mit dem MC, bin mir noch nicht sicher was für ein ich nehmen soll,
im moment sieht es so aus als ob ich einen PIC nehmen müsste. gibt es
z.B. zum PIC ein allgemeines vorgehen bzw. die abfrage am a/D und die
daten verwalten, bräuchte nur diesen code den rest schaffe ich schon
alleine denke ich. aber das mit den daten wandeln bereitet mir
kopfschmerzen. wie die schleife aussehen muss damit keine daten
verloren gehen usw.

mfg
jan

von Martin S. (Gast)


Lesenswert?

na ja, verlustfreie Komprimierung hast du schon mal "ganz
bekannterweise" z.B. wenn du diene Dateien "zippst", also z.B.
Win-ZIP nutzt. Es gibt sicherlich auch bessere verlustfreie
Komprimierungs-Algorithmen. Je nach Ursprungsdaten bekommst du dann
Kompressionsfaktoren von ca 1:2 bis 1:4 hin.

Im Gegensatz dazu ist z.B. MPEG3/MPEG4 verlustbehaftet, d.h. die
ursprüngliche Information wird verfälscht (man bekommt aber dadurch
auch für Audio z.B. einen Komprimierungsfaktor von 1:10 bis 1:15 hin)

Ziel der Komprimierung sollte es sicherlich sein, die Datenmenge auf
der Transportstrecke zu reduzieren. Bei 100 Kbyte pro Sekunde
anfallender Nutzdaten brauchst du für asynchrone (serielle V.24)
Übermittlung unkomprimiert ca. 1 Mega-Bit Taktrate. Kann dies dein
sendendes bzw. empfangendes Gerät? "Normale" serielle Schnittstellen
am PC haben ja meisten schon Schwierigkeiten, die 115 Kilo-Bit/sekunde
vernünftig zu handhaben.

"Wie eine schleife aussehen muß daß keine Daten verloren gehen" ist
kein algorithmisches Problem, sondern eine Frage der Dimensionierung
(Speuicher, Ausführungsgeschwindigkeit) des ganzen Geschehens.

Steht die Datenmenge von 100 Kilo-Byte pro Sekunde kontinuierlich über
einen längeren Zeitraum an oder wird das begrenzt? In jedem  Falle
solltest du dir Gedanken über eine mögliche Pufferung der
senderseitigen Daten machen, falls die Schnittstelle nicht schnell
genug mitkommt. Wie groß soll dein Puffer dimensioniert sein?



Was ist mit dem Zielsystem? Wieviel Daten soll es aufnehmen, und wie
soll es diese aufnehmen ? 0,1 Mega-Byte pro Sekunde * 3600 Sekunden
[also 1 volle Stunde] ergeben 360 Mega-Byte. Sicherlich auch nicht die
Welt, aber die wollen ja auch irgendwie verwaltet werden. Hinweis: Ich
würde es NICHt in eine fette Datei hinein spoolen, sondern mehrere
kleine Häppchen bauen, damit beim Transport-Fehler nach 59 Minuten
nicht die gesamten 360 Mega-Byte verloren gehen)

von jan (Gast)


Lesenswert?

hallo,
also das mit dimensionierung und pufferung macht mir zu schaffen.
aber erstmal die dimensionierung und handhabung mit dem A/D wandler.

die daten zu puffern ist klar, dachte da an einen schnellen speicher
(weiss auch noch nicht was für ein, aber wohl nicht das eprom, da es
langsam ist, was würde der experte vorschlagen?)
würde die daten in diesen puffer packen und z.B. wenn 5 kByte an daten
da sind diese zu verpacken (+Fehlererkennung check) und los schicken,
dabei aber noch die ankommenden werte weiter verwalten.
es soll nicht 10 minuten gemessen werden. erstmal nur soviel wie
möglich ist für das system, dann die daten seriell zum PC schiffen und
dann evtl erneut messen.

wie bekomme ich das mit der dimensionierung hin?
wodrauf muss ich aufpassen usw. gibt es beispiele???

mfg
jan

von Sebastian (Gast)


Lesenswert?

Von der geschwindigkeit mal ganz abgesehen ist ein eprom wohl ganz und
gar nicht als puffer geegnet, da diese dann recht schnell "kaputt"
gehen. 100.000 schreibzyklen sind zwar recht viel, aber wenn man das
ganze in einer schleife macht...
z.B. 100 durchläufe pro sek
100.000/100/60
dann ist schon nach ca. 15 minuten nicht mehr sicher ob das was man im
eprom liest auch noch das ist was man reingeschrieben hat.
10 durchläufe pro sek... 150 minuten ist auch noch nicht wirklich viel
als puffer von solchen daten ist sram sicher besser geeignet

von Martin S. (Gast)


Lesenswert?

@Jan
"aber erstmal die dimensionierung und handhabung mit dem A/D
wandler."

Ich weiß nicht was du beim A/D Wandler dimensionieren willst.

Und was soll an der Handhabung komisches zu erwarten sein?

Wahrscheinlich hat man (Prozessor-unabhängig) Anfangs irgendwelche
Initialisierungs-Routinen auszuführen. Und wenn die mal durchgelaufen
sind, dann kan man regelmäßig irgendwelche Werte einlesen.

Wenn du mehr als 1 A/D Kanal hast, dann "muß" es irgendein Verfahren
geben, diese zu selektieren. Ob du da nun einen (möglicherweise
externen) Multiplexer umschalten mußt, der Eingangskanal #1, #2, #3
umschaltet; oder ob da 3 verschiedene Port-Adressen #1, #2, #3 gegeben
sind für 3 Eingangskanäle ist auch wiederum ziemlich "wurscht".



Zum grundsätzlichen Programm (wäre mal so eine Idee):

definier dir 3 Eingangs-Ringpuffer (für jeden der 3 Eingangskanäle je
einen).

Lese die Daten zeitgesteuert durch einen Timer / Interrupt jeweils von
Kanal 1,2,3 ein und stopf sie in die zugehörigen Ringpuffer.

Definier dir einen (kleineren) Ausgangs-Ring-Puffer, in dem die zu
versendenden Datenpakete mit entsprechendem Header vorbereitet werden.
Bei Bedarf kannst du ja die zu versendenden Pakete auch noch
komprimieren

Jetzt mußt du dir nur noch folgendes überlegen:
1. Wann versendest du das Ausgangs-Zeugs
2. Wie erfogt das Handshaking mit der Gegenseite
3. Wie Verhälst du dich bei einem Puffer-Überlauf (sowohl
Eingangs-Ringpuffer als auch Ausgangs-Ringpuffer)


Na ja, und für die Zielseite mußt du dir noch überlegen was du mit den
so übermittelten Daten alles machen möchtest....

von Martin S. (Gast)


Lesenswert?

Ich hab grad nochmal nachgedacht: Natürlich brauchst du keine 3
Eingangs-Ringpuffer. Es reicht ja schon aus, wenn du die 3 Werte der 3
Eingangs-Wandler "hintereinander weg" in einen Ringpuffer legst. Da
du ja "weißt" wie du dei daten versendest (1. byte=1. A/D-Wandler, 2.
byte = 2. A/D Wandler, 3. byte=3. A/D Wandler) weißt du also auch wie du
den Kram empfangsseitig wieder auseinander gepflückt bekommst.

Trotzdem hast du die Notwendgkeit den regelmäßigen Einlesevorgang vom
unregelmäßigen Übermittlungsvorgang zu entkoppeln.


Wenn du 1 Minute messen / sampeln möchtest dann laufen da bis dahin 0,1
Mega-Byte * 60 = 6 Mega-Byte an Daten auf (so groß muß dann halt auch
dein Zwischenspeicher / Puffer sein).

Während dieser Zeit schaffst du es (bei einer angenommenen
Transfer-Leistung von 115 Kilo-Bit/sek entspricht ca. 10 Kilo-Byte pro
Sekunde) ca. 600 Kilo-Byte auf dein PC zu übertragen. Die restlichen
Bytes benötigen dann noch mal 9 Minuten bis die auch "drüben"
angekommen sind. Vielleicht solltest du dir erst mal darüber Gedanken
machen wie du das Zeugs weg bekommst was du da aufsammeln möchtest.

von jan (Gast)


Lesenswert?

hi,



>Jetzt mußt du dir nur noch folgendes überlegen:
>1. Wann versendest du das Ausgangs-Zeugs
>2. Wie erfogt das Handshaking mit der Gegenseite
>3. Wie Verhälst du dich bei einem Puffer-Überlauf (sowohl
>Eingangs-Ringpuffer als auch Ausgangs-Ringpuffer)

zu 1.:
ich würde es gerne sofort parallel versenden, wenn es sinn macht und
überhaupt möglich ist.

zu 2.:
weiss auch noch nicht so recht wie das genau funktionieren soll, auf
jedenfall das es eine quittung von empfänger gibt nach einem
übertragenen block (mit assambler programmiert??). bin mir nicht
sicher, aber habe gehört, das ich die daten mit hilfe von visual basic
vom port abfragen kann, ginge das oder muss das im MC mit der
quittierung programmiert werden??? wie geht das? denn mit VB wäre es
einfach per DLL (aktive x) die daten zum auswerte programm zu
schicken.


3.:
was macht man bei solchen überläufen? da gibt es doch schon bestimmt
schlaue methoden, oder? gehen die daten dann verloren?


----------------------------------------------------------------------


>Es reicht ja schon aus, wenn du die 3 Werte der 3
>Eingangs-Wandler "hintereinander weg" in einen Ringpuffer legst.

spare ich dadurch zeit, weil ich nicht ständig den Ringpuffer register
wechsele? deswegen?



>Wenn du 1 Minute messen / sampeln möchtest dann laufen da bis dahin
>0,1 Mega-Byte * 60 = 6 Mega-Byte an Daten auf (so groß muß dann halt
>auch dein Zwischenspeicher / Puffer sein).

gibt es solche grossen puffer und wenn dann was für welche?
SRAM wäre doch geeignet aber gibt es so grosse? kenne mich da überhaupt
nicht aus?

wenn das die 10 minuten dauert ist nicht schlimm, hauptsache die daten
kommen richtig an!!

mfg
jan

danke sehr für die hilfe

von Martin S. (Gast)


Lesenswert?

@Jan

> bin anfänger in sachen assambler programmierung und MC.

Na ja, deinen Fragen/Antworten zufolge nicht nur in Sachen MC, sondern
generell in Sachen "Programmierung, Algorithmen & Datenstrukturen"
etc.

Ist jetzt nicht bös gemeint, aberes hilft natürlich erst einmal, den
Wissensstand seines Gegenüber zu kennen, um desen nicht mit
vermeintlich vorhandenen "Selbstverständlichkeiten" zu überfordern.

> zu 1.:
> ich würde es gerne sofort parallel versenden, wenn es sinn macht und
> überhaupt möglich ist.

"parallel" kann es nicht versendet werden, da ja erst einmal 3
Meßwerte (a/d#1, A/D#2, A/D#3) eingelesen werden müssen. 3 macht aber
auch nicht richtig Sinn, dann lieber 30 oder 300 oder 3000 Meßwerte
einlesen. Da hast du mehr "Masse" zum komprimieren (falls du das
magst) oder zum Ermitteln einer gemeinsamen Prüfsumme (CRC, checksum).

> zu 2.:
> weiss auch noch nicht so recht wie das genau funktionieren soll, auf
> jedenfall das es eine quittung von empfänger gibt nach einem
> übertragenen block (mit assambler programmiert??). bin mir nicht
> sicher, aber habe gehört, das ich die daten mit hilfe von visual
> basic
> vom port abfragen kann, ginge das oder muss das im MC mit der
> quittierung programmiert werden??? wie geht das? denn mit VB wäre es
> einfach per DLL (aktive x) die daten zum auswerte programm zu
> schicken.

Ein "ordentliches" Handshake bzw. Steuerkommunikation zwischen den
beteiligten Partnern muß natürlich von beiden Seiten gewährleistet
sein. Über geeignete Handshake-Protokolle kanns du dir bestimmt
irgendwo was ergoogeln.

möglich wäre z.B:
PC > MC "jetzt gehts los, schick mir mal ganz viele Daten"
PC geht in Lausch-Position
MC sammelt 3000 Messwerte und übermittelt danach das Paket an PC
MC wartet auf erfolgreiche Quittung.
- "normalerweise" antwortet PC innerhalb von 1000 msek mit: OK, dein
Datenpaket mit Checksum xxx ist angekommen
MC vergleicht gesendete Checksum mit zurückgemeldeter Checksum, und
wenn alles ok, dann werden dei Daten aus dem Ausgangspuffer gelöscht
(genauer: Der Ringpuffer-Pointer wird umgestellt)
- wenn PC nicht innerhalb der erwarteten Zeit antwortet, dann nervt
ihn
MC > PC "was ist denn nun mit deiner Quittung ?"
falls PC nicht antwortet, dann ... (noch zu überlegen)

und so weiter. Du siehst, das ist alles nicht Prozessor-spezifisch, und
das kannst du in eine Hochsprache (sogar natürliche Sprache, brauch noch
nicht mal Programmiersprache) deiner Wahl artikulieren.


> 3.:
> was macht man bei solchen überläufen? da gibt es doch schon bestimmt
> schlaue methoden, oder? gehen die daten dann verloren?

Ja, wenn das Milchtöpfchen überkocht, ist die Milch verloren. Oder was
sollte damit sonst sein? HAst du etwa eine schlaue Methode entdeckt,
mehrere bits gleichzeitig in eine Speicherstelle reinzuquetschen?

> spare ich dadurch zeit, weil ich nicht ständig den Ringpuffer
> register wechsele? deswegen?

Deine Ringpuffer sind nicht im Register, höchtens (sofern du genügend
Register hast) Pointer zu irgerndwelchesn Speicherstellen, welceh
Ringpuffer realisieren. Aber deine Annahme ist ansonsten korrekt

> gibt es solche grossen puffer und wenn dann was für welche?
> SRAM wäre doch geeignet aber gibt es so grosse? kenne mich da
> überhaupt nicht aus?

Wieviel Speicher du anschließt hängt ein wenig vom verwendeten
Prozessor ab, aber "irgendwie" ist alles möglich. Die MC mögen zwar
nicht alles linear adressieren, aber da kann man ja hübsche
Page-Mechanismen implementieren.

Klar gibt es auch große statische RAM-Bausteine. google mal ein wenig

> wenn das die 10 minuten dauert ist nicht schlimm, hauptsache die
> daten kommen richtig an!!

Wenn deises wichtig ist, solltest du dir auch möglicherweise Gedanken
über eine Zeit-synchronisation machen, meint: Du willst ja nicht nur
"irgendwelche" z.B. 900.000 Meßwerte übertragen, sondern GENAU die im
Zeitfenster von

hh:mm:ss:0000 (tausendstel Sekunden) bis hh:mm:10:0000

also EXAKT die aus dem benannten Zeitfenster.

Ich nehme an deine Auswerteprogramme werden "zerwurschtelt" wenn da
zwischendurch ein paar Meßwerte fehlen

Bei z.B. einer Temperatur-Regelung wäre es nicht ganz so schlimm, wenn
da ein paar Meßwerte zwischendurch fehlen, da es sich bei einer
Regelung um eine träge STrecke handelt und da in der bestimmten
Milli-Sekunde nix gravierendes ändern wird, aber wie sieht es aus bei
deienr Anwendung?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.