Lautstärkeregelung ohne Poti, ist das eine alternative zum PGA?

[Frank S]

Dann programmiert ihr ineffizient und nutzt die Controller nur zu 40% aus. Dann geht es natürlich. Darm man nur nie auf die Idee kommen, interne ADCs/DACs, Timer, UARTs etc. zu nutzen oder spezielle Features wie die Adressierungen des MSPs. In kleineren Firmen mag das gehen - bei höheren astückzahlen aber nicht möglich, da stets mit geringstem Aufwand (kleiner Controller) die Ergebnisse erzielt werden müssen. dann fällt es auch nicht ins Gewicht, ob hier und da das Engineering etwas länger braucht um effizienter zu programmieren und die Features der Controller voll auszufahren.

[Nuggets]

letzter post von Frank:
Da bin ich mal auf die Antwort von Bernhard gespannt, wenns denn eine gibt.

@ Bernhard:
Die Frage mit den Buffern meinte ich natürlich nicht für den Fall der symmetrischen Vorstufe, sondern für normales "single ended". Hätte ich vielleicht dazu schreiben sollen. Würdest du für den Fall einen (evtl. verstärkenden) Buffer einsetzen?

Nuggets

[BN]

@Nuggets
Also ich würde im Single-Ended fall keinen Buffer mehr dahinterklemmem. Der eingebaute OP des PGA2310 liefert ausreichend Spannung, Strom und verträgt auch einigermaßen gut kapazitive Lasten, zumindest für alle üblichen Einsatzfälle.

@Frank S

Dann programmiert ihr ineffizient und nutzt die Controller nur zu 40% aus. Dann geht es natürlich. Darm man nur nie auf die Idee kommen, interne ADCs/DACs, Timer, UARTs etc. zu nutzen oder spezielle Features wie die Adressierungen des MSPs. In kleineren Firmen mag das gehen - bei höheren astückzahlen aber nicht möglich, da stets mit geringstem Aufwand (kleiner Controller) die Ergebnisse erzielt werden müssen. dann fällt es auch nicht ins Gewicht, ob hier und da das Engineering etwas länger braucht um effizienter zu programmieren und die Features der Controller voll auszufahren.

Alles was ein µ-Controller an Peripherie bietet, läßt sich auch nutzen, wenn man ihn in C programmiert. Adressierungsarten interessieren nicht mehr, wenn in einer Hochsprache programmiert wird. Das ist dann Sache des Compilers.

Was wirklich effizient ist und was nicht ist oft gar nicht so einfach zu beantworten. Manchmal muß dazu der gesamte Lebenszyklus eines Produkts betrachtet werden. Was heutzutage dabei herauskommen kann, mag das folgende Beispiel zeigen: Bei BMW ist negativ aufgestoßen, daß beim Wechseln der Stoßdämpfer (mit eingebauter Elektronik) der 7er Serie wieder ein Stoßdämper mit dem exakt gleichen Mikrochip eingebaut werden muß, weil er sonst nicht mehr mit dem Rest des Autos zusammenarbeiten würde. Das ist natürlich ein Riesenproblem für die Ersatzteilversorgung, weil die Verfügbarkeit von Microcontrollern über einen Zeitraum von 15 Jahren u.U. gar nicht garantiert werden kann. Was macht man also? Die Funktion des Mikrochips des Stoßdämpfer wird auf eine Java Applikation abgebildet, die auf einer Java-Engine ausgeführt wird und diese läuft auf einem embedded Betriebssystem auf dem Micro-Controller des Stoßdämpfers ab. Durch ein CAN-Bus Soap Protokoll wird die Stoßdämpfer-Funktion dem Stoßdämpfer nach der Montage oder vor Fahrtbeginn (weiß ich nicht genau) vom Server des Autos eingeimpft. Warum das alles? Damit man nicht genau das originale Ersatzteil vorhalten muß sondern ein ähnliches, das lediglich die Ablaufumgebung für die Java-Applikation bereithalten muß. Interessant finde ich, daß mittlerweile Internet-Protokolle bemüht werden, um die Stoßdämpfer-Funktion in einem 5er BMW sicherzustellen.

