Hallo zusammen, Ich versuche derzeit den PortA eines Atmega32 gemischt zu betreiben. An PA7 bis PA4 schalte ich über verschiedene Bitkombinationen einen Multiplexerbaustein. Den analogen Ausgang dieses Multiplexers werte ich auf PA0 aus. Alles funktioniert soweit gut, außer wenn ich PortA komplett Low setze also 0b00000000. Dann werden die Ausgänge für ein paar Nanosekunden kurzzeitig low geschaltet und wechseln anschließend automatisch wieder auf High.. Vielleicht hat jemand eine Idee woran das liegen konnte, solange mindestens ein Highsignal auf dem Port liegt funktioniert alles einwandfrei. Vielen Dank im voraus
> außer wenn ich PortA >komplett Low setze also 0b00000000. Dann werden die Ausgänge für ein >paar Nanosekunden kurzzeitig low geschaltet und wechseln anschließend >automatisch wieder auf High.. > >Vielleicht hat jemand eine Idee woran das liegen konnte, Das liegt an deinem Programm.
Ich nehme an, dass sich in Zeile 42, Deines Programmes, der Fehler eingeschlichen hat;)
Amateur schrieb: > Ich nehme an, dass sich in Zeile 42, Deines Programmes, der Fehler > eingeschlichen hat;) Vielleicht liegt es aber auch nicht an dieser Zeile. mfg (could not resist)
:
Bearbeitet durch User
mega32 schrieb: > paar Nanosekunden Es (das mega32) hat ein wirklich gutes Oszi... Ob es auch einen Debugger bedienen kann ? (oder Strg + C / Strg + V) Sagt ein Widerstand zum anderen ... > (could not resist)
Wie muss man eigentlich Fragen um hier keine dummen Antworten zu kriegen?
mega32 schrieb: > Wie muss man eigentlich Fragen um hier keine dummen Antworten zu > kriegen? Mit vernünftigen Angaben. Sollen wir Hellsehen, was bei dir das Problem sein könnte? Im Zweifelsfall gehört da praktisch immer das Programm mit dazu. Falls es sich wirklich mal um den unwahrscheinlichen Fall handelt, dass es sich wirklich um einen bekannten Hardwarefehler im µC handelt, dann hat man halt ein paar Bytes zuviel raufgeladen. Aber der Fall kommt praktisch nie vor. In der Praxis ist es meistens eine gute Idee, von der Annahme auszugehen, dass man selbst irgendwo einen Fehler gemacht hat. Nur: wie soll das irgendwer verifizieren?
:
Bearbeitet durch User
>Wie muss man eigentlich Fragen um hier keine dummen Antworten zu >kriegen? Liefere mehr Details. Sonst muss man ja raten. Je mehr Details umso besser.
mega32 schrieb: > Wie muss man eigentlich Fragen um hier keine dummen Antworten zu > kriegen? Oh sorry, das habe ich wohl missverstanden. Die Frage war so lächerlich unmöglich zu beantworten mit Deinen Angaben das ich mich nicht getraut habe das Niveau zu weit anzuheben.
Naja wenn ich einen Ansatz hätte würde ich nicht Fragen sondern selbst suchen.. Die Frage zielt natürlich darauf ab ob es daran liegen könnte dass ich den port gemixt betreibe..
>Die Frage zielt natürlich darauf ab ob es daran liegen könnte >dass ich den port gemixt betreibe. Das geht problemlos wenn das Programm korrekt ist;)
Wie wärs mit RTFM? > 4. If any ADC port pins are used as digital outputs, it is essential that > these do not switch while a conversion is in progress. (zitiert aus Datenblatt ATMega32 02/11, Seite 209)
:
Bearbeitet durch User
mega32 schrieb: > dass ich den port gemixt betreibe Das machen viele andere auch und haben keine Probleme damit. Stell dein Programm hier rein (und zwar das ganze und nicht cryptische Auszüge). Ansonsten: Der Fehler liegt in 90% der Fälle zwischen Tastatur und Sitzfläche.
>> 4. If any ADC port pins are used as digital outputs, it is essential that >> these do not switch while a conversion is in progress. Das ist eine Empfehlung und kein muss. Eine Erklärung warum seine Portpins da mit einmal den Zustand ändern ist es auch nicht.
Matthias Sch. schrieb: > Wie wärs mit RTFM? >> 4. If any ADC port pins are used as digital outputs, it is essential that >> these do not switch while a conversion is in progress. Das kann ich ausschließen, habe den Code zum auslesen aus dem AVRGcc Tutorial kopiert, aus der Funktion komme ich erst heraus wenn die Konvertierung abgeschlossen ist. /* ADC Einzelmessung */ uint16_t ADC_Read( uint8_t channel ) { // Kanal waehlen, ohne andere Bits zu beeinflußen ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F); ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion" while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten } return ADCW; // ADC auslesen und zurückgeben }
>>> 4. If any ADC port pins are used as digital outputs, it is essential that >>> these do not switch while a conversion is in progress. > Korrigier mich, wenn ich falsch liege. Bei dieser Empfehlung geht es doch darum, dass das ADC Messergebnis durch die Schaltvorgänge unter Umständen beeinflusst wird.
Asche auf mein Haupt.. Mit break; Anweisung funktioniert auch Case16.
>Asche auf mein Haupt.. Mit break; Anweisung funktioniert auch Case16.
Dann war die erste Antwort ja die richtige;)
Karl Heinz schrieb: > Bei dieser Empfehlung geht es doch darum, dass das ADC Messergebnis > durch die Schaltvorgänge unter Umständen beeinflusst wird. So isses. Da der TE von einigen Nanosekunden redet, kann das durchaus so ein 'Noise' sein.
:
Bearbeitet durch User
Eventuell Kapazitive Übertragung von dem knallhart auf 0 geschalteten Pin zu den anderen Hochohmigen Eingangspins. Die Portpins werden intern wohl irgendwo nah beienander geführt werden müssen
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.