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

Schaltest du da Ausgänge des AVRs zusammen?

Sowas macht man ja eigentlich nicht ...

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

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