Das zum Thema, ob es bei Großserienprodukten so sehr darauf ankommt, einen Chip bis ins letzte auszunutzen, so daß man ihn gleich in Assembler programmieren müßte. Denn eines sollte klar sein, Java Engines und Soap Protokolle sind alles mögliche, nur nicht besonders effizient, was die Ablaufgeschwindigkeit und auch die Menge an erforderlichen Daten und Code angeht.

Nachzulesen hier:
http://www.netigator.de/netigator/li...ng,,thes,.html

Grüße
Bernhard

[Frank S]

Natürlich läßt sich die Peripherie des Controllers aus C heraus nutzen - aber eben nicht portieren. Die Adressierungsarten sollten einen C Programmierer sehr wohl interessieren, damit er weiß, was er wie zu implementieren hat. Die Intelligenz des Compilers hat seine Grenzen. Manche drehen Zählschleifen um (runterzählen statt hochzählen wegen DJNZ oder DEC+JNZ) oder ersetzen Unterprogrammaufrufe durch Makros, wenn der entsprechende Controller für CALL+RET zu lange braucht und hinreichend Speicher existiert. Wenn ich weiß, daß der Controller mit Pointern gut umgehen kann, darf ich großen Gebrauch davon in C machen und auch komplexe Zugriffsverfahren mit Offsets anwenden. Andererseits erschlage ich damit einen Controller, der Speicherzugriffe über z.B. einen Z Pointer durchführen muß, der dann noch umständlich zu initialisieren ist. Konkret muß ich auch in C auf die Eigenheiten des Controllers Rücksicht nehmen, wenn ich effizient programmieren will. Ich kann so C schreiben, daß ich dem Compiler quasi vorschjreibe, wie er zu übersetzen hat. Oder ich schreibe 08-15 und erhalte eher stochastische Ergebnisse.

Wegen der Gefahr der Abkündigung Emulationen in Java vorzunehmen ist reichlich exotisch. Besser wäre gerwesen, eine Soft-Core CPU in programmierbarer Logik einzusetzen. Oder eben Lieferverträge mit dem entsprechenden Hersteller. Evtl. sind die Stückzahlen des 7ers dafür doch zu gering.

[BN]

Original geschrieben von Frank_S
Natürlich läßt sich die Peripherie des Controllers aus C heraus nutzen - aber eben nicht portieren.

Warum denn nicht? Portieren heißt ja nicht, daß ich das Programm 1:1 übernehmen kann. Kleine Anpassungen müssen schon gemacht werden. Die Adressen von Ein-Ausgabeports müssen z.B. geändert werden. Das geschieht in der Regel durch geänderte Defines und bei komplexerer Peripherie wie z.B. UARTs müssen schon mal Funktionen neu geschrieben werden oder es wird ein anderer Treiber verwendet. Aber der Großteil eines Programms bleibt von solchen Anpassungen unberührt.

Die Intelligenz des Compilers hat seine Grenzen. Manche drehen Zählschleifen um (runterzählen statt hochzählen wegen DJNZ oder DEC+JNZ) oder ersetzen Unterprogrammaufrufe durch Makros, wenn der entsprechende Controller für CALL+RET zu lange braucht und hinreichend Speicher existiert.

Das stimmt schon, aber wie oft kommt es denn vor, daß die Programmlaufzeit wirklich sooo kritisch ist? Dort wo die Ausführungszeit wirklich kritisch ist, kann man das Programm laufzeitmäßig analysieren und dann gezielt optimieren. Dafür werden von den Herstellern der Entwicklungssysteme auch Tools angeboten. Aber daß ein C-Programm in Hinblick auf den Maschinenbefehlssatz der CPU von vornherein in einer bestimmten Weise geschrieben wird, halte ich für eine ganz seltene Ausnahme.

Grüße
Bernhard

[Matthias]

