ADC-Kanäle sukzessive abfragen

[Veit D. (devil-elec)]

StefanK schrieb:
> Veit D. schrieb:
>> StefanK schrieb:
>>> @Veit D.
>
>> Ein bool Datentyp hat immer die kleinste Byte Größe. Beim 8Bit AVR 1
>> Byte. Lasse dir auf deiner Zielplattform von allen Datentypen die Größe
>> mittels sizeof() ausgeben. bool kann nur Werte von true/false annehmen.
>> Das ist die Eigenschaft des Datentyps.
>
> Dann bedeutet das, dass mehrere bools in so einer Struct nicht in ein
> Byte gepackt werden?

Nein.

> D.h. man muß sich ein Byte anlegen, dieses als
> Bit-Basis verwenden und auf seine bits einzeln zugreifen, wenn man nicht
> für jedes bool ein ganzes Byte spendieren will.

Du kannst bei Bedarf mit Bitfelder rumspielen.
https://en.cppreference.com/w/cpp/language/bit_field.html

[StefanK (stefanka)]

Dergute W. schrieb:
> Moin,
>
> StefanK schrieb:
>> was
>> hätten denn mehr Details zu Anfang Ihrer Meinung nach daran geändert,
>> die Methode zu finden, wie man am schnellsten ohne im Hauptprogramm zu
>> warten mehrere ADC-Kanäle mißt?
>
> Dann waere z.b. mir voellig klar gewesen, dass das mit dem "am
> schnellsten" natuerlich Quatsch ist.

Ja, das wäre wohl so gekommen und wir hätten Ihre Ideen verloren, wenn 
Sie sich aus der Diskussion verabschiedet hätten. Das finde ich eben 
schade.

@Rainer W. (rawi)
>Möchtest du die Flügelschläge einzelner überfliegender Insekten
>ausregeln oder warum so schnell?

Das vielleicht nicht gerade, es gibt ja auch immer weniger Insekten ;-)
Es gibt von Microchip eine interessante Application Note dazu. Sie 
verwenden natürlich einen PIC. Der mißt 4 Kanäle * 4 Messungen und 
Mittelwert mit 1000Hz (wir schaffen immerhin 600Hz mit Atmega328/ATtiny 
bei 16MHz Systemtakt). Die 1000 Datensätze pro Sekunde gehen in einen 
PI-Regler, der den MPP 40 mal pro Sekunde anpasst.
Bei allen MPP-Suchalgorithmen von P&O, Hill-Climbing über Incremental 
Condutance bis hin zu Fire Flies etc. steigt der MPP-Wirkungsgrad, also 
den richtigen Punkt zu finden und zu halten mit der Frequenz. Daher ist 
es gut schnell zu sein.

[Dergute W. (derguteweka)]

Moin,

StefanK schrieb:
> Ja, das wäre wohl so gekommen und wir hätten Ihre Ideen verloren, wenn
> Sie sich aus der Diskussion verabschiedet hätten. Das finde ich eben
> schade.

Bullshit.
Wenn du gleich am Anfang auch noch erwaehnt haettest, dass du ja auch 
noch einen UART brauchst, den aber mangels Vorhandensein in HW unbedingt 
in SW machen musst, dann waere ziemlich sicher nicht nur bei mir die 
Idee aufgekommen, eben den zeitkritischen Teil des UARTs im 
Timerinterrupt zu machen und dann eher so "nebenbei" den ollen ADC zu 
triggern und dessen Eingang umzuschalten.
Und nich ewig rumzukaspern ob der ADC jetzt 13.5 oder 14.3 Takte 
braucht...
Und wenn du dann auch noch erwaehnt haettest, dass dein Wissen von 
seriellen Protokollen in C auch noch durchaus Potential nach oben hat...
Naja, waere sicherlich schneller gegangen, da was wirklich halbwegs 
durchdachtes fuer's Gesamtproblem vorzuschlagen, kann mir ja aber eher 
auch wurscht sein :-)

Gruss
WK

[Rainer W. (rawi)]

StefanK schrieb:
> Es gibt von Microchip eine interessante Application Note dazu.

AN????

> Sie verwenden natürlich einen PIC
Dann muss die Application Note schon älter sein. Inzwischen kommen auch 
die AVR von Microchip.

[Torsten B. (butterbrotstern)]

https://ww1.microchip.com/downloads/en/appnotes/00001521a.pdf
https://ww1.microchip.com/downloads/en/Appnotes/00002321A.pdf
https://ww1.microchip.com/downloads/en/appnotes/pv_appnotes.pdf
https://www.microchip.com/content/dam/mchp/documents/OTH/ApplicationNotes/ApplicationNotes/01444A.pdf

[Mi N. (msx)]

StefanK schrieb:
> kleinen MPPT-Solarladereglers

... mit ATtiny13.
Ist das nur total blöd oder schon krank?