www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Synchrone bitorientierte serielle Daten mit AVR


Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SPI

Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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... :)

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleicht ist auch das USI der Tinys für dich interessant?

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens Carstens (jcarstens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!


Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.