IDE-Schnittstelle 2

Beitrag von **Tommy** » Mittwoch 23. November 2005, 11:01

Gorcon hat geschrieben:Die Frage des Programmierens des Chips ist nicht ganz unberechtigt.
Glaube kaumdasman einen Fabrikneuen Chip einlöten kann underst dann per D-Box programmieren kann?

Wenn das gehen sollte erledigt sich die Sockelfrage.

Gruß Gorcon

Vllt kann das Teil ja mit einem uCode geladen werden? Je nach Wunschfunktion als IDE, NIC oder beides?

tomster hat geschrieben:UIII!
Des klingt ja ziemlich vielversprechend! Auch wenn ich etwas Bammel habe vor "..is ja dann Software.." zwex keinen Plan von sowas. Und so ein CPLD-Programmer ist auch nicht gerade billig.

Aber sonst begeistert mich die Einfachheit des Aufbaus in dem Posting. Und Mal ehrlich: so ein CPLD, auch mit 0.5mm Pitch, is doch eigentlich mit einer dünnen Lötspitze und etwas Entlötlitze schnell drin, bzw. drauf. Der Chip is ja gut zugänglich. Einfacher jedoch wär's wenn man nur einen Sockel auflöten würde in den man dann den fertig programmierten Chip einsetzen kann (Verfügbarkeit von in-socket-steckbar nicht verifiziert). Das spart dem nicht ganz so versierten Lötartisten/ ISP Programmer (da zähl ich mich übrigens auch dazu) wohl einiges an Gefrickel. Vorausgesetzt es fände sich ein "Fertig-programmierter-Chip-Versender"...

"Is ja dann software" bezieht sich immer darauf, das man das einfach ändern kann, nur ein bisschen Maus schubsen und Tastatur klappern. Nix mehr mit Lötkolben und so... Leider ist Software üblicherweise viel komplexer als Hardware, aber es geht dort auch nicht so leicht was kaputt :-)

Den Chip kann man ganz einfach selbst programmieren, ein Programmiergerät braucht man nicht, nur einen PC mit Parallelport, und das sogar in einer laufenden DBox. Schon x-Mal gemacht.
Edit: Das gilt auch für die erste Programmierung des Chips, da er zum Programmieren erst gelöscht wird, dann ist er ja auch neu. Das geht, weil ich nur IO-Pins zum Memory Connector verwendet habe, die im Reset hochohmig werden, und dann ist das für die CPU so, als wäre gar kein Board vorhanden.

Die Software dazu gibts kostenlos von Xilinx, und grosse Teile laufen auch unter Linux. Leider nicht der State-CAD Teil, den ich intensiv verwendet habe, aber so begeistert bin ich von dem Output nicht immer. Eine reine VHDL Lösung würde dann wohl auch komplett unter Linux gehen, was jawohl die natürliche Umgebung für Dbox-Software Entwickler ist...

Zum Kabel, das man zum Programmieren braucht: Es war möglicherweise sogar mal in der Elektor, habe ich mal gehört. Ansonsten gibts irgendwo bei Xilinx ein PDF mit dem Schaltplan. Zwei TTL Chips, also nix schlimmes. Aber ich habs bisher nicht selbst probiert.
Nur mit so einem Kabel wird man Verbesserungen an dem Chip auch später nutzen können, und da man den Umprogrammieren kann, ist er irgendwie dann auch ein Teil der Treibersoftware, oder?
(Vielleicht überlegt sich ja jemand, wie man so einen Chip über den Modem-Anschluss auch direkt in der Dbox Programmieren kann?)

Einen Sockel für die Chips halte ich daher nicht für notwendig, wenns die überhaupt gibt. Sind übrigens 144 Pins. Klar kann man das löten, hat ja ein guter Freund von mir auch gemacht.
Mit den 80 Pins vom Connector dazu ist das dann auch schon fast alles.
Nur sind das halt ne Menge Pins, und irgendwann sieht man nach einer Weile vor lauter Pins nix mehr :-)

Beitrag von **Tommy** » Mittwoch 23. November 2005, 11:16

...also nix mit uCode like AVIA und Konsorten? Denn das wäre ja zum entwickeln und testen am leichtesten - ganz ohne Kabel

@DBoxBaer

Hmm, auch ein Ansatz. Ich mein so ein Selberlötkabel geht sicher auch irgendwie. Stimmt.

