Idee des Ganzen ist, eine normale Infrarotfernbedienung mit einer SPS zu
koppeln.
Die Forensuche hat mich auf den Baustein SAA3049 gebracht, leider wird
dieser nichtmehr hergestellt.
Daher hab ich mir vorgestellt, das Ganze mit einem Atmega 8 zu
realisieren.
Da dies mein 1. Mikrocontrollerprojekt wird, hoffe ich mal auf eure
Unterstützung.
Angefangen habe ich damit, einen Schaltplan zu erstellen.
Evtl. schaut Ihr mal drüber und nehmt mein Projekt auseinander - bin
Kritikfähig
Hallo Edison,
kannst du den schaltplan evtl in bessere Qualität nocheinmal posten ??
Wieso willst du denn den empfangen code nicht einfach per serieller
Schnittstelle an die sps schicken, wäre doch viel einfacher und der
Schaltungsaufwand wäre um einiges kleiner.
Den Code gibt es bereit sfertig in der Codesammlung.
Gruß
Dennis
Hast Du Dir den Schaltplan als Vollbild angesehen?
Dann sollte eigentlich alles zu erkennen sein.
Wie groß darf hier ein Dateianhang sein? War da lieber ein wenig
vorsichtiger.
Klar, wäre per 232 erheblich einfacher.
Leider kostet sone Simatic CP Baugruppe 240,- da gehe ich lieber den
Umweg über Digitaleingänge.
Hrmm, also die SPS, mit der ich an der Schule arbeiten sollte, hatte
sowas wie eine serielle Schnittstelle nicht.
Die Schaltung sieht IMHO Ok aus. Vieleicht einen kleinen, eventuellen
Schwachpunkt:
Die meisten Optokoppler brauchen mindestens 20mA und haben einen
Spannungsverlust von ca. 1,3V. Da könnte der 330 Ohm Vorwiederstand
etwas knapp werden. Ich würd' 180 oder 220 Ohm nehmen.
Ok, war bloss ein bisschen blind ;-)
Was noch eine simple lösung wäre, des ganze über 2 drähte seriell in die
SPS zu schreiben, mittels eine daten und einer clockleitung.
Davon mal abgesehen, würde ich das taste aktiv bit auf den portd legen,
um die adressbits ebenfalls von bit 0 anfangen zu lassen, erspart dir
später eventuell ne nervige schieberei
@Nils
Richtig, der Optokoppler benötigt 20mA/typ 1,2V macht bei 5V dann
3,8V/0,02A also 190 Ohm.
Da hab ich mich wohl verrechnet.
@Dennis
Ja, hatte auch schon darüber nachgedacht, eine Datenübertragung über
weniger Eingänge zu realisieren - wollte aber erstmal möglichst simpel
an mein Ziel kommen.
Ist ja mein erstes Mikrocontrollerprojekt.
Werde die Adressbits verschieben und Taste Aktiv auf PB5 legen - besser
so?
ja, da du das empfangsbyte direkt auf den Port schreiben kannst ohne
viel hin und her zu schieben.
hast du dir schon Gedanken über die kommunikation gemacht ??
Wie lange willst du die Info anstehen lassen ??
Ich würde mir auf jedenfall noch ein bereit Bit oder ein Gelesen Bit der
SPS zum Controller schicken.
Edison wrote:
> @Nils> Richtig, der Optokoppler benötigt 20mA/typ 1,2V macht bei 5V dann> 3,8V/0,02A also 190 Ohm.> Da hab ich mich wohl verrechnet.
Das die Koppler 20mA verkraften, heißt noch lange nicht, daß man sie
immer damit stressen muß.
Nur bei Kopplern mit Schmitt-Trigger Ausgang muß man den minimalen Strom
einhalten.
Passive Koppler haben oft ne Stromübertragung von >=50%.
D.h. wenn die Last 1mA braucht, reichen 2mA durch die LED völlig aus.
Peter
Peter Dannegger wrote:
> Das die Koppler 20mA verkraften, heißt noch lange nicht, daß man sie> immer damit stressen muß.
Verkraften tun die laut Datenblatt 50mA. Von "stressen" kann eigentlich
keine Rede sein; dass ist die normale Betriebstemperatur des Tachos.
Viel weniger als die 20mA sollte man eigentlich nicht anlegen, da sonst
Collector-Emitterstrecke des Optokopplers als Leiter nicht mehr
sonderlich viel taugen könnten.
Ich hab sogar schon mit Photokopplern zu tun gehabt, die dann in eine
Art schwingend- rauschenden Zustand verfielen, wenn sie zuwenig juice
bekommen. Krass Alter, oder? :)
Super Unterstützung hier, ein dickes Danke so mal Zwischendurch.
werde also bei den 190 Ohm bleiben, denke damit liege ich innerhalb der
Spezifikationen der Optokpller.
Wenn das decodierte RC5 Signal 20ms lang ansteht, dann bin ich weit auf
der sicheren Seite, das ganze mit der SPS erfassen zu können.
Ich werde SPS seitig auswerten, ob eine Änderung eingetreten ist - so
sollte ich auf ein bereit Bit oder ein Gelesen Bit verzichten können.
Außerdem bekomme ich ja mitgeteilt, das momentan eine Taste gedrückt
wird.
Niels Hüsken wrote:
> Ich hab sogar schon mit Photokopplern zu tun gehabt, die dann in eine> Art schwingend- rauschenden Zustand verfielen, wenn sie zuwenig juice> bekommen. Krass Alter, oder? :)
Kann ich nicht bestätigen, ich nehme generell nur 1..5mA und hatte noch
nie Probleme.
Hast Du mal ne Bezeichnung von diesen komischen Typen. Vielleicht zu
heiß gelötet? Normal ist das jedenfals nicht.
Man sollte bloß keine Typen mit herausgeführter Basis nehmen, die können
bei ungünstigem Layout leicht Störungen einfangen.
20mA braucht man nur, wenn man die maximale Geschwindigkeit haben will.
Peter
@ Edison (Gast)
>Dateianhang: 4_10_07.JPG (139,6 KB, 10 Downloads)>Habe den Schaltplan mal auf aktuellen Stand gebracht
Beim nächsten mal die Bildformate beachten.
MFG
Falk
Falk Brunner wrote:
> Beim nächsten mal die Bildformate beachten.
Vieleicht ein wenig Offtopic:
Was dort über BMPs steht, ist nicht ganz richtig. BMPs können
unkomprimiert sein; sie können aber auch JPEG- oder PNG-Kodiert sein.
Siehe dazu Wikipedia:
http://en.wikipedia.org/wiki/Windows_bitmap
Dennoch mein vollstes Verständnis, wenn man BMPs grundsätzlich meiden
möchte.
@ Niels Hüsken (monarch35)
>Vieleicht ein wenig Offtopic:>Was dort über BMPs steht, ist nicht ganz richtig. BMPs können>unkomprimiert sein; sie können aber auch JPEG- oder PNG-Kodiert sein.
Falsch. Bilder können als BMP, JPEG oder PNG kodiert sein. Alle drei
sind Bildformate. Aber niemals BMPs als JPG oder PNG.Das wäre ja ein
Bildformat nochmal in ein anderes Format gepackt. Und das steht auch
nicht im Wikipediaartikel, wenn gleich die Formulierung nicht so ganz
gelungen ist.
MFG
Falk
Ich will mich da eigentlich nicht drum streiten, aber BMP ist eine Art
Quasicontainer für gewisse Kompressionsalogorhytmen. Der Bitmap-Teil
eines BMP kann sehr wohl Kompressionsdaten von PNG oder JPEG enthalten.
Seit Version 2 kann BMP schon RLE; PNG und JPEG ist erst seit Version 3
dabei...
Genauso wie in einem AVI Xvid, DivX oder WMV9 eingebettet sein kann.
Das steht nicht nur bei Wikipedia so, sondern auch hier:
http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html
Wie gesagt, im Prinzip ist es wurscht, aber was hier im Wiki steht ist
definitiv falsch.
@ Niels Hüsken (monarch35)
>Ich will mich da eigentlich nicht drum streiten, aber BMP ist eine Art>Quasicontainer für gewisse Kompressionsalogorhytmen.
Nein, das "normale" BMP ist ein sehr einfaches Bildformat, welches schon
seit einer Ewigkeit existiert. Und das ist kein Container ala AVI.
>Seit Version 2 kann BMP schon RLE; PNG und JPEG ist erst seit Version 3>dabei...>http://www.fortunecity.com/skyscraper/windows/364/...
Kann es sein, dass du BMP mit DIB verwechselst? Weil die Trennung auch
in diesem Artikel sehr unscharf ist.
>Wie gesagt, im Prinzip ist es wurscht, aber was hier im Wiki steht ist>definitiv falsch.
Sehe ich nicht so. So ziemlich jedes Programm, welches BMP ausspuckt,
spuckt das "normale" alte, unkomprimierte BMP aus. Damit ist der Rest
der Diskussion akademisch.
MFG
Falk
So weit weg von eurem Forenstandart war ich doch garnicht.
Danke für den Link.
Den Plan hab ich mit Splan erstellt - da kann ich leider nicht als PNG
exportieren.
Sind meine JPGs wirklich so schrecklich?
> Sind meine JPGs wirklich so schrecklich?
Zum Verständniss warum JPGs für Schaltpläne schlecht sind:
Jpeg wandelt Bildteile in überlagerte Sinusschwingungen um, löscht
diejenigen die den geringsten Anteil am Bild haben (betragsmäßig kleine
koeffizienten), und speichert die übrigen => Verlustbehaftete
komprimierung
Kann man sich als Elektroniker etwa als Versuch vorstellen, eine
Signalform durch Überlagerung von Sinusschwingungen nachzubilden.
Deine Schaltpläne haben nun harte Kanten, entsprechend einem
Digitalsignal. Das lässt sich nun denkbar schlecht so abbilden, die
Koeffizienten sind sozusagen alle wichtig. JPEG kann nun entweder alle
speichern => unnötig große Datei, oder auch wichtige verwerfen => Linien
werden unscharf, Blockartefakte.
Zum Vergleich hab ich mal dein Bildchen in PNG konvertiert:
8kb statt 140!
(Die schlechte Bildqualität liegt an der JPEG-Vorlage, direkt generiert
wär das PNG wohl noch kleiner+besser geworden)
Gut, gebe mich geschlagen ;-)
Habe meinen Plan als EMF exportiert und mit Irfan View als PNG
konvertiert.
Das File ist wirklich besser, hat aber auch 374kb.
Muß ich noch was bei den Einstellungen beachten?
Ach ja, zu meiner Schaltung - die Ausgänge des Atmega sind jetzt
Low=aktiv und die Belegung hat sich geändert.
@ Sascha W. (edison)
>Dateianhang: test.png (373,8 KB, 14 Downloads)>Gut, gebe mich geschlagen ;-)
Nich geschlagen, du solltest etwas lernen.
>Habe meinen Plan als EMF exportiert und mit Irfan View als PNG>konvertiert.>Das File ist wirklich besser, hat aber auch 374kb.>Muß ich noch was bei den Einstellungen beachten?
Sicher.
Glaubst du, dass es sinnvoll ist, das Bild mit 7896x5048 Punkten zu
speichern? 124x768 tuns meist locker.
Glaubst du, dass es sinnvoll ist, diesen Schaltplan mit 24 Millionen
Farben zu speichern? Wieviele Farben siehst du?
MFG
Falk
Falk Brunner wrote:
> Glaubst du, dass es sinnvoll ist, das Bild mit 7896x5048 Punkten zu> speichern? 124x768 tuns meist locker.> Glaubst du, dass es sinnvoll ist, diesen Schaltplan mit 24 Millionen> Farben zu speichern? Wieviele Farben siehst du?
Lernen ist ein langwieriger Prozess - das muß ich wohl immerwieder
feststellen.
Hatte gestern einfach nur gegoogelt, mit welcher Software ich ins PNG
Format konvertieren kann und mir Irfan View installiert.
Muß mich wohl noch näher damit auseinandersetzen.
Werde mich aber bessern - bestimmt
28_09_07.JPG
(120 KB)
