Mikrocontroller.net - Benutzerbeiträge [de]

Projekt Netzteiltester

2012-08-04T12:46:51Z

77.198.181.4: Änderung 67728 von 87.184.234.211 (Diskussion) wurde rückgängig gemacht.

[[Bild:Pstester_img_1.jpg|thumb|Der Netzteiltester in Aktion]]

== Features ==
* Über RS232 vom PC aus frei einstellbare Pulsfolgen, die mit 1kHz Wiederholrate ausgegeben werden
* Auf Wunsch Speicherung der Folgen-Definition im [[EEPROM]] des Controllers
* Erzeugung eines Trigger-Impulses für das Oszilloskop (externe Triggerung)
* Verwendung eines leistungsfähigen HEXFETs von International Rectifier, deshalb sollten Ströme bis 20A kein Problem sein (habe es noch nicht selbst ausprobiert, bei 3A war jedenfalls keine Erwärmung des FETs spürbar)
* 0.1Ω Keramik-Shuntwiderstand zur Strommessung
* Platine kleiner als halbe Eurokarte (d.h. kleiner als 80x100mm), trotzdem keine SMD Parts

== Hardware ==
* [[AVR|ATMega8]] mit 16MHz Quarz
* [[RS-232]] Schnittstelle für die Kommunikation mit PC
* IRF 1404 HEXFET als Leistungstransistor

== Bekannte Probleme ==
bisher sind keine Probleme bekannt :-)

== Kontakt und Diskussion ==
Natürlich freue ich mich auf jeden Kommentar und auf jede Anregung (Flames wandern trotzdem in den Mülleimer :)

In Bälde mehr ...

--[[Benutzer:Cl|Cl]] 15:36, 14. Mär 2005 (CET)

== Weblinks ==