Ich wollte mit den Software-Bedenken eigentlich nur ausdrücken, dass ich da überhaupt keinen Plan habe. Prinzipiell ist es wohl aber sicher besser auf sich Software-Updates/ Firmware zu beschränken, als dauernd die Hardware zu ändern. Und dann ist so ein eigenes Kabel sicher hilfreich.
Dennoch wär es zu überlegen, gleich den größeren Bruder des XC95144 zu nehmen. Dann hätte man noch Luft für Erweiterungen.

144 PINs? Naja, die Bezeichnung würde ja sowas suggerieren. Aber das Datenblatt spricht von 100/160 PINs:
"..Available in 100-pin PQFP, 100-pin TQFP, and 160-pin
PQFP packages.."
Aber vielleicht hab ich auch das Falsche erwischt.

Ich hab grad hier was zusammengelötet, das waren gute 4.000 PINs. Aber irgendwann stumpft man ab ;-) Das war mein erstes SMD-Projekt. Drum schocken mich die "paar PINs" nun wirklich nicht mehr.

Die genaue Bezeichnung ist wohl (Habe nur gerade kein Board in der Hand)

XC95144XL-5TQ144C

Die erste 144 bezieht sich auf die Zahl der Flipflops. Die zweite ist dann die Zahl der Pins. Die -5 steht für 5ns, was scheinbar noch gerade reicht,
die Timinganalyse ergibt zur Zeit etwa 80Mhz maximal Takt. (Bitte nur drüber nachdenken, wer was von "kritischer Pfad" und so versteht)

Den fetten 288er kann man auf einer Platine, die dann noch x-andere Sachen machen soll bestimmt brauchen, allerdings sind auch nicht mehr so viele Pins übrig. Da muss man dann mal zählen wieviel endgültig übrig bleiben. Der 288er kostet aber auch etwa das doppelte, soweit ich mich erinner:

Eine Frage, die ich mir bei der ganzen Geschichte ab und zu gestellt habe, ist wieviel man in die Box einbauen will. Irgendwann wirds unsinn, weil es das schon für ähnliches Geld fertig gibt. Tatsächlich ist ein PC mit DVB Karte irgendwann billiger als einen Haufen Teile in eine Dbox zu löten. Cooler ist das mit der Dbox zwar irgendwie schon, aber eigentlich will ich ja auch mal die ganzen Filme anschauen, die längst auf der Platte liegen...
(allerdings noch per Streaming dort gelandet.)

Ich weiss nicht ob es für das Kabel günstige fertige Quellen gibt. Vielleicht findet sich ja jemand, der die IDE-Platinen im grossen Stil produziert. Da kann man dann das Downloadkabel dann vielleicht auch gleich bauen lassen. Denn auch für Softwareentwickler ist das vielleicht mal interessant und man kann so selbst ein Update reinbrennen.

Infos zum Kabel finden sich hier:

http://www.xilinx.com/xlnx/xil_ans_disp ... ePath=3418

oder per google: Sucht mal nach:
xilinx jtag cable

Wenn man eine "Firmware aus Flash der DBOX per CPU Download" Lösung bauen will, wäre dann übrigens ein FPGA vielleicht die bessere Wahl?

Beitrag von **Gorcon** » Mittwoch 23. November 2005, 12:59

Vieleicht mal bei ELV oder bei emedia oder Segor nachfragen ob die nicht die Platinen und Bausätze zusammenstellen können.

Gruß Gorcon

Das Layout habe ich hier auch schon gefunden:
http://toolbox.xilinx.com/docsan/data/a ... /fig26.htm

und andere auch:
http://elm-chan.org/works/avrx/report_e.html

Allerdings versteh ich es noch nicht so ganz.. Bin halt nur ein Zusammenlöter, kein Elektroniker ;-) Aber eine Bauteileliste und kurzes HowTo würde da nicht nur mir, sondern auch den übrigen Interressierten helfen. Vielleicht kann man ja sowas erarbeiten; da bin ich gern behilflich.
Am Besten auf Lochrasterplatine, dann kann's jeder nachbauen. Die Bauteile werden ja im niedrigen Euro-Bereich liegen.

Die IDE-Platine wird wohl mit aufgelöteten Bauteilen nicht mehr ganz erschwinglich sein. Deine 120 Euro haben sich warscheinlich auf die 6 Leerplatinen bezogen. Bestückt wär's ja ein unschlagbarer Preis...
Aber im Pool kann der Preis zumindest für die Leerplatine schon ganz gewaltig sinken. Naja, darüber kann man aber eh erst nachdenken, wenn es mal soweit ist.

