Jump to content

Core Platine - PIC Problem (TX)


paya
 Share

Recommended Posts

Hallo SLP

Ja der 10Mhz Quarz hatte zwei gleichlange Beinchen.

Habe sicherheitshalber heute beim Conrad einen neuen Quarz und eine neue Diode (1N4148) gekauft und verbaut ... leider ohne jegliche Verbesserung...

so langsam aber sicher gebe ich auf...

ich habe alle kontakte auf kurzschluss überprüft und komme nicht mehr weiter...

bei mir waren die Beinchen des IC3 7805 miteinander verbunden, trotzdem hatte ich die richtige Spannung laut checkliste  ???

http://www.ucapps.de/howtodebug/mbhp_core_extract_measuring_vdd.gif

http://www.ucapps.de/howtodebug/mbhp_core_extract_measuring_gnd.gif

das wurde zwar behoben aber kann es sein das deswegen etwas kaputgegangen ist?

Link to comment
Share on other sites

Du hättest die Teile nicht gleich ersetzen müssen, ich hab nur gedacht dass du eventuell den falschen - sprich einen Quarz mit verschieden langen Beinchen - verwendet hast. Ich kann mir sonst nicht vorstellen wie man einen Quarz verkehrt herum einbauen kann...

Der 10 MHz crystal ist richtig gesetzt.

überprüf bitte nochmal ob auch alle bauteile am richtigen platz sind, eventuell helfen dir diese Grafiken weiter.... allerdings glaube ich dass midiMike keine doppelseitigen Platinen ätzt...

Link to comment
Share on other sites

Servus paya,

Du könntest ja mal ein paar Fotos mit guter Auflösungvon beiden Platinenseiten machen wenn Du die Möglichkeiten dazu hast. Außerdem wurde ja schonmal danach gefragt wo Du wohnst, da bestimmt jemand nicht so weit weg von Dir wohnt, der Dir helfen kann. Ich könnte mich anbieten und wohne ca. 50km östlich von Frankfurt/Main.

Gruß

suital

Link to comment
Share on other sites

Hey Paya,

.. du hast Post ...

Das Problem ist gelöst. Es war definitiv ein leerer PIC im Sockel.

Nachdem ich Bootloader und MIOS aufgespielt hatte, meldete sich das CORE fröhlich und wartete auf seine Applikation.

Leerer PIC ist natürlich doof und für den Laien nicht ohne weiteres erkennbar.

Na ja, hauptsahe das CORE funzt jetzt.

Gruss

Doc

Link to comment
Share on other sites

Hi Doc

1000 Dank noch mal

Also war mein Verdacht von Anfang an richtig  >:(

Ich weiß gar nicht wie ich dir danken soll...

der erste song wird auf jeden fall dir gewidmet :)

Und natürlich geht auch ein dickes DANKESCHÖN an alle hier im Forum, die mir bei er Problemsuche geholfen haben.

Gruss

Paya

Link to comment
Share on other sites

  • 8 months later...

Hallo Zusammen

Nach langer pause, ist das Projekt nun fast fertig... lediglich für die Stromversorgung muss ich mir noch was ausdenken.

Vielen Dank für alle die mir hierbei geholfen haben.

Ein Besonderer Dank geht hier an Onkel DOC  ;D

Wie versprochen hier ein paar Bilder zum genießen:

http://gentoo916.homelinux.org/gallery/main.php?g2_itemId=877

Sicher könnte man sich mehr mühe geben, aber ich wollte nur noch schnell fertig werden :)

Gruss

paya

Link to comment
Share on other sites

Danke MTE ...hab mir auch Mühe gegeben  ;)

hier noch ein paar Bilder aus einer anderen Perspektive sowie Innenleben

http://gentoo916.homelinux.org/gallery/main.php?g2_itemId=776

eine Info bezüglich des D-OUT und der blauen LED's

Ich musste anstatt der 220 Ohm "10k Ohm" Widerstände verwenden, da man sonnst ohne Sonnenbrille nichts sehen konnte  ;D

Gruss

Paya

Link to comment
Share on other sites

Dazu hätte ich evtl. einen Vorschlag zu machen, der aber eine Änderung/Erweiterung des

Bootloaders zur Folge hätte. Dafür könnte jeder "Laie" sehen, ob der PIC...

