hallo alle zusammen! zuerst bevor ichs wieder vergess^^: programmier mit avr studio in c auf stk500-board mit atmega128 und atmega32 sitz hier seit nun schon tagen an einem projekt, in dem ich gerne mehrere atmegas32 als slave über einen master (atmega128) auslesen möchte. war jetzt soweit, dass ich eine spi verbindung vom master zum slave hinbekommen hab... ziel ist es die vier slaves mit ner rate von 1kHz sozusagen zu samplen (slave hängt jeweils an einem sensor), sich die messwerte ausgeben zu lassen und dann auf nem touch-lcd anzeigen zu lassen. jetzt versuche ich, die kommunikation zwischen slave->master zu realiseren. oder besser gesagt, der slave sollte mir ein 0x04 senden, wenn er sein 0x02 vom master erhalten hat(code-anhang). nur wenn ich die empfangenen byte am master ausgeben möchte (über leds), bekomm ich immer nur die 0x02 angezeigt.also gibt der master scheinbar sein eigenen sendepuffer wieder aus anstatt das SPDR vom slave zu entpfangen! wobei das oszi auf der MISO-Leitung deutlich anzeigt, das daten gesendet werden, also denke ich, dass mein code irgendwo en fehler hat... das größte problem ist, dass jegliche beiträge hier im forum nur den datentransfer von master zum slave behandeln, und eben nicht andersherum. auch im datenblatt siehts da richtig mau aus und so fällts schwer nur ansatzweise weiterzukommen... hoff, dass ein paar ma so lieb wären und sich mein bisherigen code anschauen würden!mir stellt sich da auch die frage, wie genau ich das mit dem "samplen" machen soll? er muss ja 4 slaves jeweils mit 1kHz abfragen und sollte damit aber nicht durchgängig beschäftigt sein? sollte ich nun den master per zB timer die slaves abfragen oder wie würde eine fachgerechte lösung aussehen? fragen über fragen! könnt noch ewig so weiter machen... hoff ihr könnt mir irgendwie mit gutem rat zur seite stehen!!! gruß keniff
Hmm. SPIF wird gesetzt sobald der Master die 8 Bits rausgetaktet hat. Zu diesem Zeitpunkt kann aber die Antwort vom Slave noch gar nicht da sein! Der Slave hat doch gerade erst das Byte erhalten und muss darauf reagieren. D.h. Nach Absenden von 0x02 müsstest du noch ein Dummy Byte auf den Weg bringen, damit für den Slave der Übertragungskanal überhaupt geöffnet wird (Der Master taktet das Dummy Byte raus und gleichzeitig kann der Slave seine Antwort auf den 0x02 übertragen).
hey karl, vielen lieben dank für die antwort! ja, das mit dem dummy byte hab ich auch schon gelesen. deswegen heissen ja die var ja auch dummy und dummy2.^^ aber im master-code sende ich doch das 0x02 in ner schleife! also müsste zwar das erste byte als dummy durchgehen, aber spätestens beim zweiten senden, müsste das gelieferte SPDR dem 0x04 entsprechen wie im slave-code eingetragen ist, oder nicht? hatte jetzt nochmal in der slave ISR das schreiben auf und von SPDR vertauscht aber auch das macht keinen unterschied!also irgendwo, denk ich, ist noch en fehler beim master oder slave da ich aber übers oszi sehe das der slave was sendet, denk ich mal eher das problem liegt beim master-code wär echt froh wenns wär findet oder jemand rat hätte!!! gruß keniff
Du brauchst entweder ein Handshake oder ne Wartezeit. Wenn Du stur hintereinander sendest, kriegt der Slave immer ne Kollision. Das SPI-Slave der AVRs ist eigentlich unbrauchbar (kein Sendepuffer). Wenn möglich, steige auf I2C um, da hat man mit dem SCL-Stretching ein Handshake automatisch mit drin. Es kann also nie zu Kollisionen oder Datenverlust kommen, der I2C-Bus wartet immer auf den langsamsten Teilnehmer. Multimaster sollte man aber nicht nehmen, da ist bei den AVRs der Wurm drin. Also besser ein Master, der die Slaves abfragt. Peter
>(slave hängt jeweils an einem sensor), s
Das kommt mir irgendwie bekannt vor. Hatten wir das nicht vor ner Weile
diskutiert?
Da war doch die Idee, das mit einem µC zu machen...?
hey peter, danke für die schnelle antwort! hab zwar eig schon feierabend... denk ma du auch, aber egal ^^ kannst du mir das mit der kollision erklären? dachte master un slave senden parallel? der umstieg auf I²C wär möglich. hatte mich nur jetzt primär für spi entscheiden, weils schneller sein soll, und die anforderungen an das bus system das schon mitmachen sollten! hatte schonmal einen thread, der dir das projekt vllt kurz besser erklären kann: Beitrag "Bräuchte euren Rat/Denkanstoss für µC-Bus" atm steht zB die baudrate bei der übertragung von sensor auf einen der µCs bei 38400. hab aber mitbekommen (der chef sagt dem mitarbeiter^^), dass es nach möglichkeit auch ma ne baudrate bis über 400 000 sein soll. da denke ich das bus system sollte schon dampf dahinter hamm wenn der verstehst! ;-) gruß keniff
Martin S. wrote: > kannst du mir das mit der kollision erklären? dachte master un slave > senden parallel? Das SPI hat keinen Sendepuffer, d.h. der arme Slave müßte exakt nach dem 8. Clockpuls in den Interrupt springen, die Empfangsdaten auswerten und das Senderegister laden, bevor der 9. Clockpuls kommt. Er hat quasi schon verloren, bevor der Interrupt überhaupt angesprungen wurde. Ein Lösung wäre, daß der Master nach jedem Byte z.B. 1ms wartet, falls der Slave noch in nem anderen Interrupt hängt. Dann ist natürlich die Datenrate lächerlich. Peter
hey peda, > >Ein Lösung wäre, daß der Master nach jedem Byte z.B. 1ms wartet, falls >der Slave noch in nem anderen Interrupt hängt. Dann ist natürlich die >Datenrate lächerlich. > hmm, das is ja dann ma nix.wenn jeder sensor allein mit 1kHz sampled, dann wirds da en bissel eng ^^ aber wie würde man das denn sonst realisieren? denk ja nicht das ich der erste bin, der solch ein bus-system mit recht schnellen übertragungen braucht... > >Das kommt mir irgendwie bekannt vor. Hatten wir das nicht vor ner Weile >diskutiert? >Da war doch die Idee, das mit einem µC zu machen...? > ja, ich bräucht aber dafür 5 uarts, die dann eig nur per software-uart möglich wären, aber viel zu langsam sind, also fällt das wohl weg. was ist denn mit I²C / TWI ? sollte ich wirklich eher darauf umsteigen oder denkt wer, mit spi könnts auch klappen? bin dankbar für jede idee! gruß keniff
sooo, hab mich jetzt mal über alle möglichen bus-systeme informiert und bin grade am überlegen mal so richtig in die vollen zu gehn und entweder CAN oder RS485 als bus zu nehmen! I²C scheint zu unsicher und mit den max. 400kHz auch zu langsam. oder zumindest hart an der grenze. ich denk, rs485 ist mit seinen 10MHz da besser geeignet. naja, can oder zB ethernet find ich ehrlich gesagt zuuu profi-mäßig (extra can-treiber usw)^^ nichts das ich da was gegen hab, nur hab ich gehofft,dass das abfragen von 4 sensoren über mehrere µCs nicht ganz so schwierig/umfangreich sei? SPI hatte mir da echt zugesagt, nur is das ja mehr als en flopp, wenn die übertragung von slave zu master nur so besch... langsam geht. gibts da echt keine weiteren möglichkeiten für solch ein projekt? gruß keniff
>ja, ich bräucht aber dafür 5 uarts, die dann eig nur per software-uart >möglich wären, aber viel zu langsam sind, also fällt das wohl weg. Hallo? Wieso brauchst du jetzt dazu fünf UARTS? Bei deiner Multi-Atmel Konzept reicht doch auch ein µC mit UART und andere mit SPI oä.. Nimm einen µC. Der sampled alle Sensoren der Reihe nach ab und verschickt die Daten per UART. Hör mit dem Unsinn auf, für jeden Sensor einen µC zu verbauen, dern nur einlesen und SPI senden tut!
Hallo! also rechnen wir mal! du willst nur ein µC nehmen: 4 sensoren, die keine adressierung haben und nur über rs232 laufen. die jetzt alle an einen sensor, der nach deiner meinung nach denk ich mal alle per hardware uart steuert/sampled? das ganze bei atm 38400baud pro sensor?wie willst du die an einen uart hängen ohne adress leitung oder sonstigem? software uart scheidet bei den bedingungen ja generell aus. das projekt soll auch noch für andre sensoren laufen können, die da noch en bischen mehr fordern: da hätt dann einer ne samplerate von an die 4kHz und baudraten jenseits von gut und böse... ^^ erklär ma wie du das mit einem µC machst? hab glaub jetzt alle threads über haus-bus-systeme und ähnliches gelesen, nur selbst da sind immer die anforderungen an geschwindigkeit usw immer nur im 1200baud bereich. was ist wenn ich aber an die 1Mbaud brauch, das ganze x4, noch en eDIP als touch eingabe und vllt ne ethernet schnittstelle zum netzwerk betrieb und und und? ein atmega8 allein bringts da glaub nicht weit... hoff immer noch auf hilfe... gruß keniff
Martin S. wrote:
> was ist wenn ...
Daraus wird nichts.
Wenn Du die eierlegende Wollmilchsau willst, wirst Du scheitern, wie
schon viele vor Dir.
Du mußt konkret werden, also:
Was sind das für Sensoren?
Senden die von sich aus oder auf Anforderung?
Wie es scheint können die max einen Meßwert pro ms.
Brauchst du diese hohe Datenrate überhaupt?
Welche Datenrate brauchst Du wirklich?
Für eine Displayausgabe brauchst Du sie nicht, kein Mensch kann 4
Meßwerte pro ms ablesen. Ergonomisch ist ein Wert pro 200..500ms.
Also Multiplexer vor die UART und alle der Reihe nach lesen. Das ist
immer noch viel zu schnell, also nochn Delay dazu bis 200ms rum sind.
Fertig ist die Laube.
Peter
Du hast recht. Dazu ist mindenstens ein Core Duo mit 4x PCI UARTs nötig.
Man Junge, erzähl doch mal was genaues.
Beantworte mal die Fragen von peda.
Die Zeit, die du in die sinnlosen Überlegungen zur
Inter-µC-Kommunikation gesteckt hast, hättest du nutzen sollen, um diese
Informationen zu sortieren und ein ordentliches Softwarekonzept für
einen µC zu überlegen...
>das projekt soll auch noch
Was denn für ein Projekt? Worum geht es da bei den Sensoren überhaupt?
Wir sitzen nicht neben dir. Wir wissen nur das was du erzählst.
hey peda, ja klar! die eierlegende wollmilchsau oder ein schmu wären super! nur gibts die ja leider nicht... ^^ deswegen frag ich ja wegen bus-systemen usw, da ich denk dass das alles ein µC niemals schafft. das ich das lcd niemals mit solchen raten aktualisieren kann ist mir schon klar... wenn das auge nur 20 bilder pro sekunden verarbeiten kann blabla.... aber darum gehts nicht! die firma in der ich atm arbeite, wirbt eben mit dieser messgenauigkeit, da sie für manche firmen der autoindustrie scheinbar doch relevant ist... das mit den anforderungen: wie gesagt, die sensoren können nur rs232. sie samplen mit ner rate von 1kHz (die auch verwertet werden sollen) und hat keine adresse, noch ein befehl den sensor per befehl zum senden eines messwert zu überreden. erschickt einfach dauerhaft... da aber auch andre sensoren an das system in ferner zukunft angeschlossen werden sollen, such ich eine lösung die auch höheren anforderungen stand hält! aber wenn dus konkret willst, was eben nur atm verwendet wird: http://www.micro-epsilon.com/products/displacement-position-sensors/optoNCDT_ILD/optoNCDT_1401/index.html hoff es hilft weiter! gruß keniff
Ok. Habe das Datenlatt mal überflogen. Jetzt *zus#tzlich* zu pedas Fragen noch folgende: - Was soll die SDchaltung mit dem µC jetzt genau machen? - Wieviel Sensoren soll diese Schaltung bedienen?
@matthias dann erzähl doch ma wie solch eine software lösung aussehn soll... du magst bus-systeme nicht so oder? ^^ und atm laufen die sensoren an nem intel pc, und genau das soll sich ja ändern... weiter oben ist ein link zu dem andern thread von mir, und vielmehr gibts bei dem projekt dann eig auch nicht mehr zu erklären! naja, hoff du kannst mir entweder das mit software lösung erklären oder hast noch ne andre idee parat? ne andre wär mir lieber ,-) wie gesagt, ich geb die hoffnung noch nicht auf! gruß keniff
Martin S. wrote: > aber darum gehts nicht! die firma in der ich atm arbeite, wirbt eben mit > dieser messgenauigkeit, da sie für manche firmen der autoindustrie > scheinbar doch relevant ist... Schön, daß wir nun wissen, worum es nicht geht. Kann bloß keiner was mit anfangen. Aber nicht wir sind es, die Hilfe suchen. Was hat die Datenrate mit der Meßgenauigkeit zu tun? Wenn Du selber nicht weißt, welche Datenrate Du brauchst, dann hast Du ein Problem. Dann ist es zum Programmieren noch zu früh und Du solltest wieder zurück ans Pflichtenheft gehen. Peter
>du magst bus-systeme nicht so oder? doch. ich hab sogar beruflich damit zutun. und hab auch schon über Ethernet mehrere SPS miteinander vernetzt. Das ist aber Aufwand, weil du ein eigenes Protokoll brauchst, wie du welche Daten wann übertragst. >und atm laufen die sensoren Was heißt immer diese atm? >das mit software lösung erklären Ja, aber erstmal muss ich wissen, was diese zu entwickelnde Schaltung mit den mehreren (wieviel denn) Sensoren tun soll? Ich fasse mal zusammen: >> lasersensor (wahlweise bis zu vier!)der mir über rs232 >>(jeweils 2 byte pro messwert) (*stimmt das wirklich? Datenblatt*) @ 1ms >>die dann verrechnet und auf nem lcd (eDIP240) angezeigt werden müssen. >atmega128)aber der wird denke ich maßlos überfordert Das bekommt der schon hin. Frage: Welche Verrechnung muss mit diesen 4Messwerten gemacht werden? Und wie oft? Nur zur Anzeige? Also 2..10mal pro Sekunde? Oder müssen diese Daten weiterversendet werden? Achja, und wie soll das LCD-Display an den µC angeschlossen werden? RS232, I2C, parallel?
hey matthias, mit den (mehrzahl) µCs meinst du wohl! ;-) nee, scherz bei seite, die schaltung soll mit max datenrate der 4 sensoren(bis jetzt noch, kann glaub auch noch auf 6-7 steigen), diese auslesen, verrechnen (schicken 2-3byte die dann auch verrechnet werden wollen), auf nem display anzeigen und bestenfalls an ein richtiges netzwerksystem angeschlossen werden (ethernet oder usb zB)!
Ja und weiter? Das ist doch nichtssagend.
Matthias Lipinsky wrote:
> Ja und weiter? Das ist doch nichtssagend.
Mir fällt dazu auch nichts mehr ein.
Ich geh ja auch nicht 20-mal am Tag zum Supermarkt einkaufen, weil ichs
kann. Sondern ich gehe genau nur so oft, wie nötig.
Da ist irgendwas grundsätzlich faul im Pflichtenheft, so kann man
einfach nicht vernünftig entwickeln.
Peter
>Da ist irgendwas grundsätzlich faul im Pflichtenheft, so kann man >einfach nicht vernünftig entwickeln. Es wird keins geben. Sondern nur eine nebulöse Idee...
danke für die idee mit dem pflichtenheft, aber ausbildung hab ich leider schon lang hinter mir! wenn du mich frägst, ob ich die datenrate überhaupt brauche und ich sage: jaaa, weil die firma in der ich arbeite damit wirbt und sie benötigt wird, auch wenns klar ist, dass ich das display nicht in der rate samplen muss. und dann meinst, dass interessiert doch keinen, dann frags doch nicht @matthias: atm = at the moment = im moment ja die daten müssen nach möglichkeit weiterverrechnet werden, auch gerne unverrechnet (also einfach die 2-3bytes), aber sollte schon möglich sein! wenn du damit beruflich zu tun hast? warum rätst du mir so stark von nem bus-system ab? ne erklärung wär nice bin hier nicht auf kriegsfuss und weiss, dass ich der hilfe-suchende bin, aber solche kommentare wie: >Dann ist es zum Programmieren noch zu früh und Du solltest wieder zurück >ans Pflichtenheft gehen. gehn mir einfach nicht rein! sorry
Matthias Lipinsky wrote:
> Es wird keins geben. Sondern nur eine nebulöse Idee...
Ich hol dann schonmal den Bestatter für dieses Projekt.
Peter
dann stellt konkreter fragen wenn ich sie euch zu belanglos beantworte! würd ich zu gern machen, da ich ja echt auf eure hilfe bau, aber was wollt ihr denn genau noch wissen???
und zum glück ist sterbehilfe verboten! also ich werd noch nicht den löffel abgeben!
>dann stellt konkreter fragen >>Frage: Welche Verrechnung muss mit diesen 4Messwerten gemacht werden? >>Und wie oft? Nur zur Anzeige? Also 2..10mal pro Sekunde? Oder müssen >>diese Daten weiterversendet werden? Formel?? >wenn du damit beruflich zu tun hast? warum rätst du mir so stark von nem >bus-system ab? ne erklärung wär nice Weil ich das hier nicht für innvoll erachte. Ich habe mal (in Studi-zeiten) folgendes erlebt: Es wurde eine Schaltung entwickelt mit einem µC, der politisch festgelegt wurde. Da dieser aber alle Aufgaben nicht schaffte, musste ein zweiter auf dieselbe Platine. Es verging viel Entwicklungszeit, damit die Komm. zwischen beiden sauber lief. Nur weil einer billiger war, als der andere... Das zwei benötigt wurden, und viel zusatzbeschaltung und Entwicklung wurde nicht gesehen... (PS: Komm bitte nicht mit Firmengeheimnis. Dann kann dir hier niemand helfen. Das ist hier schließlich kostenlos, und du/Firma verdienst damit Geld)
@peda: >Ich geh ja auch nicht 20-mal am Tag zum Supermarkt einkaufen, weil ichs >kann. Sondern ich gehe genau nur so oft, wie nötig. Hab ich schon erlebt: Wir bauen ein spezielles I/O-Modul für eine SPS. Prozessdatenbreite 2Kilobyte. Nur wenige davon (ich schätze ca 50Bytes) ändern sich zyklisch. Trotzdem wurden die kompletten 2KB einmal pro Buszyklus (1ms) übertragen. Warum? Weil wir es können.. ;-( Aber nach mehreren solchen Modulen war selbst dieser Bus zu... Jetzt ist aufräumen angesagt...
Du willst also die Daten nur deshalb maximal reinschaufeln, weil es ein Werbegag ist. Dann stellt sich aber sofort die andere Frage, wohin mit dem ganzen Datenwust, etwa ins Null-Device? Der AVR ist da schon knirsch auf Knack, da brauchts dann richtige 32Bit-Datenschaufler (z.B. ARM Cortex M3) mit richtig dickem SRAM zum puffern und Ethernet on Board. D.h. das schnelle Einlesen ist garnicht das Hauptproblem. Wenn Du also nen Werbegag haben willst ohne erkennbaren Nutzeffekt, dann mußt Du richtig dicke CPUs nehmen. Peter
Martin S. wrote: > wenn du damit beruflich zu tun hast? warum rätst du mir so stark von nem > bus-system ab? ne erklärung wär nice Weil Multi-µC immer einen grossen, neuen Sack, neuer Probleme aufmachen, die man nicht hätte, wenn man nicht unbedingt drauf steht sagen zu können, dass in diesem System x-Prozessoren zusammenarbeiten. Der Schwierigkeitsgrad mit x-Prozessoren steigt nicht linear! Ein System aus x-Prozessoren am Leben zu halten ist nicht x-mal so schwer wie nur einen einzigen Prozessor zu haben, sondern eher kommt das x in den Exponenten. Wenn es nicht unbedingt sein muss, dann lässt man sowas lieber bleiben. Wie du schon gesehen hast, kann einem alleine die zuverlässige Kommunikation zwischen den Prozessoren graue Haare bescheren. Und das war erst der Anfang. Viele gehen so dermassen blauäugig in so ein Projekt hinein. "Och, da nehmen wir einfach mehrere Prozessoren" "Jaaa, cool" Während des Projekts sind sie dann hochgradid suizidgefährdet und wenn das Projekt dann endlich durch ist, sind sie um Jahrzehnte gealtert.
sry formel, wie sie im atmega-code im moment drin steht könnt ich erst morgen auf arbeit posten oder du schaust kurz im datasheet des sensors. weiss aus em stehgreif dass ich zuerst das höhere byte mit dem niedrigern byte per bit-operanten zusammenfügen und dann ne recht simple mathematische rechnung (alla n = n *3 / 4000) durchführen. wenn du sagst das ist für ein 128er kein problem (der langweilt sich) dann wär ich echt froh darüber, nur kann ichs nicht ganz glauben und ps: keine sorge, wenn ich hier en betriebsgeheimnis hüten müsste, würd ich kein code posten^^ s.o. ich weiss, dass es hier kostenlos ist, auch wenn nach meiner meinung wie ne visa karte! einfach unbezahlbar! welche infos wären noch relevant? gruß keniff
>welche infos wären noch relevant?
Was mit den verrechneten Werten der 4(8) Sensoren geschehen soll?
Nur ANzeigen? Dann muss nur max. 10mal pro Sekunde gerechnet werden..
Oder was noch?
Martin S. wrote:
> mathematische rechnung (alla n = n *3 / 4000) durchführen.
Das lohnt dann ja kaum, dass der Mega seine Arithmetik Einheit anwärmt.
Das macht der mit links, während zb. die UART-Einheit in Hardware das
nächste Byte reinschaufelt.
und nein! das soll kein werbegag werden, sondern sit einfach meine aufgabe die mir mein chef aufgetragen hat! ich geb zu, dass warum dir jetzt genau sagen zu können, wär mir zu hoch, da ich in der materie noch nicht lang genug drin stecke, aber ich frag morgen gern den kollegen, der mir lang und breit erklären kann, warum diese raten doch benötigt werden! also auf graue haare hab ich jetzt noch keine lust! wenns mit einem gehn sollte gerne, nur wie?
Was soll noch mit den (un)verrechneten Werten geschehen? Nur Anzeigen? (Mensch, lass Dir doch nicht alles aus der Nase ziehen)
Karl heinz Buchegger wrote: > Martin S. wrote: > >> mathematische rechnung (alla n = n *3 / 4000) durchführen. > > Das lohnt dann ja kaum, dass der Mega seine Arithmetik Einheit anwärmt. Ich würds auf n = n * 49UL / 65536 umstellen, dann entfällt die Division. Peter
den grund warums benötigt wird kann ich dir nicht nennen (is ja jetz auch schon spät, gähn^^), aber es gibt ihn! nein, nicht nur anzeigen, sondern auch weitergeben zB über ethernet/usb/rs232 an en andres netz...
>wenns mit einem gehn sollte gerne, nur wie?
ALso, mal einen Denkanstoß/Diskussionsgrundlage
2x TL 16C554 FN (reichelt)
Das ist ein UART mit 4 Schnittstellen und FIFO.
Den würde ich parallel(8bit) an einen µC mit SRAM als
memory-mapped Device verschalten. Zwei Stück garantieren
dir 8xRS232, gepuffert. Somit kannst du paar Datenpakete
zwischenspeichern, bevor du sie ausliest. Das Auslesen
ist wie ein Lesezugriff auf eine Varaible (da memory-mapped)
1x Atmel mit SRAM Interface
1x eDIP240
Wenn ich richtig gelesen habe, wird das per RS232 angesteuert.
Da kannst du die interne im µC nehmen. Ich (persönlich) verbaue
lieber LCDs mit parallel (8bit). Die blende ich ebenfalls in
den SRAM ein. Das spart Zeit und Zugriffe in der Software. ISt
aber eine Philosophifrage..
PS: Bevor jetzt sowas kommt wie: zu aufwändig, zu teuer (das IC):
Von nichts kommt nichts. Die EiWoMiSau kostet auch Geld. (Und wird den
Erfinder sicherlich zum steinreichen Mann/Frau machen!)
nenene, würd dich grad lieber küssen! kein witz! ^^ dein denkanstoss werd ich morgen zerpfücken und aufs übelste auseinandernehmen! ;-) die möglichkeit eines ICs der mir den uart auf mehrere erweitert, wurde mir auch schon nahe gelegt, aber wurde (vllt leider zu früh) wieder verworfen! wie gesagt, das is ja da kein normales rs232 mit 9600-8-n-1 sondern eher richtung an die 1Mbaut oder höher! ist das mit solchen bausteinen auch machbar?
>das is ja da kein normales rs232 mit 9600-8-n-1 sondern eher richtung an >die
1Mbaut oder höher!
Moment. Der Sensor macht 38k4.
Du musst die Daten ja intern auch abholen und handeln können.
Und ein Megabyte pro Sekunde, da ist der Atmel wirklich an der Grenze..
Aber die Sensoren senden ja nur (sagen wir mal) je 10Bytes pro ms. Das
sind 80kByte je Sekunde.
Das ist sportlich. Deshalb die Frage, was soll damit geschehen..
naja, wie gesagt, es gäb da auch noch andre sensoren die zB auf ner baudrate von 921,6kbaud laufen, also wenn die drann wären, wär da ja denfinitiv finito! was mach ich mit solch apparaten?^^
>baudrate von 921,6kbaud laufen,
Überlegen, ob das wirklich benötigt wird!
1000Messwerte pro Sekunde wollen erstmal verarbeitet werden.
Bei vielen Prozessen ist das allerdings recht sinnlos.
Im Rahmen der z-Transformation haben wir mal als Faustregel bekommen:
Die Abtastfrequenz (also die des Sensors) sollte mind. 10mal größer
sein, als die kleinste Zeitkonstante der Strecke/des Prozesses.
Das sollte erfüllt sein, aber das heißt nicht, 10'000 mal...
Also:
Was messen die Sensoren? Wie schnell muss reagiert werden..
Diese Fragen musst du zuerst klären. Danach kannst du dir über die
Hardware Gedanken machen..
morgähn! ok, shame on me. hätt doch vorher erstma richtig mein chef ausquetschen sollen^^ ne rate von 0,01/sec würde auch reichen und die 4 sensoren sollen zwar mit 1kHz aufgenommen werden, aber eben gemittelt werden auf die 0,01rate was die anforderungen an die übertragung denke ich wesentlich leichter macht. da hört sich deine idee mit uart baustein doch gleich mal viel netter an! ;-) sorry wenns jezt unnötiges kopfzerbrechen war, aber fands trotz allem doch sehr informativ!^^ gruß keniff
Naja, dann nimm die Idee als Grundlage und gucke obs brauchbar ist, .. Das ist ja (von mir) noch nicht zuende durchdacht.. Nur als Ansatz...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.