@Gorcon

Pool-Platinisten gibt's wie Sand am Meer. Und Segor macht meines Wissens so geringe Stückzahlen wohl auch nicht vorgefertigt.
Einfach Mal eine Anfrage starten. Das geht mit Target z.B. recht einfach. Da verschickt das Tool sogar die Emailanfragen!

Aber ich denke es ist eben noch zu früh um einen Pool aufzulegen. Erstmal sollte doch Baer's Prototyp laufen, oder?

Mal eine andere Frage an die Herren Checker: Kann kann nicht einen normalen STK200/300-kompatiblen AVR-Programmer durch Umbelegung des Ausgangslayoutes dafür hernehmen? Ich kenn mich da leider nicht so aus. aber ein fertiger AVR-Programmer kostet um die 12 Euro...

Beitrag von **Tommy** » Mittwoch 23. November 2005, 13:23

Die IDE-Platine wird wohl mit aufgelöteten Bauteilen nicht mehr ganz erschwinglich sein. Deine 120 Euro haben sich warscheinlich auf die 6 Leerplatinen bezogen. Bestückt wär's ja ein unschlagbarer Preis...
Aber im Pool kann der Preis zumindest für die Leerplatine schon ganz gewaltig sinken. Naja, darüber kann man aber eh erst nachdenken, wenn es mal soweit ist.

Auf jeden Fall muß gut überlegt werden das:

a. evtl der Netzwerkchip (wenn realisierbar) schon auf der Platine vorgesehen ist. (2 Platinen halte ich für zu teuer und zu Platzaufwändig da ja die Platte auch noch irgendwo rein muß)
b. eine Universallösung für alle drei Boxen gefunden wird (die überall von Form und Konnektivität reinpaßt)
c. vorher eine Umfrage (evtl. in extra thread) gemacht wird wieviel Bedarf besteht für Nokia, Sagem, Phillips

Beitrag von **gurgel** » Mittwoch 23. November 2005, 14:48

so, das Layout und der Schaltplan für Eagle kann ab sofort unter http://www.dboxservice-hallenberg.de/ide/ heruntergeladen werden.

Beitrag von MB » Mittwoch 23. November 2005, 20:26

Tommy hat geschrieben: Auf jeden Fall muß gut überlegt werden das:

a. evtl der Netzwerkchip (wenn realisierbar) schon auf der Platine vorgesehen ist. (2 Platinen halte ich für zu teuer und zu Platzaufwändig da ja die Platte auch noch irgendwo rein muß)
b. eine Universallösung für alle drei Boxen gefunden wird (die überall von Form und Konnektivität reinpaßt)
c. vorher eine Umfrage (evtl. in extra thread) gemacht wird wieviel Bedarf besteht für Nokia, Sagem, Phillips

Ihr seid euch aber schon im klaren das ebensolche anfragen/wünsche so ein Projekt fast schon wieder erwürgen!?
Lasst doch einfach mal nen IDE Board kommen (ne Nokia hab ich noch

). Wenn sowas für ne Nokia läuft und jemand vorgemacht hat wies geht, dann finden sich auch andere die das an Sagem/Philips anpassen...

Allerdings bin ich nicht bereit für die teile 100 Euro (ohne hdd natürlich) auszugeben, da ich hier ne Fix & Fertig Lösung (Homecast S8000 CIPVR) stehen habe und dessen einfachheit für gerademal 300 euro sehr schätze

so manch anderer sollte trotz der wirklich Kultigen DBox auch mal über den Tellerrand schauen, schaden tuts net, wenn mir auch Neutrino fehlt

Weiter so, ich wünsche dem Projekt alles gute.

Also ich würde auch sagen wir sollten die Kirche mal im Dorf lassen.

Ist doch schon echt genial das in das IDE-Projekt wieder leben gekommen
ist. Meiner Mienung nach sollte erste einmal diese Funktionalität
sichergestellt sein, bevor schon wieder über andere Funktionen
nachgedacht wird.

Ein Produzent für die Platinen in kleiner Stückzahl sollte sich meiner
Meinung nach finden lassen. Es gibt ja auch andere Steckplatinen für
die dbox die es fertig zu kaufen gibt...

Das selber zu löten ist denke ich nur eine Sache für Leute die in diesem
Bereich entsprechene Erfahrung haben.

Möchte noch hinzufügen das ich sofort 5 Stück kaufen würde.
Vorausgesetzt der Preis bleibt im Rahmen...

