ZitierenSind halt 9000 bytes pro sekunde, bei 30 FPS. Das ist schon machbar. Und ich sehe keinen echten Vorteil in I2C, weil der Bottleneck eh beim RS232 liegt. Auf dem Adapter sitzt überigens schon ein Mega8.
mhhh ein blick auf dein blog verrät mir das du also eine art bildmatrix hast und die schneller machen möchtest ... *grübel* ... also wenn du alle chips parallel anschliesst und einfach die datensätze für jeden chip hintereinander packst und den chips dann überlässt zu entscheiden WELCHES paket für ihn bestimmt ist, wird es so wahrscheinlich am effektivsten sein, aber es kann auch passieren das mal ein oder 2 byte flöten gehen und dann nur salat rauskommt, das ist dann das risiko! aber trotzdem seh ich die optimale lösung darin die daten "komprimiert/optmiert" über RS232 an einen controller chip über einen USB RS232 adapter zu senden der dann aus dem kompakten bilddaten die datensätze macht und dann per I2C sendet ... überlegenswert wäre hier ob du eine echte komprimierung mit ausreichend geschwindigeit erreichen kannst, weil der RS232 ist für bewegte biler doch etwas eng
Sind halt 9000 bytes pro sekunde, bei 30 FPS. Das ist schon machbar. Und ich sehe keinen echten Vorteil in I2C, weil der Bottleneck eh beim RS232 liegt. Auf dem Adapter sitzt überigens schon ein Mega8.
-> MEIN PROJEKTBLOG <-
naja wenn du auf absolute zuverlässigkeit pfeifst dann mach das mit dem parallel anschliessen, die bytes werden so oder so von den controllern empfangen(zumindest sollten sie 1 byte kurzzeitig speichern ... ich hab mich mit RS232 noch net auseinandergesetzt :P)
also was spricht dagegen einfach ein bild als frame/bytefolge zu senden und dann jeden controller so einzustellen das er einen bestimmten teil der übertragung nur auswertet der ihm zugeordnet ist ... du könntest praktisch 1 pin benutzen mit nem taster und dann die "kanäle" durchsteppen bis der controller den richtigen frame ausgibt und das dann im EEPROM speichern damit er beim nächsten start nicht neu eingestellt werden muss, sokanst du für alle controller dasselbe progg nehmen
dasselbe programm nehmen ist ja nicht so wichtig. ich werde das mal ohne chip-select testen und schauen, ob jeder controller seine daten selber rausfiltern kann. muss ja eigentlich nur mitzählen. nur ne fehlerkorrektur sollte man auch einbauen, falls mal ein byte verlorengeht. vllt den cs-pin (der nach meinem umbau am wochenende schon existiert) nutzen um allen controllern nach einem frame zu sagen "fangt mit dem zählen bei 0 an, ein neuer frame beginnt." dann hat man vllt mal nen frame mit fehlern, der die nachfolgenden frames aber nicht beeinflusst.
-> MEIN PROJEKTBLOG <-
zur not hintendrann nen crc byte berechnen ...die idee mit der signalleitung iss eigentlich auch nciht schlecht, evtl. könntest du ja multiplexen, mit jeder highflanke counten die chips mit, du sendest das datenpaket, alle empfangen es aber nur der angesprochene chip wertet die bytes auch aus, die anderen verwerfen die bytes ... ist das paket empfangen und die prüfsumme in ordnung, sendet der empfänger ein acknowledged signal ... ich merke grad das viele gedanken hier im topic schon in die richtung gegangen sind, aber je mehr ich dein projekt im detail kennenlern umso klarer wirds das direktes ansprechen besser sit aber eben unzuverlässiger ^^
eigentlich hast du recht, wenn du jedem chip per leitung sagst empfange oder empfange nichts wäre es wohl besser aber vom timing her würde ich mir keine gedanken machen, wenn du erst im register den einen pin auf low ziehst, dann den nächsten auf high, und dann erst mit der übertragung beginnst sollte es sich am empfänger schon auswerten lassen wer was empfängt
Ich versteh nicht so ganz, was du meinst. Ich dachte eher (wenn ich tatsächlich CS benutze) die Leitung so lange high zu halten, wie der Slave empfangen soll. Also quasi UART enable. Wenn der Pin nicht high ist, hört der Slave gar nicht mit.Zitat von Ceos
-> MEIN PROJEKTBLOG <-
naja das "nicht mithören" ist etwas problematisch, es könnte passieren das noch ein byte im eingangspuffer liegt und dann murks rauskommt, alle sollten schon bewusst die bytes empfangen aber eben alle nur empfangen und nicht auswerten, es sein denn die leitung ist high ... obs nun mit flanke(multiplex modus mit einer leitung) oder pegel(1 leitung je empfänger) läuft bleibt dir überlassen .. du kannst ja auch echte mux/demux nehmen und die selectleitung anpulsen die dann den pin für jeden chip einzeln hochziehen und wieder runterziehen aber das wäre schon fast wieder overkill ^^
Und wenn du die daten wie ein schieberegister reinschiebst?
Gruß
ceos: ich hatte schon geplant, nen schieberegister zu nehmen, um nachher alle CS-Leitungen getrennt per pegel anzusprechen.
thehawk: ?
-> MEIN PROJEKTBLOG <-
Berechtigungen
Lesezeichen