a) programmiert ist und

b) ob das Core läuft

Und zwar müßte man einige fest definierte Ausgabepins des PIC mit LEDs beschalten können.

Außerdem definiert man einen Eingabepin als "Test".

Schließe ich den "Test"-Pin z.B. per Jumper nach Masse kurz, sollte ein funktionierender PIC

daraufhin z.B. die LED im Sekundentakt blinken lassen.

Ist der "Test"-Jumper offen, wird der Bootloader gaaanz normal gestartet (dann muß natürlich auch die LED wieder abgeklemmt werden).

Über zwei weitere LEDs könnte man einen simplen MIDI-Monitor realisieren, wobei eine LED MIDI-IN, die andere MIDI-OUT anzeigen würde.

Damit hätte jeder eine 10000%ig sichere Möglichkeit die einwandfreie Funktion des Cores (und des PICs) in ein paar Sekunden herauszufinden.

Diese Funktionalität könnte evtl. auch in die Applikation(en) eingebaut werden - für den Fall, daß mal was nicht mehr klappt. Einfach Test-Jumper stecken und nachschauen...

Mir ist zwar klar, daß es zusätzlicher Aufwand wäre, die entsprechenden Routinen zu schreiben.

Ich denke aber, daß dieser Aufwand sich irgendwo auch lohnen würde und daß es für den ein oder

anderen sehr hilfreich wäre.

Andererseits, wenn ich bedenke, daß TK "mal eben" einen LCD-Treiber proggt (hab ich kürzlich hier gelesen...),

für ihn sollte das -hoff- kein allzu großes Problem darstellen.

Noch etwas zum Verhalten der LC-Displays (es heißt nämlich gar nicht LCD, ätsch -lach-):

Ich habe 10 Displays von Displaytech, Typ 162 mit 2 Zeilen á 16 Zeichen.

Alle Displays machen beim Einschalten ohne Verbindung zu einem "Sender" rein gar nichts.

Nur die Hintergrundbeleuchtung arbeitet (logo).

Ein anderes Display (2 x 20) schaltet beim Anlegen der Versorgungsspannung hingegen in der 1. Zeile 20 Curor-Kästchen ein, von denen die ersten 8 mit Unterstrich sind.

Wieder ein anderes (2 x 40) Display schaltet an der 1. Zeichenposition ganz kurz (< 0.5 S) eien Cursor ein und löscht dann den kpl. Displayinhalt.

Man sieht also, nicht alle Displays verhalten sich nach einem Reset gleich. Es ist also daran nicht sicher zu erkennen, ob ein Core spielt oder ob das Display falsch angeschlossen oder defekt ist.

Sollte jetzt keine "schulmeisterliche Belehrung" sein, sondern ich wollte nur mal meine eigenen Erffahrungen zu diesem Thema preisgeben.

Amiga-Falcon

Amiga-Falcon

Link to comment
Share on other sites

Dazu hätte ich evtl. einen Vorschlag zu machen, der aber eine Änderung/Erweiterung des

Bootloaders zur Folge hätte. Dafür könnte jeder "Laie" sehen, ob der PIC...

a) programmiert ist und

b) ob das Core läuft

Nette Idee .... aber:

Programmiertechnisch wäre das gar kein Problem. Das Problem sehe ich eher darin, daß man zwei Ports des PICs für eine (einmalige) Testoption verschwendet. Ganz abgesehen davon, dass die freien Ports überaus rar geworden sind.

Es stellt sich mir auch die Frage nach dem Nutzen einer Blink-Led als Funktionstest.

Es sei zunächst einmal festgestellt, das in den wenigsten Fällen tatsächlich ein leerer oder fehlerhaft programmierter PIC Schuld am Fehlverhalten des COREs ist. In den meisten Fällen sind es Löt- oder Bestückungsfehler.

Was mich gleich zum nächsten Contra-Punkt bringt:

Wie willst Du verhindern, das der "noob" die TestLED falsch herum einlötet?

Ich befürchte, wir würden uns einen neuen "Troubleshoot"-Renner einfangen:

Wir müssten erst dafür sorgen, das die Testschaltung funktioniert, bevor wir das Core testen....

Davon halte ich nicht sehr viel.

Damit hätte jeder eine 10000%ig sichere Möglichkeit die einwandfreie Funktion des Cores (und des PICs) in ein paar Sekunden herauszufinden.

