Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header
des obigen Schnipsels einzubinden.
Daher die neue Frage:
Wieso ist bool test = heater_STATUS();
immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht
finden kann?
Grüße Oekel
D a v i d K. schrieb:> Also an dem PIN hängt ein OptoCoupler, der richtig angesprochen wird.
Damit ist wirklich alles erschöpfend erklärt.
Ich liebe sie, diese Prosa-Schaltpläne.
Lieba Gedichte schrieb:> Ich liebe sie, diese Prosa-Schaltpläne.
nicht nur prosa Schaltpläne. Auch Prosa Fehlermeldungen
D a v i d K. schrieb:> wenn heater_STATUS() extern definiert wurde und er es nicht> finden kann
Und zu PINC gibt es nicht mal Prosa.
Möglicherweise hast du den Optokoppler ohen Vorwiderstand zwischen den
PIN und VCC angeschlossen. Dadurch liegt der PIN immer auf High.
Das PIN Register liest den aktuellen Zustand des PIN ein.
Das PORT Regsietr kannst du benutzen, um abzufragen, welchen Pegel der
Ausgang eigentlich haben sollte.
Zwischen beiden besteht ein Unterschied, wenn der Ausgang
kurzgeschlkossen wird.
D a v i d K. schrieb:> Wieso ist bool test = heater_STATUS();> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht> finden kann?
Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE
intitialisiert wurde.
Ich würde zuallererst mal nachmessen, welcher Pegel bzw. welche
Spannung denn tatsächlich am Pin 7 vom Port C liegt. Dieses
Messergebnis könnte bedeutend für den Programmverlauf sein...
isimmerso schrieb:> D a v i d K. schrieb:>> Wieso ist bool test = heater_STATUS();>> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht>> finden kann?>> Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE> intitialisiert wurde.
Naja, er dürfte es nicht einmal compilieren. Deswegen wundert es mich
gerade das er überhaupt einen Status annehmen kann ;-)
Lothar M. schrieb:> Ich würde zuallererst mal nachmessen, welcher Pegel bzw. welche> Spannung denn tatsächlich am Pin 7 vom Port C liegt. Dieses> Messergebnis könnte bedeutend für den Programmverlauf sein...
Wie ich oben bereits geschrieben habe ist der Code richtig. Und
selbstverständlich habe ich einige Iterationen durch, in denen ich
validiert habe, dass die Ausgänge richtig schalten.
Hinzu kam lediglich die Statusabfrage, die ich an anderer Stelle im
Programcode benötigte.
Rene K. schrieb:> isimmerso schrieb:>> D a v i d K. schrieb:>>> Wieso ist bool test = heater_STATUS();>>> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht>>> finden kann?>>>> Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE>> intitialisiert wurde.>> Naja, er dürfte es nicht einmal compilieren. Deswegen wundert es mich> gerade das er überhaupt einen Status annehmen kann ;-)
Danke euch beiden. Diese Info hatte ich vermutet und gebraucht.
Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE
falsifiziert ist mir immer noch ein Rätsel. Hätte wie ihr auch erwartet,
dass der Compiler zumindest eine Warnung ausgibt. Nichts dergleichen!
D a v i d K. schrieb:> Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE> falsifiziert ist mir immer noch ein Rätsel. Hätte wie ihr auch erwartet,> dass der Compiler zumindest eine Warnung ausgibt. Nichts dergleichen!
Wenn es keine Meldung vom Compiler gibt, woher weißt du dann überhaupt,
dass "er es nicht finden kann"?
Alles irgendwie sehr nebulös.
D a v i d K. schrieb:> der Compiler
Welcher denn?
Und was änderst du jetzt in deinem Programm zwischen "geht" und "geht
nicht"?
> Diese Info hatte ich vermutet und gebraucht.
Dass ein Compiler etwas "ahnt"?
> Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE> falsifiziert ist mir immer noch ein Rätsel.
Du solltest das mal auf einen "Dreizeiler" reduzieren, so dass du ein
einfaches Programm hast, das mal den Fehler aufweist und mal nicht. Dann
kann man das evtl. nachvollziehen. Aber bisher waren die allermeisten
"Compilerfehler", die Anfänger hatten, letztlich Bedienfehler.
Ich hatte bisher erst 2 richtige Fehler im Compiler, einer trat sofort
nach einem Update auf. Der andere hat fast eine Woche Zeit gekostet, um
nachzuweisen, dass es tatsächlich der Compiler war, der einen
unaligned Zugriff falsch abhandelte.
Lothar M. schrieb:> Und was änderst du jetzt in deinem Programm zwischen "geht" und "geht> nicht"?
Das hatte er ja zu Eingangs beschrieben:
D a v i d K. schrieb:> Ich hatte lediglich vergessen den Header> des obigen Schnipsels einzubinden.
Und da er keine Lust hat, das nochmal auszuprobieren oder gar zu
verstehen, ist die angebotene Lösung der vorausahnenden Kompilierung
ausreichend ;-)
Achim S. schrieb:> vorausahnenden Kompilierung
Ein schöner Ausdruck! Muß ich mir unbedingt merken, wenn es mal wieder
um die "Ahnungen" eines Compilers geht.
Das hat schon fast was von "künstlicher Intelligenz" :-)
Stefan E. schrieb:> Wenn es keine Meldung vom Compiler gibt, woher weißt du dann überhaupt,> dass "er es nicht finden kann"?>> Alles irgendwie sehr nebulös.
Na weil mein Programm die Ausgänge regelmäßig ändert , sonst bräuchte
ich ja keinen MC.
Also Header eingebunden und Ablauf/Display beobachtet.
Nee...
So nicht!
Wenn der Kompiler was nicht findet, dann hagelt es Errors.
Spätestens der Linker bricht dir dann ins Essen.
Denn der hat die Pflicht, die extern Deklaration aufzulösen, mit einer
Adresse zu versehen.
D a v i d K. schrieb:> Na weil mein Programm die Ausgänge regelmäßig ändert , sonst bräuchte> ich ja keinen MC.> Also Header eingebunden und Ablauf/Display beobachtet.
Gutes Vorgehen, um "mal eben kurz zu schauen", schlechtes Vorgehen um
damit die Frage in einem Forum wie diesem zu starten.
Als nächstes könntest du mal direkt am PIN des uC messen, welche
Spannungen da anliegen (am besten mit einem Oszi). Sollte da wider
Erwarten eine Spannung kleiner 0.3*Vcc anliegen kannst du beginnen,
Stück für Stück deinen Code abzuspecken bis der Fehler verschwindet.
Sollte der Fehler bis zum Schluss, wenn der Code also so einfach ist wie
möglich, immer noch da sein kannst du den Quellcode mal packen und hier
hoch laden. Vielleicht erkennen dann die Spezialisten wo genau das
Problem ist.
D a v i d K. schrieb:> DDRC |= ((1 << PC3) | (1 << PC4) | (1 << PC5) | (1 << PC6) | (1 <<> PC7)); /* Ausgaenge */
Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden
sollte bevor man ihn abfragt?
> bool heater_STATUS(){> return (PINC & (1 << PC7));> //return (PORTC & (1 << PC7));
Was ich mich frage, wifür überhaupt zurück lesen?
Der aufrufende Teil könnte sich ja auch einfach merken was passiert,
zumal hier ja auch sowieso noch eine globale Variable gesetzt wird.
Die Variable könnte dann auch noch so zurück gesetzt werden
1
heater_OFF()
2
if(heater_STATUS() != 0)
3
{
4
// alarm, geht nicht aus??!!??
5
}
6
else
7
{
8
virtualTankUp = true;
9
}
Na, vielleicht, eher mit weniger Zeilen. :-)
Einzeiler zu kapseln finde ich generell etwas überflüssig.
Vor allem welche die nicht danach aussehen als bräuchte man die drölfzig
Mal im Code.
Und statt das sich das Programm den Zustand merkt kann man das auch so
einrichten das in jedem Umlauf erneut entschieden wird ob was an oder
aus sein soll.
Die Bedingung die zu einem heater_ON() führt ist ja sowieso schon
vorhanden und wird geprüft.
D a v i d K. schrieb:> Wie ich oben bereits geschrieben habe ist der Code richtig. Und> selbstverständlich habe ich einige Iterationen durch, in denen ich> validiert habe, dass die Ausgänge richtig schalten.
Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt,
dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.
Hi
Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung
auf LOW ziehen.
Obwohl man gerade selber HIGH sendet (in diesem Fall den PullUp an hat
und der Port auf IN geschaltet ist), muß Das nicht mit dem tatsächlichen
Stand zu tun haben - deshalb liest man den Zustand des Pin, weil man
nicht wissen will, was geplant ist, sondern, was wirklich anliegt.
MfG
Patrick J. schrieb:> Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung> auf LOW ziehen.
Das sieht nur schwer nach AVR aus und die haben keine Open-Collector
Ausgänge, zumindest nicht als IOs.
Zur Überwachung würde ich dann auch einen anderen Pin als Eingang
benutzen.
Auch bei einem AVR kann man, wenn der Pin sich im Output befindet, den
IST-Zustand über PINx abfragen. Gerade wenn mit Pull-Up / -Down
gearbeitet wird ist dies sehr hilfreich. Ob dies nun bei allen AVR so
ist, kann ich nicht beurteilen - zumindest geht es beim ollen
Attiny2313, Mega16 und Mega32u4.
Rene K. schrieb:> Auch bei einem AVR kann man, wenn der Pin sich im Output befindet, den> IST-Zustand über PINx abfragen.
Ja, klar.
Nur wenn der Pin als Ausgang geschaltet ist und auf High, aber extern
gegen Low gezogen wird, dann ist der Pin kurz vor dem Abfackeln.
Ebenso anders herum mit dem Pin auf Low geschaltet und extern gegen Plus
gezogen.
Das kann man zwar abfragen, sowas sollte aber schon in der Schaltung gar
nicht möglich sein.
Rudolph R. schrieb:> Patrick J. schrieb:>> Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung>> auf LOW ziehen.>> Das sieht nur schwer nach AVR aus und die haben keine Open-Collector> Ausgänge, zumindest nicht als IOs.
Korrekt. Ungeachtet dessen könnte ein auf H gesetzter Ausgangspin
trotzdem extern auf L gezogen werden. Das ist dann zwar nicht ganz
regelkonform, insbesondere weil dann ein heftiger, möglicherweise sogar
außerhalb der absolute maximum ratings liegender Kurschlußstrom aus dem
Pin fließen würde. Aber gehen würde es. Und: man könnte genau diesen
Fall durch das Lesen des PIN-Registers feststellen.
> Zur Überwachung würde ich dann auch einen anderen Pin als Eingang> benutzen.
Das wäre im eben geschilderten Szenario kein Vorteil.
Rolf M. schrieb:> D a v i d K. schrieb:>> Wie ich oben bereits geschrieben habe ist der Code richtig. Und>> selbstverständlich habe ich einige Iterationen durch, in denen ich>> validiert habe, dass die Ausgänge richtig schalten.>> Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt,> dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.
Wobei ein Blick auf bisherige Beiträge des TE (beileibe nicht nur in
diesem Thread) die Wahrscheinlichkeiten ganz massiv dahin verschiebt,
die Annahme "der Code [ist] richtig" in Frage stellen zu wollen.
Rudolph R. schrieb:> Ja, klar.> Nur wenn der Pin als Ausgang geschaltet ist und auf High, aber extern> gegen Low gezogen wird, dann ist der Pin kurz vor dem Abfackeln.> Ebenso anders herum mit dem Pin auf Low geschaltet und extern gegen Plus> gezogen.> Das kann man zwar abfragen, sowas sollte aber schon in der Schaltung gar> nicht möglich sein.
Das ist richtig. :-) Es heißt ja nicht ob es gut ist, sondern ob es
geht.
Die Frage die ich in den Raum geworfen habe war ja auch nicht, ob das
funktioniert, sondern wofür überhaupt. :-)
OpenCollector jetzt mal ausser acht gelassen.
Wenn sowas möglich ist buche ich das als Schaltungsfehler und wenn mir
der Pin abfackelt nützt es herzlich wenig wenn die Software davon was
merkt.
Axel S. schrieb:> ein heftiger, möglicherweise sogar> außerhalb der absolute maximum ratings liegender Kurschlußstrom aus dem> Pin fließen würde. Aber gehen würde es. Und: man könnte genau diesen> Fall durch das Lesen des PIN-Registers feststellen.
Nicht wirklich.
Ein Strom außerhalb der Maximum Ratings zerstört den µc in beliebig
kurzer Zeit.
Ob du das vor der Zerstörung noch durch Rücklesen des Pins erkennen
kannst und auch noch dagegen reagieren kannst, ist Zufall und mit
Sicherheit auch abhängig vom Controllerchip und dessen
Herstellungscharge.
xXx schrieb:> Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden> sollte bevor man ihn abfragt?
Nein, das ist nicht erforderlich.
Rudolph R. schrieb:> Was ich mich frage, wifür überhaupt zurück lesen?
Um z.B. an anderen Stellen im Programm zu prüfen, ob grade geheizt wird
oder nicht. Kann man auch mittels Flag in Software machen, man kann aber
auch den Hardware-Pin einfach abfragen. Mach ich fast immer so.
Axel S. schrieb:>> Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt,>> dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.>> Wobei ein Blick auf bisherige Beiträge des TE (beileibe nicht nur in> diesem Thread) die Wahrscheinlichkeiten ganz massiv dahin verschiebt,> die Annahme "der Code [ist] richtig" in Frage stellen zu wollen.
Darauf wollte ich eigentlich auch hinaus. Es ist eben ungeschickt, wenn
das System nicht funktioniert und man um Hilfe bittet, zuerst mal voller
Inbrunst zu postulieren, dass man alles richtig gemacht hat. Das lässt
nicht viele Möglichkeiten für Hilfe zur Lösung des Problems offen.
MaWin schrieb:> Ein Strom außerhalb der Maximum Ratings zerstört den µc in beliebig> kurzer Zeit.
Wie kurz sind die denn deiner Erfahrung nach?
> Ob du das vor der Zerstörung noch durch Rücklesen des Pins erkennen> kannst und auch noch dagegen reagieren kannst, ist Zufall und mit> Sicherheit auch abhängig vom Controllerchip und dessen> Herstellungscharge.
Ich hab's zwar noch nicht ausporbiert, aber kann mir irgendwie nicht
vorstellen, dass bei einem Kurzschluss am I/O-Pin der µC innerhalb einer
einstelligen Zahl von Mikrosekunden abraucht.
Rolf M. schrieb:> Ich hab's zwar noch nicht ausporbiert, aber kann mir irgendwie nicht> vorstellen, dass bei einem Kurzschluss am I/O-Pin der µC innerhalb einer> einstelligen Zahl von Mikrosekunden abraucht.
Ein Atmega328 verkraftet mehrere Millisekunden das Eineinhalbfache des
im Datenblatt angegebenen Wertes für einen Pin, das ist zumindest meine
Erfahrung
Rolf M. schrieb:> Wie kurz sind die denn deiner Erfahrung nach?
Das spielt keine Rolle, weil es bei deinem Chip anders ist.
Wenn Elektronik für eine beliebig kleine Zeit außerhalb der Maximum
Ratings betrieben wird, dann ist sie als defekt anzunehmen.
D a v i d K. schrieb:> Wieso ist bool test = heater_STATUS();> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht> finden kann?
Also ich verstehe das jetzt so, dass das Programm wie gewünscht
funktioniert, wenn die Header-Datei eingebunden wurde. Fehlt diese, tut
es das nicht.
Der Grund liegt im C-Standard. Erst einmal sind (aus historischen
Gründen) Funktionsprototypen im Gegensatz zu C++ nicht obligatorisch.
Der Compiler sieht einen fehlenden Prototypen daher nicht als Fehler an,
sondern geht bei der Kompilierung der aufrufenden Funktion defaultmäßig
davon aus, dass der Rückgabe-Wert der aufgerufenen Funktion ein int ist,
auf dem AVR also 2 Bytes.
Die aufgerufene Funktion hat den Rückgabewert bool, beschreibt also nur
ein 8-Bit-Rückgabe-Register. Die aufrufende Funktion interpretiert
jedoch zwei Register als Rückgabewert (int). Der (implizite) cast von
int nach bool ist laut Standard immer true, wenn der int-Wert ungleich
Null ist. Steht also in dem als High-Byte des Rückgabewertes
interpretierten Register keine Null (was meistens der Fall ist), ergibt
sich also am Ende ein 'true', selbst wenn die Funktion selbst ein
'false' zurück gegeben hat.
Daher: Immer alle Warnungen des Compilers einschalten und auch ernst
nehmen!
Detlev T. schrieb:> Daher: Immer alle Warnungen des Compilers einschalten und auch ernst> nehmen!
Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern
bringt einen Fehler und compiliert garnicht erst.
Rene K. schrieb:> Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern> bringt einen Fehler und compiliert garnicht erst.D a v i d K. schrieb:> Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header> des obigen Schnipsels einzubinden.
MaWin schrieb:> Wenn Elektronik für eine beliebig kleine Zeit außerhalb der Maximum> Ratings betrieben wird, dann ist sie als defekt anzunehmen.
Ich würde es etwas anders formulieren: man muss mit einem Defekt
rechnen.
Denn:
- der Hersteller garantiert unterhalb der Maximum Ratings, dass das
Bauteil nicht kaputt geht
- der Hersteller garantiert aber nicht, dass das Bauteil oberhalb der
Maximum Ratings kaputt geht.
> Ein Strom außerhalb der Maximum Ratings zerstört den µc> in beliebig kurzer Zeit.
Mein Motorrad schafft auf ebener Strecke maximal 140km/H. Laut
Betriebsanleitung soll ich vermeiden, über einen längeren Zeitraum mit
maximaler or annähernd maximaler Geschwindigkeit zu fahren, besonders
bei erhöhter Temperatur.
Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins
bei Mikrochips.
In den 90er Jahren machte ich anhand eines PC Mainboardes die Erfahrung,
daß die 74LS245 Bustreiber sehr empfindlich auf Schrauben im Slot
reagieren.
Ich kann mich allerdings nicht erinnern, daß mir danach jemals auch nur
irgendein IC wegen Kurzschluss an einem einzelnen Ausgang kaputt
gegangen wäre (womit ich nicht behaupten will, daß alle IC's
kurzschlussfest seien).
Insofern würde ich "in beliebig kurzer Zeit" auf "in beliebig langer
Zeit" ändern. Es ist in der Praxis lange nicht so dramatisch, wie deine
Bemerkung anmutet.
Zur Erkennung von Kurzschlüssen kann ich mir durchaus vorstellen, das
PIN Register eines AVR Ausganges zu lesen. Man könnte dann die Leitung
deaktivieren und eine entsprechende Fehlermeldung anzeigen.
Detlev T. schrieb:> Rene K. schrieb:>> Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern>> bringt einen Fehler und compiliert garnicht erst.>> D a v i d K. schrieb:>> Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header>> des obigen Schnipsels einzubinden.
Ja dazu darfst du folgendes aber auch nicht vergessen:
D a v i d K. schrieb:> wenn heater_STATUS() extern definiert wurde und er es nicht> finden kann?
M. K. schrieb:> Ein Atmega328 verkraftet mehrere Millisekunden das Eineinhalbfache des> im Datenblatt angegebenen Wertes für einen Pin, das ist zumindest meine> Erfahrung
Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND
ohne merkbaren Schaden. Ich habe das mal an 10 getestet und die dann
gegen neue Atmega vermessen: auch nach 2 Monaten Kurzschluss keine
messbaren Unterschiede zu unbelasteten Pins ode Pins neuer AVR.
Stefan U. schrieb:> Insofern würde ich "in beliebig kurzer Zeit" auf "in beliebig langer> Zeit" ändern. Es ist in der Praxis lange nicht so dramatisch, wie deine> Bemerkung anmutet.
So ist es. Man kann sogar einen kompletten Port kurzschließen. Der AVR
wird heiß, funktioniert aber hinterher trotzdem noch.
xXx schrieb:> Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden> sollte bevor man ihn abfragt?
Sieh dir einfach mal die innere Beschaltung eines AVR IO-Pins an: den
Pegel am Pin kannst du immer lesen. Egal, ob der Treiber auf Ein- oder
Ausgang geschaltet ist.
Lothar M. schrieb:> Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND> ohne merkbaren Schaden.
Das ist eine gewagte These an deren Korrektheit ich Zweifel hege.
Vielleicht klappt das unter so Randbedngungen wie das der
Spannungsregler gar nicht genug Strom liefern kann.
Stefan U. schrieb:> Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins> bei Mikrochips.
Wenn das Programm den Pin abfragt, ob der Kurzschluss-Fall eingetreten
ist, dann hab ihr einen Fehler in eurem Schaltungsdesign. Denn ihr habt
euer System außerhalb der Spezifikation designed.
Das wird euch auf jeden Fall auf die Füße fallen.
Der Kurzschluss muss schaltungstechnisch/programmtechnisch verhindert
werden. Er darf in keinem Fall auftreten können. Und dann braucht man
ihn auch nicht abzufragen, da er ja nicht auftreten kann.
Lothar M. schrieb:> Ich habe das mal an 10 getestet und die dann> gegen neue Atmega vermessen
Und aufgrund dieser Stichprobe gehst du jetzt mit deinem
Kurzschlusskonzept in deinem Design in Serie?
Sehr gewagt.
Der AtMega ist nicht für Kurzschlüsse am Pin ausgelegt. Wenn das durch
äußere Gegebenheiten auftreten kann, muss es in einer Vorschaltung
abgefangen werden.
Und dann braucht man den Pin auch nicht abzufragen.
> Das wird euch auf jeden Fall auf die Füße fallen.
Na wenn du meinst... Das Gute ist, wir müssen uns nicht einige werden.
Wenn die Schaltung zuverlässig funktionieren soll, sollte man zweifellos
nur das tun, was das Datenblatt zusichert.
Wenn es billig sein soll, dann einfach mal ausprobieren, was geht. Aber
hinterher nicht rumheulen, wenn ein Bauteil dabei dann doch kaputt geht.
Stefan U. schrieb:> Na wenn du meinst... Das Gute ist, wir müssen uns nicht einige werden.>> Wenn die Schaltung zuverlässig funktionieren soll, sollte man zweifellos> nur das tun, was das Datenblatt zusichert.>> Wenn es billig sein soll, dann einfach mal ausprobieren, was geht. Aber> hinterher nicht rumheulen, wenn ein Bauteil dabei dann doch kaputt geht.
Na also. Da sind wir uns dann doch noch einig geworden.
Lothar M. schrieb:> Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND> ohne merkbaren Schaden.
Vorsicht!
> Ich habe das mal an 10 getestet und die dann> gegen neue Atmega vermessen: auch nach 2 Monaten Kurzschluss keine> messbaren Unterschiede zu unbelasteten Pins ode Pins neuer AVR.
Das ist durchaus glaubhaft, aber nur unter bestimmten Randbedingungen,
deren wichtigste ist: Es muss ein grosses Gehäuse sein (oder auch ein
kleines Gehäuse, dann aber auf relativ viel Kupfer darunter).
Der erste Knackpunkt ist nämlich die Verlustleistung. Solange das
Gebilde die loswerden kann, ohne die Temperatur im Hotspot allzusehr
ansteigen zu lassen, geht die Sache halbwegs in Ordnung. Eins meiner
privaten Beispiele dazu: Nutzung zweier (komplementär betriebener)
Timer-OCR-Ausgänge zum direkten Betrieb eines (magnetdynamischen)
Lautsprechers im Brückenbetrieb. DDS-PWM, entsprechende Filterschaltung
natürlich vorher durchgerechnet und hardwaremässig auch tatsächlich
vorhanden.
Diese Anwendung (näherungsweise Leistungsanpassung, also nichtmal
wirklich Kurzschluss) schafft es im Dauerbetrieb, einen Mega1284P in
DIP40 auf ca. 20K über Umgebungstemperatur zu bringen. Das ist
tatsächlich relativ unkritisch und läuft monatelang im Dauerbetrieb ohne
jegliche Probleme und es sind auch, genau wie du es beschreibst, danach
keinerlei Degradationserscheinungen messbar.
AAABERR: mit einem 1284P im 7x7mm VQFN-Gehäuse geht die Sache schon ganz
anders aus (du ahnst, wie genau...) Und wenn du es nicht wahrhaben
willst: Probier es einfach selber aus, die Rauchwolke, als Entertainment
aufgefasst, ist die 7 Euro durchaus wert ;o)
Zu der Abwärmeproblematik kommt allerdings noch ein weiteres Problem
hinzu, welches allerdings im privaten Umfeld oder Büroumgebungen wohl
kein Problem darstellt, spätestens in der EMV-Prüfung aber gnadenlos
aufgedeckt wird. Energieeintrag mit hinreichenden Transienten (Teil der
EMV-Prüfung) grillt auch die solcherart überlasteten Ausgänge eines
1284P im DIP40-Gehäuse zuverlässig und hochgradig (nämlich zu 100%)
reproduzierbar.
Allerdings ist gut möglich, dass dieser Effekt bei einem wirklichen
Kurzschluss am Ausgang nicht aufgetreten wäre, weil der Energieeintrag
im konkreten Fall offensichtlich über die Zuleitung zum Lautsprecher
erfolgt ist und kein gnädiger Kurzschluss sie vom Ausgangstreiber
ferngehalten hat. Ein wenig Ferrit-Magie an der richtigen Stelle löste
dieses Problem...
MaWin schrieb:> Stefan U. schrieb:>> Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins>> bei Mikrochips.>> Wenn das Programm den Pin abfragt, ob der Kurzschluss-Fall eingetreten> ist, dann hab ihr einen Fehler in eurem Schaltungsdesign.
Richtig. Ich wollte das auch keinesfalls als empfehlenswertes Design
darstellen, sondern nur darauf hinweisen, daß es u.U. tatsächlich
sinnvoll sein kann, den Pegel an einem auf Ausgang geschalteten Pin per
Zugriff auf das PIN Register zurückzulesen. Als Designpattern taugt das
so richtig erst bei open-drain Ausgangsstufen.
Was den Defekt des µC angeht - das hängt wesentlich an bishher nicht
diskutierten Randbedingungen. Die Ausgänge der AVR können IIRC bei 3.3V
Versorgung ohnehin schon nicht so viel Strom treiben, wie die maximum
ratings erlauben. In diesem Fall wäre man also schon mal auf der
sicheren Seite. Ansonsten ist das Limit ein thermisches. Die MOSFET in
den Ausgangsstufen schnüren früher oder später ab und begrenzen den
Ausgangsstrom. Die Frage ist, ob die Verlustleistung und die damit
einher gehende Temperaturerhöhung ausreicht, den Chip permanent zu
schädigen.
Axel S. schrieb:> Als Designpattern taugt das> so richtig erst bei open-drain Ausgangsstufen.
Ich lese auch öfter einen Output Pin ein.
Das erspart ein Flag im Ram.
Kann mich nicht erinnern, da jemals einen falschen Wert bekommen zu
haben.
Never.
Rolf M. schrieb:> Arduino F. schrieb:>> Ich lese auch öfter einen Output Pin ein.>> Das erspart ein Flag im Ram.>> Da könntest du aber genauso gut das PORT-Register nehmen.
Kleiner Tipp: Für solche Zwecke haben ATMEGAs General Purpose
IO-Register (GPIO). Das sind einzelne Bytes von Speicher, die im
IO-Bereich (0x00-0x3F) liegen und daher sehr effizient angesprochen
werden können.
Hi
Arduino F. schrieb:> Kann mich nicht erinnern, da jemals einen falschen Wert bekommen zu> haben.> Never.
Hier bei mir geht es nicht um einen 'falschen' Wert - bei mir hier geht
es darum, ob jemand Anders den Pin auf LOW zieht - und Da ist die
Abfrage, ob der Pin wirklich HIGH ist, nicht die schlechteste Wahl.
MfG
... und da sind Sie, die Nazi-Vergleiche :)
Wie war dazu der Fachbegriff?
Jupp, dieser Post darf ohne Bedenken (mit) gelöscht werden.
@Hater
Die paar Takte Unterschied vom aktivem Setzen des Ausgang bis zum
Einlesen dürften durch ein rjmp oder Interrupt-Aufruf locker erreicht
werden.
Mich interessiert, ob der IST mit dem SOLL-Zustand überein stimmt.
Mein Ablauf:
- Pin setzen (IN HIGH oder OUT LOW, das HIGH kommt von einem PullUp)
- bei PinChange 'nachsehen', welchen Pgel wir gerade haben und, ob Das
unser Pegel ist
- bei LOW Außen und HIGH Innen kann ich davon ausgehen, daß da Jemand
Anders 'funkt'.
Die Zwischenzeit, Die der PIN braucht, um mein aktives Setzen
umzusetzen, habe ich nach dem nächsten rjmp bereits überbrückt.
Ich sehe in dieser Verzögerung keine Probleme.
MfG
PS: Wobei ich nicht der TO bin - nur nebenbei erwähnt
Patrick J. schrieb:> Die paar Takte Unterschied vom aktivem Setzen des Ausgang bis zum> Einlesen dürften durch ein rjmp oder Interrupt-Aufruf locker erreicht> werden.
Natürlich. Aber wenn du in Assembler schreibst:
sbi PORTy, BITx
sbic PINy, BITx
rjmp anywhere
rjmp anywhereelse
wirst du wider Erwarten bei anywhereelse landen. Und, es kann dir auch
in plain C passieren, dass genau dies passiert, wenn du sinngemäß den
gleichen Code schreibst. Übrigens ist das gerade dank der relativ guten
Optimierung des Compilers so...
Nur in dem Arduino kann das nicht passieren, weil der eben einfach lahm
ist. Genau um die Unterdrückung dieser Information ging es vermutlich
eigentlich im Wesentlichen bei der Löschung meines Posting. Und genau
darum, dass ich nicht bereit bin das zu akzeptieren, weil ich das für
einen niederen Beweggrund halte, geht es hier.
Rudolph R. schrieb:> Das ist eine gewagte These an deren Korrektheit ich Zweifel hege.
Tu das.
c-hater schrieb:> Aber wenn du in Assembler schreibst:> sbi PORTy, BITx> sbic PINy, BITx> rjmp anywhere> rjmp anywhereelse> wirst du wider Erwarten bei anywhereelse landen.
Kommt drauf an. Auf die Taktfrequenz und die Last am Pin. Im ohmschen
Normalfall geht es hier wie erwartet nach anywhere...
c-hater schrieb:> AAABERR: mit einem 1284P im 7x7mm VQFN-Gehäuse geht die Sache schon ganz> anders aus (du ahnst, wie genau...) Und wenn du es nicht wahrhaben> willst: Probier es einfach selber aus, die Rauchwolke, als Entertainment> aufgefasst, ist die 7 Euro durchaus wert ;o)
Werde ich tun.
BTW: die Löschungen deiner Posts könnten in deiner unnötig unmöglichen
Wortwahl liegen. Ich bin sicher, du weißt, was ich meine. Wenn solche
Worte zu deinem Umgangsformen gehören, dann lass sie dort. Hierher
gehören sie jedenfalls nicht.
Und die dazu gehörende Stelle im Datenblatt: "When reading back a
software assigned pin value, a nop instruction must be inserted as
indicated in Figure 14-4."
Lothar M. schrieb:> Kommt drauf an. Auf die Taktfrequenz und die Last am Pin. Im ohmschen> Normalfall geht es hier wie erwartet nach anywhere...
OMG.
Nein. Du hast offensichtlich nicht ein AVR8 Datenblatt wirklich
gelesen...
Wenn schon die Zensoren so derart krass anfähig sind, wie soll sich denn
dann jemals die Wahrheit durchsetzen?
> BTW: die Löschungen deiner Posts könnten in deiner unnötig unmöglichen> Wortwahl liegen.
Das kann dann höchstens "Arduidiot" gewesen sein. Ich finde den Begriff
allerdings auch im Rückblick nicht nur sehr kreativ und lustig, sondern
obendrein überaus zutreffend...
Aber OK, ich kann voll verstehen, dass er den Arduidioten selber
vermutlich nicht so gefällt und sie auch nicht in der Lage sind, das
einfach an sich abgleiten zu lassen, wie erwachsene Nutzer des Internet
das zu tun in der Lage wären...
Als Kompromiss würde ich der Zensur vorschlagen, in Zukunft einfach nur
solche mißliebigen Begriffe zu "schwärzen", statt gleich das ganze
Posting zu löschen...
Oh, ich weiß, dass das geht. Macht allerdings den Zensoren mehr Arbeit.
So what: Für so viel Macht muss man auch mal ein wenig (mehr)
arbeiten...
Ihr seid euch doch hoffentlich bewußt, welch große Macht ihr ausübt?
c-hater schrieb:> in Zukunft einfach nur solche mißliebigen Begriffe zu "schwärzen", statt> gleich das ganze Posting zu löschen...
Habe ich dann ja auch gemacht. Allerdings ist es eben unglaublich
mühsam, den Dreck anderer wegzuräumen.
c-hater schrieb:> Nein. Du hast offensichtlich nicht ein AVR8 Datenblatt wirklich> gelesen...
Doch schon mal. Aber danke für die Erinnerung an dieses Gebastel. Das
war bei den ersten AVR übrigens noch nicht so, es kam erst mit dem
ersten Shrink und der dabei eingeführten Synchronisationsstufen an den
Eingängen.
c-hater schrieb:> Aber OK, ich kann voll verstehen, dass er den Arduidioten selber> vermutlich nicht so gefällt und sie auch nicht in der Lage sind, das> einfach an sich abgleiten zu lassen, wie erwachsene Nutzer des Internet> das zu tun in der Lage wären...
Erwachsene Nutzer sollten aber auch in der Lage sein, Postings ohne
Beschimpfungen zu verfassen.
> Als Kompromiss würde ich der Zensur vorschlagen, in Zukunft einfach nur> solche mißliebigen Begriffe zu "schwärzen", statt gleich das ganze> Posting zu löschen...
Ich schlage vor, solche Begriffe ganz einfach nicht zu verwenden, wenn
du nicht willst, dass deine Postings gelöscht werden.
> Oh, ich weiß, dass das geht. Macht allerdings den Zensoren mehr Arbeit.> So what: Für so viel Macht muss man auch mal ein wenig (mehr)> arbeiten...
Nur weil du dich nicht beherrschen kannst, sollen andere sich extra
Arbeit machen? Lass die Beleidigungen einfach weg, dann wird auch nix
gelöscht, und niemand hat irgendwelche Arbeit damit, deine Posting davon
zu bereinigen. Die Moderatoren sind doch nicht deine Putzfrauen, die
hinter dir her wischen...
> Ihr seid euch doch hoffentlich bewußt, welch große Macht ihr ausübt?
In den Nutzungsbedingungen steht klar, dass Beiträge, die Beleidigungen
enthalten, gelöscht werden. Nicht vom Moderator so umformuliert, dass
sie den Regeln entsprechen, sondern gelöscht!
Lothar Miller schrieb:
> Das war bei den ersten AVR übrigens noch nicht so,> es kam erst mit dem ersten Shrink und der dabei> eingeführten Synchronisationsstufen an den Eingängen.
Wann soll das gewesen sein - beim AT90S1200?
Mein ältester, ein AT90S8515-8PI von 9825, verhält sich genauso.
c-hater schrieb:> Das kann dann höchstens "Arduidiot" gewesen sein. Ich finde den Begriff> allerdings auch im Rückblick nicht nur sehr kreativ und lustig, sondern> obendrein überaus zutreffend...
Schade dass fachliche und soziale Kompetenz nicht immer in Personalunion
in Erscheinung treten. Du bewegst dich, in Sachen sozialer Kompetenz,
eher auf den Niveau einer Bordsteinkante.
Zur Erinnerung:
Das Grundgesetz spricht von "Würde".
Und das Strafgesetz kennt die "Beleidigung".
Du bewegst dich mit deinen Äußerungen im strafbaren Bereich, und findest
das auch noch toll. Sogar stolz drauf.
S. Landolt schrieb:> Mein ältester, ein AT90S8515-8PI von 9825, verhält sich genauso.
Mhmmmm...
Offenbar trügt mich die Erinnerung. Ich finde da auch nichts mehr. Oder
ich verwechsle das tatsächlich mit dem 8051.
Dieses Verhalten ist aus meiner Sicht als Hardware-Designer sowieso ein
Fehler im Silizium. Aber wie heißt es so schön: "Wir waren jung und
brauchten das Geld!" ;-)
@Arduino Fanboy
Du hast zwar Recht aber dein Beitrag ist auf ebenso niedrigem Nieveau.
Nur die Wortwahl ist gepflegter. Lass ihn doch einfach, jeder bekommt
irgendwann die gerechte Strafe für sein Handeln - sei es durch andere
oder weil sie sich irgendwann selbst in die Sch*** rein reitet. Da muss
man gar nicht nachhelfen.
Thread beobachten
Seitenaufteilung abschalten