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
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.
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 ??
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
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)
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 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
@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....
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.
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
@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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.