Original geschrieben von BN
Edit: das würde mich mal interessieren. Einige hier studieren ja E-Technik oder Informatik. Wird Assemblerprogrammierung heute tatsächlich noch irgendwo gelehrt oder ein entsprechender Kurs angeboten? Das würde würde mich echt wundern.

Ich sprech mal für mich (TU-Ilmenau):
Das ganze gilt wohl sowohl für meinen Studiengang ( Ingenieurinformatik ), als auch für die E-Techniker und Informatiker, weil die wohl im Bereich programmieren am Anfang das gleiche gemacht haben:
Wenn man von Leuten befragt wird, was man denn in der Uni so macht, gehen ja die meisten davon aus, dass man einen Kurs für C, einen für C++, einen für Java, einen für Assembler, ... hat, also im Prinzip nur programmieren lernt. Tatsächlich ist das eben nicht so, es wird maximal eine Programmiersprache gelehrt, programmieren ist eher etwas was man sich selbst beibringen sollte.

Assembler (x86) wurde bei uns im ersten Semester im Rahmen des Seminars zu "Rechnerarchitekturen" gelehrt. Ein viertel Jahr lang mit 1,5h/Woche. Das ganze reicht völlig aus um Assembler zu verstehen. Ich habe das ganze als ziemlich sinnvoll empfunden. Und zwar nicht, weil man es dann tatsächlich zum programmieren einsetzen will, sondern weil man dadurch dann wirklich die Struktur einer CPU versteht. Man weiß, wozu da dieses und jenes Register im Kern ist, was eine ALU ist, ein Stack, ein Adresszähler, und wie eben eine CPU ein Programm eben so abarbeitet. Wer nur Java lernt kriegt von diesen Details nichts mit. Deswegen halte ich es für sinnvoll auf jedenfall weiterhin ASM zu unterrichten.

Daneben gab es (auch im ersten Semester) noch die Vorlesung "Einführung in die Programmierung", dort wurde Pascal gemacht. Gut, von Pascal hatte ich nicht allzuviel gehalten, C wäre vielleicht sinnvoller gewesen, da viel verbreiteter. Im Prinzip ist aber auch mit Pascal und C ziemlich das gleiche möglich nur die Syntax ist leicht anders. Für die wirklich tiefgreifenden Features von C++ (Templates etc.) wäre wohl sowieso keine Zeit gewesen.
An vielen Unis scheint jetzt aber eher Java die Sprache der Wahl geworden zu sein. Ich würde hier weiterhin C++ bevorzugen, weil wer C++ verstanden hat kann jede andere imperative Sprache in einer Woche erlernen.

Eine extra Vorlesung zum Bereich Mikrocontroller gibts auch, aber erst in den letzten Semestern. Kann ich aber nicht viel dazu sagen, da ich sie selbst nicht besucht habe und es auch nicht tun werde. Aber es geht da wohl weniger ums C/ASM/sonstwas programmieren, sondern eher um die ganze Peripherie die man noch so drankleben möchte, bzw die heutzutage wohl meist schon integriert ist.

Zum konkreten Projekt mit der Lautstärkeregelung:
Ich denke der von Frank vorgeschlagene Atmel AVR wäre auf jedenfall eine gute Wahl. Gibts in verschiedenen Größen und Gehäusen. Ist einfach zu beschalten. Von der Geschwindigkeit reicht für die Lautstärkeregelung und Eingangswohl wohl so ziemlich jeder Controller. Nur Hardware SPI sollte er wohl schon können, damits etwas einfacher wird.
Programmer kann man sich für weniger als 5€ an Teilen selbst bauen, so einen hatte ich damals. Parallelportstecker an der Lochrasterplatine ging aber nicht allzuschön, deswegen ist das Teil irgendwann zerfallen. Für paar Euro mehr ein solides fertiges Kabel kaufen ist sicher auch nicht verkehrt (gibts bei shop.mikrocontroller.net für 16,-). Das STK500 geht preislich aber auch, und man kann damit dann wohl noch mehr machen.

