Hallo Zusammen, ich möchte mich an dieser Stelle bei all denen bedanken, die mir beim Entwurf dieser Platine geholfen haben. Als kleines Dankeschön, befindet sich im Anhang die notwendigen Dateien, um diese Platine ätzen zu können. Als Empfangsroutine kann die RC5 Bibliothek von Peter verwendet werden. Der Motorpoti wird über die Ports B und C angesteuert. Der TSOP wird über Pin D7 dem Mikrocontroller zu geführt. Die Ports D2 - D6 stehen als In- / Outports zur Verfügung. Um das im PDF hinterlegte Layout zu drucken, ist darauf zu achten, dass alle Skalierung im PDF-Reader ausgeschaltet sind (Seitenanpassung: keine). Wird diese Einstellung nicht gewählt, wird das Layout um die entsprechende angegebene Skalierung verkleinert! Wer die Platine als Leerplatine haben möchte, kann mir eine PM senden. Gruss Frank Link
Hier der Sourcecode zur Platine. Der Code wurde mit AVR Studio 4 entwickelt. Es kann also sein, dass für andere Umgebungen Anpassungen erfolgen müssen. Da ich normalerweise in Delphi entwickle, entspricht der Code bestimmt nicht allen C-Konventionen. Aber dafür ist er für mich verständlich und pflegbar. In der ReadMe.txt stehen alle notwendigen Informationen. Über Anregungen und Vorschläge in Bezug auf Optimierung und / oder Verbesserungsvorschläge würde ich mich freuen. Ansonsten hoffe ich, dass der ein oder andere mit der Platine und dem Code etwas anfangen kann. Bei Fragen einfach mailen: franklink61 (at) aol (dot) com. Gruß Frank
Hi Simon, was würde dagegen sprechen? Ich habe die Platine jetzt seit einigen Monaten ohne Probleme im Dauerbetrieb im Einsatz. Die Platine ist hier im Forum auch vorgestellt worden und alle Anregungen diesbezüglich eingearbeitet worden. Keine hat darauf hingewiesen, dass die Ausgänge nicht zusammengeschaltet werden dürfen. Ich persönlich wüsste so auf Anhieb auch keinen Grund. Aber ich lasse mich gerne überzeugen. Gruß Frank
Nunja, mir hat mal jemand gesagt, dass man Digitalausgänge nicht zusammenschaltet, da es passieren kann, dass nicht alle zur gleichen Zeit durchschalten. Das würde bedeuten, dass es minimal kurz zu einem Kurzschluss zwischen den Ausgängen kommen kann. Naja, vielleicht triffts ja beim AVR nicht zu. ;)
Ich habe eben nochmals im Forum recherchiert. Parallel geht wenn am gleichen Port und gleichzeitig geschaltet. Danke nochmal für den Hinweis. Gruß Frank
Nur so als Idee: Wie wäre es wenn sich der letzte Zustand der Ports gemerkt oder konfigurierbar gemacht wird ? Wenn ich zb. Kanal 3 aktiv geschaltet hatte, würde ich gerne nach dem Einschalten wieder Kanal 3 aktivieren. Oder habe ich da etwas falsch verstanden (habe den src. durchgeschaut) ? Gruß Sven
Hallo Sven, vielen Dank für die Idee. Im Augenblick ist es so, dass in der Variablen Channel der letzte Zustand steht. D.h. solange die Platine unter Spannung steht und nur die Aus-Funktion der Fernbedienung verwendet wird, wird beim Einschalten der letzte Zustand wieder aktiviert. Dies gilt allerdings nur für den Type2 der Software. Da hier über einen Portpin ein Relais zum ein/ausschalten des Gerätes verwendet werden kann und die Steuerung selber ständig unter Spannung steht. Aber Deine Idee hat in soweit etwas, dass man in jedem Fall den letzten Zustand wegschreiben sollte. Ich frage mich nur, ob man das softwaretechnisch realisieren kann, für Hardware ist kein Platz mehr!?! Im Augenblick entwickle ich eine kleine Delphi Oberfläche, mit der ich die Lehrnfähigkeit implementieren möchte. Gruß Frank
Hier noch eine kleine Korrektur in den #defines der Datei Button.h. Durch die falsche Initialisierung von #define CHANNEL1_INIT wird in der Type2 Variante Bit 5 nach einem Reset sofort geschaltet. Das darf so nicht sein. Gruß Frank
> Aber Deine Idee hat in soweit etwas, dass man in jedem Fall den letzten > Zustand wegschreiben sollte. Ich frage mich nur, ob man das > softwaretechnisch realisieren kann, für Hardware ist kein Platz mehr!?! Klar geht das :-) Der AVR hat ja ein internes EEPROM und kann dort auch nach! Stromausfall Daten wieder zurücklesen und dauerhaft speichern. siehe hier: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM Wichtig ist noch, das man nur Daten ins EEPROM schreibt wenn sich der Wert wirklich geändert hat. also so z.B.: if (EEPROM_INTEGER_READ != CURRENT_VALUE_TO_WRITE) { WRITE_TO_EEPROM(CURRENT_VALUE_TO_WRITE); } Gruß Sven
Ergänzung: Das EEPROM hat halt eine begrenzte Schreibanzahl ;-), die zwar sicher bei > 100.000 Zyklen liegen soll, aber man kann sich ja auch vorher Gedanken machen ;-)
Hallo Sven, was ich eigentlich sagen wollte, war, dass beim Abschalten (Stromlos machen) der Wert automatisch ins EEPROM abgelegt wird. Ich habe nochmal im Forum recherchiert was die Anzahl der Schreibzyklen angeht. Eine Idee war die Speicherstelle mit jedem Schreibzugriff in einem Bereich zuwechseln. Damit würde die Anzahl der möglichen Zyklen jenseits von Gut und Böse liegen. Wobei >100000 mal auch schon ein wirklich großer Wert ist. Bei 10 Schaltvorgängen pro Tag würden es immer noch 27 Jahre sein. Ich denke, dann kann man auch mal den Kontroller austauschen. Ich werde die Speicherroutine heute noch einbauen und das Ergebnis zurückspielen. Gruß Frank
Hallo Zusammen, im Anhang die Version 1.1 der Software, Änderungshistorie 05.11.2007 - Alle Tastencodes werden in der Datei button.c in verschiedenen Arrays abgelegt. - Die Funktionen, die die Tastencodes prüfen, greifen auf die Arrays zu. - Der zuletzt gewählte Kanal wird im EEPROM gespeichert und steht somit auch nach einem Reset wieder zur Verfügung. Leider bekomme ich das Auslesen der EEPROM Daten mit Hilfe von eeprom_read_block im Augenblick noch nicht hin. Sobald das funktioniert, stelle ich die nächste Version mit einer Lernfunktion zur Verfügung. Gruß Frank Link
Moin, ist wahrscheinlich eine reichlich blöde Frage am frühen morgen aber ich wage es sie zu stellen: Welche Funktion steht hinter deinem Konzept? Da mir die Zeit fehlt mich durchs Programm zu lesen, bitte ich dich um eine kurze Funktionsbeschreibung!?!? Lieben Gruß Leidi
Hallo Sebastian, ich habe ein kleines Delphiprogramm geschrieben, mit dem ich die EEPROM-Daten auslesen kann. Über das Programm kann ein Anwender die Tastencodes die im EEPROM gespeichert sind überschreiben. Im Prinzip habe ich meinen Controller lernfähig gemacht, ohne den Controller mit zusätzlichen Code zu belasten. Die Kommunikation erfolgt über den UART. Innerhalb des Controllers ist eine entsprechende Routine implementiert die die Kommunikation steuert. Wenn ich alles vollständig implementiert und getestet habe, stelle ich alles ins Forum. Leider fehlt mir im Augenblick die Zeit um es zu Ende zu bringen. Als zusätzlichen Hintergrund musst Du noch wissen, dass ich die Platine auch gewerblich über meinen Shop vertreibe und meine Kunden sind nicht alle in der Lage einen MC zu programmieren. Falls Du mit Deiner Frage auf die Grundfunktionen abzielst, dann macht das ganze nichts anderes als einen ALPS-Motorpoti über eine RC5-FB anzusteuern. Zusätzlich habe ich noch 5 Ports nach außen gelegt. Gruß Frank
Moin Frank, vielen Dank für die Info. Habe gefragt, weil ich eine individuelle Lösung für ein kleines Problem suche: Suche eine Ansteuerung für einen hochpräzisen Motorpoti. Hintergrund: Habe bei einem Kunden einen 1 MW Gleichstrommotor stehen. Dessen Drehzahl wird über einen Poti geregelt (leider will der Kunde keine große Investition tätigen; damit fällt bspw. eine Lösung über einen Simoreg etc. weg). Dem Kunden geht es um Hochlaufversuche. D.h. er möchte den Motor in individuell einstellbaren Zeiten von Drehzahl Null auf Drehzahl x hochfahren. Da die Hochlaufversuche linear stattfinden sollen, ist nen flexibler Motorpoti wohl ein Lösungsansatz, oder??? Habe bislang ein elektronisches Poti "MR 255" von Micronor herausgesucht. Dachte evtl. dass man mit deiner Lösung auch etwas machen könnte?!?! Hast du evtl. nen Vorschlag Gruß Leidi
Hallo Leidi, einfach unbedarft gesprochen: Theoretisch könntest Du über die 5 freien IOs 5 Kennlinienverläufe programmiert abfahren. Die Kennlinien legst Du ins EEPROM. Über mein kleines Delphiprogramm könntest Du dann die Kennlinien einpflegen. Damit kann der MC je nach gewählten Programm den Motorpoti steuern. Die nachgeschaltete Elektronik müsste dann an Hand der Widerstandswerte die jeweilige Motordrehzahl einstellen. Der kritische Pfad dabei ist, dass der MC nicht weiss, wo der Poti steht. D.h. mit dieser Platine wird es nicht gehen, da ich alle Analgoeingänge belegt habe. Änderst Du aber das Layout dahin gehend, dass Du zur Steuerung des Potis ein Motor-IC verwendest, benötigst Du lediglich zwei IOs zur Ansteuerung. Wenn Du dann einen Stereopoti verwendest, kannst Du den einen Kanal über den Analogeingang abfragen und hast damit die Position. Wobei die Genauigkeit natürlich von gewählt ADC abhängt. [edit] hatte ich übersehen. Jeder Motorpoti läuft mit einer maximalen Drehzahl. Dies ist die kürzeste Zeit, die ein lineares hochlaufen des Motors ermöglichen würde. Langsameres Hochlaufen ist immer möglich, schnelleres nicht. [edit] Gruß Frank
Hallo, ich würde die Schaltung gerne in ein bestehendes Projekt integrieren, habe aber von Mikrocontrollern keinen blassen Schimmer. Aber trotzdem forsch an Werk: von AVR den myMultiprog V1.06 und den mySmartUSB Adapter gekauft und miteinander verlötet. Einen ATmega8 eingesetzt und das myAVRProgTool gestartet(zuerst den Treiber installiert). Treiber geladen, Port und ATmega8 erkannt. Soweit so gut. Der Versuch die Datei Motorpoti.hex zu brennen wird mit der Fehlermeldung: "Fehler: Der eingestellte(AT90CAN128) stimmt nicht mit dem erkannten(ATmega8) Prozessor überein." quittiert. Kann mir jemand behilflich sein und einen Tipp geben, woran es liegen könnte? R.Kempkes
R.Kempkes wrote: > "Fehler: Der eingestellte(AT90CAN128) stimmt nicht mit dem > erkannten(ATmega8) Prozessor überein." Deine Programmersoftware geht davon aus, dass du einen AT90CAN128 programmieren willst. Sag deiner Software, dass sie einen ATMEGA8 programmieren soll, und alles wird gut ;) Gruß, Magnetus
Danke Magnus Ich war halt nur so naiv zu glauben, dass, wenn ein ATmega8 erkannt wird und das Programm für eien ATmega8 ist, er dieses auch ohne Murren schreibt. Hab dann aber die Einstellung gefunden und (fast) alles ist gut :-) Eine klitzekleine Frage noch: Es reicht also aus die .hex-Datei in den Flash zu brennen, weiter muss nichts getan werden? Also nichts ins EEPROM oder so? Und zwei Fragen an den Entwickler, fall er mitliest: 1. Der Output des IR-Sensors gelangt auf der Platine an den Anschluss 6 der Anschlussleiste mit den schaltbaren Ausgängen. Warum? Wird doch in der Anleitung ausdrücklich darauf hingewiesen daran tunlichst nichts anzuschliessen? 2. Wozu ist die Anschlussleiste Reset/RXD/TXD gedacht? Da wird doch normalerweise gar nichts angeschlossen? Viele Grüsse R. Kempkes
Hallo, zu Punkt 1, Ich habe noch ein weiteres Board, mit dem ich die Platine ansteuere, in dieser Kombination, wird Pin 6 als serieller Eingang verwendet und der IR-Sensor nicht bestückt. zu Punkt 2: Die Anschlußleiste Reset/RXD/TXD dient dem Zweck der UART-Kommunikation und der Möglichkeit einen Reset-Schalter anzuschließen. Du hast ja die Möglichkeit den Quellcode für Deine Bedürfnisse anzupassen, also habe im Layout nicht alles dadurch vermasselt, dass ich die Ports dicht gemacht habe. Gruß Frank
Nach der Vollendung meines Vorverstärkers ist es an der Zeit mich hier bei Frank Link herzlich für den Prozessor und die tatkräftige Unterstützung zu bedanken. Seine fernbedienbare Lautstärkeregelung und die Quellenwahl funktionieren absolut perfekt. Dies ist die einfachste und eleganteste Lösung für eine Lautstärkefernbedienung unter Verwendung eines Motoropotentiometers, welche meines Wissens aktuell am Markt ist. Als besondere Zugabe sind dabei die TTL-Ausgänge zu sehen, welche eine Umschaltung der Eingänge über Relais ermöglichen. Nochmals herzlichen Dank! Martin
Bitte 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.