Gruß
____Paule

@PauleFoul
Yupp, so seh ich das auch. Es sollte doch erstmal das Grundinterface laufen, bevor man über neue Dinge nachdenkt. Wobei ich dennoch der Meinung bin, dass die Idee mit dem "größeren Bruder-Chip" vielleicht nicht schlecht ist.
Auch wenn der Chip das Doppelte kostet. Sind ja "nur" 40 anstatt 20 Euro. Dafür hätte man aber noch Luft für andere Tasks. Man müsste wohl dafür auf der Platine einige Expansion-Anschlüsse vorsehen, weil man ja an die Pins direkt nur schlecht was anlöten kann. Aber auch das ist Zukunftsmusik.

Nach meinem momentanen Recherchestand kommt so ein IDE-Bausatz inkl. Platine (mit dem kleinen Chip) wohl auf irgendwas um 35-40 Euro. Evtl. sogar noch günstiger. Ich hab keine Preise für den Nokia-Memory-Connector oder die benötigten passiven Bauelemente um den IC. Die Platine liegt bei einem angefragten Platinenhersteller unbestückt bei unter 5 Euro! (Auflage 100 Stück). Dann muss natürlich jeder den IC selbst auflöten. Soviel zur Hardware.

Was jedoch noch software-seitig notwendig ist, um das Interface im Image auf zum Laufen zu bringen, weiss ich (noch) nicht. Wäre nett von DBoxBaer, wenn er mal kurz hierzu den Sachstand posten könnte.

Wie siehts mit der Software aus:

Im U-Boot habe ich einige Routinen in common/cmd_ide.c modifiziert.
Da ich den Source im Moment nicht vor mir liegen habe, aus dem Gedächtnis:
Es sind die inb, outb und die beiden Varianten fürs read (swapped und
normal). Die Write Routine habe ich noch nicht laufen lassen, die ist aber natürlich auch geändert. (Ich meine diese kleinen Routinen, die in einer Schleife die 128 Worte bzw. 512 Bytes kopieren)

Die Include Files für die Konfiguration der Adressen reichten leider nicht aus, weil ich zum Beispiel immer gleich 32-Bittig auf den Chip zugreife: Das machts aus Chip-Sicht einfacher (misalignte Zugriffe und solchen Quark), und für die CPU ist das sowieso egal.

Als ich vor einiger Zeit im Kernel geschaut habe, habe ich dort vergleichbare Routinen gefunden, daher ist das wohl schon alles, muss ich halt nur noch ausprobieren:
Immerhin habe ich meine Umgebung endlich soweit zusammen das wieder ein Kernel vom Netz geholt wird, und die Config des Kernels habe ich wohl auch bereits angepasst, das die entsprechenden Module erzeugt wurden.

Meine Theorie sieht so aus, das "inb" und "outb" sich nicht so schrecklich auf die Performance auswirken sollten, den die Daten fliessen nur bei den read und write Routinen. Inb braucht bei mir halt zwei Zugriffe statt einem, aber das macht wohl kaum was aus. read braucht 130 Zugriffe, aber bei 16 Bit Interfaces sinds ja 256. Dummerweise darf das aber nicht überoptimiert werden, am besten wäre es wenn man die read und write Routinen in Assembler schreibt, das sie möglichst genau alle 240ns ein Wort lesen: Schneller darfs nicht, und langsamer heisst schlechter.
Keine einfache Übung, aber es geht ja um exakt eine Loop für genau einen Prozessor... Wenn da jemand vielleicht einen Vorschlag hat: her damit.
Ach ja: Das ganze gilt nur für PIO Mode 4 Platten die nicht noch Warte-Zyklen einstreuen. Aber das sollten doch wohl sowieso alle heutigen Platten so machen?! Für den Fall habe ich aber auch schon eine Idee, wie der Chip das mit der CPU aushandelt, wenn es denn notwendig ist.

Die swapped-Variante beim read im U-Boot wird meiner Meinung nach nur für den Identity-Info-Block der Platte gebraucht, daher ist hier eine Optimierung auch nicht so wichtig und bleibt der Software überlassen. Für das normale read sollte der CPLD die Daten nämlich schon in der richtigen Reihenfolge liefern. (fatls von u-boot Kommandozeile hätte sonst wohl kaum funktioniert)

