Hallo Gemeinde! Ich bin gerade am Verzweifeln: Sehe ich das Richtig, dass der AVR-USART zwar mit externer Taktquelle arbeiten kann, aber immer Start- und Stopbit verlangt, also folglich keine Bitorientierten Protokolle senden und empfangen kann. Kennt einer einen Controller oder (erhältlichen) USART, der das kann (ausser Z85C30)? Fragt, auf Erleuchtung hoffend: Jens P.S.:Er muss auch keine Protokollunterstützung (Sync etc.) automatisch leisten, mir würde es zunächst völlig langen, die Bits rein- und rauszukriegen.
Upps... da sieht man mal, wie gross das Brett vorm Kopf sein kann. Jetzt müssen nur noch Sende- und Empfangstakt gleich sein, die werden nämlich beide vom fraglichen Modem geliefert. Messen ist leider nicht, da der Krempel gut 1000km von hier entfernt steht und das laufen muss, wenn ich das nächste mal wieder da bin :-( Hat vielleicht jemand schonmal mit sowas zu tun gehabt und kennt sich aus? Ich kann ja das Problem nochmal ein wenig erläutern: Wir sollen etliche Altgeräte bei einem Kunden durch eine PC-Basierte Neuentwicklung ersetzen. Als Spezifikation für die Datenanbindung war uns bekannt: RS232, 4800bps und die Datentelegramme. Heute rückte der Kunde noch mit einer 'nebensächlichen Zusatzinformation' raus: synchron, HDLC, LAPB... Passende Schnittstellenkarten gibt es noch aus Altbeständen: ISA, und wir brauchen 16 Stück im Rechner... Konverterboxen gibt es auch noch bei Blackbox im Internetkatalog. Sind aber nicht mehr lieferbar... Es ist zum Mäusemelken, jetzt prüfen wir aus Verzweiflung, ob man sowas schnell selber bauen kann. Vielleicht hat ja jemand noch eine Idee?
>Jetzt müssen nur noch Sende- und Empfangstakt gleich sein, die werden >nämlich beide vom fraglichen Modem geliefert. Zumindest beim AVR-SPI sind die beiden direkt miteinander verkuppelt. >Heute rückte der Kunde noch mit einer 'nebensächlichen >Zusatzinformation' raus: synchron, HDLC, LAPB... Ja, ja, geraucht haben sie auch... :)
Was hast du gegen Z80-SIO oder Z85C30? Ansonsten kann ein Microcontroller 4800bps zweifellos per Software erledigen. SPI ist dabei auch nutzbar, aber nur half duplex. Ganz irre Lösung, aber evtl. recht fix machbar: Tiny2313 als Software-HDLC / Hardware-UART Konverter und damit an USB-COM-Ports oder eine gewöhnliche 16port-Async-Karte.
A.K. wrote: > Was hast du gegen Z80-SIO oder Z85C30? Höhö, nichts, im Grunde, der Z8530 (ohne C) ist sogar mein Freund von früher, also... ganz früher... 1985 habe ich damit eine Studienarbeit gemacht. Den habe ich bislang aber nur als DIP40 erhältlich gefunden, mit einem Controller dazu wird eine Adapterschachtel schon recht gross, im Steckergehäuse geht da wohl nicht, und wir brauchen 16 Kanäle. > Ansonsten kann ein Microcontroller 4800bps zweifellos per Software > erledigen. SPI ist dabei auch nutzbar, aber nur half duplex. > > Ganz irre Lösung, aber evtl. recht fix machbar: Tiny2313 als > Software-HDLC / Hardware-UART Konverter und damit an USB-COM-Ports oder > eine gewöhnliche 16port-Async-Karte. Hardcore :-), aber wenn alle Stricke reissen muss das so gehen. Geld spielt keine Rolle, nur die Zeit... Wenn doch nur irgendwo 16 von den vergriffenen Adapterboxen aufzutreiben wären, seufzt Jens
Rahul Der trollige wrote: >>Heute rückte der Kunde noch mit einer 'nebensächlichen >>Zusatzinformation' raus: synchron, HDLC, LAPB... > > Ja, ja, geraucht haben sie auch... :) Neulich im Supermarkt fragt mich die Verkäuferin: "Wollen sie ne Tüte?" Ich: "Nee... wenn ich jetzt was rauche, vergesse ich wieder die Hälfte..." SCNR Jens
Hi! Ich habe das mal selber machen müssen, um ein Siemens 24-Bit serielles Modemprotokoll auf 3x8Bit seriell für PC umzusetzen. Habe dazu einen ATmeg8515 genommen, dessen UART die PC-Seite bedient hat. Die 24-Bit Seite habe ich in Software emuliert, also als Software-UART. Lief synchron mit <1.7% Jitter und asynchron mit 0%. Da das Modem aber keine Clock lieferte, musste das ganze mit 4x Oversampling gemacht werden. Aber grundsätzlich kannst Du Schnittstellen mit so langsamen Datenraten wie 4kBaud in einem AVR ganz gemütlich und einfach in Software emulieren. Bei Problemen oder weiteren Fragen, meld Dich ruhig. Leider war es bei dem damaligen Projekt auch so, dass die ganzen versteckten Rahmenparameter nicht bekannt waren. Effektiv gab es bei den 24-Bit nämlich nur 8 Datenbit, der Rest war Handshake und dieses hätte der Atmega locker vor Ort abfrühstücken können, anstatt es an den Server weiter zu leiten. Der Kunde faselte auch immer was von synchron und fremdgetaktet u.s.w. Nichts davon stimmte. Das ganze Modul war so klein, dass es in ein Hutschienen-Gehäuse passte, obwohl es, weil Einzelanfertigung, auf Lochraster gefädelt war. Mit einem Layout würde es vermutlich in ein nicht zu kleines 25-Pol AMP Gehäuse passen. Gruß, Ulrich
Moin Ulrich! > Hi! > Ich habe das mal selber machen müssen, um ein Siemens 24-Bit serielles > Modemprotokoll auf 3x8Bit seriell für PC umzusetzen. Habe dazu einen > ATmeg8515 genommen, dessen UART die PC-Seite bedient hat. Die 24-Bit > Seite habe ich in Software emuliert, also als Software-UART. Lief > synchron mit <1.7% Jitter und asynchron mit 0%. > Da das Modem aber keine Clock lieferte, musste das ganze mit 4x > Oversampling gemacht werden. Ich hab den Clock, dafür müsste ich riesige Datenpakete (512 Byte!) zwischenspeichern können, um LAPB auf dem Controller zu fahren. > Aber grundsätzlich kannst Du Schnittstellen mit so langsamen Datenraten > wie 4kBaud in einem AVR ganz gemütlich und einfach in Software > emulieren. Bei Problemen oder weiteren Fragen, meld Dich ruhig. Mach ich hiermit. > Leider war es bei dem damaligen Projekt auch so, dass die ganzen > versteckten Rahmenparameter nicht bekannt waren. Effektiv gab es bei den > 24-Bit nämlich nur 8 Datenbit, der Rest war Handshake und dieses hätte > der Atmega locker vor Ort abfrühstücken können, anstatt es an den Server > weiter zu leiten. > Der Kunde faselte auch immer was von synchron und fremdgetaktet u.s.w. > Nichts davon stimmte. Das ist man ja bei Kunden gewöhnt. Im Nachhinein stellten wir fest, dass unser Kunde es garnicht vergessen hatte, sondern nur ganz unleserlich klein in einer Fremdspache darauf hingewiesen hatte. Das haben die mit Absicht gemacht! Jede andere Firma haben sie ja bereits damit abgeschreckt, aber mit uns Hamburgern können sie es ja machen. In Hamburg und Lübeck und Bremen, gibt das manchmal Nachts schmutzige Geschäfte... > Das ganze Modul war so klein, dass es in ein > Hutschienen-Gehäuse passte, obwohl es, weil Einzelanfertigung, auf > Lochraster gefädelt war. Mit einem Layout würde es vermutlich in ein > nicht zu kleines 25-Pol AMP Gehäuse passen. Ja, genau sowas wird es werden, allerdings nicht auf Hutschienen sondern in einem Adaptergehäuse von Reichelt. Platine mit Eagle gemacht und von Olimex gefertigt. Mehr sowas leichtes. Stromversorgung aus der Schnittstelle, z.B., deswegen habe ich extra 8 Schottydioden und 14C88 und 14C89 bei Reichelt bestellen müssen! 1488 und 1489 habe ich hier noch zu hunderten rumliegen. Bin ich auch ganz froh drüber, weil die pinkompatibel sind und ich die Tage bis zum Eintreffen der CMOS-Teile die +-12V eben von Aussen zuführe. Ich hab mich dann noch entschieden, HDLC und LAPB auf dem PC zu machen. Falls es interessiert, werde ich weiter berichten. > Gruß, Ulrich Dito, Jens!
Hi! Also 512 Byte auf dem Controller sind bei z.B. einem ATmega32 kein Problem, der Footprint ist klein genug um weiter ein Steckergehäuse zu nehmen (oder ein anderes kleines Gehäuse). Interrupt-Quellen gibt es bei den AVRs genug, um dort den Takt der Seriellen einzuspeisen, bei 4800Baud kann man die Daten im PIO-Mode über die GPIOs fahren, sogar mit Oversampling, also den Ausgang setzen, dann Eingang 4x abtasten, 1 und 0 zählen, wessen Zähler höher ist, der entscheidet. x88er und x86er Treiber halte ich persönlich für ungeeignet. Das Problem ist die nicht garantierte minimale Versorgungsspannung, die sich bei der Ableitung aus den Signalen einstellt. Ich würde die Schaltung mit 3.3V Aufbauen und z.B. einen LE33C als Längsregler einsetzen. Als Schnittstellenbaustein setzt man einen ST232 oder einen entsprechend größeren Baustein ein, der genug Rx/Tx Stufen besitzt, um beide Serielle komplett abzudecken. ST hat den Vorteil mit kleineren Kondensatoren aus zu kommen und einen weiteren Spannungsbereich abzudecken, auch jenseits der Spezifikation. Wenn man das so macht, dann hat man noch genug Energie übrig um auch ein paar kleine LowPower LEDs als Statusinfo unterzubringen, ohne dass diese einem die Energie für die Treiber weg nuckeln. Eagle ist da wunderbar, nutze ich auch ausschließlich. Da das ganze Projekt kommerziell ist, wirst Du das hier nur in Teilen veröffentlichen können, so ist es auch mit meinem damaligen Konverter der Fall, aber Du kannst ich per PM kontaktieren. HDLC/LAPB auf einem AVR zu implementieren könnte noch andere interessieren, wäre also schick, diesen Ausschnitt zu veröffentlichen. Vielleicht tun wir uns da zusammen, ohne die IP deiner Firma zu verletzen, wenn Du magst / wenn das geht. Gruß, Ulrich
Vieleicht ist auch das USI der Tinys für dich interessant?
Hi nochmal. Im Nut-Os ist das HDLC bereits für den ATmega implementiert. http://www.ethernut.de/api/files.html Vielleicht ist das was für Dich. Klar, wenn das Protokoll komplett über den PC abgefrühstückt wird, dann ist ein Tiny einem Mega vorzuziehen, wegen der geringeren Stromaufnahme. Bei 4800Baud reicht eine Clock < 8MHz vollends aus und damit bewegen wir uns im Bereich der 1.8V-3.3V der L Serien und haben genügend Energie für eine Versorgung aus der Schnittstelle selbst. Zwei Schottky-Brücken für RX/TX und RTS/CTS sollten reichen, wenn's luxuriös sein soll, dann beide Schnittstellen anzapfen, also Sender und Empfänger. Hmmm... Einfacher wäre es sicherlich man könnte sich eine einfache vorhandene Stromversorgung zu nutze machen, wenn man nicht zusätzlich noch eine Wandwarze unterbringen möchte. Einen freien USB-Port kann man mit 50mA ( Also etwa dem 2-5Fachen dessen, was wir brauchen) belasten, ohne sich anmelden zu müssen, also einfach nur Kontakt 1 und 4 nutzen. Wenn man den Konverter nun doch in ein Steckergehäuse baut und ein USB-Kabel herausführt und in den am PC vorhandenen USB stöpselt... Ist nur so eine Idee. Gruß, Ulrich
Hallo zusammen! An alle Interessierten im Allgemeinen und an Ullrich im Besonderen hier mal auf diesem Wege ein Update (Kann man eigentlich irgendwo sein Benutzerpasswort ändern??? Ich habe den Zettel nicht immer bei mir, man soll das ja eigentlich auch garnicht aufschreiben, aber Worte wie vi8$68gsaoig kann ich mir einfach nicht merken...) Ich bin also nach den verschiedenen Ideen hier den Weg des geringsten Widerstandes gegangen und habe den Adapter mit einem Mega8L-8 und 14C88 und 14C89 gebaut. Den Mega8 kenne ich wie meine Westentasche, und nachdem ich mich entschlossen hatte, um Zeit zu sparen möglichst viel auf dem PC zu machen anstatt auf dem Controller, ist der sicher etwas überdimensioniert, aber er hat genug Pins und die Kiste läuft jetzt. Stromversorgung aus RxC und TxC von der Synchronschnittstelle (Wenn die weg sind, hat der Prozessor auch nichts zu rechnen..) und aus RTS und DTR vom PC. Jede Seite alleine reicht, um die Kiste zum Leben zu bringen. Programmieren geht nur, wenn beide dran sind, aber das soll ja auch nicht so oft nötig sein. Ich hab da noch einen Testpin drangemacht, um irgendwas >7V einzuspeisen, wenn das Ding völlig standalone programmiert werden soll. Der ganze Quargel passt in SMD in ein Adaptergehäuse von Reichelt. Zur Software nur soviel: Kommunikation zum PC über den USART (ich hatte da schon was rumliegen...) mit Hardware-Handshake nur auf der Empfangsseite, sendeseitig habe ich auf den Handshake verzichtet, denn wenn der PC die paar Daten nicht weggeschaufelt bekommt, habe ich ein ganz anderes Problem... (Mal abgesehn davon, das in realiter 16 dieser Adapter über einen N-Port-Server an einem PC hängen werden, und die alleine haben schon genug Buffer, um irgendwelche allfälligen Windows-Spirenzchen abzufangen). Auf der Synchronseite liegen die Clocks auf INT0 und INT1, RxD und TxD auf Portpins, die durch eine recht übersichtliche Software betrieben werden. Das Bitstuffing wird gleich beim Senden und Empfangen gemacht, wobei ich mir bis vor einer Stunde nicht im Klaren darüber war, ob der CRC nun vor oder nach dem Bitstuffing gemacht wird. Dazu aber später. Flags werden auf dem Adapter selbstständig generiert und erkannt, dann braucht der PC sich nicht mit sovielen sinnlosen Bits zu beschäftigen. Es werden in beide Richtungen nur End- und Abort-Flags übertragen, dazu gibt es jedesmal 2 Bytes, ebenso bei flagartigen Datenworten, vulgo Bytestuffing. Läuft echt super, das Moped, für abends mal schnell so zusammengeschraubt :-) Ich bin mittlerweile schon 'ein Stück weit' weiter, eben habe ich die FCS in den Griff bekommen und daraufhin beschlossen, es für heute genug sein zu lassen, nachdem ich durch die CRC-Hölle gegangen bin. Spätestens an dieser Stelle hätte ich bei diesem Unterfangen verkackt und verschissen gehabt ohne den alten hp4952. Für die jüngeren unter den zufälligen Lesern dieses Sermons: Das ist ein RS232-Protokollanalyzer. Und Simulator. Voll die Steinzeit, 20 Jahre alt. Sowas gutes wird heutzutage garnicht mehr gebaut, und deswegen scheitern insbesondere Informatiker leicht an der im Grunde recht simplen seriellen Schnittstelle. Ach.. aber ich wollte ja hier über mein HDLC-Projekt berichten, und nicht dem allgemeinen Weltschmerz verfallen. Soviel sei nur noch gesagt: Gerade gestern gelang es mir, völlig unabhängig von der HDLC-Geschichte, mittels eines der wenigen noch existierenden hp4952 ein Problem zu analysieren und zu isolieren, dessen Bewältigung ansonsten wahlweise Aktenordner voller Protokolle oder Datenbanken voller Bugreports erfordert hätte. Einfach mal richtig draufkucken, dann wird das sehr schnell klar, um jetzt zum Thema zurückzukommen: das Teil kann auch HDLC simulieren. Und sowohl 'Good FCS' als auch 'Bad FCS' erzeugen. Und so kam ich dann in die CRC-Hölle. Weil, ja!, an der FCS hängt alles. Und im Internet gibt es viel zu lesen über CRC, HDLC, FCS etc. pp. Aber auch so unendlich viel Scheisse. Es gibt da z.B. etliche 'Tools' mit denen man bei gegebenen Polynomen, Initialwerten, Bitordern etc.pp. den Wert des CRC ausrechen kann, C-Quellcodes noch und nöcher, kluge Seiten mit ellenlangen Abhandlungen über Polynominalkoeffizientenplutimikation mit und ohne Vorzeichen, in Mathe hatte ich immer ne 1, aber nee, das ist so traurig... 15 von 16 Algorithmen lieferten Ergebnisse, die der hp4952 als 'Bad FCS' einstufte. Am Ende habe ich mich darauf verstiegen, Hardware-CRC-Generatoren und -Checker in Software nachzubauen, so richtig mit Schieberegistern und XOR. Aber selbst da wird im Internet so viel Scheisse verzapft, dass es der Sau graust. Am Ende fand ich im Datenblatt eines VHDL-Cores (sic!) den Schaltplan einer Schieberegisterlösung, die funktioniert. Am Ende muss man nochmal mit 0xffff xoren, dann kommen genau die FCS raus, die der hp haben will und auch sendet. Und, aller Theorie zum Trotz, bin ich mir sicher, damit auch übernächste Woche im Feindesland, äh... also an der Kundenfront... bestehen zu können. Der Rest ist jetzt nur noch Tralala :-) So. Es dauert also noch ca. 3 Wochen, bis endgültige Aussagen über den Erfolg meines Lösungsansatzes getroffen werden können, aber danach bin ich gerne bereit, meine Erkenntnisse mit jedem zu teilen, der ein wirkliches Interesse daran hat. IP.. MEIN Schatz.. GollumGollum... Ach, es wird Zeit, ins Bett zu gehen. IdS. grüsst Jens 'der CRC-Höllenhund' Carstens P.S.: Die FCS wird über alle Bits OHNE Bitstuffing berechnet. Allahu akhbar!
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.