Hallo zusammen, ich bin hier grade am verzweifeln. Ich habe mit ein Tastenfeld mit 3 Tasten(Taster) gebaut. Hinter Jedem Taster liegt ein Wiederstand. Wenn ich mich nicht irre sind dies: 560; 1,2k; 2,2k. Über einen der ADC-PINs wird dann gemessen welcher Taster gedrückt wurde. Das ganze hat auch immer mal wieder funktioniert, jedoch habe ich Probleme mit dem Integer, den mir der ADC zurückgibt. Die funktion zum Messen des ADC-Wertes habe ich hier aus dem Forum und ist meiner Meinung nicht daran schuld. Es ist im Prinzip eine Single-conversion, die nach mehrmaligem Messen einen Druchschnitterrechnet. Wie gesagt, hat alles auch schon funktioniert. Für den "Nach-Links-Knopf" habe ich einen Wert von ~339; Enter hat ~448, Rechts ~224. Das eigentliche Proble ist, das ich 3 Zeilen im Programm geändert habe und nun (mal wieder) statt dem Wert 339 wirkürlich zb: 8339 oder 1339 ausgegeben bekomme. Da ich aus der PC-Programmierung (Java) komme sind mir fehler dieser Art nicht sonderlich bekannt. Ich habe schon an einen Überlauf gedacht, jedoch kann ich mir nicht erklären wie sieder zu stande kommen soll. Ich mache 15 Messungen. Pro Messung ein max.-Wert von 1023. 15*1023 = 15345 ; das sollte doch eigentlich in einen uint16 passen?! Danach wird wieder durch 15 geteilt um auf den Mittelwert zu kommen. Aber wie gesagt, der Fehler tritt erst auf, seit dem ich 2 Ausgaben mehr auf das Display werfe. Selbst wenn ich die Zeilen wieder rausnehme bekomme ich keinen richtigen Wert mehr. Ich werd jetzt aus frust einen anderen Mega testen. Mir wäre aber sehr beholfen wenn ihr mir mögliche fehlerquellen bei Integerberechnungen nahelegt. Ich dreh hier sonst noch durch ...
ohne Quellcode kann dir hier kaum jemand helfen. Aber ich würde 16 Messungen machen und durch 16 Teilen - das gefällt dem µC besser.
Enteroctopus Dofleini schrieb: > Ich mache 15 Messungen. Pro Messung ein max.-Wert von 1023. 16 wären besser. 16 ist eine 2-er Potenz > Aber wie gesagt, der Fehler tritt erst auf, seit dem ich 2 Ausgaben mehr > auf das Display werfe. > Selbst wenn ich die Zeilen wieder rausnehme bekomme ich keinen richtigen > Wert mehr. Fehler dieser Art sind oft an ganz anderer Stelle zu suchen. Array-Überläufe, Stack zerschossen oder anderes in dieser Richtung. > Ich dreh hier sonst noch durch ... Sollst du nicht. Geh deinen Code durch. Überprüf jede einzelne Operation. Kann das Ergebnis den zulässigen Zahlenbereich verlassen? Ist ein Array im Spiel? Kann es sein, dass der Array Index hinter oder vor dem Array liegt Ist ein Pointer im Spiel? Zeigt der immer auf etwas sinnvolles? Handelt es sich um einen String? Habe ich bedacht, dass ich für das '\0' Byte ein Byte mehr reservieren muss als augenscheinlich notwendig. Kann es sein, dass ich zuviele lokale Variablen habe und mir der Stack in den Heap wächst? Es gibt noch mehr potentielle Problem, aber mit der Liste sollte das meiste abgehakt sein. Letztendlich geht es meistens darum, dass das Programm Speicherzellen verändert, die eigentlich nicht verändert werden dürften.
Ich habe mal versucht das ganze in Minimalkonfiguration Nachzustellen.
Jetzt ist mir zu mindest ersichtlich, das die letzte Ziffer auch an
erster Stelle steht.
Ich gehe mal davon aus das es ein Problem mit dem Zeiger ist.
Aber wie kann ich das vermeiden?
int main(void){
char *buffer;
// TastennummerN: Links: 339; Enter 448; Rechts: 224
unsigned long num=0;
initLCD();
DDRC = (1<<PC0) | (1<<PC1) | (1<<PC2);// | (1<<PC0);
PORTC = (1<<PC1) | (1<<PC2);
while(1) {
num=ReadChannel(PC0);
ltoa(num, buffer, 10);
lcd_puts( buffer );
lcd_puts("\n");
num=0;
}
}
> char *buffer;
danach hast du ein Zeiger, aber dieser zeitg irgednwo hin. Du musst erst
speicher anfordern.
oder besser
char buffer[10];
Enteroctopus Dofleini schrieb:
> Aber wie kann ich das vermeiden?
Speicher fuer deinen String beschaffen waere ein guter Anfang.
Z.B:
char buffer[ 7];
Und ein C-Buch waere gut und programmieren nochmal von Anfang an lernen.
Peter Stegemann schrieb: > Enteroctopus Dofleini schrieb: > >> Aber wie kann ich das vermeiden? > > Speicher fuer deinen String beschaffen waere ein guter Anfang. Nein. Ein indiziertes Array ist durchaus noch etwas anderes! > > Z.B: > char buffer[ 7]; > > Und ein C-Buch waere gut und programmieren nochmal von Anfang an lernen. Sorry, aber solche Anworten bringen mich nicht weiter und ist der Grund warum ich selten in Foren unterwegs bin! C-Bücher habe ich zu hauf hier liegen, aber Schulwissen ist hier nicht gefragt! Da steht nämlich nicht mehr, sondern weniger drin als der Copiler wirklich macht! Ein chararray hilft mir hier nicht weiter, da hierbei die letze stelle abgeschnitten wird - warum auch immer.
Enteroctopus Dofleini schrieb: > Ein chararray hilft mir hier nicht weiter, Doch. Das tut es. Zumindest in deinem hier geposteten Demo-Programm > da hierbei die letze stelle > abgeschnitten wird - warum auch immer. Wahrscheinlich, weil du es zu klein dimensioniert hast. > C-Bücher habe ich zu hauf hier > liegen, aber Schulwissen ist hier nicht gefragt! Wenn du irgendwo etwas abspeichern willst, benötigst du eine Speicherfläche dafür. Eine Pointervariable ist selbst keine Speicherfläche, sie verweist nur auf eine. Ein Pointer ist im Grunde nichts anderes als ein Zettel in der Bibliothek, auf dem steht: Das Malbuch findet sich im Gang 5, Regal 2, unterste Ablage. Nur wenn das auf dem Zettel steht, sollte besser sichergestellt sein, dass im Gang 5, Regal 2, unterste Ablage auch tatsächlich das Malbuch steht, in dem du zu malen gedenkst. Dem Compiler ist das wurscht. Der schreibt auch dorthin, wenn dort die Magna Carta steht.
Naja, das Bsp mit dem Zettel ist nicht besonders optimal: Ein Zettel ist eine Speicherfläche! Aber wieso wird denn beim char[4] die letze Stelle abgeschnitten? Statt 448 bekomme ich immer nur 44
Enteroctopus Dofleini schrieb: > Naja, das Bsp mit dem Zettel ist nicht besonders optimal: Ein Zettel ist > eine Speicherfläche! Auch ein Pointer ist eine Speicherfläche. Aber er nimmt nur die Adresse im Speicher auf, wo die von dir gewünschte Information steht. (Insofern ist die Aussage von weiter oben: "Ein Pointer ist keine Speicherfläche" misverständlich. Gemeint war: Du speicherst dort nicht deine Texte oder sontige Daten ab, sondern die Adresse wo die Daten zu finden sind) Die Analogie mit Zettel und etwas was darauf geschrieben steht, stimmt sogar ziemlich gut. Auf manchen Zetteln steht die von dir gewünschte Information. Auf wieder anderen steht drauf: Um die Information zu finden, sieh dort und dort nach. Letzteres sind genau die Pointer.
Enteroctopus Dofleini schrieb: > Naja, das Bsp mit dem Zettel ist nicht besonders optimal: Ein Zettel ist > eine Speicherfläche! > > Aber wieso wird denn beim char[4] die letze Stelle abgeschnitten? > Statt 448 bekomme ich immer nur 44 Dann zeig den Code dafür. Solange du ltoa irgendwo in den Speicher schreiben lässt (weil du ihm einen uninitialisierten Pointer übergibst), kannst du dich auf nichts verlassen.
Karl heinz Buchegger schrieb: > Enteroctopus Dofleini schrieb: >> Naja, das Bsp mit dem Zettel ist nicht besonders optimal: Ein Zettel ist >> eine Speicherfläche! > > Auch ein Pointer ist eine Speicherfläche. Aber er nimmt nur die Adresse > im Speicher auf, wo die von dir gewünschte Information steht. > > Die Analogie mit Zettel und etwas was darauf geschrieben steht, stimmt > sogar ziemlich gut. Auf manchen Zetteln steht die von dir gewünschte > Information. Auf wieder anderen steht drauf: Um die Information zu > finden, sieh dort und dort nach. Letzteres sind genau die Pointer. Richtig, richtig... Mal kurz und schmerzlos: So blöd bin ich nicht, nur weil ich 14 Jahre kein C mehr gesprochen habe heisst das nicht das ich nichts mehr wüßte! Mir ist der unterschied durchaus bewusst, aber hilft mir das nicht weiter... Zeiger -> zeigt auf den Anfang in eines undefinierten Speicherbereich Array -> Indizierter Speicherbereich bei dem anfang un Ende bekannt sind und auf den mittels Zeiger zugegriffen werden kann Es sei jetzt (noch)mal dazu gesagt, das es mit dem Zeiger bereits funktioniert hat ( in einem wesentlich größerem Code). Mit dem Array widerum wurde immer die letzte Stelle abgeschnitten, daher habe ich mich mit dem Zettel bisher zufrieden gegeben.
Enteroctopus Dofleini schrieb: > Mal kurz und schmerzlos: So blöd bin ich nicht, nur weil ich 14 Jahre > kein C mehr gesprochen habe heisst das nicht das ich nichts mehr wüßte! Es sieht aber definitiv so aus, als ob du das nicht mehr wüsstest. Das was du hier treibst, ist noch nicht mal im Ansatz argumentier- oder interpretierbar. Es verstößt gegen jegliche C-Regeln und du landest sofort bei dem, was der C-Standard "undefiniertes Verhalten" nennt. > Es sei jetzt (noch)mal dazu gesagt, das es mit dem Zeiger bereits > funktioniert hat ( in einem wesentlich größerem Code). Es mag so ausgesehen haben. Funktioniert hat es aber nie wirklich. Du hattest einfach nur das Pech, dass sich der Fehler nicht gezeigt hat. Merke: Nur weil ein Programm kein Fehlverhalten zeigt, heißt das noch lange nicht, dass es fehlerfrei ist. Durch Testen kann man immer nur das Vorhandensein von Fehlern nachweisen, aber nie die Fehlerfreiheit eines Programmes. > Mit dem Array widerum wurde immer die letzte Stelle abgeschnitten, daher > habe ich mich mit dem Zettel bisher zufrieden gegeben. Dann sollte man dort den Hebel ansetzen. Wenn du einen Fehler korrigierst und das Programm funktioniert immer noch nicht richtig, hast du noch mindestens einen weiteren Fehler im Programm. Fehler werden nicht dadurch korrigiert, indem man einen Gegenfehler einbaut, sodass sich beide scheinbar aufheben. Das hier
1 | int main(void){ |
2 | char *buffer; |
3 | |
4 | ...
|
5 | |
6 | ltoa(num, buffer, 10); |
7 | |
8 | ...
|
9 | }
|
ist definitiv und unzweifelhaft ein Fehler. Sogar ein ziemlich schwerer Fehler. Auch dann, wenn dein Testprogramm scheinbar damit funktioniert.
1 | int main(void){ |
2 | char buffer[10]; // nicht kleckern, klotzen! |
3 | |
4 | ...
|
5 | |
6 | ltoa(num, buffer, 10); |
7 | |
8 | ...
|
9 | }
|
Mich wundert nur, das in einem "3-Zeiler" (siehe oben) so schwere fehler
sitzen können.
Hier mal die abfrage des ADCs:
Ansonsten sollte der Minicode oben ausreichen um das ganze zu testen
uint16_t ReadChannel(uint8_t mux) {
uint8_t i;
uint16_t result;
ADMUX = mux; // Kanal waehlen
ADMUX |= (1<<REFS1) | (1<<REFS0); // interne Referenzspannung nutzen
ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteiler
// setzen auf 8 (1) und ADC aktivieren
(1)
/* nach Aktivieren des ADC wird ein "Dummy-Readout" empfohlen, man
liest
also einen Wert und verwirft diesen, um den ADC "warmlaufen zu
lassen" */
ADCSRA |= (1<<ADSC); // eine ADC-Wandlung
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result = ADCW; // ADCW muss einmal gelesen werden,
// sonst wird Ergebnis der nächsten Wandlung
// nicht übernommen.
/* Eigentliche Messung - Mittelwert aus 15 aufeinanderfolgenden
Wandlungen */
result = 0;
for( i=0; i<16; i++ ) {
ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion"
while ( ADCSRA & (1<<ADSC) ) {
; // auf Abschluss der Konvertierung warten
}
result += ADCW; // Wandlungsergebnisse aufaddieren
}
ADCSRA &= ~(1<<ADEN); // ADC deaktivieren (2)
result /= 16; // Summe durch vier teilen = arithm.
Mittelwert
return result;
}
Jetzt mal Hypothetisch:
Wenn ich ein Array nutze bei dem die letze Stelle abgeschnitten wird,
kann das zu weiteren Problemen führen?
Der Genau Wert ist mir im grunde wurst, da es mit nur darum geht
herauszufinden welcher Taster gedrückt wurde. Und da die beiden ersten
Ziffern sich genügend unterscheiden wäre das kein Problem.
Karl heinz Buchegger schrieb: > Enteroctopus Dofleini schrieb: > >> Mal kurz und schmerzlos: So blöd bin ich nicht, nur weil ich 14 Jahre >> kein C mehr gesprochen habe heisst das nicht das ich nichts mehr wüßte! > > Es sieht aber definitiv so aus, als ob du das nicht mehr wüsstest. ... Nicht behaupten - Wissen! Genau so hat es ja nie funktioniert. Ich bekomme nur eine Zweistellige Zahl, die allerdings 3 stellig sein muss. Deshalb mein unverständniss... >
1 | > int main(void){ |
2 | > char buffer[10]; // nicht kleckern, klotzen! |
3 | >
|
4 | > ... |
5 | >
|
6 | > ltoa(num, buffer, 10); |
7 | >
|
8 | > ... |
9 | > } |
10 | >
|
Enteroctopus Dofleini schrieb: > Mich wundert nur, das in einem "3-Zeiler" (siehe oben) so schwere fehler > sitzen können. So ist das nun mal in der C-Programmierung. Es gibt kein Sicherheitsnetz. > Hier mal die abfrage des ADCs: > Ansonsten sollte der Minicode oben ausreichen um das ganze zu testen Da brauche ich nichts testen. Fehler ist Fehler. Und dieser Fehler ist einer von der Sorte, der mit einem Blinklicht auf sich aufmerksam macht. Wenn man weiß, wonach man suchen muss, natürlich. > Jetzt mal Hypothetisch: > Wenn ich ein Array nutze bei dem die letze Stelle abgeschnitten wird, > kann das zu weiteren Problemen führen? Es deutet darauf hin, dass es noch mindestens einen weiteren Fehler gibt. > herauszufinden welcher Taster gedrückt wurde. Und da die beiden ersten > Ziffern sich genügend unterscheiden wäre das kein Problem. Behebe die Ursachen und hör auf an den Symptomen rumzudoktern.
Enteroctopus Dofleini schrieb: > Mich wundert nur, das in einem "3-Zeiler" (siehe oben) so schwere fehler > sitzen können. Wenn man ausreichend Ahnungslosigkeit mit Arroganz koppelt, dann geht sowas ganz einfach. Und dir fehlen die wesentlichen Grundlagen fuer C. > Der Genau Wert ist mir im grunde wurst, da es mit nur darum geht > herauszufinden welcher Taster gedrückt wurde. Und da die beiden ersten > Ziffern sich genügend unterscheiden wäre das kein Problem. Das ist genau der Murks, den ich von Java-Entwicklern gewohnt bin... Du hast von sowohl von mir, als auch von Karl Heinz (wie gewohnt sehr ausfuehrlich :-) Korrekturen bekommen - wie waere es, die erst einmal umzusetzen?
Peter Stegemann schrieb: > ausfuehrlich :-) Korrekturen bekommen - wie waere es, die erst einmal > umzusetzen? :-) Das tut er nicht, denn dann würden sich weitere Fehler bemerkbar machen. Er ist von der Sorte, die lieber einen Pappendeckel über die Beule am Auto machen und den überlackieren, anstatt das fachmännisch richten zu lassen. Selbst dann, wenn die Beule in der Fahrertür so gross ist, dass er das Kupplungspedal nicht mehr erreichen kann. Dann muss eben ein Seilzug her, mit dem man die Kupplung bedienen kann. Oder es muss dann eben ohne Kupplung gehen. Wenn dann das Getriebe hops geht, ist auf keinen Fall die nicht fachmännisch behobene Beule schuld. Statt dessen kleben wir lieber das Loch im Getriebegehäuse mit Klebeband zu.
Ein letzes mal in diesem Forum: Eure korrekturen habe ich alle bereits vorher getestet und werden daher von mir nicht als solche bewertet. Bisher waren es mal wieder 3 Std Forenzeit ohne fortschritt, im gegenteil ich werde als unwissen dahingestellt ohne das auch nur annähernd gefragt wurde was überhaupt alles schon getestet wurde. Den einzigen Post der in meinen augen annhembar war ist der erste von Karl Heinz - Immerhin hat er sich bemüht auf die frage einzugehen. Der rest war nichts weiter als - "ich möchte auch gerne was dazu schreiben" Wenn doch alle so gut informiert sind, warum geht es dann nicht mit dem Array?
Enteroctopus Dofleini schrieb: > Ein letzes mal in diesem Forum: Eure korrekturen habe ich alle bereits > vorher getestet und werden daher von mir nicht als solche bewertet. Wem nicht zu helfen ist. > Bisher waren es mal wieder 3 Std Forenzeit ohne fortschritt, im > gegenteil ich werde als unwissen dahingestellt ohne das auch nur > annähernd gefragt wurde was überhaupt alles schon getestet wurde. Da geht es nicht um testen. Der Fehler ist für jeden C-Programmierer so offensichtlich, offensichtlicher geht es nicht. Wenn alle Fehler so einfach zu finden wären, könnte ich meine 40-Stunden Woche auf 5 Stunden verkürzen. > Wenn doch alle so gut informiert sind, warum geht es dann nicht mit dem > Array? Zeig doch mal, WAS nicht geht! Aber genauen, exakten Code bitte. In der Programmierung kommt man mit Winken aus der Ferne nicht weiter. Die Details sind es, die den Unterschied ausmachen. Wahrscheinlich strotzt das Programm nur so von immer dem gleichen Fehler: Du schreibst in Speicherbereiche, in denen du nichts verloren hast (sprich: du benutzt uninitialisierte Pointer). Solange der Compiler dort keine anderen Variablen angesiedelt hat, sieht das dann so aus, als ob alles in Ordnung ist. Aber wehe, wenn sich die Memory-Konfiguration deines Programmes verändert ....
Enteroctopus Dofleini schrieb: > Bisher waren es mal wieder 3 Std Forenzeit ohne fortschritt, im > gegenteil ich werde als unwissen dahingestellt ohne das auch nur > annähernd gefragt wurde was überhaupt alles schon getestet wurde. Und da das Problem in deinem geposteten Testprogramm jetzt nun hinreichend oft durchgekaut wurde, hat es auch keinen Sinn danach zu fragen, was bei deinem richtigen Programm getestet wurde, solange die Erkentniss aus dem Testprogramm ("so gehts nicht") nicht konsequent in deinem richtigen Programm eingebaut und umgesetzt wurde. Dir scheint nicht klar zu sein, dass das Auftreten eines Fehlers nach der Behebung eines anderen Fehlers etwas Gutes ist. Dem kann man nachgehen und wiederrum diesen beheben. Interessant wird es erst, wenn sich kein Fehler mehr zeigt. Dann ist die spannende Frage: Wars das jetzt oder schlummert noch etwas in den Tiefen und ich habe es bis jetzt einfach nur nicht bemerkt. Oder was in die gleiche Kerbe schlägt: Wenn ein Programm anscheinend auf Anhieb funktioniert, dann stimmt etwas nicht.
> Wahrscheinlich strotzt das Programm nur so von immer dem gleichen > Fehler: Du schreibst in Speicherbereiche, in denen du nichts verloren > hast (sprich: du benutzt uninitialisierte Pointer). Solange der Compiler > dort keine anderen Variablen angesiedelt hat, sieht das dann so aus, als > ob alles in Ordnung ist. Aber wehe, wenn sich die Memory-Konfiguration > deines Programmes verändert .... Kann ich mir zwar nicht vorstellen, da es ebend nur noch aus den paar Zeilen (siehe oben) besteht, aber ich hab es mal als anhang beigefügt.
Auf die Schnelle:
Tu dir selbst einen Gefallen und dimensioniere deine Buffer nicht so
knapp.
char buffer[4];
->
char buffer[10];
Dann hast du einen, wenn auch kleinen, Sicherheitspolster, falls in
ReadChannel dann doch irgendwann einmal etwas größeres als 999
rauskommen sollte (zb. bei einem Hardwarefehler an deinen Widerständen)
Die Funktion, um einen unsigned long in seine ASCII Form zu überführen,
heißt ultoa. Aber daran liegt es momentan nicht.
Apropos: Wie sind eigentlich deine Widerstände genau verschaltet. Wenn keine Taste gedrückt ist, ist sichergestellt, dass der ADC Eingang nicht einfach in der Luft hängt und jedes dahergelaufene elektromagnetische Feld ausmisst?
Ja, ich weiß. Der long steht auch nur wegen der vielen anderen misserfolge da. Ebenso die entsprechende konvertirungsfunktion...
Abgesehen davon, muss dieses Programm dann aber auch die richtigen Werte anzeigen. Wenn nicht, kann es immer noch ein Hardwareproblem sein (die ADC Routine hab ich jetzt nicht im Detail angesehen. Sieht aus wie eine 1:1 Kopie der Tutorial Routine). Am Programm liegt es dann aber auf jeden Fall nicht mehr.
Karl heinz Buchegger schrieb: > Apropos: > > Wie sind eigentlich deine Widerstände genau verschaltet. Wenn keine > Taste gedrückt ist, ist sichergestellt, dass der ADC Eingang nicht > einfach in der Luft hängt und jedes dahergelaufene elektromagnetische > Feld ausmisst? Na wenigstens mal eine frage bei der ich meine schwäche zeigen muss, denn da habe ich keine Bücher (sondern nur ein Buch ;) ) drüber. Derzeit hängt der ADC in der Luft. PC0(ADC)----------------- | | | \ \ \ 560 1,2k 2,2k | | | GND GND GND Der fehler selbst muss jedoch woanders liegen, denn das einzige Problem ist wie du schon geschrieben hast, da ich zwischendurch eine Ladung habe die 'aus der Luft kommt'.
wenn es wirklich so verschaltet ist, wunder ich mich das das überhaupt geht. Ein Widerstand ohne Stromfluss erzeugt keine Spannung. Oder ist der PullUp Aktiv?
Enteroctopus Dofleini schrieb: > Der fehler selbst muss jedoch woanders liegen, denn das einzige Problem > ist wie du schon geschrieben hast, da ich zwischendurch eine Ladung habe > die 'aus der Luft kommt'. Das Problem ist, dass du da keinen Spannnungsteiler am ADC hast. Was auch immer der ADC misst, hat mit den Widerstandswerten an den Tastern herzlich wenig zu tun.
Karl heinz Buchegger schrieb: > Enteroctopus Dofleini schrieb: > >> Der fehler selbst muss jedoch woanders liegen, denn das einzige Problem >> ist wie du schon geschrieben hast, da ich zwischendurch eine Ladung habe >> die 'aus der Luft kommt'. > > Das Problem ist, dass du da keinen Spannnungsteiler am ADC hast. Was > auch immer der ADC misst, hat mit den Widerstandswerten an den Tastern > herzlich wenig zu tun. Das wundert mich seit beginn des zusammenbauens. Mit Spannungsteiler 10k an Masse kam immer schon das gleicher raus wie ohne. Ohh gott, es wird doch Zeit durchzudrehn... nachtrag: Jetzt mal ohne Witz, aber wie kann der ADC dann überhaupt auf die gleichen Werte kommen?
Lass dich von diesen Fabrikarbeitern nicht verarschen. Pullup beim ADC... lol. Du hast recht - Foren sind geschlossene Gemeinden die nur versuchen falsch zu belehren um selbst den job nicht aus Unwissenheit zu verlieren. Sei froh, das du nicht Lehrling bei dem deppen bist... Ist leider so, im bereich der Programmierung meinen die Alten doch tatsächlich mithalten zu können obwohl sie wissen das sie nicht (mehr) mitkommen. Und blos immer mal wieder noch dem Code fragen um selbst nicht ausprobieren zu müssen... Sieh nochmal in ruhe das Datenblatt vom uc an - das hilft.
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.