Genau das sehe ich Anders. Ich denke, wir schaffen uns damit eine weitere Fehlerquelle. Denn, wie oben erwähnt, wie willst Du sicherstellen, das die "Hardware" funktioniert ??

Über zwei weitere LEDs könnte man einen simplen MIDI-Monitor realisieren, wobei eine LED MIDI-IN, die andere MIDI-OUT anzeigen würde.

Auch das würde wertvolle Ports verschwenden. Wenn man blinkende LEDs mag, kann man das mit einem 74HC00 (LTC-Modul) gerne haben.

Ein 100%-iger Test ist es ebenfalls nicht, denn eine flackernde Led am CORE heisst noch lange nicht, dass auch der Optokoppler funktioniert (Und eben in dieser Sektion liegt die zweit häufigste Fehlerquelle...)

Versteh mich nicht falsch, ich will Deine Idee nicht schlecht machen. Auf den ersten Blick klingt sie auch wirklich gut. Näher betrachtet scheint mir Dein Vorschlag aber mehr Probleme einzufahren, als er löst.

Meine höchst eigene Schätzung der am häufigsten auftretenden Fehlerursachen sieht so aus:

80% Löt- und Bestückungsfehler

10% Fehlerhafte Bauteile

5% Inkompatibilitäten am PC-Midi-Port

5% Fehlerhaft programmierte PICs

Dabei bleiben die "Bedienerungenauigkeiten" unberücksichtigt, denn manchmal ist auch derjenige,der den Lötkolben in der Hand hält das Problem ... ;D ;D

Unser bestes Troubleshooting Utensil ist einfach der "Midi-Troubleshooting-Guide". Damit kannst Du 99,9% aller Fehlerquellen abdecken. Mehr muss nicht sein.