Ach ja: Bleibt noch sowas kleines wie der Interrupt:
So wie ich das sehe ist bei der Nokia an der CPU Pin 15 von Port C am Modem Connector angeschlossen. Laut Doku der CPU sollte dieser Pin einen Int auslösen können: Der Rest ist dann Software(TM): Ich glaube wir brauchen einen Int, aber wie das nun im Kernel eingehängt wird habe ich in meiner Betrachtung mal nach ganz hinten geschoben...

Aus der Doku der CPU:
16.14.9.5 PORT C INTERRUPT CONTROL REGISTER.
The 16-bit read/write port C interrupt control (PCINT) register indicates how changes on the pin cause interrupts when they are generated with that pin. The PCINT is cleared by reset.
Bits 0â€“3â€”Reserved. These bits are reserved and must be set to 0.
EDM4â€“EDM15â€”Edge Detect Mode for Lines 4â€“15

Und dann noch das Thema DMA:
Die SCCs der CPU erlauben etwas das IDMA genannt wird. Laut newsgroups bei den 8xx Cpus wohl nicht das schnellste, was man so machen kann, aber vielleicht hilfts uns trotzdem, weil es "nebenher" arbeiten kann, also vielleicht die CPU-Load senkt?! Immerhin scheint mir die CPU sowieso schneller zu sein als das IDE Interface...

Ich meine am Modem auch die Leitung PB23 gesehen zu haben:
PC15 ist auch DREQ1, und PB23 ist auch SDACK1

Dazu dann dieses aus der Doku der CPU:

16.6.2 IDMA Interface Signals
The MPC823 IDMA has two dedicated control signals per channelâ€”DMA request and DMA acknowledge. IDMA accepts DMA requests from the DREQ1 and DREQ2 signals and acknowledges the request with the SDACK1 and SDACK2 signals. The peripheral used with these signals can either be a source or destination of the IDMA transfers. The DREQx signals are also used for memory-to-memory request generation and, in this case, must be connected to the timer that controls the transfer.

16.6.3.11.3 Single-Address Mode (Fly-By Transfers). Each IDMA channel can be independently programmed to provide single-address transfers. The internal storage is not used by IDMA, since the transfer occurs directly from a device to memory. This mode is often referred to as fly-by mode because the internal storage is not used.

16.6.3.11.4 Single-Buffer Burst Fly-By Mode. This mode is used to transfer a data block from a peripheral to system memory. When the buffer has been completely transferred, channel operation is terminated. Both progressive (non-interlaced) and interlaced destination address generation modes are supported. This mode of operation is a subset of
the buffer chaining mode with reduced latency and it is restricted to fly-by transfers. It is supported only on IDMA channel 1.

OK, a little too much information...

Zumindest für mich. Aber wenn ich es richtig verstehe, dann gibt es noch keine "fertigen" Files/ Kernel, die einfach im vorhandenen Image ausgetauscht werden müssten um das Interface zum Laufen zu bringen.
Man (=DBoxBaer) ist also noch am wurschteln. Nicht dass das meine Vorfreude schmälern würde, aber damit wird es noch nicht ratsam sein eine größere Menge an Platinen zu bestellen. Ich mein aus End-Nutzer-Sicht.

tomster hat geschrieben:OK, a little too much information...

Zumindest für mich. Aber wenn ich es richtig verstehe, dann gibt es noch keine "fertigen" Files/ Kernel, die einfach im vorhandenen Image ausgetauscht werden müssten um das Interface zum Laufen zu bringen.
Man (=DBoxBaer) ist also noch am wurschteln. Nicht dass das meine Vorfreude schmälern würde, aber damit wird es noch nicht ratsam sein eine größere Menge an Platinen zu bestellen. Ich mein aus End-Nutzer-Sicht.

Na ja, lieber zuviel Info als zuwenig... Oder?

Ansonsten "full Ack".

Der Zustand ist im Moment halt so, das schon einiges geht, und nun der eine oder andere vielleicht hilfreiche Kommentare beitragen kann. Und wer will, kann auch schon drüber nachdenken, wie man die Hardware organisieren könnte usw. (Angebote einholen zum Beispiel?).

