Was verstehst Du unter höherer Geschwindigkeit? Was verstehst Du unter empfindlich? Was hast Du für Kabellängen? Vermutlich nur kurze Strecken von im einstelligen m-Bereich, da Du was von USB und SPI schreibst.
Weisst Du überhaupt, was synchrone Anbindung/Übertragung ist? USB fällt garantiert nicht darunter und bei SPI hätte ich da auch gewisse Zweifel.
Also ich täte mir eine synchrone Übertragung nur noch über meine Leiche an. Das muss man nicht haben.
Nö, RS232 toleriert +-3 1/8 % in der Clockrate. So schlechte/falsche Quarze kriegst Du heutzutage garnicht mehr. Selbst RC Oszillatoren kriegt man besser hin.
Nun mal Butter bei die Fiche: wieviel Byte/sec musst Du denn übertragen? Kontinuierlich oder Burst?
Wenn Du bei den Leiterlängen Probleme mit RS232 bekommst, dann hast Du noch ganz andere Probleme!
Problem sind die Teiler, mit denen eine Standard-Datenrate nicht ganz genau hinzubekommen war. Vielleicht könnte eine Verbesserung erzielt werden, wenn mit einer nicht standardmäßigen Datenrate gearbeitet wird, dann kann man auf beiden Seiten genau(er) arbeiten.
Wie parallel bereits geschrieben: angepeilt sind 1 MBit/s. Das ist Faktor 20 zum bisherigen System.
Burst, d. h. Übertragung nach Anfrage durch PC-Applikation. Dabei kann es aber durchaus mal passieren, daß eine solche Übertragung aus mehreren Hundert Abfragen besteht (ca. 16 Byte), auf die eine Antwort von bis zu 1 kiB folgt.
Hmm, klingt ja gar nicht so schlecht. Allerdings schneidet der beim Stromverbrauch relativ schlecht ab. (Soll eine mobile, akkubetriebene Anwendung werden, die nur ab und zu kommuniziert.)
Speziell die 25 µA im Stop-Mode kommen mir im Vergleich zu anderen recht hoch vor. Evtl. wird das aber auch gar kein Problem darstellen.
Desweiteren müßte ich noch eruieren, ob sich der Pullup auf D+ selektiv abschalten läßt, wegen der Charging-Geschichte. (Vor dem USB-Connect muß die Hardware prüfen, ob ein Charging port vorhanden ist, das geht nur mit deaktiviertem Pullup.) Müßte aber mit
| This bit is used to completely switch off all USB-related analog | parts if it is required to completely disable the USB peripheral for | any reason. When this bit is set, the USB peripheral is disconnected | from the transceivers and it cannot be used.
erledigt sein.
Und preislich ist er auch erträglich.
Ich glaube, der ist grade in seiner Gunst etwas gestiegen.
Und da, wie ich soeben erfahre, MAX3420E ohnehin nicht mehr für neue Designs empfohlen wird (böse Panne, das zu übersehen), würde es anderweitig ohnehin schwierig...
Das käme hin, zumal da ja der externe USB-Chip entfallen könnte.
Ja, und genau das ist der Vorteil des UniversalAsynchronReceiverTransmitter im Gegensatz zur synchronen Datenübertragung. Hmm, ich merke, dass ich langsam alt werde. Die letzte synchrone DÜ hab ich etwa 1980 beerdigt :-) Es geht auf keine Kuhhaut, was man mit einer synchronen DÜ sich alles an Ärger einhandeln kann.
SPI ist ein Master Slave System, was nichts mit der klassischen Synchr. DFÜ zu tun hat. IIRC könnte man ISDN vermutlich auch dazu zählen, aber das ist auch mächtig kompliziert. Also lass ichs mal :)
Genau braucht es eben nicht zu sein +-3 1/8% also +-3,125% typisches Indianermass mit dem Bruch :)
Kannst Du für die UARTS einen externen gemeinsamen Clock anlegen?
Solange alle in dem +-3,125% Fenster der gemeinsamen nominalen Baudrate liegen, ist alles Paletti. Beispiel 38.400 Bd und 16fach Clock: (=614.440 Hz) da funzt alles mit Clocks zwischen rund 612,5 kHz und
633,6 kHz.
Das sollte bei Deinen paar cm Leitungslängen machbar sein, falls Du UARTs hast die mit 16 oder 32 MHz Clock arbeiten. Die machen typisch 16 bzw. 32 fach sampling eines Bitframes um eben den Jitter rauszuklabüstern. Hab keine Ahnung, wie hoch aktuelle UARTS kommen.
Undurchsichtige oder komisches Verfahren. Ist da eine Abfrage dabei, die den ganzen Kram startet? Oder ist das eine Wettrennschaltung? Warum dann nicht eine gezielte Aufforderung mit allen gewünschten Daten?
Oder kommt auf jede Abfrage mit 16 byte eine Antwort mit bis zu 1kB?
Oder generell zykl. Aussendung mit allen Daten und der Empfänger sucht sich selber das raus, was er will. Dann braucht es kaum Kommunikation.
Warum überhaupt 16byte = 128bit als Anfrage? Kann mir kaum vorstellen, dass es 2^128 verschiedene Antworten gibt. Da ist noch was mächtig undurchsichtig. Zumindest für mich, stellt sich die Frage: warum einfach, wenns auch umständlich geht! :O
Wenns stromsparend sein soll, nehme ich den MSP430. Gibts seit neuestem auch mit USB, habe ich aber noch nicht eingesetzt.
formatting link
Zur Zeit ist Ti aber ein Drama mit den Lieferzeiten :-(
MAXIM hat bei uns einen roten Balken. Darf nur eingesetzt werden wenn ein 100%iger second Source vorhandne ist (und dann auch lieber der second Source).
'Glatte' Datenraten wie 750 kBit/s oder 1 MBit/s gehen mit dem FT232RL problemlos. Sogar mit einer normalen WinAPI Anwendung, z.B. mit HTerm. Ich passe daher die Datenrate immer an die µC Taktfrequenz an ;-) Grüße Robert
Naja, mit gemeinsamem Clock wäre ich ja schon wieder synchron... Wäre evtl. machbar, aber eher schwierig.
Aber wie gesagt, der FT232 fällt eh flach, weil sich sein D+-Pullup nicht abschalten läßt. Wir werden jetzt wohl den Weg gehen, den Rolf vorgeschlagen hat.
Hmmm... wir hatten bereits bei 57600 sporadisch zusätzliche Nullbytes, die übertragen wurden...
Womöglich war das bislang das Problem, daß aufgrund zu geringer Taktfrequenz die Ungenauigkeit zu hoch war ("mangelnde Abtastbarkeit", wenn man das so nennen kann)
Bin mir nicht sicher, wie detailliert ich werden darf, aber es ist ein Frage-Antwort-Spiel, wo jede Nachricht in einem Frame steckt (Start- und Stop-bytes, CRC-gesichert)
Im Prinzip ja. Wobei die "großen" Antworten zwar anzahlmäßig in der Minderzahl sind (etwa 20%), aber zeitmäßig klar dominieren und in Zukunft potentiell noch größer als heute (Speicher auslesen).
Die 16 Byte war ein Richtwert, manche Kommandos sind auch kürzer (inkl. Framing 7 Bytes).
Auf den war ich im Zuge der Recherchen auch gestoßen, der ist aber für unsere Applikation mit etwas wenig Flash ausgestattet. Es hat sich auch herausgestellt, daß die 35 µA gar kein Problem sind. Daher nehme ich den ST, aber nicht den F105, sondern den 103er. Zwar kein USB OTG, sondern nur normales USB, dafür n paar andere Schmankerl.
Achte darauf, dass der 103 keine DA Wandler hat. Hattest du angesprochen, deshalb als Vorschlag der 105. Ansonsten ist der 103 ein nettes Teil. Habe damit schon ein paar Designs realisiert. Schau dir aber vorher die Erratas an. Nicht das gerade die Funktion, die du benötigst, eine Macke hat. Aber durch die einigermaßen Pin Kompatibilität kann man ja auf andere Derivate ausweichen.
Nein, synchrone DFÜ arbeitet völlig anders. Ganz grob: Man hat keine Start und Stopbits, also im Prinzip nur die Nutzdaten und die Daten sind dauernd synchron(isiert). Wenn aktuell keine Daten zur Übertragung anstehen, werden Fülldaten gesendet, damit die Modems nicht aus dem Tritt kommen. Das führt dazu, dass man im Mittel 1/2 Date zeitlichen Versatz hat, da ja immer auf den passenden Schlitz gewartet werden muss. Also im Mittel 4 bitclocks, was schlimmstenfalls fast 8 clocks werden kann.
Bei einer asynchronen Übertragung wird nur gesendet, wenn es was zu zu übertragen gibt. Dazu braucht man aber noch die Start und Stopbits für jede Date. Im Regelfall hast Du eben nur das Start und Stopbit abzuwarten und für ein Zeichen nur einen Verzug von 2 bitclocks.
Dh. für einzelne Bytes bist du wesentlich schneller, handelst Dir aber die zusätzlichen Start und Stopbits ein, also mehr overhead auf der Leitung, dafür ein simples Protokoll je Zeichen.
Bei synchroner DFÜ hast Du dafür einen deutlichen Mehraufwand auf der Treiberseite auch die Fehlersicherung ist deutlich aufwändiger...
Irgendwas stimmt da nicht, NULL-Bytes kenne ich nur von DEC in derem verpfuschten LA36 Betrieb und bei MIESENS in deren völlig vermurksten
3964R Protokoll. Wer NULL-Bytes braucht/benutzt, hat einen kräftigen Design-Fehler und das RS232 absolut nicht verstanden.
Übliche UARTs haben immer 16/32 fache Bitrate-Clock. Einige wenige hatten für den TX auch optional 1-fache Clockrate. Aber RX immer mit 16/
32 fach Abtastung.
Was soll das CRC Gedöns bei ein paar cm Leitungslänge bringen? Wenn Du da CRC Fehler bekommst, hast Du ein echtes Hardware Design Problem!
Sorry, erscheint mir alles recht unausgegoren für ein paar cm Leitungslänge. Alles nach dem Motto: Angst essen Seele auf!
Setz das Parity richtig (um Unterbrechung und Stuck abzufangen) und werte es richtig aus, dann hast Du bei den paar cm keine Problem.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.