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.
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.
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!
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]
@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
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.
Eine eigene Frage?
Dieser Thread ist über 11 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Unbenannt.PNG
(9,9 KB)
