Kollege verwechselt da etwas- oder ich?

Was stört dich daran?

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.

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.

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.

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.

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.

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)

Karl Heinz schrieb:

> Heute steckts du den Drucker an die serielle USB an...

...annd then, plug and pray...

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.

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....


=)

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 )

:)