Hallo, ich hab hier eine Schaltung mit einem µC, bei der ich dabei bin die nachzuvollziehen. Dabei ist mir die Tasterschaltung aufgefallen: Pin vom µC auf Schalter -> Schalter direkt auf Masse. Keine Widerstände oder Kondensatoren irgendwie integriert. Kann das sein oder hab ich mich vertan? und wie müsste man die Pins vom µC initialisieren, damit das funktioniert? Danke
Jupp. Interne Pullups, Entprellung in Software. Mit PIC24 geht das hervorragend. Ich mach noch immer 100n parallel dazu und schau nur auf die positive Flanke, dann ist das auch noch in Hardware entprellt.
Die meisten MCs haben intern zuschaltbare Pullups. Ein offener Eingang mit Pullup enabled liest dann High. Kondensatoren braucht man keine, da das Entprellen mit einem Timerinterrupt zuverlässiger und bequemer ist.
asu schrieb: > Kann das sein Ja, allerdings darf das Zuleitungskabel nicht zu lang sein, bei ca. 90k pull up wären schon 50cm Zuleitung ein Störrisiko.
asu schrieb: > Kann das sein > oder hab ich mich vertan? Ja, interner Pullup und Software Entperellung
kann schon gehen, ich aber nicht schön. viele µCs haben internen einen zuschaltbaren pull-up oder pull.down. ich benütze dennoch immer noch einen zusätzlichen externen irgendwas um die 10K. ausserdem sollte man noch ein kleines C zum Schalter legen, sonst prellt er, aber auch das kann man im µC softwaremäßig abfangen.
die Platine ist von einem 10€ Heizungsthermostatregler. Ich denke da soll gespart werden wo's nur irgendwie geht... Danke für die Infos :)
asu schrieb: > Keine Widerstände oder Kondensatoren irgendwie integriert. Kann das sein > oder hab ich mich vertan? und wie müsste man die Pins vom µC > initialisieren, damit das funktioniert? > Danke Ja, wenn der µC einen internen Pullup hat, ist das die Standardschaltung.
Max H. schrieb: > Gero schrieb: >> ich aber nicht schön. > Wieso nicht? Weil manche Leute ohne weitere Cs und Rs in einer Schaltung Schweißausbrüche kriegen und zwanghaft irgendwelche Bauteile dran basteln müssen. Das sind auch die typen die heute im Jahr 2015 noch jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein C und natürlich einen externen PullUp braucht. DAS WAR SCHON IMMER SO, wobei immer ihre veraltet schrottige Technik von vor 30 Jahren war.
asu schrieb: > Ich denke da > soll gespart werden wo's nur irgendwie geht... Es ist sinnvoll, sobald man einen MC verwendet, möglichst viele Funktionen von der Hardware in die Software zu verlagern. Weil Software schreibt man nur einmal, aber Hardware muß in jedes einzelne Gerät mit eingelötet werden. Nebenbei steigt damit auch die Zuverlässigkeit, da weniger Lötstellen. Lötstellen sind eine der Hauptausfallursachen in Geräten.
Cyblord ---- schrieb: > Weil manche Leute ohne weitere Cs und Rs in einer Schaltung > Schweißausbrüche kriegen und zwanghaft irgendwelche Bauteile dran > basteln müssen. Das sind auch die typen die heute im Jahr 2015 noch > jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein > C und natürlich einen externen PullUp braucht. DAS WAR SCHON IMMER SO, > wobei immer ihre veraltet schrottige Technik von vor 30 Jahren war. Nein. Privat mag das angehen, nicht aber bei einem Serienprodukt. Selbst da ist es fragwürdig: bei jeder Berührung des Schalters bekommt der µC ungeschützt ordentlich eine geballert. Für Serienprodukte muss man ESD-Tests machen. der µC bekommt die Kriese, wenn du auf einen solchen Schalter ohne weitere Bauteile draufknallst. Musst du aber tun, und dann darf da nichts ausfallen. Die ESD-Schutzbeschaltung im µC braucht oft einen Serienwiderstand, damit nicht ausfällt. Mit externen Cs ist außerdem der Softwareoverhead extrem gering. Du hängst einen Interrupt auf die steigende Flanke, fertig. Mit 100n prellt das nicht, das ist schnell, einfach und zuverlässig, bei wenigen Zeilen Code. Daher hat das mit Angstbauteilen nichts zu tun.
WehOhWeh schrieb: > Selbst da > ist es fragwürdig: bei jeder Berührung des Schalters bekommt der µC > ungeschützt ordentlich eine geballert. Blödsinn, da stehen am Taster keine Drahtenden raus die der Finger überbrückt, sondern es gibt einen schönen Plastikknopf und man kommt den Leitungen nicht näher als dem Rest der Schaltung.
MaWin schrieb: > Blödsinn, da stehen am Taster keine Drahtenden raus die der Finger > überbrückt, sondern es gibt einen schönen Plastikknopf und man kommt den > Leitungen nicht näher als dem Rest der Schaltung. Fahr mal zum TÜV :-) 8kV AD -> Peng. Bei mir haben sie mal mit 16,5kV in die Lüftungsschlitze reingeblitzt für Safety. Da war dann eine "Fangleitung" am Rand der Platine fällig, weil eine solche Entladung hat der µC nicht überlebt :-) Dazu: kapazitive Kopplung. Auf einem nacktem Pin hat der "Status" der Leitung ein "Gewicht" von nur 5-10pF - das wackelt schnell mal herum, wenn ein Finger mit ein paar 100V in der Nähe vorbeifährt.
Nur hat EMV/ESD mit dieser Thematik gar nichts zu tun. Natürlich muss man dafür noch Vorkehrungen treffen. Es geht aber um die funktionale Beschaltung.
MaWin schrieb: > Blödsinn, da stehen am Taster keine Drahtenden raus die der Finger > überbrückt, sondern es gibt einen schönen Plastikknopf und man kommt den > Leitungen nicht näher als dem Rest der Schaltung. Es reicht eine simple Burst-Messung, um den uC zuverlässig immer wieder in den Reset zu versetzen. Für mich gilt automatisch, wenn im Datenblatt steht "internal pullup, this pin may be left open when not needed", dass dann ein Kondensator und/oder ein niederohmiger externen Pullup (max 4k7) da dran kommt. Aber für einen simplen Tastereingang, der sowieso noch von der Software durchgewaschen wird, reicht so ein interner Pullup allemal...
:
Bearbeitet durch Moderator
Cyblord ---- schrieb: > Nur hat EMV/ESD mit dieser Thematik gar nichts zu tun. Natürlich muss > man dafür noch Vorkehrungen treffen. Es geht aber um die funktionale > Beschaltung. Naja, eine funktionale Beschaltung ist in meinen Augen erst dann funkional und gegeben, wenn die Schaltung auch wirklich EMV/ESD Sicher ist. Ich mache selbst auch EMV-Tests und du würdest Dich wundern was so mancher Entwicklungsingenieur unter CE-Konform versteht! Auf dem Arbeitsplatz in einem Entwicklungslabor funktioniert fast jede Schaltung - gespeist vom wahnsinnig tollen und extrem teuren Labornetzteil, welches die Ausgangsspannung auf 3 Komastellen genau regelt. Sobald die Schzaltung dann aber im KFZ-Boardnetz eines Nutzfahrzeuges hängt, entstehen die wildesten Quereffekte! Wenn so ein dicker Diesel mal ein paar Laständerungen erfährt kann man schön beobachten wer sich bei der Entwicklung Mühe gegeben hat....
Cyblord ---- schrieb: > Das sind auch die typen die heute im Jahr 2015 noch > jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein > C "Hilfe, programmieren per ISP geht nur jedes zweiundvierzigstes mal"
Marian B. schrieb: > Cyblord ---- schrieb: >> Das sind auch die typen die heute im Jahr 2015 noch >> jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein >> C > > "Hilfe, programmieren per ISP geht nur jedes zweiundvierzigstes mal" Was noch NIEMALS am fehlenden Pullup oder fehlendem C gelegen hat.
Cyblord ---- schrieb: > Marian B. schrieb: >> Cyblord ---- schrieb: >>> Das sind auch die typen die heute im Jahr 2015 noch >>> jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein >>> C >> >> "Hilfe, programmieren per ISP geht nur jedes zweiundvierzigstes mal" > > Was noch NIEMALS am fehlenden Pullup oder fehlendem C gelegen hat. Stimmt, das passiert auch nur mit C. Wer lesen kann, stellt schnell fest, dass Atmel seit Jahren sagt: Kein C an /RESET, bittedanke.
:
Bearbeitet durch User
Marian B. schrieb: > Cyblord ---- schrieb: >> Marian B. schrieb: >>> Cyblord ---- schrieb: >>>> Das sind auch die typen die heute im Jahr 2015 noch >>>> jedem Anfänger erzählen, dass man an den Reset eines AVRs unbedingt ein >>>> C >>> >>> "Hilfe, programmieren per ISP geht nur jedes zweiundvierzigstes mal" >> >> Was noch NIEMALS am fehlenden Pullup oder fehlendem C gelegen hat. > > Stimmt, das passiert auch nur mit C. Durchaus möglich. Aber das würde ich nun auch nicht unbedingt behaupten. Aber Atmel hat eine schöne AppNote zu dem Thema. Da drin steht sinngemäß dass eine Aussenbeschaltung von Reset in sehr störungsbelasteten Umgebungen sinnvoll sein kann. Es geht da sehr eindeutig hervor, dass es unter normalen Bedingungen absolut nicht notwendig ist.
Marian B. schrieb: > "Hilfe, programmieren per ISP geht nur jedes zweiundvierzigstes mal" Bei mir Zuhause habe ich einen solche Fall. Taster, am PIC, mit internem Pullup - wie es der TP beschrieben hatte. Nur mit noch 0,5m Kabel dran (ja schon klar, das ist Mist). Das ist ein Testaufbau mit dem Breadboard, da will man ja nicht soviele Bauteile draufstecken. Der Taster ist blos ein one-shot-Interrupt, da ist prellen ja egal. Anfänglich ging das super ohne jedes Bauteil. Bis ich vor zwei Wochen einen neue Sessel gekauft habe (Meyer spirit). Seit dem ist das Ding habe: Mit der Hand das Kabel zwischen µC und Taster berührt -> µC macht Reset Taster angefasst -> PICkit3 -> disconnect vom PC Also aus der Luft gegriffen sind solche Sachen - auch für Bastler - nicht. Der Sessel ist allerdings auch wirklich kein gutes Beispiel. Ich bekomme jedesmal eine gewischt, wenn ich ein geerdetes Metallteil anfasse. Das kann man sogar bei den amzon-Bewertungen nachlesen ;-) Werd mir jetzt mal ein ESD-Armband kaufen, weil der Sessel ist wirklich toll.
Cyblord ---- schrieb: > Aber Atmel hat eine schöne AppNote zu dem Thema. Da drin steht sinngemäß > dass eine Aussenbeschaltung von Reset in sehr störungsbelasteten > Umgebungen sinnvoll sein kann. 100 nF am /Reset sollte jeder ISP-Prommer verkraften. 3k3 Pullup sind bei mir immer vorhanden. Auch einen Ein-Aus-Taster an einem Interrupt-Pin anzuschließen, ist eine zuverlässige Methode der Entprellung, auch wenn die meisten Leute mit dieser genialen Schaltung überfordert sind: 10 kOhm liegen in Reihe zum Taster und 100 nF direkt am Eingangspin. Auch bei Gewitter läuft Alles bestens ;-)
m.n. schrieb: > auch wenn die meisten Leute mit > dieser genialen Schaltung überfordert sind: 10 kOhm liegen in Reihe zum > Taster und 100 nF direkt am Eingangspin. Überfordert nicht, aber es dauert mir einfach viel zu lange, im Schaltplan 2 Bauteile hinzuzufügen, im PCB diese zu plazieren und zu routen, sie zu kaufen und einzulöten und das auch noch je Taster, also 16 unnötige Bauteile für 8 Taster. In der Zeit hab ich längst die Entprell-Lib per Drag&Drop dem Build hinzugefügt und damit 8 Tasten auf einen Schlag abgehandelt, Zusatzfunktionen (lang/kurz/repeat/doppeldruck usw.) inklusive. Du kannst Leuten keinen Vorwurf daraus machen, daß sie mit ihrer Arbeitszeit ökonomisch umgehen.
Peter Dannegger schrieb: > Du kannst Leuten keinen Vorwurf daraus machen, daß sie mit ihrer > Arbeitszeit ökonomisch umgehen. Selber Schuld, wenn Du aus einem Taster nun acht machst. Bedarfsgerecht geht anders.
WehOhWeh schrieb: > Der Sessel ist allerdings auch wirklich kein gutes Beispiel. Ich bekomme > jedesmal eine gewischt, wenn ich ein geerdetes Metallteil anfasse. Das > kann man sogar bei den amzon-Bewertungen nachlesen ;-) > > Werd mir jetzt mal ein ESD-Armband kaufen, weil der Sessel ist wirklich > toll. M.W. gibt es da Abhilfe aus speziellen Spühdosen.
Harald Wilhelms schrieb: > M.W. gibt es da Abhilfe aus speziellen Spühdosen. Ja, Chromspray. Das läßt Dich glänzend dastehen! ;-) MfG Paul http://www.baumarkthandel.de/images/produkte/i71/7144-Chromlack-400ml-chrom-silber-Schuller-Lackspray-Eff.jpg
Paul Baumann schrieb: > Harald Wilhelms schrieb: >> M.W. gibt es da Abhilfe aus speziellen Spühdosen. > > Ja, Chromspray. Das läßt Dich glänzend dastehen! > ;-) > MfG Paul > http://www.baumarkthandel.de/images/produkte/i71/7144-Chromlack-400ml-chrom-silber-Schuller-Lackspray-Eff.jpg Ich hatte eigentlich eher an so etwas gedacht: http://www.amazon.de/s/?ie=UTF8&keywords=antistatikspray+für+textilien
m.n. schrieb: > Selber Schuld, wenn Du aus einem Taster nun acht machst. > Bedarfsgerecht geht anders. Doch meine Routine ist bedarfsgerecht. Die benötigten Ressourcen sind minimal. Daher lohnt es sich nicht, eine extra Routine für nur eine Taste zu schreiben. Sie entprellt immer einen ganzen Port, also je nach Architektur 8, 16 oder 32 Pins parallel (Vertical Counter Prinzip). Beim Programmieren versucht man, Routinen möglichst flexibel zu gestalten, um nicht für jede kleine Änderung nochmal neu programmieren zu müssen.
> Beim Programmieren versucht man, Routinen möglichst flexibel zu > gestalten, um nicht für jede kleine Änderung nochmal neu programmieren > zu müssen. Da gibt es aber durchaus auch andere Lehrmeinungen. Nämlich das genaue Gegenteil. Entwickeln einer Routine genau auf den Punkt, keine unnötige Flexibilität/Funktionalität auf Vorrat, etc. Und genau dann umschreiben, wenn es benötigt wird. Siehe "agile development" oder "extreme programming".
Gerhard schrieb: > Siehe "agile development" oder "extreme programming". Das hört sich für mich wie "Hinbasteln" und "Consulting" an. Unsere Intelligenztest-Abteilung (IT) kennt diese Entwicklungsstrategien offenbar auch...
Ja, die Begriffe hören sich wirklich dämlich an. Die Prinzipien dahinter
sind aber durchaus solide, da direkt aus dem üblichen Scheitern von
Software-Großprojekten abgeleitet.
Ich entwickele sicherheitsrelevante Software für die Luftfahrt. Da ist
der Flexibilitätsansatz ("von Anfang an für alle Eventualitäten in der
Zukunft entwickeln") aus einleuchtenden Gründen ebenfalls verpöhnt.
Agil bedeutet eigentlich "flexibel auf geänderte Situation reagieren". Das ist das genau Gegenteil von "exakt auf den Punkt programmiert". Ich habe allerdings im Job oft den Verdacht, daß die Hype-Word Blubberer die essentiellen Dinge einer Methodig gar nicht erfassen.
Ich hatte zuerst auch Entprellroutinen für 1 bzw. 2 Tasten. Da sie aber keinerlei Vorteile hatten, habe ich sie wieder gelöscht. Mit "von Anfang an für alle Eventualitäten in der Zukunft entwickeln" hat das überhaupt nichts zu tun. Es geht einfach nur um die Nachnutzung in weiteren Projekten. Wenn man einmal entwickelte Routinen nachnutzen kann, erhöht das auch die Zuverlässigkeit.
Harald Wilhelms schrieb: > Paul Baumann schrieb: >> Harald Wilhelms schrieb: >>> M.W. gibt es da Abhilfe aus speziellen Spühdosen. >> >> Ja, Chromspray. Das läßt Dich glänzend dastehen! >> ;-) >> MfG Paul >> > http://www.baumarkthandel.de/images/produkte/i71/7144-Chromlack-400ml-chrom-silber-Schuller-Lackspray-Eff.jpg > > Ich hatte eigentlich eher an so etwas gedacht: > http://www.amazon.de/s/?ie=UTF8&keywords=antistatikspray+für+textilien Danke, das kannte ich noch gar nicht. Was es nicht alles gibt :-) Die paar € werde ich mal investieren. Dann muss ich nicht mit einer Hand an die Heizung fassen, wenn ich am Steckbrett herumfummle.
> Agil bedeutet eigentlich "flexibel auf geänderte Situation reagieren". > Das ist das genau Gegenteil von "exakt auf den Punkt programmiert". Agil als Wort bedeutet erstmal nur "beweglich". "Agile Programming" dagegen ist eine in zahlreichen Werken exakt definierte Methodik mit genau umrissenen Bestandteilen. Ich habe im Moment nicht den Eindruck, dass du dich damit schonmal beschäftigt hättest. Das wäre aber gut, bevor man (falsche) Behauptungen aufstellt. Die Bedeutung eines aus dem lateinischen entlehnten Wortes zu kennen bedeutet nicht automatisch sich mit allem auszukennen, was mit diesem Wort passend (oder weniger passend) bezeichnet wird. In der agilen Programmierung wird genau auf die Anforderung hin programmiert, ohne für zukünftige Erweiterungen auf Vorrat zu coden oder eine Funktion universaler zu machen, als sie aktuell sein muss. Die Anforderungen dagegen können sich im Laufe des Projektes ständig ändern ("agile"), so dass Programmbestandteile immer wieder mal umgeschrieben werden müssen ("refactoring"). Im "test driven development" wird erst der unit test geschrieben, der genau die (aktuellen) Anforderungen darstellt. Die eigentliche Funktion wird dann nach und nach so geschrieben, dass sie genau die Anforderungen erfüllt und nicht mehr. Das meine ich mit "auf den Punkt programmiert". Praxisbeispiel: Ein High-Side-Switch mit Fehlerrückmeldung soll angesteuert werden und die Fehlerbedingungen ausgewertet werden (evtl. nach kleiner Zeitverzögerung). Das würde ich zunächst mal hardcodiert für genau die vorgesehene MCU und die verwendeten GPIOs implementieren. Natürlich wäre die Versuchung groß, eine universelle Routine zu implementieren, die ich in eine Lib packe für spätere Verwendung ("sowas kann man doch immer mal gebrauchen"). Das ist aber bei der agilen Programmierung gerade verboten, weil es von der eigentlichen Aufgabe ablenkt und jeder zusätzliche Funktionsparameter und Variable wieder neue Fehlerquellen einführt. Erst in dem Moment, wo ich im gleichen Projekt für einen zweiten Pin genau die gleiche oder eine sehr ähnliche Funktionalität brauche, macht man sich Gedanken über die Wiederverwendung. Man denkt auch sehr genau drüber nach, ob man die vorhandene Funktion universeller gestaltet und von zwei verschiedenen Stellen aus aufruft, oder ob man eine neue Funktion schreibt. > Ich > habe allerdings im Job oft den Verdacht, daß die Hype-Word Blubberer die > essentiellen Dinge einer Methodig gar nicht erfassen. q.e.d. Lies mal den Wikipedia-Artikel http://de.wikipedia.org/wiki/Agile_Softwareentwicklung Nur weil etwas nach Hype Word klingt, ist es nicht automatisch schlecht. Nicht jeder, der einen nun mal verbreiteten dämlichen Begriff für etwas verwendet, ist ein Blubberer.
Irgendwo stand was von 100n parallel zum Taster - das ist ein sehr zuverlässiger Weg, heute übliche Taster nach nur wenigen Hundert Betätigungen zu killen. Wer meint, den Kondensator zu brauchen, sollte auch nicht zu geizig sein, auch noch einen zusätzlichen Widerstand zu spendieren, der den Entladestrom begrenzt.
Gerhard schrieb: > Nur weil etwas nach Hype Word klingt, ist es nicht automatisch schlecht. Manchmal richtig, leider nur manchmal. > Nicht jeder, der einen nun mal verbreiteten dämlichen Begriff für etwas > verwendet, ist ein Blubberer. Er klingt aber immer noch so. ;-) H.Joachim Seifert schrieb: > Irgendwo stand was von 100n parallel zum Taster - das ist ein sehr > zuverlässiger Weg, heute übliche Taster nach nur wenigen Hundert > Betätigungen zu killen. > Wer meint, den Kondensator zu brauchen, sollte auch nicht zu geizig > sein, auch noch einen zusätzlichen Widerstand zu spendieren, der den > Entladestrom begrenzt. Da allerdings kommt dann oft der Geiz, aehhhhhh.. ich meine die "resourcenschonende Entwicklung" durch und der Widerstand wird weggelassen. wendelsberg
@gerhard: Und worin liegt bitte die Agilität eine Entprellroutine, die von Haus aus 8 Eingänge kann, auf einen einzuschrumpfen, weil man gerade nicht mehr braucht. Und Bein 2. Projekt darf ich's dann universeller machen, weil ich dann gemerkt hab, das ich's nochmal brauch. Diese Logik funktioniert leider nur bei Grünschnäbeln, denn mein 2. Projekt war im letzten Jahrtausend. Komisch nur das so gesteuerte Projekte gern mal an an Problemen sterben, die die alten Deppen schon anfangs kannten, aber aufgrund von "vergeßt mal alles was ihr über 'so macht man das am Besten' wisst" gar nicht wichtig waren. Manchmal muß man nämlich nicht bei Null anfangen. Z.B. Wenn man Fehler kein 2.Mal machen möchte. Der Wiki-Artikel enthalt im übrigen für mich nur minimale Spuren dessen, was du da herausgelesen haben willst. Die Hauptrichtung ist meine!
Hallo Peter, Peter Dannegger schrieb: > Ich hatte zuerst auch Entprellroutinen für 1 bzw. 2 Tasten. Da sie aber > keinerlei Vorteile hatten, habe ich sie wieder gelöscht. > > Mit "von Anfang an für alle Eventualitäten in der Zukunft entwickeln" > hat das überhaupt nichts zu tun. > > Es geht einfach nur um die Nachnutzung in weiteren Projekten. Wenn man > einmal entwickelte Routinen nachnutzen kann, erhöht das auch die > Zuverlässigkeit. Kurz gesagt: dabei geht es um Skalierbarkeit, nicht um Funktionalität. Der Gerhard sollte mal Deinen Code lesen! Liebe Grüße, Karl
Gerhard schrieb: > Praxisbeispiel: Ein High-Side-Switch mit Fehlerrückmeldung soll > angesteuert werden und die Fehlerbedingungen ausgewertet werden (evtl. > nach kleiner Zeitverzögerung). Das würde ich zunächst mal hardcodiert > für genau die vorgesehene MCU und die verwendeten GPIOs implementieren. Und ich würde es genauso machen und das dann als Funktionsmodell bezeichnen. Nur würde ich schon dieses Funktionsmodell /sicherlich/(!) anders programmieren, als einer, der gerade sein EVA Prinzip an der Schule gelernt hat. Mein Programm wäre von vorn herein so ausgelegt, dass es möglichst wenig Ressourcen (Zeit und Interrupts) braucht, und dass es weiterverwendbar ist. > Natürlich wäre die Versuchung groß, eine universelle Routine zu > implementieren, die ich in eine Lib packe für spätere Verwendung ("sowas > kann man doch immer mal gebrauchen"). Das ist aber bei der agilen > Programmierung gerade verboten, weil es von der eigentlichen Aufgabe > ablenkt und jeder zusätzliche Funktionsparameter und Variable wieder > neue Fehlerquellen einführt. Diesen Schritt mache ich aucht. Ich stelle etwas für einen bestimmten Prozessor fertig, weiß aber da schon ganz genau, dass ich diesen Code auf einem anderen weiter verwenden könnte. > Erst in dem Moment, wo ich im gleichen Projekt für einen zweiten Pin > genau die gleiche oder eine sehr ähnliche Funktionalität brauche, macht > man sich Gedanken über die Wiederverwendung. Und genau hier unterscheidet sich der Anfänger vom Profi. Deshalb wird bei dieser agilen Programmierung bei Anfängern nur Schrott rauskommen, weil alles nur so hingebastelt und nicht von vorn herein mitgedacht wird. Horden von _delax_ms() und while(busy); zeugen davon. Und ich traue mich auch, ein Konzept, das zu 90% "fertig" ist, wegzuwerfen, weil der Ansatz schlecht und unbrauchbar war. Ein Anfänger verbeißt sich dann und sagt "Ich bin doch fast fertig!"... Ergo: diese "agile Programmierung" wurde m.E. von einem Profi erfunden, der von sich aus nicht mehr in jeder Sackgasse bis ans Ende läuft. Und sie wird von Anfängern als Schutzbehauptung für vermurkste Konzepte verwendet...
Richtig agil wird's hält, wenn nicht jede kleine Änderung, "wir brauchen noch eine 2.Taste", das ganz Konzept über den Haufen wirft. Zudem wäre, nach Gerhard, und bis zu Ende gedacht, jede Standard-Lib verboten, den sie beinhaltet immer Dinge, die das aktuelle Projekttarget nicht braucht. Ich arbeite im Moment in eine SCRUM-Projekt und kann der Methode einiges abgewinnen. Nur hab ich das mit Kollegen schon vor 22 Jahren so gemacht. Wir wußten nur nicht wie das heißt. Alle diese Methoden sich der Versuch, zu formalisieren wie erfolgreiche Leute Projekt angehen. Das ist im Prinzip gut, aber das Anwenden der Formalismen ist kein Erfolgsgarant. Und es besteht die Gefahr mittel Konzentration auf die Methode die wahren Gründe für's Gelingen zu übersehen. @Lothar: Zum Thema Schutzbehauptung: exakt!
H.Joachim Seifert schrieb: > Irgendwo stand was von 100n parallel zum Taster - das ist ein sehr > zuverlässiger Weg, heute übliche Taster nach nur wenigen Hundert > Betätigungen zu killen. Das sieht die Kontaktschweißerfraktion aber ganz anders. Diese fordert nämlich für jeden Kontakt einen Mindeststrom, der jeden Dreck gleich wegbrennt. Vielleicht sind 100nF sogar noch zu wenig? ;-) Peter Dannegger schrieb: > Es geht einfach nur um die Nachnutzung in weiteren Projekten. Wenn man > einmal entwickelte Routinen nachnutzen kann, erhöht das auch die > Zuverlässigkeit. Wenn es darum geht, nehme ich keine Routine die einen kompletten Port eines µC benötigt, zumal ja nie garantiert ist, daß er frei zur Verfügung steht. Schon beim AVR sind speziell benötigte Pins in diverse Ports 'eingestreut' und nicht anders nutzbar. Beim STM32 ist die Situation noch schlimmer. Eine 'Nachnutzung' bleibt ein Traum. Da sind dann Schieberegister die bessere Wahl. Ob 8 oder 64 Taster, man kann beliebig skalieren und dafür auch einen ATtiny85 verwenden.
> Wenn es darum geht, nehme ich keine Routine die einen kompletten Port
eines µC benötigt
Benötigt? Vielleicht ist "Einsammel von bis zu 8 Portbits" und
"Entprellen von bis zu 8 Bits" nicht das Gleiche. Wenn man die
Bausteine, die man zusammensetzen will, nicht richtig dimensioniert,
dann wird das nichts. Der Eingangswert für PeDa's Entprellung kann
direkt von PINx kommen, muß es aber nicht. Man darf auch einzelne Bits
von PINA..PINH in das eine Byte Eingangswert sammeln, z.B. wenn man die
Hardware nicht Software-optimiert hat. Und wenn man ganz dreist ist: die
Entprellung als C++-Template mit Typen größer 8Bit machen. Oder mehrere
Instanzen für jeweils bis zu 8Bit. Programmieren ist auch ein kreativer
Akt. Nur ist nicht jeder Künstler.
m.n. schrieb: > Wenn es darum geht, nehme ich keine Routine die einen kompletten Port > eines µC benötigt Seit wann blockieren Lesezugriffe einen ganzen Port? Es gibt nur wenige IO-Register, wo ein Lesezugriff Seiteneffekte hat, z.B. eine gepufferte UART. Die Portregister gehören nicht dazu, die kann jeder lesen, wie er lustig ist. Natürlich ist es selten sinnvoll, die Ereignisbits der Entprell-Lib für einen Pin auszuwerten, an dem gar keine Taste hängt und der vielleicht ADC-Input, PWM-Output oder sonstwas ist. Die Ereignisbits werden eben für alle Portpins bereitgestellt, weil das kein Mehraufwand ist, ob nur für einen Pin oder 8 Pins.
m.n. schrieb: > H.Joachim Seifert schrieb: >> Irgendwo stand was von 100n parallel zum Taster - das ist ein sehr >> zuverlässiger Weg, heute übliche Taster nach nur wenigen Hundert >> Betätigungen zu killen. > > Das sieht die Kontaktschweißerfraktion aber ganz anders. Diese fordert > nämlich für jeden Kontakt einen Mindeststrom, der jeden Dreck gleich > wegbrennt. > Vielleicht sind 100nF sogar noch zu wenig? ;-) Naja. Bei 3.3V sind in dem Kondensator stolze 540nJ drin. Wieviel Metall man wohl damit verbrennen kann? Wird der Kontakt sich in hell leuchtendes, 7000Grad heißes Plasma auflösen? Oder wird das Plastikgehäuse durch geschmolzene Metalltropfen durchlöchert? Ich bezweifle, dass das bei so kleinen Spannungen und Energieen den Kontakt wirklich beschädigen können. Bei einem kurzen Versuch heute (ca. 100 Schaltvorgänge) hat der Taster auf meinem Steckbrett alle Schaltvorgänge mit 3,3V / 1µ (Kerko) überlebt. Auf mehr habe ich gerade keine Lust. Genaures dazu wäre es aber schon interessant. Vielleicht kennt wer eine Appnote dazu? Disclaimer : Natürlich ist ein Serienwiderstand zum Taster sinnvoll! Das will damit auch ich gar nicht bestreiten.
Peter Dannegger schrieb: > m.n. schrieb: >> Wenn es darum geht, nehme ich keine Routine die einen kompletten Port >> eines µC benötigt > > Seit wann blockieren Lesezugriffe einen ganzen Port? Seit wann ist ein 'kompletter' Port ein 'blockierter' Port? Wer redet denn hier von Seiteneffekten? Ich dachte, ich hätte mich verständlich ausgedrückt - guten Willen vorausgesetzt. WehOhWeh schrieb: > Natürlich ist ein Serienwiderstand zum Taster sinnvoll! Das > will damit auch ich gar nicht bestreiten. Bau ihn einfach ein und dann ist es gut.
m.n. schrieb: > Peter Dannegger schrieb: >> m.n. schrieb: >>> Wenn es darum geht, nehme ich keine Routine die einen kompletten Port >>> eines µC benötigt >> >> Seit wann blockieren Lesezugriffe einen ganzen Port? > > Seit wann ist ein 'kompletter' Port ein 'blockierter' Port? Was sollte Deine Formulierung denn sonst bedeuten? Daher habe ich richtig gestellt, daß sie nicht "einen kompletten Port benötigt", also die Pins, an denen keine Taster sind. Sie kann aber auch auf Tasten arbeiten, die z.B. über den ADC, I2C oder SPI eingelesen werden.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.