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.
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)
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
> 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 > 4MbpsKlaus 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
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