Sieh Dir auch mal die PIN Belegung des PIC an (http://www.ucapps.de/mios/mios_pin_list.txt), dann verstehst Du, warum ich so auf den Ports herumreite. Die Vielfalt der Möglichkeiten des COREs lässt nicht mehr viel Spielraum für freie Pins ...

Gruss

Doc

Link to comment
Share on other sites

Nette Idee .... aber:

Programmiertechnisch wäre das gar kein Problem. Das Problem sehe ich eher darin, daß man zwei Ports des PICs für eine (einmalige) Testoption verschwendet. Ganz abgesehen davon, dass die freien Ports überaus rar geworden sind.

Da hast Du wohl etwas falsch verstanden, lieber Doc. Die Port-Pins für die Testfunktionen sollen eben nicht permanent belegt werden. Ich meinte das in etwa so:

Der Bootloader startet und schaut nach ob z.B. RC4 an Mase liegt (= Test-Jumper).

Wenn ja, dann läßt er z.B. eine an RC5 angeschlossene LED im Sekundentakt blinken (KEINE Blink-LED !).

Ist der Jumper offen (wie im Normalfall auch), bottet er durch und übergeht die Testroutinen.

Was an MIDI-daten rein kommt, könnte eine 2. LED anzeigen und die eigene Ausgabe könnte mit einer 3. LED funktionieren.

Der MIDI-Test könnte in etwa so ablaufen:

Ich sende über den PC eine bestimmte Bytefolge an den PIC, der diese mit einer ganz bestimmten Antwort quittiert.

Gleichzeitig könnte er die 1. Test-LED z.B. 3 mal schnell blinken lassen, so nach dem Motto "hab verstanden".

Damit hätte man beide MIDI-Wege separat gecheckt und wüßte auch gleich, daß diese Sache läuft.

Evtl. klappt ja das Core und der MIDI-Treiber macht Mucken... Da suchst Du dabnn vllt. Stunden dran rum.

Es stellt sich mir auch die Frage nach dem Nutzen einer Blink-Led als Funktionstest.

Siehe oben...

Es sei zunächst einmal festgestellt, das in den wenigsten Fällen tatsächlich ein leerer oder fehlerhaft programmierter PIC Schuld am Fehlverhalten des COREs ist. In den meisten Fällen sind es Löt- oder Bestückungsfehler.

Was mich gleich zum nächsten Contra-Punkt bringt:

Wie willst Du verhindern, das der "noob" die TestLED falsch herum einlötet?

Das kann man mit Sicherheit nie ausschließen. Dennoch wäre (auch für erfahrene Lötkolben-Jongleure) ein

solcher "Quicktest" sicherlich ganz brauchbar.

Man kann das Core erstmal zur Seite legen, weil es ja funktionöckelt und muß sich nicht erst ein LCD besorgen.

Ich befürchte, wir würden uns einen neuen "Troubleshoot"-Renner einfangen:

Ich denke, eher das Gegenteil wird der Fall sein. Ok, Wenn jemand partout ´ne Midibox basteln will, obwohl er nicht mal weiß, an welchem Ende der Lötkolben warm wird... Daran kann man nun mal nix machen.

Aber meine "Forum-Les-Erfahrung" zeigt, daß auch Elektronik-Neulinge durchaus in der Lage sind,

etwas (fast) auf Anhieb funktionierendes zusammen zu bauen.

Wir müssten erst dafür sorgen, das die Testschaltung funktioniert, bevor wir das Core testen....

Davon halte ich nicht sehr viel.

Eine LED kann man mit einem Ohmmeter auf Funktion testen und ob sie richtig herum eingekötet ist auch.

Einen Jumper braucht man i.d.R. nicht zu messen...

Genau das sehe ich Anders. Ich denke, wir schaffen uns damit eine weitere Fehlerquelle. Denn, wie oben erwähnt, wie willst Du sicherstellen, das die "Hardware" funktioniert ??

Auch das würde wertvolle Ports verschwenden. Wenn man blinkende LEDs mag, kann man das mit einem 74HC00 (LTC-Modul) gerne haben.

Und genau DAS hast Du wohl in den falschen Hals bekommen. War anders rum gemeint.

Ein 100%-iger Test ist es ebenfalls nicht, denn eine flackernde Led am CORE heisst noch lange nicht, dass auch der Optokoppler funktioniert (Und eben in dieser Sektion liegt die zweit häufigste Fehlerquelle...)

100%ig ist nichts im Leben.

Damit hätten wir aber die häufigste Fehlerquelle eingedämmt, oder nicht ?

Außerdem kann man einen Optokoppler ebenfalls mit einer LED am Ausgang "schnell" testen.

Im angeschlossenen MIDI-Gerät ist ja auch ein Optokoppler, dessen LED wir mit unserem ansteuern.

Versteh mich nicht falsch, ich will Deine Idee nicht schlecht machen. Auf den ersten Blick klingt sie auch wirklich gut. Näher betrachtet scheint mir Dein Vorschlag aber mehr Probleme einzufahren, als er löst.

Ich bin Dir wegen Deiner Meinung überhaupt nicht böse oder nehme Dir das krumm. Wieso auch ?

Hier ist ein öffentliches Forum, in das jeder seine Meinung, seine Tipps und Ratschläge, sowie seine persönlichen Ansichten schreiben darf (und auch sollte).

Meine höchst eigene Schätzung der am häufigsten auftretenden Fehlerursachen sieht so aus:

80% Löt- und Bestückungsfehler

10% Fehlerhafte Bauteile

5% Inkompatibilitäten am PC-Midi-Port

5% Fehlerhaft programmierte PICs

Dabei bleiben die "Bedienerungenauigkeiten" unberücksichtigt, denn manchmal ist auch derjenige,der den Lötkolben in der Hand hält das Problem ... ;D ;D

Unser bestes Troubleshooting Utensil ist einfach der "Midi-Troubleshooting-Guide". Damit kannst Du 99,9% aller Fehlerquellen abdecken. Mehr muss nicht sein.

Sieh Dir auch mal die PIN Belegung des PIC an (http://www.ucapps.de/mios/mios_pin_list.txt), dann verstehst Du, warum ich so auf den Ports herumreite. Die Vielfalt der Möglichkeiten des COREs lässt nicht mehr viel Spielraum für freie Pins ...

Gruss

Doc

Wie gesagt, meine Idee war anders gemeint, als sie offensichtlich verstanden wurde.

Vielleicht hab ich das auch zu ungenau beschrieben.

Außerdem müssen (!) meine (mehr oder weniger guten) Ideen gleich in die tat umgesetzt werden.

Das wäre ja noch schöner... Obwohl... soo schlecht ist diese Idee gar nicht... Hmmm... -lach-

Ich selber bin ein groooßer Freund von "Fehlerabfabg-Routinen".

Ob das in der Elektronik ist oder ob ich programmiere.

Mein Doppel-Core hat z.B. am Spannungseingang keinen Stabi, sondern eine Schaltung mit einer Z-Diode und einer 1N4007. Macht das Netzteil mal "Mucken" oder wird es verpolt, geht ´ne Sicherung kaputt. Ende.

Das selbe mache ich mit allen Modulen meiner Midibox.

Dort, wo "richtig" Strom fließt (z.B. auf dem Motorfader-Modul) habe ich für jeden Fader eine separate Stromversorgung nebst Sicherung vorgesehen. Ok, ist etwas aufwändiger, aber dafür geht im Falle eines Falles

nicht alles hops.

In diesem Sinne wünsche ich allen BOX´ern ein schönes, ruhiges Bastelwochenende,

Amiga-Falcon

Link to comment
Share on other sites

Da hast Du wohl etwas falsch verstanden, lieber Doc. Die Port-Pins für die Testfunktionen sollen eben nicht permanent belegt werden. Ich meinte das in etwa so:

Der Bootloader startet und schaut nach ob z.B. RC4 an Mase liegt (= Test-Jumper).

Wenn ja, dann läßt er z.B. eine an RC5 angeschlossene LED im Sekundentakt blinken (KEINE Blink-LED !).

Ist der Jumper offen (wie im Normalfall auch), bottet er durch und übergeht die Testroutinen.

Was an MIDI-daten rein kommt, könnte eine 2. LED anzeigen und die eigene Ausgabe könnte mit einer 3. LED funktionieren.

Ja, das täte aber nur tuten, wenn der Pin unter keinen Umständen niemals nicht über ein angeschlossenes Modul als "auf Masse liegend" erkannt werden würde. Sonst würde der Bootloader bei angeschlossenem SID Modul z.B. meinen er müsse in den Testmodus gehen. Das wär ja irgendwie doof, was?

Der MIDI-Test könnte in etwa so ablaufen: [...]

Also in etwa der MIDI Loopback Test nur eben im Bootloader integriert.

Dennoch wäre (auch für erfahrene Lötkolben-Jongleure) ein solcher "Quicktest" sicherlich ganz brauchbar.

Näh.

Ok, Wenn jemand partout ´ne Midibox basteln will, obwohl er nicht mal weiß, an welchem Ende der Lötkolben warm wird... Daran kann man nun mal nix machen.

Eben.

^---- Alles nur meine kleine Meinung.

Link to comment
Share on other sites

Im Prinzip sind die Ideen nicht schlecht, doch es mangel wie so oft an verfuegbaren Speicher. Im Bootloader-Bereich sind bspw. nur noch 22 bytes frei, da passen also nur noch 11 Assembler Befehle rein. Das reicht nicht. Deshalb muss man sich damit zufrieden geben, fuer einen Funktionstest eine LED an den MIDI Tx Pin anzuschliessen. Damit werden zwar nicht alle Fehlerfaelle abgedeckt, doch die LED sendet immerhin ein "Sign of Life"

IMHO reichen zwei Tests aus, um die Funktion des Cores in wenigen Sekunden festzustellen: TEST_OUT1 und TEST_INOUT1 - wenn die nicht funktionieren, beginnt die Fehlersuche - und hierbei wuerde ein erweiterter Bootloader nicht weiterhelfen. Stattdessen muss man nach wie vor die bereits dokumentierten Testreihe durcharbeiten.

Gruss, Thorsten.

Link to comment
Share on other sites

Ahs, so ist das also. Das konnte ich natürlich nicht wissen, daß der Speicher im PIC sooo knapp ist.

Ok, Aber das mit der LED am MIDI-Out ist ja schon mal was.

Immerhin zeigt dies, daß...

1) der PIC nicht defekt ist

2) er ein laufenden Programm hat

3) er imstande ist, MIDI-Signale zu senden.

Mehr ist für einen allerersten (quasi Alpha-) Test auch nicht nötig.

Wenn das schon nicht klappt, da gebe ich TK vollkommen Recht, dann beginnt eh die große Suche nach der evtl. Stecknadel.

Nun gut, ich danke Euch auf alle Fälle für die Infos,

Amiga-Falcon

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...