Hi zusammen, es bedarf eurer Weißheit, da ich alleine nicht weiter komme Zunächst die Daten. Hardware: - 32 HCT165 in Reihe - D7-D3 Erhalten ein Sensorsignal und liegten (für dieses Problem) immer auf einem HIGH-Pegel (+5V) - D2-D0 permanent auf GND gelegt/lötet - Q der "ersten Stufe", CLK, PL (parallel load) gehen auf den µC - SERIAL DATA IN der "letzten Stufe" ist über 10k an GND - Jeder HCT hat einen 1µF Kondensator - Die Schaltung ist als U aufgebaut. Das heißt die Steuerleitung CLK, PL bekommen zuerst das IC 1 und 32, gefolgt von 2 und 31, gefolgt von 3 und 30 usw. Software: - CLK hat highpegel wärend PL "Daten" einliest. - Werte werdern bitweise eingelsen, in ein Byte überführt und in einem Array gespeichert. Das Problem: Da der Dateneingang der letzten Stufe ja auf GND liegt und ich anstatt 32 z.B. 38 mal ein Byte einlese sollten die die letzten 6 Byte ja alle durchgängig 0 sein.... und genau das ist nicht der Fall. Zumindest nicht immer! Teils ja, teilweise habe ich aber genau das gleiche Muster wie bei den physisch vorhandenen Schieberegistern. Also 0b11111000 anstelle 0b00000000 und das macht mich sehr stzuig und ich verstehe nicht warum. Warum lese ich den nun 38 mal aus ? -> NUR SO, weil mir danach war und ich jetzt einen Fehler aufgedeckt habe, der mich zweifeln lässt ob die Übertragung sicher abläuft. Zumal schwankt das Ergebniss immer. Mal ist es richtig, mal nicht. Hat einer von euch ne Idee wie das kommen kann ? Ich lasse mir die Daten über die RS232 Schnittstelle ausgeben was dann so ausschaut wie im angehängten Bild.
Angehängte Dateien:
-
Unbenannt.PNG
9,9 KB
Axel schrieb: > Da der Dateneingang der letzten Stufe ja auf GND liegt und ich anstatt > 32 z.B. 38 mal ein Byte einlese sollten Gibt es einen SAchaltplan?
Axel schrieb: gleich vorweg. Ich hab auch keine Patentlösung. > - Jeder HCT hat einen 1µF Kondensator Ist vielleicht ein bischen groß. Schon mal 100n probiert? > Software: > - CLK hat highpegel wärend PL "Daten" einliest. > - Werte werdern bitweise eingelsen, in ein Byte überführt und in einem > Array gespeichert. Was benutzt du? Software oder Hardware-SPI? Taktrate? Ich würde auch mal an einzelnen 165-ern anstelle der fixen 1 Bits unterschiedliche Muster anlegen und dann sehen ob die im Output korrekt auftauchen.
Könnte es sein, dass du PL für eine kaum messbare Zeit auf low und gleich wieder auf high setzt während du ausliest (also zwischen den Bytes)? Das geht dann in vielen Fällen gut, weil die Flanke zu kurz ist, um erkannt zu werden, aber wenn sie mal zufällig dann doch einmal zu lange ist, dann initialisiert sich die ganze Kette zwischendrin mal neu... Vielleicht kannst du ja mal das Muster des dem uC am nächsten liegenden Registers etwas abwandeln (ein zusätliches Bit auf 0), so dass du erkennen kannst, falls der Inhalt dieses Schieberegisters erneut auftaucht (spräche für die Theorie eines unbeabsichtigten "loads"). Könnte auch ein Übersprechen einer benachbarten Leitung auf PL sein, 32 Schieberegister sind ja ne ziemlich lange Kette... -> Pullup am Ende von PL ausprobieren.
:
Bearbeitet durch User
Erfüllen deine Eingangssignale am HCT165 die Spezifikation der Flankensteilheit von typ <500nsec Anstiegs-/Abfallzeit? Wenn nicht hast du eine 1 am Eingang und "vielleicht" eine 1 oder 0 am Schieberegister.
Das ging aber schnell. N. A. schrieb: > Gibt es einen SAchaltplan? könnte einen zusammen schrauben, aber im endeffekt genau so wie im http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister nur halt mir 32 HCT's Karl Heinz schrieb: > Ist vielleicht ein bischen groß. Schon mal 100n probiert? nun von denen hatte ich aber ne ganze Schüppe. Aber eine größere Kapazität heißt doch nicht das die "langsamer" werden oder ? MC0603X105M6R3CT, CAP, MLCC, X5R, 1UF, 6.3V, 0603 Benutze ne Software ansteuerung, die ja auch "meistens" zu funktionieren zu scheint. Joe F. schrieb: > Könnte es sein, dass du PL für eine kaum messbare Zeit auf low und Ansteuerung ist so: CLK und PL auf high ziehen, "obwohl sie es schon vorher waren" PL low..... ACH HER GOTT.... das hbe ich mir extra ne Pre-Compiler anweisung geschrieben um eine Delay bei PL einzubauen und schön artig 5µS Pause eingesetzt, das ding aber nicht schwarf gemacht. jetzt klappt es... So ein Mist oder Gut wie mann es nimmt ;) DANKE JUNGS !
Axel schrieb: > nun von denen hatte ich aber ne ganze Schüppe. Aber eine größere > Kapazität heißt doch nicht das die "langsamer" werden oder ? Doch. Ein größerer Kondensator kann zwar größere Spikes ausgleichen, braucht aber auch länger um zu reagieren. D.h. bis der Kondensator seine Ladung in den Spike 'nachschiebt', kann es schon zu spät sein. > jetzt klappt es... So ein Mist oder Gut wie mann es nimmt ;) Hauptsache du hast das Problem gefunden.
Axel schrieb: > hbe ich mir extra ne Pre-Compiler anweisung geschrieben um eine > Delay bei PL einzubauen und schön artig 5µS Pause eingesetzt, das ding > aber nicht schwarf gemacht. So ganz verstehe ich nicht, wie das das Problem gelöst haben soll, aber okay. Ich vermutete ja eher, dass PL hin und wieder zwischendrin und unbeabsichtigt auf low geht, und du scheinst aber eher die (beabsichtigte) low-phase verlängert zu haben. Eine zu kurze low-phase von PL erklärt aber nicht dein ursprüngliches Problem, denn dann wären eher nur Nullen in der Kette, da die Schieberegister nicht geladen wurden. Anyway.
Joe F. schrieb: > So ganz verstehe ich nicht, wie das das Problem gelöst haben soll, aber > okay. nun ich wollte gerade im Code nachgucken wie lang ich PL auf LOW ziehe und da viel mir eben auf das ich zwar 5µS vorgegeben habe, diese aber nicht "scharf" gestellt habe. also Header: #define PL_Pause 5 'ms #define Mit_PL_Pause 0 in der C-file (vereinfacht ohne richtigen Syntax): PL - Low #if (Mit_PL_Pause) # _delay_ms(PL_Pause) #endif PL - High Der Gedanke dabei war: HCT165 schafft 30MhZ und der AVR fährt mit 20MHz -> wird schon passen. Wenn nicht mache ich eben den Delay rein, was ich dann aber erfolgreich verbaselt habe. Aber um mir sicherzu sein hänge ich nacher mal ein Oszi in die Leitung und gucke mir das Signal an. Karl Heinz schrieb: > Ein größerer Kondensator kann zwar größere Spikes ausgleichen, braucht > aber auch länger um zu reagieren Das hätte ich gedacht wird durch die Technologie bestimmt also Elko, tantal o.ä. Aber gut, man lernt nie aus. ( Ja.... viel hilft nicht immer viel Verstanden :D ) Gruß Axel
>Karl Heinz schrieb: >> Ein größerer Kondensator kann zwar größere Spikes ausgleichen, braucht >> aber auch länger um zu reagieren >Das hätte ich gedacht wird durch die Technologie bestimmt also Elko, >tantal o.ä. Gibt es da etwas zum Nachlesen?
Hallo. Haben HCT595 im ähnlichen Einsatz wie Du. Nur als Ausgang. Aber das serielle Geschiebe ist ja ähnlich. Hatten auch regelmäßig Probleme mit verdoppelten oder aber verschluckten Bits. Haben zwei Verbesserungen integriert: 1. PullUps am letzten HCT595. 2. Haben die Clk und Daten Leitungen per Buffer nach einigen Stufen wieder verstärkt, da die Flanken teilweise schon ziemlich langsam wurden. Danach war Ruhe.
Pepe schrieb: > 1. PullUps am letzten HCT595. > 2. Haben die Clk und Daten Leitungen per Buffer nach einigen Stufen > wieder verstärkt, da die Flanken teilweise schon ziemlich langsam > wurden. klingt interessant. Pull-(DOWN) habe ich schon, aber mit 15k evtl ein bissel groß. Wo wir schon beim Füllen meiner Wissenslücken sind. Lege ich den wie folgt aus? 32*(1µA) input leakage Current + I_pull down <=20mA Signal verstärken sollte auch gehen, da nach jedem 2'ten HCT165 ein Stück Flachbandkabel kommt wo ich den Verstärker einschleusen könnte. Denkst du da an sowas wie den HC4050 ? Gruß Axel
Axel schrieb: > Wo wir schon beim Füllen meiner Wissenslücken sind. Lege ich den wie > folgt aus? > 32*(1µA) input leakage Current + I_pull down <=20mA Die 32uA leakage kannst du ja im Vergleich zu den 20mA gleich mal ignorieren ;-) 20mA sind allerdings recht viel, auch im Hinblick von Übersprechen und EMI ungünstig. Ich würde da mal hemdsärmlig 2.2K - 4.7K versuchen.
Joe F. schrieb: > Ich würde da mal hemdsärmlig 2.2K - 4.7K versuchen. Ich würde mal hemdsärmlig mir überlegen ob ich nicht mit verteilten kapazitiven Lasten und grossen Leitungslängen ein massives Problem auf den Clock- und PL-Leitungen habe. Bei solchen Aufbauten kommt man nicht drum herum sich die Qualität der Signale explizit mit dem Oszilloskop anzuschauen, und zwar am Sender und an den Empfängern. Scheinbar hat hier noch keiner einen einzigen kurzen Gedanken darauf verschwendet wie das Ganze wirklich physikalisch aufgebaut ist. Aufgrund der hohen Anzahl an (Signal-) Emfängern muss es da eigentlich unausweichlich zu Problemen kommen.
Also wir haben 4k7 als PullUps drin. Wir haben PullUps genommen, da wir die einfach als Widerstandsarray auf den letzten Stecker löten konnten. PullDown sollte aber auch gehen. Bezüglich Buffer haben wir einfach 74xx14 verwendet (Natürlich 2 hintereinander sonsts ist je das Signal invertiert). Auf einer anderen Schaltung haben wir 74xx1G17 verwendet. isidor schrieb: > Ich würde mal hemdsärmlig mir überlegen ob ich nicht mit > verteilten kapazitiven Lasten und grossen Leitungslängen > ein massives Problem auf den Clock- und PL-Leitungen habe Genau das dürfte das Problem sein.
Noch was vergessen: Wenn Du ein Oszi hast, schau Dir mal die CLK Leitung an. Bei uns waren die Flanken durch die große Leitungslänge so schlecht, dass wir nur noch Zipfelmützen hatten. Das Timing stimmt dann natürlich gar nicht mehr ;-)
Die Clockbuffer sollte man allerdings eher parallel betreiben, als sie zwischen den Registern in Serie zu legen, sonst zerreist man bei hohen Geschwindigkeiten auch das Timing zwischen Clock und Daten. Ich glaube aber nicht, dass das das Problem von TO ist, denn sonst würde er Bitshifts in den Daten sehen, was ja offenbar nicht der Fall ist.
Axel schrieb: > Die Schaltung ist als U aufgebaut. Das heißt die Steuerleitung CLK, PL > bekommen zuerst das IC 1 und 32, gefolgt von 2 und 31, gefolgt von 3 und > 30 usw. Der Einwand von Joe F. ist gut. Du müsstest wirklich Bitshifts bekommen. Mir ist gerade noch was in deiner Frage aufgefallen: Wieso bekommen die ICs unterschiedliche CLKs und PLs? Zuerst die äußeren 2, dann die nächsten 2 , etc. Wenigstens lese ich das das so. Sollten CLK und PL nicht an alle ICs parallel gehen ?
Pepe schrieb: > Mir ist gerade noch was in deiner Frage aufgefallen: Wieso bekommen die > ICs unterschiedliche CLKs und PLs? Zuerst die äußeren 2, dann die Ich habe ihn so verstanden: der µC "sitzt" in der Mitte und "sieht" nach rechts und links jeweils 16 Schieberegister.
Route_66 schrieb: > Ich habe ihn so verstanden: Schaltpläne in Prosa sind einfach viel besser als immer diese blöden Bildchen da ..... Da weiss man was man hat!
>rechts und links jeweils 16 Schieberegister Und ich dachte, jeweils 128. >Schaltpläne in Prosa Paul Baumann kann's ja mal in Gedichtform bringen.
S. Landolt schrieb: >>Schaltpläne in Prosa > Paul Baumann kann's ja mal in Gedichtform bringen. Der Mikro in der Mitte sitzt, Mit Schieber rechts und links. Da braucht man für PL und CLK, schon erst mal 3, 4 Pins. Pull-Ups und Downs sind auch schon da, mit 4-punkt-7 k; Die Kapas sind ganz schön zerstreut, nach Motto "Schau'n mer ma'" ;-) [EDIT: Sorry, bin nicht Paul Baumann :-P]
:
Bearbeitet durch User
@ Eric B. Respekt ! ======= Das beschreibt die Fehlerursache doch schon deutlich besser. Gruss
Ihr bekommt als wenn ich zuhause bin. Aber danke schon mal für die ganzen hilfreichen Antworten! Gruß Axel
@Eric B. Darf ich dich beim nächsten Fehler, den ich nicht finde, aufs nächste Gedicht einladen. Da macht die ganze Sache doch schon wesentlich mehr Spaß. Kann mich nur anschließen: Respekt.
Eric B. schrieb: > [EDIT: Sorry, bin nicht Paul Baumann :-P] Aber ich! ;-) Nachdem ich Deinen Text gelesen dacht' ich, das wär' ich gewesen. Besser hätt' ich's nicht geschafft, als Dichter stehst Du gut im Saft. Wenn er dadurch den Fehler findet der ihm Zeit und Kräfte bindet, war das eine gute Tat mit Lötzinn und mit Kupferdraht! In diesem Sinne Paul
Danke an Eric B. und Paul Baumann! (Zwei Glanzlichter an einem sonst ziemlich lausigen Tag)
Angehängte Dateien:
-
32_HCT_Schem.PNG
6,5 KB -
20150206_193522.JPG
110 KB -
PL_Anfang__Ende.JPG
50 KB -
CLK_-_Anfang.JPG
86 KB
So Jetzt noch mal die Versprochenen Bilder, Also ichkann nicht sehen, dass das ihrgentetwas verschliffen wird und ich habe überhaupt keinen Pull-up in diesem zustand eingebaut ?! Das Verwundert mich jetzt allerdings auch wieder... Allerdings habe ich testweise mal einen frischen Controller genommen. Denke die Biler sprechen für sich. Als Triggersignal habe ich immer die steigende Flanke von PL direckt am µC benutzt (unterer Kanal) Gruß Axel
Der Schaltplan entspricht wohl nicht 100% der Realität, oder? Die unverbundenen Eingänge müssen (in deinem Fall) mit VCC verbunden werden. Ausserdem muss Pin 15 immer auf GND.
>- SERIAL DATA IN der "letzten Stufe" ist über 10k an GND Lege ihn doch direkt auf Masse. >- D7-D3 Erhalten ein Sensorsignal und liegten (für dieses Problem) immer >auf einem HIGH-Pegel (+5V) >- D2-D0 permanent auf GND gelegt/lötet Prüfe mit einem Durchgangsprüfer, ob das wirklich so ist
Ich weiß zwar nicht was du für einen Takt hast. Aber die Flanken sehen gut aus. Vergiss die Zipfelmützen ;-) Generell ist es immer gut alle Eingänge auf einen definierten Pegel zu legen. Bei fliegender Verdrahtung mag das vielleicht nervig sein, aber floatende Eingänge bringen so ihre Probleme mit sich. Aber ich glaube trotzdem nicht, dass ein floatender ClockEnable das Problem ist. Dann müsstest Du ja BitShifts haben. Bist Du Dir sicher, dass der Rest funktioniert? Normalerweise würde ich einen BitShift erwarten, aber bei Dir ist das Bitmuster in sich immer korrekt. Nur es fehlt manchmal ein komplettes Byte. Das genau 8x ein Fehler auftritt ist unwahrscheinlich. Stimmt die Firmware? Wird der SPI sauber bis 32 gezählt? Sind noch die Werte vom letzten Mal irgendwo in der Pipeline ?
Um etwas mehr Infos zu erhalten, könntest Du auf deine Eingänge ein unterschiedliches Bitmuster drauflegen. Aber eins was du eindeutig in deiner Wertetabellen wieder findest. Musst ja nicht gleich die Nummer der Bausteine binär abbilden. Aber vielleicht mal in jedem 1/4 der Bausteine ein eindeutiges Bitmuster ( einen Pin auf Low anstatt High ) Dann kannst du wenigstens schon mal Zählen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.