Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Hans-Peter Diettrich Newsgroups: de.sci.electronics Subject: Re: ATmega328p an 32 kHz Date: Fri, 24 Feb 2017 14:15:18 +0100 Lines: 40 Message-ID: References: <1f0snd-4b4.ln1@criseis.ruhr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net 3IODMMH8F1G41wVkiYbW5QfBWilA0dLa6pIMxnkrrqdZtGaxey Cancel-Lock: sha1:rGmdAkHsRk5y6icm/QKVA5nX0dA= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 In-Reply-To: Xref: csiph.com de.sci.electronics:223734 Am 23.02.2017 um 14:02 schrieb Wolfgang Allinger: > > On 23 Feb 17 at group /de/sci/electronics in article eh7vl7FbjifU2@mid.individual.net > (Hans-Peter Diettrich) wrote: >> Wobei erst mal der Entwickler gefeuert gehört, der für hohe Datenraten >> ausgerechnet eine UART gewählt hat :-] > > > Oh, früher(tm) gabs manchmal nix anderes. 9600Bd 20mA CL über 400-1000m. > (Stahlwerk, KKW...) Nein synchrone DÜ ware keine alternative unter diesen > Bedingungen. Damals war das aber keine Herausforderung für die Controller, die den Datenfluß verarbeiten sollten. Unsere pdp-11/34 hat Meßdaten von bis zu 16 9600Bd Leitungen klaglos geschafft. Die Umgebung war vergleichbar verseucht, mit thyristorgesteuerten Motoren im MW Bereich, und Leitungslängen bis 50m, und das ging mit RS-232 auch fehlerfrei. Bei meinem Disketten-Controller mußte ich Takte zählen und in Assembler optimieren, um mit einem 4MHz Controller auf Datenraten von 250kBd (entsprechend Floppy FM) zu kommen. > Da musste man dann die Daten eben genügend verdichten und nur das > Endergebnis (eines Prüfbereiches) auf dem Bildschirm liefern. Bei KKW > wurden die kompletten Daten für alle Bereiche vor Ort auf einer > Wechselwinchester gespeichert. Da hatte ich später ähnliche Probleme, bei der Messung in Kfz. Dabei mußten die Daten auf eine Ramdisk der ersten Laptops (80C188) passen, weil das Abspeichern auf Floppy während der Fahrt zu fehlerträchtig war. Ein ganz anderes Problem war die Leertaste, die ein Testfahrer mit dem Bauch betätigt hat, und den Tastaturpuffer dank Auto-Repeat zum Überlaufen brachte. Und die Programmierung mußte in GW-Basic erfolgen, weil die Grafik-Ausgabe aller damals verfügbaren Compiler die Interrupts während des Bildschirm-Refresh einfach abgeschaltet hat. DoDi