Hallo, Ich arbeite derzeit an einem Ladegerät mit 8 USB Ausgängen. Dieses Ladegerät wird gespeist von einem Bleiakku oder auch direkt von einer Solarzelle. Läuft die Schaltung über den Akku ist es wichtig das nur ein USB Port gleichzeitig aktiv ist. Der Akku liefert nur eine begrenzte Stromstärke. Die USB Ports werden vom Mikrocontroller via P-Kanal Mosfets gesteuert. Die Steuerung ermittelt anhand der Stromstärke wann ein abgeschlossenes Gerät voll geladen ist und wechselt dann auf einen anderen USB-Port. Deshalb verwende ich einen ADC Kanal für die Strommessung und einen anderen für die Spannungsmessung. Nun ist mir aufgefallen das er den Strom korrekt misst aber auf zu niedrige Spannung gar nicht reagiert. Selbst wenn ich den ADC Kanal auf GND ziehe schaltet er nicht ab. Der ADC läuft im "Single Conversion Mode" mit 62.5Khz. Die entsprechenden Register setze ich zu Beginn des Programmes. In den Abfrageroutinen schalte ich nur ADMUX auf den gewollten Kanal und dann ADCSRA.6 ein damit die Wandlung beginnt. Ich warte nach dem ADMUX Kanalwechsel sogar noch 10ms und schalte die Wandlung dann erst ein aber trotzdem scheint ein falscher Wert gemessen zu werden. Ich habe des Problem bisher dadurch gelöst daß ich zwei Mal konvertiere also den ersten Wert verwerfe. Nur bei anderen Chips funktioniert es auch ohne doppelt messen und ohne 10ms Pause direkt auf Anhieb richtig zu messen. Gibt es denn bei den Attiny44 eine Besonderheit weswegen das hier nicht so funktioniert? Freundliche Grüße PS: Ich kann auch bei Bedarf das Programm hochladen.
Ah gut danke ich dachte erst an Zeile 41 aber da lag ich ja völlig falsch... Ich denke meine Frage ist ja sehr allgemein und deswegen das Programm selbst irrelevant. Ich habe schon einige Programme erstellt welche gut nach dem Schema funktioniert haben. Als Beispiel habe ich den Mega328P nacheinander 6 Kanäle messen lassen, ohne Kunstpausen oder verwerfen von Messungen nach Kanalumstellung. Grüße
Hi >Ich denke meine Frage ist ja sehr allgemein und deswegen das Programm >selbst irrelevant. Aber die Schaltung nicht. MfG Spess
Das steht doch im Datenblatt drin das man nach MUX Umschalterei das erste Messergebnis verwerfen soll...
:
Bearbeitet durch User
Das es im Datenblatt steht weiß ich nur warum es bei einem Chip geht und den anderen nicht. Das finde ich eben verwunderlich. Die Schaltung ist trivial, an ADC6 ist via Spannungsteiler die Akkuspannung und an ADC7 der ACS712 für Strommessung. Wie gesagt ich dachte es gibt irgendwo im Chip einen Unterschied der das Verhalten erklären würde. Ich denke ja im 328P ist der gleiche ADC verbaut wie im Tiny44.
Malte B. schrieb: > nur warum es bei einem Chip geht und > den anderen nicht. Das finde ich eben verwunderlich. Eben DESWEGEN steht im Datenblatt das so drin. Damit so Leute wie Du sich nacher nicht wundern müssen wenn die Messwerte "komisch" sind.
@TO: Hast Du überhaupt mal gecheckt, ob plausible Wandlerwerte rauskommen? Hast Du das Programm überhaupt selbstgeschrieben? Oder nur C/P? Gruss Chregu
> ... steht im Datenblatt das so drin ...
Das Verwerfen einer Messung steht dort nur bei Umschaltung der
Referenzspannung oder bei Differenzmessung - beides kann ich aus dem
Anfangsbeitrag von Malte B. nicht herauslesen.
Das bewährte mittel bei "komischen" ADCs ist visualisieren. Egal ob seriell ausgeben und dann per Excel (lange turnaround-Zeiten) oder als Graph/Histogramm/min-max-wert/nur wert auf Display (mit Taster zum Reset-Neustart). Damit siehst Du direkt * ob Nachbarkanäle Einfluss haben * Werte zappeln oder feste "Muster" haben, z.b. die untersten 4 Bit immer 0 * ob es zeitliche Muster gibt (bursts wenn der Lötkolben an geht) * ein eingespeistes Signal von 0 bis max gut abgebildet wird
Sldt hat richtig erkannt das ich keine Referenzspannung umschalte sondern lediglich den Kanal wechsle. Nachdem ich den Kanal zweimal Messe stimmt auch alles. Wenn ich morgen Zeit habe kann ich nachmessen ob was schwingt. Aber der Logik nach ist das eigentlich überflüssig weil wenn ich den Kanal auf GND ziehe kann ja nix mehr schwingen. Und selbst da hatte er nichts gemessen. Ich poste morgen mal den originalen Quellcode vielleicht fällt da auf was ich übersehen hatte. Das Programm ist übrigens nirgends geklaut. Bin kein Fan von Copy&Paste. Grüße
:
Bearbeitet durch User
Malte B. schrieb: > Und selbst da hatte er nichts gemessen Was bedeutet "nichts"? Klar kann ein Fehler im Code sein, den hier jemand findet. Du kannst aber auch einfach eine Pause von 1s an ein paar Stellen setzen und schauen, ob es dann funktioniert, bzw. was Du jeweils ausliest.
So nun hier noch endlich das Programm... Habe es kommentiert für ein besseres Verständnis.
Björn W. schrieb: > Das steht doch im Datenblatt drin das man nach MUX Umschalterei das > erste Messergebnis verwerfen soll... Also ich kann keinerlei solche Angabe finden. Kannst Du bitte mal angeben, wo das stehen soll (Seite, Abschnitt, Zitat). Lediglich bei der Referenzumschaltung könnte es eventuell möglich sein, daß das Ergebnis fehlerbehaftet ist: "The first ADC conversion result after switching reference voltage source may be inaccurate, and the user is advised to discard this result." Ich benutze immer mehrere Eingänge und wandele reihum mit perfektem Ergebnis (MUX weiterschalten, Messung starten). Eine Ausnahme ist nur die Bandgap (1,1V), die ist so hochohmig, daß man nach der MUX-Umschaltung warten muß (Delay).
Danke Peter, eben darum dreht sich ja meine Frage. Es ist auch meine gängige Praxis Kanäle ohne Wartezeit und verwerfen durchzuschalten. Aber eben hier hat das nicht funktioniert. Deswegen dachte ich an eine Besonderheit des Chips...
Differentieller Eingang könnte auch Fehler bewirken: "Special care should be taken when changing differential channels. Once a differential channel has been selected the input stage may take a while to stabilize. It is therefore recommended to force the ADC to perform a long conversion when changing multiplexer settings." Steht ziemlich versteckt erst bei der Registerbeschreibung. Man muß aber nicht eine komplette Wandlung abwarten, ADEN löschen und setzen reicht.
:
Bearbeitet durch User
In welcher Reihenfolge liest denn BASCOM da die Register?
1 | ADC_LOW = ADCL:ADC_HIGH = ADCH |
1 | Once ADCL is read, ADC access to data registers is blocked. This means that if ADCL has been read, and a conversion completes before ADCH is read, neither register is updated, and the result from the conversion is lost. When ADCH is read, ADC access to the ADCH and ADCL registers is re-enabled. |
Edit: ne vergesst es. Sagt ja nur dass der ADC nicht mehr auf das Register schreiben kann.
:
Bearbeitet durch User
Ich kann kein BASIC - an welcher Stelle im Programm wird ADIF (ADCSRA.4) zurückgesetzt? 'Alternatively, ADIF is cleared by writing a logical one to the flag' PS: Weshalb wird nicht ausschließlich mit ADSC (ADCSRA.6) gearbeitet? 'ADSC will read as one as long as a conversion is in progress. When the conversion is complete, it returns to zero'
:
Bearbeitet durch User
Mir deucht, ADIF bleibt permanent gesetzt - und irgendwie müssen ja die 208 us der Wandlung abgewartet werden, notfalls eben mit diesen ominösen 10 ms.
Zurückgesetzt wird der beim Abfragen von ADCH... Soweit ich weiss...oder beim starten durch ADCSRA.6 Was mir zumindest logisch erscheint. Möglich wäre theoretisch auch nur mit ADCSRA.6 zu arbeiten. Interessanter Ansatz den ich demnächst mal anwenden werde. Ich habe mich bisher auf das ADIF eingeschossen weil ich meist den ADC im Freerun ausgewertet hatte. Daher wohl eher historisch gewachsen. Grüße
:
Bearbeitet durch User
> Zurückgesetzt ,,, Soweit ich weiss
Da befinden Sie sich im Irrtum - im Datenblatt nachlesen: erfolgt
implizit beim Einsprung in die ISR (damit arbeiten Sie aber nicht) oder
explizit, wie oben beschrieben.
PS:
Ich meine, was hindert Sie daran, statt der Mutmaßungen einfach mal nach
jedem 'BITWAIT ADCSRA.4,SET' ein 'ADCSRA.4=1' einzubauen und zu schauen,
was passiert?
:
Bearbeitet durch User
Im Grunde hindert mich nichts daran. Wenn ich mehr Zeit habe(vielleicht WE) probiere ich beide Ansätze aus. Also das ADCSRA.6 allein auszuwerten und auch Bit 4 manuell zu setzen. Grüße
S. L. schrieb: > Weshalb wird nicht ausschließlich mit ADSC (ADCSRA.6) gearbeitet? > 'ADSC will read as one as long as a conversion is in progress. When > the conversion is complete, it returns to zero' So macht man das typischerweise. Kennt BASCOM keine Bitnamen, daß man mit magischen Ziffern (.6) arbeiten muß?
> Wenn ich mehr Zeit habe ...
Jetzt haben Sie in Ihr Problem doch sicher bereits über eine Stunde
investiert, scheuen aber die drei Minuten, um einen Vorschlag
auszuprobieren? Da frage ich mich, warum Sie sich überhaupt an unser
Forum gewandt haben.
Ich habe es bereits getestet und mich dazu entschieden in Zukunft nur noch mit Abfrage des ADCSRA.6 zu arbeiten. Das macht mehr Sinn und vermeidet solche Fehler im vorraus. Bascom kennt auch die direkten Bitnamen der jeweiligen Peripherie. Ich benutze aber immer die Angaben mit Register und Bitnummer. Da weiß man direkt welche Stelle man anschreibt. Das war wichtig für andere Programme die mit PC kommunizieren und Register synchronisieren müssen. Vielen Dank an alle die zur Fehlersuche beigetragen haben.
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.