Den "Inhalt" vom CPLD gibts demnächst natürlich ebenfalls, da ist noch die Frage, in welcher Form man das macht, denn es gibt verschiedene Nutzungen dieser Daten:
- Einmal um am CPLD selbst zu arbeiten. Da sind die Original Sourcen notwendig und die ganze Entwicklungsumgebung. Die Source-Files zippe ich demnächst mal zusammen.
- Dann um den CPLD zu programmieren (z.B. initial) . Da braucht man nur das Binary und ne Software/Kabel zum downloaden. Da kann ich dann zum Beispiel einfach meine jeweils aktuellste Version zur Verfügung stellen was die Entwicklungsumgebung ausgespuckt hat.
- Die dritte Nutzung ist für Softwerker: Dokumentation, was im Chip passiert. Zum Beispiel wie die Adressen verwendet werden usw. Da braucht man dann nur die Bilder von den States usw. Ich überlege gerade, ob das nicht vielleicht was fürs Wiki ist?

Angebot hab ich schon eins eingeholt. Allerdings nur für die unbestückten Platinen. Der Preis liegt bei einer Auflage von 100 Stück bei irgendwas um die 3,50 Euro brutto. Also gar nix.

Ob es Sinn macht auch eine Bestückungsanfrage zu senden mag ich bezweifeln. Es gibt hier sicher jemanden, der eine Hot-Air-Station sein Eigen nennt und die Chips in nullkommanix auf die Platine gelötet hat. Ansonsten sei auch die Toaster-Oven-Methode erwähnt:
http://www.seattlerobotics.org/encoder/ ... en_art.htm

Geht sicher auch mit einem handelsüblichen Umluftherd. Mal vorsichtig bei der besseren Hälfte anfragen. Ach wenn ich's mir so recht überleg nicht fragen. Besser warten bis sie außer Haus ist ;-)

Ich will damit nur sagen: Habt keine Angst vor der Lötarbeit. Wer nicht gerade 2 Hände in Gips hat, sollte das hinbekommen. Und die Ersparnis sollte deutlich sein, gegenüber einer fertigen Platine.

just a thought or two...

das Löten ist für mich kein Problem, und würde ich dann auch anbieten.

Ansonsten sei auch die Toaster-Oven-Methode erwähnt:
http://www.seattlerobotics.org/encoder/ ... en_art.htm

In einem Minibackoffen, sowas habe ich auch noch nicht gesehen.

Die Plattine ist danach bestimmt gut durch.

Wie ist denn der Pinabstand? so wie bei einem Avia600 oder eher so wie beim Frontprozessor?

Gruß Gorcon

avia600

Das wird eng.

Ich glaube dann muß gugel löten.

Gruß Gorcon

Gorcon hat geschrieben:
Ansonsten sei auch die Toaster-Oven-Methode erwähnt:
http://www.seattlerobotics.org/encoder/ ... en_art.htm

In einem Minibackoffen, sowas habe ich auch noch nicht gesehen. :gruebel:

Die Plattine ist danach bestimmt gut durch. :lol:

Wie ist denn der Pinabstand? so wie bei einem Avia600 oder eher so wie beim Frontprozessor?

Gruß Gorcon

ROTFL!

Aber mit meinem Backofen darf ich das bestimmt nicht.

Doch im Ernst: Die Platine ist beidseitig bestückt ( -> ergibt besonders kurze Wege): Unten Connector, oben drauf der CPLD. Fällt dann nicht einer von beiden im Ofen runter? :-)

Deshalb fällt auch das Bügeleisen zum Festlöten wohl leider aus: An sowas hatte ich beim Layout auch wirklich nicht gedacht...

Wie gesagt die "normalen" SMD bekomme ich auch noch gut gelötet, aber vor dem Chip und deren geringen Pinabstand habe ichdann auch gesunden Respekt. (vor allem wenn sich da eine Brücke bilden sollte wo sie nicht hingehört.) Habe nun mal keinen Heisluft lötkolben.

Gruß Gorcon

Die Variante mit dem Ofen war zwar nur informationshalber gepostet, aber ich beabsichtige wirklich eine Platine eines anderen Projekts so zu machen. Da sind es aber gute 1200 Lötstellen pro Platine. 3 hab ich schon händisch gemacht, aber im Ofen sollte es deutlich schneller gehen.

Allerdings in unserem Fall wird es wirklich schwer damit beidseitig zu bestücken. Aber dann muss man halt zumindest den Connector händisch auflöten.

@Gorcon
Wegen der Lötbrücken brauchst du dir wirklich keine Sorgen zu machen. Für sowas gibt es Entlötlitze. Damit bekommst du alles wieder weg, was da nicht hingehört. Man muss ja nicht grad mit 400 Grad an die Pins gehen.

Ich muß mal schauen vieleicht habe ich noch irgendeine Platine zum üben.

Gruß Gorcon