naja es sieht nicht so aus als ob er die baudrate oder frequenz des foxboard (ab von irgendwelchen standards)manipulieren kann und deshalb geh ich mal davon aus das es sehr exakt arbeitet !
wenn der AVR dann nciht präzise genug ist, kann es schon problematisch werden ?! ist doch dasselbe wie ein PC im prinzip und der macht bei steigender datenrate auch mehr zicken
Hallo nochmal!
Gut, ich bin so weit im BildeVielen Dank! Wie ich das Problem jetzt tatsächlich angehe, weiss ich noch nicht. Wenn ich etwas von Interesse zu Wege gebracht habe, werde ich gerne hier berichten.
@ceos: natürlich kann ich die Baudrate beim FoxBoard einstellen, wieso auch nicht!?
Gruß,
Malte
Mal ne Frage.
Reden wir hier über 250 kBit/s - Die sind für einen AVR mit 8MHz Quarz kein Problem, oder reden wir hier tatsächlich über 250 kByte/s was dann 2000 kBit/s wären ? Und da wirds eng.
Übertragungsraten werden üblicherweise in kBit/s angegeben - weil Du am Ende von einer Baudrate sprichst.
naja ich meinte du kannst im AVR das MCUCR register beschreibn und ne krumme baudrate einstellen die kein PC je versteht, das ginge beim foxboard nicht, und es schien mir, dass Besserwessi darauf hinaus wollte ?!
okok lassen wir daswill ja kein offtopic disput über die auslegung von sachverhalten anderer personen im vergleich zu mir halten XP
Hallo,
ich meinte genau das, was ich geschrieben habe, also 250 kByte/s, was in der Tat ca. 2 Mbit/s sind (s.o.)
Um die Sache mit der Baudrate nochmal klarzustellen: die Baudrate ist die Symbolrate und wird (strenggenommen) in Symbole/s gemessen. Theoretisch davon zu unterscheiden ist die Datenübertragungsrate, die wird in der Tat in Bit/s gemessen. Aber so lange die Einheiten stimmen, sind Namen ohnehin Schall und Rauch
Gruß,
Malte
ich denk 2 Megabit/s werden für nen AVR zu eng sein,
1 MBit/s sollen gehen, aber das Doppelte gleich
vermutlich nicht und wenn, dann hat er vermutlich
keine Zeit mehr für andere Geschichten dazu, dann
wird er komplett mit Datenübertragung belegt sein ...
Zähl mal die Zyklen, wieviele brauchst Du
um das UDR-Register zu beschreiben und u.U. noch
Daten aus dem RAM zu lesen bzw. Daten aus dem UDR lesen
und ins RAM zu schreiben ohne das noch n loop fürs
TXC-Register dabei wäre
Vor den Erfolg haben die Götter den Schweiß gesetzt
Die Rechenzeit wird knapp, aber man hat bei 16 Mhz Takt immerhin noch 64 Zyklen pro Byte. Da kann man duchaus noch was machen, zumindest in Assembler.
Hallo Vitis und Besserwessi!
Jo, das ist dann gleich das nächste Problem. Ich kann noch nicht genau abschätzen, wieviel Zeit ich noch neben der Datenübertragung brauche. Im Prinzip soll der AVR nichts anderes tun, als die einlaufenden Daten Puffern und mit präzisem Timing per SPI an einen 8-Kanal-16-Bit-DAC weiterreichen und dabei einige Triggerkanäle setzen. Ich bin mit meiner Planung aber noch ganz am Anfang, also ggf. ändere ich konzeptionell auch noch alles.
Dank Euch!
Malte
FPGA wird die Antwort auf die Geschichte sein denke ich
Vor den Erfolg haben die Götter den Schweiß gesetzt
Je nachdem wie Aufwendig die Triggerkanäle sind sollte das von der Geschwindigkeit gehen. Das Präzise timing könnte aber nicht ganz einfach werden, zumindestens in einer Hochsprache. Vom Umfang der Aufgabe sollte dafür wohl schon ein Mega48, Mega168 oder so reichen, da kann man dann bis 20 MHz takt gehen. Begrenzend ist da eher das RAM als das Flash.
Berechtigungen
Zitieren
Lesezeichen