Hallo! Ein Kollege (alter Elektronik-Hase, aber keine µC- Erfahrungen) malte mir jüngst in meinen Schaltplan (mit einem vorhandenen Atmel- Controller) einen zusätzlichen AD- Wandler ein: 8 Datenbeinchen, ChipSelect, Spannung, fertig. Hat einen ganzen Port plus einen Pin an Platz weggenommen. Ich fands lustig und belehrte ihn über seine Missetat, dass man das nämlich so natürlich nicht tut. Er fragte "Warum dasn nicht?. Ich sagte " ". Nun frage ich mich: mir ist diese Datenbusstruktur aus der Prozessortechnik wohl bekannt- aber nicht auf Controllerebene. Dabei spricht -bei Beinchenüberschuß- doch aber gar nix dagegen- oder?
Ich versteh nicht, was die diskussion soll :-/ Wenn ein AD-Wandler einen parallelen datenbus besitzt, muss man ihn doch auch so anschließen... Wo ist da der ansatzzpunkt des klugschisses?
Karl Heinz schrieb: > Was stört dich daran? Ich meine jetzt ausser der Fargestellung, warum man nicht einen AVR mit eingebautem ADC benutzt, bzw. wenn einer vorhanden ist, warum dann nicht dieser benutzt wird.
Karl Heinz schrieb: > Was stört dich daran? Gute Frage. Das eine fühlt sich nach Prozessortechnik und das andere nach Controllertechnik an.
Stephan schrieb: > Nun frage ich mich: mir ist diese Datenbusstruktur aus der > Prozessortechnik wohl bekannt- aber nicht auf Controllerebene. Dabei > spricht -bei Beinchenüberschuß- doch aber gar nix dagegen- oder? Kannst du natürlich machen - heutzutage ist es aber wirklich einfacher, den eingebauten ADC des AVR zu nehmen. MCs mit Onboard ADC sind zwar nicht so neu (m.E. gibt es den 80C535 schon seit mindestens 20 Jahren) aber wer den nicht verwenden wollte, nahm halt einen externen.
...wenn der interne ADC aber nicht den anforderungen entspricht...? (z.B. Eingangsspannungsbereich etc)
Stephan schrieb: > Karl Heinz schrieb: >> Was stört dich daran? > > Gute Frage. Das eine fühlt sich nach Prozessortechnik und das andere > nach Controllertechnik an. Das ganze ist eine Frage von parallel und seriell. Nichts weiter. Beides kommt bei Controllern vor. Allerdings ja, heutzutage setzt man eher auf serielle Systeme und spart dadurch Pins. Früher war da mehr parallel. Ich würde ohne Not keinen parallen ADC einsetzen. Und ich würde den internen im AVR einsetzen, wenn vorhanden. gruß cyblord
... schrieb: > ...wenn der interne ADC aber nicht den anforderungen entspricht...? > (z.B. Eingangsspannungsbereich etc) Dann passt man die eben an. Sooo toll kann ein externer 8-Bit ADC gar nicht sein.
Stephan schrieb: > dass man das > nämlich so natürlich nicht tut. Was denn? Einen Chip anschliessen? Wenn man ihn braucht, 8 parallele Bits sind schnell, vielleicht muss es schnell sein. Natürlich würde I2C Pins sparen, ist aber langsamer. Letztlich noch eine Konstenfrage, sind 4 zusätzliche I/O billiger als der andere D/A?
Den IO-Pins ist es egal, was man da anschließt. Man kann sie daher auch als Bus nehmen. MCs mit vielen Pins haben oft sogar den Adreß-/Datenbus rausgeführt und man kann bequem zusätzlichen Speicher usw. anschließen. Einen 8Bit-ADC anzuschließen ist nicht falsch, aber warscheinlich überflüssig. Einen 16Bit-ADC anzuschließen, kann dagegen sinnvoll sein. Ich bevorzuge dann aber SPI.
Danke für die Info. Bin froh über den Trend zu seriellen Busse.
Stephan schrieb: > Bin froh über den Trend zu seriellen Busse. WEnn es richtig schnell werden soll, kommt man um die Paralleli- sierung nicht drumherum. Ausserdem sind Parallelschnittstellen viel einfacher zu handhaben. Gruss Harald
Harald Wilhelms schrieb: > Stephan schrieb: > >> Bin froh über den Trend zu seriellen Busse. > > WEnn es richtig schnell werden soll, kommt man um die Paralleli- > sierung nicht drumherum. Ausserdem sind Parallelschnittstellen > viel einfacher zu handhaben. Jep. Siehe zb das Gedöns mit den Druckern. Vor 30 Jahren wurden Drucker mit einer parllelen Centronics angeschlossen. Kabel eingesteckt, Drucker ausgewählt (wenn überhaupt), läuft. Einen Drucker für reinen Textdruck zu programmieren bzw. anzuschliessen war derart banal, dass es daran kaum etwas zu verbessern gab. Heute steckts du den Drucker an die serielle USB an, hoffst das das BS den Drucker erkennt, den entsprechenden Treiber lädt und das Ding auch funktioniert. Und wehe es funktioniert nicht. Dann hast du die Arschkarte und so gut wie keine Chance den Fehler aktiv zu finden.
:
Bearbeitet durch User
Frueher, vor warscheinlich 30-40 Jahren waren CPU im Einsatz, die alle gemeinsam hatten, dass der interne Datenbus extern verfuegbar ist, und externe Peripherie in den Adressbereich eingebunden wurde. CPU hatten maximal 256 Ram und wenn mehr gebraucht wurde, musste ein externes Ram ran.
Karl Heinz schrieb: > Heute steckts du den Drucker an die serielle USB an, hoffst das das BS > den Drucker erkennt, den entsprechenden Treiber lädt und das Ding auch > funktioniert. Und wehe es funktioniert nicht. Dann hast du die > Arschkarte. Das hat aber exakt garnichts mit der verwendeten Schnittstelle zu tun. Der dem ganzen zugrundeliegende Transportlayer funktioniert exakt genauso zuverlässig und ohne zusätzliche Treiber, wie es der alte Parallelport auch getan hat. Und Probleme mit passenden Druckertreibern sind völlig unabhängig von der genutzten Schnittstelle; ob der Drucker seriell, parallel, per IrDA oder Ethernet angeschlossen ist, ist für den Druckertreiber selbst bedeutungslos. Erst bei Multifunktionsgeräten sieht das anders aus, weil die mehr als die USB-Standardgeräteklasse "Drucker" verwenden, die jedes Betriebssystem von Hause aus kennt. (oder kennen sollte, die Frickel-Versionen von Windows kannten Standardgeräteklassen nur sehr eingeschränkt).
Rufus Τ. Firefly schrieb: > Karl Heinz schrieb: >> Heute steckts du den Drucker an die serielle USB an, hoffst das das BS >> den Drucker erkennt, den entsprechenden Treiber lädt und das Ding auch >> funktioniert. Und wehe es funktioniert nicht. Dann hast du die >> Arschkarte. > > Das hat aber exakt garnichts mit der verwendeten Schnittstelle zu tun. > Der dem ganzen zugrundeliegende Transportlayer funktioniert exakt > genauso zuverlässig und ohne zusätzliche Treiber, wie es der alte > Parallelport auch getan hat. Wenn er funktioniert. Der Punkt ist: Einen parallel Centronics Drucker anzusteuern kriegte jeder Programmier-Neuling hin. Das war technisch so banal, da konnte nicht viel schief gehen. Da brauchte es technisch noch nicht einmal Druckertreiber. Byte an den Port legen, einmal Strobe und das Byte war drüben (ok, noch ein paar Details drumherum, aber im Kern war es genau das). Einen Text auszudrucken war recht banal, wenn auch laut :-) (wenn du mir das raunzen noch gestattest. Heute hab ich das Problem, dass ich einen einwandfrei funktionierenden 10 jahre alten Laser-Drucker (Canon LPB-810), wegschmeissen muss, weil Canon keinen 64 Bit Treiber anbietet)
:
Bearbeitet durch User
Karl Heinz schrieb: > Heute steckts du den Drucker an die serielle USB an... ...annd then, plug and pray...
Karl Heinz schrieb: > Der Punkt ist: > Einen parallel Centronics Drucker anzusteuern kriegte jeder > Programmier-Neuling hin. Das war technisch so banal, da konnte nicht > viel schief gehen. Da brauchte es technisch noch nicht einmal > Druckertreiber. Byte an den Port legen, einmal Strobe und das Byte war > drüben (ok, noch ein paar Details drumherum, aber im Kern war es genau > das). Einen Text auszudrucken war recht banal, wenn auch laut :-) > > (wenn du mir das raunzen noch gestattest. Heute hab ich das Problem, > dass ich einen einwandfrei funktionierenden Laser-Drucker (Canon), > wegschmeissen muss, weil Canon keinen 64 Bit Treiber anbietet) Und was hat das mit seriell/parallel zu tun? Stell wir uns doch mal vor der Drucker wäre über SPI angeschlossen, CS und Byte rausschieben, fertig. Das kriegt auch jeder Neuling hin ;)
Eumel schrieb: > Und was hat das mit seriell/parallel zu tun? :-) Ausgangspunkt meiner Raunzerei war das hier > Ausserdem sind Parallelschnittstellen viel einfacher zu handhaben. > Stell wir uns doch mal vor der Drucker wäre über SPI angeschlossen, > CS und Byte rausschieben, fertig. Das kriegt auch jeder Neuling hin ;) Erwischt
Karl Heinz schrieb: > (wenn du mir das raunzen noch gestattest. Heute hab ich das Problem, > dass ich einen einwandfrei funktionierenden 10 jahre alten Laser-Drucker > (Canon LPB-810), wegschmeissen muss, weil Canon keinen 64 Bit Treiber > anbietet) Den Drucker müsstest Du aber auch wegschmeissen, wenn er am Parallelport hinge. Und auch, wenn er einen Ethernet-Druckserver integriert hätte. Das Treiberproblem hängt nicht am Transportmedium.
LBP-810 - hatte der nicht einen Postscript-interpreter an Board? Wenn ja: einen ähnlichen ps-Drucker (z.b. HP LJ4 PS) wählen und die nächsten 20 Jahre weiterarbeiten.
Andy P. schrieb: > LBP-810 - hatte der nicht einen Postscript-interpreter an Board? Nein, das ist ein GDI-Drucker, der kann noch nicht mal PCL.
Am Anfang des Freds dachte ich erst, es ginge um irgendwas mit internem/externem ADC.... ....wie man sich doch täuschen kann.... =)
:
Bearbeitet durch User
Wir sind immer noch beim Thema. Ein echter Hacker baut aus einem LBP-810, einem µC und einer WLAN-Antenne an einem schnellen AD-Wandler einen Postscript Netzwerkdrucker.
Lästermaul schrieb: > Wir sind immer noch beim Thema. > Ein echter Hacker baut aus einem LBP-810 (...) Es juckt mich zwar gerade in den Fingern das Thema noch weiter auszuschlachten, aber damit würde ich den Fred nur noch weiter in Richtung Off Topic treiben. Warum schaffen wir es eigentlich nicht, derartige Ausuferungen in einen eigenen Fred auszulagern? ( --> hierzu bitte gegebenen Falls einen eigenen Fred aufmachen ) :)
Karl Heinz schrieb: > (wenn du mir das raunzen noch gestattest. Heute hab ich das Problem, > dass ich einen einwandfrei funktionierenden 10 jahre alten Laser-Drucker > (Canon LPB-810), wegschmeissen muss, weil Canon keinen 64 Bit Treiber > anbietet) Musst du nicht, du musst bloss erkennen, dass das unsägliche unbrauchbare Betriebssystem die Ursache ist, schmeiss das weg, 32 bit tuts auch.
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.