Programmieren kann man ihn dann nach Lust und Laune in C oder ASM, beide Entwicklungsumgebungen kostenlos.

Ich denke mal für nur Lautstärkeregelung ist mit beiden Sprachen kein Problem. Ein großer Teil des Aufwandes ist vermutlich wirklich das Zugreifen der Programmierschnittstelle, und da das sowieso nicht portabel ist, erübrigt sich der Aspekt der Wiederverwendbarkeit. Eine große Bibliothek, die man irgendwo wiederverwenden könnte, wird wohl sowieso eher nicht entstehen.

Übrigens: Warum BMW Java braucht um seine Ersatzteilversorgung sicherzustellen vesteh ich nich
Eine Bibliothek mit nach außen fest definierten Schnittstellen (auf die dann über CAN oder MOST zugegriffen wird) lässt sich in C genausogut realisieren. Wichtig ist hier doch nur die gleiche Hardwareschnittstelle(CAN, MOST), und dass dann die Softwareschnittstelle auf die Kommandos gleich reagiert. Ich weiß zum Beispiel immer, dass wenn ich über MOST ein Kommando an den Function-Block Amplifier im Auto ein spezielles Kommando schicke sich die Lautstärke erhöht. Und zwar ganz unabhängig davon wer das Radio gebaut hat, welcher Mikrocontroller drin ist, und welche Programmiersprache verwendet wird.

So, viel zuviel Text geschrieben, ich bastel jetz bissl weiter an meinem DSP Board (mit Mikrocontroller, aber leider ohne PGAs ).

Schöne Grüße
Matthias

[dllfreak2001]

Eigentlich wäre mir ja so eine Schaltung mit dem PGA4310(ich glaube das war die nummer von der 4-Kanaltype) lieber.
Denn der PGA 2310 hat nur einstellbare Balance der 4310 verarbeitet jeden Kanal einzeln. Für Mehrkanalanwendungen wäre also die größere Variante sinnvoll, außerdem soweit ich weiß relativ identisch zum kleinen Bruder. Großer Nachteil bei dem Chip, er ist in SMD Bauform.

[Matthias]

Naja, SMD ist nicht umbedingt ein Nachteil. Bei den meisten Sachen sehe ich SMD als Vorteil an. Die größeren SMD Sachen mit so 1mm Pitch lassen sich problemlos per Hand löten. 805er Widerstände und Kondensatoren sind mit Pinzette auch kein Problem, wenn man den Dreh mal raus hat gehts sogar um einiges schneller als bedrahtet.

Nur der PGA4311 hat halt auch eins von den hübschen 0.5mm Fine Pitch Gehäusen. Wie gut das funktioniert weiß ich noch nicht. Vielleicht kann ichs dir demnächst sagen, auf dem Layout für mein DSP Board finden sich nämlich mittlerweile auch 4 ICs mit 0,5mm Pitch und in Summe > 300 Pins. Ob das was wird, wird sich noch herausstellen

[dllfreak2001]

Also für eine Heimkino-Anwendung bräuchte man schon 2 Stück
also 8-Kanal

[Matthias]

Kannst auch den ganz neuen PGA8311 für 8 Kanäle nehmen, im hübschen 48HTQFP Gehäuse
Der sollte dann immerhin das beste Preis-Leistungsverhältnis bieten.

[dllfreak2001]

War das jetzt ein Witz?
Finde diesen IC per Google nicht!

[Matthias]

Wieso per Google suchen, wenn man auch direkt auf der TI Seite suchen kann?

http://focus.ti.com/docs/prod/folder...t/pga8311.html

Ist ganz neu und hat noch den Status PREVIEW, gibts also bis jetzt weder zu kaufen noch als Samples, deswegen vermutlich auch noch nicht viel auf anderen Seiten und Suchmaschinen.

[dllfreak2001]

THX,
faszinierend der würde sich ja optimal eignen.

[harry_m]

Ja, das wäre etwas was auch zu meinem Verstärker passen würde.

[dllfreak2001]

Boah, dein Amp ist ja echt das Monster.