Hallo zusammen, ich möchte einen sehr schelles RS-485 Bussystem mit bis zu 10 Teilnehmern entwickeln und befinde mich z.Z. in der Konzeptfindungsphase und prüfe die Machbarkeit. Mein Anforderungsprofil ist folgendes: 1. Zwei-Draht RS-485 Phy.Bus mit Uart Kommunikation > 4Mbps 2. Übertragung von Datenblöcken mit bis zu 1k in beide Richtungen 3. Variable Blocklänge 4. Datenrahmen ist 8,1,even und die Sicherung soll per BCC checksumme erfolgen 5. In der Initialisierungsphase soll die Kommunikation nur mit 115kbits stattfinden 6. Die Anfrage und Antwortlatenz soll so klein wie möglich sein (Datenblock -> 50us -> Datenblock -> 50us ->...meine Vorstellung!?) Für mein bisheriges Verständniss muss ich für die Controllerauswahl (Master/Slave) folgenden Dinge berücksichtigen. 1. Hat Uart's mit hoher Baudrate und genug oversampling 2. Interne möglichst grosse sende und empfangs FIFO's 3. Eine sehr gute DMA unterstützung und schnelle Interruptzeiten 4. genug RAM für die Puffer 5. Der Slave soll eine möglichst kleine Bauform haben und preislich günstig zu bekommen sein Meine bisherige Recherche haben mich auf die NXP und Stellaris Cortex M3 serie geführt. STM32 fällt wegen fehlender FIFO's und mässiger DMA transferleistung ohne Burstfunktion durch. Wie gut Pic und andere Kontroller diese Anforderung bewerkstelligen können weiss ich eben nicht. Deshalb meine Frage an euch: 1. Welche günstigen Controller könnt ihr mir für diese Anforderung empfehlen (Cortex, PIC...), wenn ja warum? 2. Die Blockendetriggerung bei verwendung variabler Blocklänge und DMA macht mir etwas Kopfschmerzen, ich bin immer noch auf der Suche nach einem optimalen Verfahren für diese Anwendung? 3. Habe ich konzeptionell etwas wichtiges übersehen? Gruss
Klingt, als ob du 10Base-T schlechter (asynchron) neu erfinden willst. MfG Klaus
> Klingt, als ob du 10Base-T schlechter (asynchron) neu erfinden willst.
Ich will eben nicht etwas neues erfinden, sondern vielmehr etablierte
Technik für meine! Bedürfnisse optimal ausnutzen!
d.H.
einfacher Aufbau, Kostengüngstige Verdrahtung, sehr schnell, Busfähig,
störunempfindlich und eine mit wenigen standard Bauteilen realisiertbare
Schnittstelle...
magic schrieb: >> Klingt, als ob du 10Base-T schlechter (asynchron) neu erfinden willst. > > Ich will eben nicht etwas neues erfinden, sondern vielmehr etablierte > Technik für meine! Bedürfnisse optimal ausnutzen! Willst Du doch! Sehr schnelle UARTs, Geschwindigkeiten umschalten, eigener Protokollstack, ... Bei Ethernet (10Base-T oder besser) werden all Deine Wünsche erfüllt.
Rein aus meiner Erfahrung: PIC32 kann was du willst, allerdings beim Empfangen mit der variablen Blocklänge wirst du 2 DMA-transfers nacheinander (erster bis du aus deinem Header die Länge hast, zweiter für die Nutzdaten) brauchen. Dafür gibts beim DMA-Modul gleich eine schnelle Hardware CRC dabei. Bei Ethernet fallen mir auf die Schnelle viele Nachteile ein: Mehr Drähte Mehr Stromverbauch Mehr Ressourcen im µC (mehr Stromverbauch im µC)
muss es ein 32-Bitter sein? Es gibt da noch die xmegas von Atmel. Die können 4MBaud, haben DMA und sind recht gut zu bekommen.
Michael H. schrieb: > Mehr Drähte 1 Draht, RS485 braucht 2 + Masse hat dafür aber keine galvanische Trennung MfG Klaus
Nee. Ethernet, zumindest 100MBit hat 2 Paare. Das 1 Draht Ding was noch das 10BaseT. Mit Koax.
Klaus schrieb: > 1 Draht, RS485 braucht 2 + Masse hat dafür aber keine galvanische Trennung Hab ja nie behauptet das es 8 wären ;) Wobei mit Standard-Steckern eigentlich immer auch die 8-Draht-Variante benutzt wird. Galv. Trennung gilt je nach verwendetem Tranceiver, von linear gibts einige getrennte. PIC24EP wären übrigens auch OK, 16bit und DMA. xMega sind bei diesen Datenraten nur brauchbar wenn das kein kontinuierlicher Datenstrom ist, sonst ist man schnell am Ende der Leistung. Eventuell auch einer mit AVR32 Kern
Delta Oschi schrieb: > Nee. Ethernet, zumindest 100MBit hat 2 Paare. Das 1 Draht Ding was noch > das 10BaseT. Mit Koax. Falsch verstanden: RS485 2 + Masse, Ethernet 2 + 2, also 1 Draht mehr. MfG Klaus
Ethernet, half duplex braucht nur ein Leitungspaar.
> Ethernet, half duplex braucht nur ein Leitungspaar.
-v, bitte.
Nach meinem Informationsstand braucht auch 10BaseT 2 Leitungspaare.
Deshalb gab es damals auch Crossover Kabel, weil TX und RX getauscht
werden mussten um 2 PCs ohne Hub zu verbinden.
Hallo Ethernet sehe Ich auch als aufwendiger an. Weniger die Zahl der Leitungen als der dazugrhörige Rechenaufwand. Einen TCP/IP Stack würde ich schon in einem 32-Bitter unterbringen wollen. Bei RS232/RS485 Verbindung ist ein 8 Bitter schnell genug. Ich würde bei 485 immer an CAN denken. Es gibt inzwischen preiswerte Chips, CAN ist wie 485 nur besser (Kollisionserkennung) und im Protokol weitgehend standartisiert. Gruß Klaus
>Rein aus meiner Erfahrung: PIC32 kann was du willst, allerdings beim >Empfangen mit der variablen Blocklänge wirst du 2 DMA-transfers >nacheinander (erster bis du aus deinem Header die Länge hast, zweiter >für die Nutzdaten) brauchen. Dein Vorschlag geht schon in die richtige Richtung. Zuerst den Header auswerten, Bytecount ermitteln und den DMA Controller neu initialisieren. Aber der was passiert mit einlaufenden Zeichen während ich den DMA controller neuen init., geht das "on the fly" ohne Nebenwirkungen (Zeichenverlust oder Zeichen-Count stimmt nicht)? Der Ende-Interrupt muss zuverlässig ausgelöst werden, sonst ist das Verfahren ungeeignet!!! >Dafür gibts beim DMA-Modul gleich eine schnelle Hardware CRC dabei. Die Prüfsummenbildung kann auch CRC sein , diese ist aber in software etwas aufwendiger und bei Verwendung von Hardware würde ich mich beim der uC auswahl einschränken Den PIC32 sehe ich mir mal etwas genauer an -> hoffentlich gibt es sie auch in kleinem package und zu kleinen Preis? >Bei Ethernet fallen mir auf die Schnelle viele Nachteile ein: >Mehr Drähte >Mehr Stromverbauch >Mehr Ressourcen im µC (mehr Stromverbauch im µC) Das sehe ich genauso, nicht zu vergessen spezial uC mit Mac-Hardware, evtl. phy chip definition der MAC Adresse... Deshalb möchte ich eben kein! Ethernet >PIC24EP wären übrigens auch OK, 16bit und DMA. xMega sind bei diesen >Datenraten nur brauchbar wenn das kein kontinuierlicher Datenstrom ist, >sonst ist man schnell am Ende der Leistung. Eventuell auch einer mit >AVR32 Kern Es muss nicht unbedingt 32 Bit, für mich sind folgenden Punkte wichtig: 1. Der Chip muss verfügbar sein, am besten nicht schon nach 2 Jahren abgekündigt werden. 2. Wenn doch, dann sollte zumindest PIN kompatibler Ersatz verfügbar sein, um frühzeitiges redesigne zu vermeiden 3. Kostengünstig für die Slaveanbindung >Ethernet sehe Ich auch als aufwendiger an. Weniger die Zahl der >Leitungen als der dazugrhörige Rechenaufwand. Einen TCP/IP Stack würde >ich schon in einem 32-Bitter unterbringen wollen. >Bei RS232/RS485 Verbindung ist ein 8 Bitter schnell genug. >Ich würde bei 485 immer an CAN denken. Es gibt inzwischen preiswerte >Chips, CAN ist wie 485 nur besser (Kollisionserkennung) und im Protokol >weitgehend standartisiert. Can habe ich zwar auch schon in betracht gezogen, aber für meine Anwendung mit dieser Blockgrösse halte ich es nicht für nicht geeignet.
magic schrieb: > 1. Zwei-Draht RS-485 Phy.Bus mit Uart Kommunikation > 4Mbps Klaus Kloos schrieb: > Bei RS232/RS485 Verbindung ist ein 8 Bitter schnell genug. 4Mbps auf einem 8-Bit-µC per UART? (dezentes Hüsteln)
nenene schrieb: > 4Mbps auf einem 8-Bit-µC per UART? > (dezentes Hüsteln) :-) da hast du nicht ganz unrecht. Das habe Ich ignoriert. Der Silabs C8051F580 (schneller 8Biter mit CAN) kann bei 50MHz Takt immerhin 3,1Mbps wenn Ich das Datenblatt richtig interpretiere. Ausprobiert habe Ich es nicht. Über CAN gehen dort 1Mbps. Das ist aber immer noch unter den Anforderungen. Gruß Klaus
magic schrieb: > Den PIC32 sehe ich mir mal etwas genauer an -> hoffentlich gibt es sie > auch in kleinem package und zu kleinen Preis? Werbetrommel rühr: PIC32MX1 und MX2 gibts im QFN28 Package. Sind aber im Gegensatz zu den anderen PIC32 nur bis 40MHz geeignet (reicht aber wohl locker). magic schrieb: > Aber der was passiert mit einlaufenden Zeichen während ich den DMA > controller neuen init., geht das "on the fly" ohne Nebenwirkungen > (Zeichenverlust oder Zeichen-Count stimmt nicht)? > Der Ende-Interrupt muss zuverlässig ausgelöst werden, sonst ist das > Verfahren ungeeignet!!! Also das ist eine zu spezifische Frage, das kann ich nicht beantworten. Wenn du allerdings mit deiner Auswertung unter der Dauer des Empfangs eines Bytes bleibst, dann passiert nichts, weil das Zeichen dann noch im UART-Buffer hängt und gar nicht beim DMA ist. Schnell überschlagen: 4Mbit -> 8N1 -> 2,5µs / Zeichen -> 100 Takte bei 40MHz CPU-Takt. Könnte sich also ausgehen. Je nach verwendetem PIC32 gibts beim UART auch noch ein FIFO der weiterempfängt während du den DMA-Interrupt abarbeitest.
magic schrieb: > Dein Vorschlag geht schon in die richtige Richtung. Zuerst den Header > auswerten, Bytecount ermitteln und den DMA Controller neu > initialisieren. > Aber der was passiert mit einlaufenden Zeichen während ich den DMA > controller neuen init., geht das "on the fly" ohne Nebenwirkungen > (Zeichenverlust oder Zeichen-Count stimmt nicht)? > Der Ende-Interrupt muss zuverlässig ausgelöst werden, sonst ist das > Verfahren ungeeignet!!! Wenn jetzt ein Fehler im Bytecount ist, ist es aus mit der Zuverlässigkeit. Das kriegt sich nie wieder ein. So wie früher ein Fehler im Header beim Graphikdrucken, Seitenweise sinnlose Zeichen. Asynchron und ungeframed ist ungeeignet, daher macht es sonst auch keiner. MfG Klaus
10Base2 kann ja immerhin bis zu 10 MBit brutto.
Dennis Heynlein schrieb: > 10Base2 kann ja immerhin bis zu 10 MBit brutto. Ja, geframed und synchron MfG Klaus
Michael H. schrieb: > Werbetrommel rühr: PIC32MX1 und MX2 gibts im QFN28 Package. Sind aber im > Gegensatz zu den anderen PIC32 nur bis 40MHz geeignet (reicht aber wohl > locker). Sehr interessantes package für die Slavemodule und nach erster Sichtung des Datasheets für den Uart: FIFO,s max 10 Mbps, DMA und 9 Bit Modus! mit Interrupt. Das erste Zeichen des Telegrammheaders ist immer ein Adressebyte 9 Bit und das Ende ebenfalls. Zwischendurch werden alle Empfangsdaten per DMA in den Speicher transportiert :-) Ist die Verwendung des 9 Bit Modus unabhängig vom Frame mit Parity bildung? 1 Startbit/9 Bit Data/1 Parity/1 Stoppbit....hmm Klaus schrieb: > Wenn jetzt ein Fehler im Bytecount ist, ist es aus mit der > Zuverlässigkeit. Das kriegt sich nie wieder ein. So wie früher ein > Fehler im Header beim Graphikdrucken, Seitenweise sinnlose Zeichen. Wenn es ein Fehler im Bytecount gibt, kann es nur eine Softwarefehler sein. Der Bytecount muss natürlich passend sein. Des weiteren ist beim DMA transfer die Überschreitung der maximalen Framegrösse zu prüfen und der Datensatz zu verwerfen. Bei nicht korrekter Prüfsumme ebenfalls. Klaus schrieb: > Asynchron und ungeframed ist ungeeignet, daher macht es sonst auch > keiner. Was meinst du mit "ungeframed"? Dennis Heynlein schrieb: > 10Base2 kann ja immerhin bis zu 10 MBit brutto. Ethernet kommt nicht in Frage, siehe weiter oben
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.