* [http://www.elektronik-kompendium.de/public/schaerer/pstst1.htm Netzteiltester von Thomas Schaerer] inclusive ausführlicher Erklärung

[[Kategorie:AVR-Projekte]]
[[Kategorie:Spannungsversorgung und Energiequellen]]

Glitch

2012-04-11T16:43:47Z

77.198.181.4: /* Die Grundlagen eines Glitch */ typo

<center>'''Die Jagd nach dem Glitch''' oder '''Warum man besser die Grundregeln für Synchrones Design beachtet'''</center>

== Einleitung ==

Heutzutage enthält fast jedes Ding im täglichen Leben ein Stück Elektronik, und fast überall ist auch digitale Elektronik dabei. Diese Digitalschaltungen werden von Ingenieuren entworfen. Vor 30 Jahren wurde diese Aufgabe mit Standard [[74xx | TTL]] Logik gelöst. Komplexe Funktionen füllten Dutzende von Platinen, jede mit hunderten von IC gefüllt, welche alle verbunden waren. Später gab es programmierbare ICs (PAL, [[GAL]]), welche durch den Anwender programmiert werden konnten und deutlich komplexere, problembezogene Funktionen mit deutlich weniger Platzbedarf erfüllen konnten. Heute sind die am weitesten entwickelten ICs die [[FPGA]]s. Diese sind in der Lage, Daten mit mehreren hundert MHz Taktfrequenz zu verarbeiten, enthalten 10.000 und mehr [[FlipFlop]]s, Funktionsgeneratoren (LUTs, Look Up Table) und spezielle Funktionsblöcke ([[Speicher#BRAM | RAM]], DLLs, spezielle IO-Zellen etc.).

== Das Problem ==

Wenn man ein digitales System mit FPGAs entwirft, müssen ein paar grundlegende Regeln eingehalten werden, um ein stabiles Ergebnis zu erhalten. Im Allgemeinen sind FPGAs und die zugehörigen Synthesewerkzeuge auf '''synchrone Schaltungen''' ausgelegt. Aber es gibt ein paar schmutzige Tricks, welche in der guten, alten TTL-Zeit funktionierten, weil die relativ langsamen ICs und die großflächige Verkabelung als Tiefpassfilter wirkten und einige Dreckeffekte versteckten. Mit modernen FPGAs, dessen FlipFlops und LUTs mit einigen hundert MHz laufen, werden diese bösen Tricks nicht mehr gefiltert, genauer gesagt können und '''werden''' diese Tricks Probleme machen. Ein erfahrener Ingenieur wird diese Probleme von vorn herein vermeiden, aber ein Anfänger, welcher durch ein Zeitfenster aus der TTL-Zeit direkt in die FPGA-Ära hereinspringt hat diese Erfahrung (=erlebtes Leid?) nicht.

== Die Grundlagen eines Glitch ==

Das hier diskutierte Problem sind Glitches von digitalen Signalen. Ein Glitch ist ein sehr kurzer Puls (nur ein paar Nanosekunden lang), verursacht durch einen Dekoder. Ein Dekoder ist im Allgemeinen ein [[Speicher#ROM | ROM]], welcher einen Eingangscode (ein Vektor aus Bits) in einen Ausgangscode übersetzt. Die meisten FPGAs haben LUTs mit 4-6 Eingängen, was ganz einfach ein ROM mit 16-64 Bit darstellt, dessen Inhalt vom Entwickler festgelegt werden kann. Wenn man einen großen Dekoder mit mehr Eingängen benötigt, als eine einzelne LUT zur Verfügung stellt, dann muss man mehrere LUTs zusammenschalten bis die gewünschte Funktion erreicht ist. Im Allgemeinen ist aber die Durchlaufzeit von allen Eingängen zum Ausgang unterschiedlich, sowohl bei einer einzelnen LUT als auch bei mehreren zusammengeschalteten. D.h., wenn mehrere Eingangsbits gleichzeitig ihren Pegel wechseln, sind einige Bits schneller als andere. Das kann und '''wird''' dazu führen, dass der Ausgang des Dekoders vom aktuellen Zustand auf einen Zwischenzustand springt und nach wenigen Nanosekunden erst auf den richtigen, dauerhaften Zustand. Wenn so ein "verglitschtes" Signal als [[Taktung FPGA/CPLD | Takt]] oder asynchroner Reset benutz wird, verursacht das viele Probleme.

Schauen wir uns die Logik an.

[[bild:circuit_delays.png |thumb|600px|left| Aufbau und Verzögerungszeiten der Logik]] {{clear}}

Das ist ein einfaches 2-Bit Schieberegister, welches nur zwischen den zwei Zuständen "01" und "10" wechselt.

{| class="wikitable"
|+ '''Wahrheitstabelle für ein XOR-Gatter'''
|-
! Eingang C || Eingang D || Ausgang E
|-
| 0 || 0 || 0
|-
| 0 || 1 || 1
|-
| 1 || 0 || 1
|-
| 1 || 1 || 1
|-
|}

Wenn man die Schaltung statisch betrachtet, wird der Ausgang E immer 1 sein. Aber dynamisch ist das nicht der Fall.

Wir nehmen an.

* Der Ausgang von FlipFlop 1 (C) braucht 1ns um den Eingang (C) des XOR zu erreichen
* Der Ausgang von FlipFlop 2 (B) braucht 3ns um den Eingang (D) des XOR zu erreichen
* Die Durchlaufverzögerung der FlipFlops sowie der LUT soll 1ns betragen

Diese Zahlen sind realistisch.

Jetzt schauen wir uns den Übergang des Schieberegisters von "10" aud "01" genau an.

[[bild:timing.png|framed|left|Zeitdiagramm]]
{{clear}}
* 0ns - Start der Simulation
* 1ns - Der Takteingang führt eine steigende Flanke aus, was dazu führt, dass die FlipFlops neue Daten laden
* 2ns - nach der Speicherverzögerung von 1ns liegen die neuen Daten am Ausgang der FlipFlops an (A und B). Das passiert sehr synchron (+/-100ps und weniger).
* 3ns - der neue Zustand von FlipFlop 1 erreicht das XOR-Gatter nach 1ns Laufzeitverzögerung, der Eingang des XOR ist nun "11", was am Ausgang zum Zustand '0' führen wird.
* 4ns - der Ausgang des XOR (E) geht auf den neuen Zustand '0' über nach 1ns Gatterlaufzeit
* 5ns - der zweite Eingang des XOR wechselt auf "0", weil das Signal von (B) nach 3ns Laufzeit endlich angekommen ist
* 6ns - Das XOR reagiert auf den neuen Eingangscode "01" und schaltet auf '1' nach 1ns Gatterverzögerung

Ein guter, alter TTL-IC würde da nicht mal blinzeln, aber heutige FPGAs sind '''sauschnell'''. Nicht nur die LUTs, auch die FlipFlips können höllisch schnell schalten.

== Messaufbau ==

Die Messungen wurden mit einem Spartan-II Evaluationboard von Insight Electronics durchgeführt. Es enthält einen XC2S100-5PQ208. Die Testschaltung wurde durch einen 36 MHz Quarz getaktet, der Wert ist aber vollkommen unwichtig, 1 MHz würde genauso funktionieren. Die Testausgänge wurden mit selbstgebauten High Speed Tastköpfen gemessen, wie sie im Buch [http://www.signalintegrity.com "High speed digital Design - A Handbook of Black Magic"] empfohlen werden. Die Anstiegszeit dieser Tastköpfe liegt irgendwo bei 200ps. Das Oszilloskop, mit welchen die Screenshots gemacht wurden, ist ein Tektronix TDS 3034 mit 300 MHz Bandbreite. Einige Zusatzmessungen wurden mit einem Tektronix CSA 404 mit einem 11A34 Verstärker gemacht, welcher 1 GHz Bandbreite hat. Leider konnten damit keine Screenshots gemacht werden (Softwareprobleme). Man beachte, dass die Leitungen nicht [[Wellenwiderstand | terminiert]] sind. Reflektionen und Überschwinger sind für diesen Test unkritisch.

[[bild:setup.png|framed|left|600px|Aufbau der Testschaltung]]
{{clear}}

Die Testlogik wurde in [[VHDL]] definiert. Sie enthält zwei FlipFlops, welche mit jedem Takt gleichzeitig umschalten. Da sie immer entgegengesetzte Pegel haben, sollte der Ausgang des XOR immer auf '1' liegen. Aber auf Grund der ungleichen Durchlaufverzögerung der zwei Eingangsbits wird der Ausgang des XOR einen Glitch erzeugen. Dieser Glitch taktet ein drittes FlipFlop. Der "verglitchte" XOR-Augang sowie der Ausgang des 3. FlipFlops sind zur Messung auf Ausgangspins geroutet.

<VHDL>
--The IEEE standard 1164 package, declares std_logic, rising_edge(), etc.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity glitch is
port (
clk_in : in STD_LOGIC;
bad_clk : out std_logic;
glitch_detect : out STD_LOGIC
);
end glitch;

architecture glitch_arch of glitch is

component LUT2
port (
I0 : in std_logic;
I1 : in std_logic;
O : out std_logic
);
end component;

-- Attribute applied to instantiation
attribute INIT : string;
attribute INIT of L_XOR : label is "6";

signal S1, S2, S3, clk_bad, clk: std_logic;

begin
-- a demonstration of a decoder generating a glitch

-- toggling FlipFlops

process(clk_in)
begin
if clk_in='1' and clk_in'event then
s1<=not S1; -- these two signals are always inverted to each other
s2<=S1;
end if;
end process;

-- this is a big NO-NO, because the decoder produces glitches
-- clk_bad<=s1 xor s2;

-- we use a LUT instanciation so we can easy place then using LOC constraints

L_XOR: LUT2
port map(
I0 => S1,
I1 => S2,
O => clk_bad
);

process(clk_bad)
begin
if clk_bad='1' and clk_bad'event then
s3<=not s3; -- a toggle FF, which would never toggle if the decoder output was glitch free
end if;
end process;

glitch_detect<=s3;
bad_clk<=clk_bad;

end glitch_arch;
</VHDL>

Die Grundelemente wurden mittels Constraints auf definierte Plätze im FPGA platziert, um deterministische Ergebnisse zu erreichen. Auch die IO-Zellen wurden auf maximale Geschwindigkeit konfiguriert.

<pre>
NET "glitch_detect" LOC = "P42";
NET "clk_in" LOC = "P80";
NET "bad_clk" LOC = "P41";

INST s1 LOC = "CLB_R15C1.S0"; # place FF2 close to XOR LUT (C37)
INST s3 LOC = "CLB_R15C1.S1"; # place FF3 close to XOR LUT (C37)
INST l_xor LOC = "CLB_R15C1.S1"; # XOR LUT
INST s2 LOC = "CLB_R15C30.S0"; # place FF1, FAR from FF2, so the glitch will be VERY big
# modify the column C30 to set routing delay

NET "bad_clk" drive=24;
NET "bad_clk" FAST;
NET "glitch_detect" drive=6;
NET "glitch_detect" SLOW;
</pre>
[[Bild:fpga_grid.png|thumb|600px|left| CLB Matrix]]
{{clear}}
Die Verzögerung zwischen FlipFlop2 und dem XOR wurde durch einen großen Abstand bei der Platzierung erreicht. Dieser Abstand wurd Schritt für Schritt verkleinert und die Ergebnisse dokumentiert.

== Messergebnisse ==

Auf Kanal 1 wird das Signal bad_clk angezeigt, auf Kanal 2 glitch_detect.

[[bild:col30.png|framed|left|FlipFlop 2 in Spalte 30]]
{{clear}}
Das ist der erste Versuch. Weil die Differenz der Durchlaufverzögerung so groß ist, ist auch der Glitch recht lang. Aber sehen wir genau hin, es ist gerade mal ein 1.5ns Puls! Das ist weit weg von der Spezifikation der minimalen Pulsbreite des Taktes für dieses FPGA. Wie man sieht, schaltet FlipFlop 3 bei dem Glitch um.
[[bild:col15.png|framed|left|FlipFlop 2 in Spalte 15]]
{{clear}}
Der Glitch ist kürzer, aber das FlipFlop 3 schaltet immer noch problemlos.
[[bild:col10.png|framed|left|FlipFlop 2 in Spalte 10]]
{{clear}}
Jetzt wird es '''richtig''' schnell. Wir sehen auch die Grenzen des Oszilloskops (300 MHz), denn auf dem schnellen 1 GHz Oszilloskop erreicht der Puls noch die 0V Linie. Das FlipFlop 3 toggelt weiter.
[[bild:col08.png|framed|left|FlipFlop 2 in Spalte 8]]
{{clear}}
Und es toggelt immer noch. Aber wir haben die Grenzen des Oszilloskops und der IO-Zelle erreicht. Der Glitch ist ausserhalb nicht mehr messbar, auch nicht mit dem 1 GHz Oszilloskop. Da die IO-Zelle bis zu 24mA liefern muss und einiges an ESD-Schutzmassnahmen enthält, sind die Stukturen deutlich größer und haben damit mehr parasitäre Kapazität als die kleinen Strukturen im Kern. Dadurch werden sie langsamer. Man sieht auch, dass die Störung auf dem glitch_detect Ausgang durch Übersprechen von Ausgang bad_clk verursacht wurde.
[[bild:col03.png|framed|left|FlipFlop 2 in Spalte 3]]
{{clear}}
Jetzt haben wir die Grenzen dieser Technologie erreicht. Der Glitch ist einfach zu klein, um vom FlipFlop 3 noch "gesehen" zu werden. Nur der liebe Gott weiß, wie das Signal im Inneren jetzt aussieht. Aber Vorsicht! Das heißt '''nicht''', dass man einen glitchfreien Dekoder erhält, wenn man die FlipFlops nah am Dekoder platziert. Die Geschwindigkeit der Logikzellen bzw. Verbindungnetze schwankt mit der Temperatur (kalt = schnell), der Versorgungsspannung (hoch = schnell) und allgemeinen Fertigungstoleranzen. Man darf nicht auf die niedrige Geschwindigkeit der ICs zählen, um sie als Glitchfilter zu missbrauchen! Wenn man die Schaltung auf eine schnellere Technologie umstellt (schnelleres FPGA, ASIC), wird diese Methode '''scheitern'''. Die einzigen zuverlässigen Wege um Glitches zu vermeiden sind

* nur jeweils ein Eingangsbit umschalten ([http://de.wikipedia.org/wiki/Graycode Gray Code])
* Ein FlipFlop am Dekoderausgang nutzen, um das das Signal abzutasten

== Siehe auch ==

* [[Taktung FPGA/CPLD]]
* [[Oszilloskop]]

== Weblinks ==

* [http://www.sigcon.com/Pubs/straight/probes.htm Probing High-Speed Digital Designs], Originally published in [http://www.elecdesign.com/ Electronic Design Magazine], March, 1997

[[Kategorie:FPGA und Co]]
[[Kategorie:Signalverarbeitung]]

RS485 IO Board - ModellBahnLichtSteuerung

2011-11-21T11:26:16Z

77.198.181.4: Änderung 61770 von 2.88.170.5 (Diskussion) wurde rückgängig gemacht.

[[Datei:rs485_test.jpg|thumb|Testaufbau]]
Von: ''[[Benutzer:Micha68|Micha68]]''

== Einleitung ==

Hier stelle ich euch meine Planungen und Baufortschritte zur PC-gesteuerten Modellbahnbeleuchtung vor.
Die Idee ist, sämtliche Beleuchtungen einzeln steuern zu können. Ich denke, dass damit die Beleuchtung wesentlich realistischer darstellbar ist, als mit ein paar wenigen Schaltern ganze Strassenzüge einzuschalten.
Dabei soll es die Möglichkeit geben, vordefinierte Abläufe auf den Modulen laufen zu lassen und per PC die komplexe Lichtsteuerung über die Zeit zu machen.

Die Module bieten bisher folgenden Funktionsumfang:

* 24 Ausgänge zum Ansteuern von LEDs und Lämpchen
* PC-gesteuert per RS485-Bus oder stand-alone
* Bis zu 255 Module an einem Bus → 6120 Ausgänge!
* Alle Ausgänge dimmbar
* Versorgung über ein Zentrales 5V-Netzteil, bei Bedarf kann ein 5V-Regler bestückt werden
* Die Ausgänge können für den Betrieb mit LEDs mit der Bordinternen 5V-Spannung versorgt werden...
* ...oder in Blöcken zu je 8 Ausgängen mit externer Spannung versorgt werden (für Lämpchen, Relais..)
* drei Statusleds zeigen 5V, Datenverkehr und Programmiermodus an
* 3 Jumper dienen zum Einstellen der Betriebsart (Programmiermodus, Stand-alone und Aktion)

Ich habe zwei Layout-Versionen erstellt. Zum einen mit SMD-Bauteilen. Diese wird bei mir zum Einsatz kommen, da diese Module nur 80×50mm klein sind.
Die DIP-Version ist für weniger geübte Löter und misst 80×100mm. Diese wird aber im Moment nicht gepflegt und erst bei Bedarf auf einen Endstand gebracht.
Die Layouts wurden mit KiCad erstellt.
Der Preis der SMD-Version bewegt sich für eine Platine um 15€, baut man 25 Platinen kommt man durch Rabatte auf ca. 315€ – macht ca. 12€ pro Platine.

Folgene Befehle sind schon umgesetzt:
* Minimale und maximale Helligkeit pro Ausgang einstellen
* LED An / Aus mit einstellbarer Dimmgeschwindigkeit auf min bzw. max
* zufälliges Flackern, Geschwindigkeit einstellbar
* Blinken, Geschwindigkeit einstellbar
* Wechselblinken von 2 Ausgängen, Geschwindigkeit einstellbar
* Baustellenblitzer mit 8 Ausgängen, Geschwindigkeit einstellbar
* Ampelschaltung mit 10 Ausgängen (2× 3-LED Ampel für Verkehr und 2× 2-LED Ampel für Fussgänger), Geschwindigkeit einstellbar
* Haussteuerung: 4 Leds schalten in einer einstellbaren Zeit zufällig ein, bzw aus, Geschwindigkeit einstellbar
* Alle 24 Ausgänge Aus / An

Alle Einstellungen lassen sich im EEprom speichern. Somit gibt es die Möglichkeit (über Jumper) das einmal programmierte Modul auch ohne PC laufen zu lassen.
Ein weiterer Jumper ermöglicht die einfache Programmierung der Adresse: Jumper setzen, einen Befehl senden und die in diesem Befehl enthaltene Moduladresse wird als eigene Adresse übernommen.

Das System bietet pro RS485-Strang die Möglichkeit, bis zu 255 Module (Adresse 1–255) anzusprechen. Die Adresse 0 dient als Broadcast-Adresse an alle Module.
Hiermit können gleichzeitig alle Ausgänge oder Funktionen Ein- bzw. Ausgeschaltet werden.

Die PC-Software ist noch in der Entwicklung. Hier fehlt mir noch die Idee, wie man eine komplette Anlage übersichtlich darstellen kann.

Das Protokoll auf der seriellen RS485-Schnittstelle ist relativ einfach gehalten:

:{| {{Tabelle}}
|-
| 0xAA || Sync-Byte
|-
| 0xAA || Sync-Byte
|-
| 1–255 || Moduladresse, oder 0 für alle
|-
| 1–24 || Nummer des Ausgangs auf dem Modul
|-
| 0–x || Befehl
|-
| 0–255 || Wert
|}

== Software ==
;AVR:

Die AVR-Software besteht zum einen aus einer Soft-PWM-Routine hier aus dem Tutorial. Dieses wurde auf 24 Ausgänge erweitert.

Die RS485-Schnittstelle wird im Interupt abgewickelt.

Ein Statemachine-ähnliches Gebilde erzeugt die Dimmer und Ablauffolgen. Jumper JP4 dient zum setzen der Adresse. Ist der Jumper gesteckt, zeigt LED D26 "prog" (rot) den Programmierstatus an. Die Adresse, die im nächsten Befehl über den RS485-Bus gesendet wird, wird als eigene Adresse übernommen und ins EEprom abgelegt. Der Jumper kann nach erfolgreicher Programmierung wieder entfernt werden.

;PC:

Die PC-Software dient zum Konfigurieren und Steuern der Module. Ich schreibe das Programm mit Realstudio für Linux und Windows.

<gallery perrow="2" align="right">
Bild:MoBaLiSt_Module.gif| Module
Bild:MoBaLiSt_Gruppen.gif| Gruppen
Bild:MoBaLiSt_Zeit.gif| Zeitsteuerung
Bild:MoBaLiSt_Hand.gif| Handsteuerung
</gallery>

;Ansicht "Module": Einstellen der Parameter der einzelnen Module und Ausgänge.

: Dies sind zB die Namen der Module, die Namen der Ausgänge, minimale und maximale Helligkeit, die Zeit zum Dimmen von maximal auf minimal und umgekehrt, die Funktion, zB Blinken etc. Ausserdem können für das gesamte Modul die Konfigurationen eingestellt werden. ''Startmodus'' gibt an, wie das Modul gestartet wird:
:* 0=Grundkonfig und warten auf PC-Befehle
:* 1=Start aller Programme wie im EEprom abgelegt.

; Ansicht "Gruppen": Definition der Ausgangs-Gruppen. Dazu werden den einzelnen Gruppen Ausgänge zugeordnet. Die Ausgänge können in mehreren Gruppen enthalten sein. Die letzte Gruppenschaltung "gewinnt".

; Ansicht "Zeitsteuerung": Den Gruppen Ein- und Ausschaltzeiten zuordnen. Die Uhrzeit kann entweder aus RocRail übernommen oder die interne FastClock benutzt werden.

; Ansicht "Handsteuerung": Die Gruppen können als Schalter frei auf dem Bildschirm platziert werden (Übersicht Anlage). Von hier aus können Gruppen dann per Hand aktiviert werden.

; Ansicht "DCC": ist noch in der Entwicklung. Möglich ist im Moment, von Rocrail die MoBa-Zeit zu übernehmen. Ebenso kann der "DCC"-Verkehr mitgehört werden. Dies ermöglicht das Schalten von Guppen "DCC-Abhängig". Es können auch DCC-Ausgänge angelegt werden, die dann über Gruppen aktiviert werden können (nur RocRail).

== Hardware ==

Genaue Beschreibung folgt, sobald die ersten Platinen bestückt sind.

Die Ausgänge 1-8, 9-16 und 17-24 können jeweils mit max. 500mA belastet werden. Mehr schafft ein ULN2803 nicht. 
Bleibt man bei normalen Leuchtdioden kommt man bei 20mA pro LED auf 160mA pro Port, also alles im grünen Bereich. 
Bei normalen Modellbahnbirnchen mit 16V und 30-50mA kommt man auch gerade noch hin. 
Grössere Lasten sind möglich, aber immer in der Summe max. 500mA pro ULN2803. 

=== Bestückungsvarianten: ===

;5V extern oder per 5V-Regler auf der Platine:

[[Bild:5v_zentral.jpg|thumb|left|5V zentral]]
Ich betreibe meine Modellbahnelektronik mit einem Zentralen 5V-Netzteil. Diese 5V werden an P1 eingespeisst (Polarität beachten!).

Diese Spannung liegt dann parallel an P2 und kann zum nächsten Modul durchgeschliffen werden.
{{Absatz}}

[[Bild:5v_extern.jpg|thumb|left|5V lokal]]
Hat man keine 5V zur Verfügung, kann die Platine auch mit einem Gleichrichter und einem 5V-Regler bestückt werden. (Bauteile G4, U1, C15, C16 und C17).
An P8 kann dann ein Netzteil oder Trafo (>9V, max. 20V) angeschlossen werden.

Der Gleichrichter schafft maximal 1,5A. Dies sollte reichen, da die Ausgänge eh nur mit 500mA je Block belastet werden können.
Allerdings ist dann die Hitzeentwicklung zu beobachten.
Werden die Treiber maximal belastet, macht es Sinn, alle 4 Gleichrichter zu bestücken und die Versorgungspins P4, P5, P6 und P8 aus einem ausreichend starken Netzteil/Trafo zu versorgen.
Die Ströme verteilen sich dann auf die einzelnen Gleichrichter und die Erwärmung hält sich in Grenzen.
Benutzt man nur normale LEDs mit 20mA kommt man maximal auf 500mA. Das dürfte kein Problem darstellen (teste ich noch...)
{{Absatz}}

;interne 5V oder externe Versorgung für LED 1-8:

[[Bild:port_5v_intern.jpg|thumb|left|LEDs mit 5V]]
Jumper JP1 in oberer Position nutzt die Boardeigenen 5V zur Versorgung der Ausgänge.

Die 5V an den LED-Ports sind über eine PolyFuse abgesichert. Jeder Port ist mit 10uF und 100n abgeblockt.
Reicht die Spannung von 5V nicht aus - zB beim Betrieb von Lämpchen - können die Ausgänge Blockweise auch extern versorgt werden.
{{Absatz}}

[[Bild:port_extern.jpg|thumb|left|LEDs extern]]
Für die Ausgänge 1-8 ist dann der Gleichrichter G1 zu bestücken und der Jumper JP1 in die unteren Position zu setzen.
Die Spannung für die LEDs 1-8 wird an P4 angeschlossen.
{{Absatz}}

;interne 5V oder externe Versorgung für LED 9-16:

Wie oben, jedoch Jumper JP2, Gleichrichter G2 und P5 für die Versorgungsspannung.

;interne 5V oder externe Versorgung für LED 17-24:

Wie oben, jedoch Jumper JP3, Gleichrichter G3 und P6 für die Versorgungsspannung. 

; Anschluss von LEDs und die Berechnung der Vorwiderstände:

Die Leds werden an die Ausgänge D1-D24 angeschlossen. Auf der Rückseite befindet sich ebenfalls eine Markierung 1-24. Je nach Anwendung könne die LEDs auch von unten angeschlossen werden.
...

; Anschluss von Lämpchen:

...

=== RS485-Bus ===
Der RS485-Bus wird an K1 angeschlossen und kann über K2 zum nächsten Modul durchgeschliffen werden. 
Es ist auf die Polarität (A und B) zu achten. Ebenso muss die Masse durchgeführt werden. 
Baudrate 1.000.000 
*USB<->RS485-Wandler inkl. galvanischer Trennung: zB http://www.cti-shop.com/epages/15488632.sf/de_DE/?ObjectPath=/Shops/15488632/Products/95031100
oder
http://www.hjelmslund.dk/USB485.asp
*Am letzten Modul den Bus mit 120Ohm (R29) abschliessen!
*Bis zu 255 Module an einem Bus (bei diesem Transceiver), weitere USB-Wandler und somit weitere 255 Module sind natürlich möglich

===Datenblätter===
*Atmega16a http://www.atmel.com/dyn/resources/prod_documents/doc8154.pdf
*ULN2803A http://focus.ti.com/lit/ds/symlink/uln2803a.pdf
*MC7805BDTG http://www.onsemi.com/pub_link/Collateral/MC7800-D.PDF
*DF10SCT-ND http://www.fairchildsemi.com/ds/DF/DF005S.pdf
*MAX3085ECSA+ http://datasheets.maxim-ic.com/en/ds/MAX3080-MAX3089.pdf
----

== Bilder ==
{| border="0" cellspacing="20"
|-
|[[Bild:MoBaLiSt_SMD.gif|thumb|SMD-Version]]
|[[Bild:MoBaLiSt_SMD_shematic.gif|thumb|Schaltbild]]
|[[Bild:MoBaLiSt_SMD_komplett.gif|thumb|KiCad]]
|}

{| border="0" cellspacing="20"
|-
|[[Bild:MoBaLiSt_SMD_top.gif|thumb|Top-Layer]]
|[[Bild:MoBaLiSt_SMD_bottom.gif|thumb|Bottom-Layer]]
|}

{| border="0" cellspacing="20"
|-
|[[Bild:platineV1_top.jpg|thumb|Platine Top (Scan)]]
|[[Bild:platineV1_bottom.jpg|thumb|Platine Bottom (Scan)]]
|[[Bild:platineV1_foto.jpg|thumb|Platine Foto]]
|Die Pads sind vergoldet (ENIG). Leider ist das auf den Scan´s nicht so gut zu erkennen.
|}

{| border="0" cellspacing="20"
|-
|[[Bild:bestuckt1.jpg|thumb|]]
|[[Bild:bestuckt2.jpg|thumb|]]
|Atmega fehlt noch, weil DigiKey meinte, mir lieber ATXmega128A1 zum Preis der Atmega16A schicken zu müssen... Leider passt das 100-Pin-Monster nicht auf die Platine :)
|}

{| border="0" cellspacing="20"
|-
|[[Bild:scanb_top.jpg|thumb|]]
|[[Bild:scanb_bottom.jpg|thumb|]]
|Fertig bestückt und funktioniert :)
|}

{| border="0" cellspacing="20"
|-
|[[Bild:5er.jpg|thumb|]]
|5 Boards für die Softwarentwicklung
|}

{| border="0" cellspacing="20"
|-
|[[Bild:MoBaLiSt_DIP.gif|thumb|DIP-Version]]
|[[Bild:rs485_test.jpg|thumb|Prototyp]]
|}
----

== Downloads ==
* Bauteilliste, Bestellnummern, Preise: [[Media:MoBaLiSt BOM.pdf|Download]] - 10.06.2011
* SourceCode: [[Media:RS485_AVR.zip|Download]] (AVRStudio-Projekt) - 08.06.2011
* Befehlsliste: [[Media:rs485_Befehlstabelle.pdf|Download]] - 10.06.2011
* KiCad Projektdateien Rev 1.1: [[Media:RS485_KiCad_rev1.1.zip|Download]] - 16.06.2011
* Gerber-Files Rev 1.1: [[Media:485decoder_Rev1.1.zip|Download]] - 16.06.2011

* PC-Programm zur Steuerung / Konfiguration
----

== Stand der Dinge ==
* Prototyp läuft
* Layout erstellt
* 29.05.2011 - 30 Platinen bestellt (schwarzer Lötstop beidseitig, weisse Beschriftung beidseitig, Lötstop beidseitig, SMD-Pads beidseitig, ENIG - Eine Platine 1.85€, Einrichtung 38.43€, Versand 19.91€ - http://www.pcbcart.com)
* 06.06.2011 - MAX487 in einen MAX3085 geändert - dadurch 255 Module an einem Bus und BiDiB-tauglich (siehe http://www.bidib.org) !
* 06.06.2011 - Quarz in 16MHz geändert (höhere Baudraten bei DiDiB)
* 09.06.2011 - Platinen sind angekommen, Perfekte Qualität
* 17.06.2011 - Erste Platine gelötet. Erste Tests erfolgreich.

== Bekannte Fehler ==
* In der ersten Platinenversion sind durch die Änderung von Quarz und RS485-Transceiver die beiden Bestückungsaufdrucke falsch.
* Der Bestückungsaufdruck (Rahmen) von C13 fehlt, warum weiss ich noch nicht.
* falsches Footprint für die ULN2803. Reihenanbstand der Pads zu gering. WorkAround: Pins der ULN leicht ans Gehäuse biegen. In Rev 1.1 behoben. (Trottelfehler!)

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/216580
* Im Modellbahnforum: http://www.stummiforum.de/viewtopic.php?f=21&t=61640
* BiDiB: http://bidib.org
[[Kategorie:AVR-Projekte]]