www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Problem: SPI daten von mehreren slaves zum master! aber wie?


Autor: Martin S. (keniff)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (keniff)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anhang: Slave-Code

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(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...?

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

hoff es hilft weiter!

gruß keniff

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja und weiter? Das ist doch nichtssagend.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky wrote:
> Es wird keins geben. Sondern nur eine nebulöse Idee...

Ich hol dann schonmal den Bestatter für dieses Projekt.


Peter

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und zum glück ist sterbehilfe verboten! also ich werd noch nicht den 
löffel abgeben!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll noch mit den (un)verrechneten Werten geschehen?

Nur Anzeigen?

(Mensch, lass Dir doch nicht alles aus der Nase ziehen)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!)

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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..

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?^^

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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..

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, dann nimm die Idee als Grundlage und gucke obs brauchbar ist, ..

Das ist ja (von mir) noch nicht zuende durchdacht..

Nur als Ansatz...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.