Go Down

Topic: ReadVcc function (Read 2169 times) previous topic - next topic

Jerduino

Hi all.

I'm new to Arduino. I've been playing with the OpenEnergyMonitor project for a few weeks, now.

I might lack insight to formulate this kind of proposal, but here it is anyway. Modestly.

As the analog read is not precise enough (its reference being the Vcc that is not stable enough), some people first read Vcc with the DAC to "calibrate" it.

If you search the web, or even this forum, you'll find many references to that.

See an example here.

Implementations differ. Sometimes due to arguments about the interpretation of the Atmel spec. See here (link currently broken) or there.

As this seems to be a recurrent need, could such a function be integrated in the core package ?

Then besides analogRead(), you'd have a readVcc(). Perhaps even a way to integrate readVcc() though an analogPreciseRead() function, or a parameter ro analogRead(), whatever...

Does this make sense ?

Coding Badly


Is your theory that putting it in the core will settle the debate?  That it will give users one correct implementation?

Jerduino

Well, incidentally yes, but it is not the point.

I don't know how it is decided that a feature/function should be part of the core or a lib and what belongs to the core or to a lib. From my arduinoobness, I see the project as (more than, but including) a set of functions that come as a layer over the avr compiler, a set that is willing to grow thanks to a community of users, basically.

And when a function is recurrently used by users on different projects, it seems sensible to add it to the project (it can be a lib, perhaps I shouldn't have said the "core"). I don't know the process for this integration. A suggestion in this forum could be a first step.

This integration would help people by making available a function

  • that would be portable (some implementations you find on the web don't set the ADC registry correctly for all ATMegas)

  • that would free the developers from the need for looking in the ATMega spec for the registry descriptions

  • that would just be correct (because adding it to the project would mean finding a consensus on how it should be done, therefore settling the debate)


What you refer to as "a correct implementation".

I apologise if I'm misunderstanding the goals of the project or the processes of decision. My point was not just to have a final answer to the initial debate. I would have asked in the proper forum section. I'm happy with 1024, I think it is pretty clear in the spec, and anyway, 1204 or 1023, I don't need that kind of precision. I just figured such a function could be a candidate to integration. I mentioned the debate to underline one of the advantages of integration : unification.

I read a lot of arduino.cc already. Perhaps you can point me to a page that would instruct me about the life of the project, decision process, patch submission, etc.

Coding Badly

Perhaps you can point me to a page that would instruct me about the life of the project,


"Life of the project"?  I don't understand what you want.

Quote
decision process,


As far as I know, David Mellis makes all software decisions for Arduino / AVR.  A good starting point is the Developers List...
http://arduino.cc/mailman/listinfo/developers_arduino.cc

Quote
patch submission, etc.


A patch starts life here...
http://code.google.com/p/arduino/issues/list

To maximize the chances of it being including, fork then create a pull request here..
https://github.com/arduino/Arduino/


You can always create your own library independent of the Arduino folks.

Jerduino

Thanks. I may formulate a bug report or even a patch when I'm more accustomed to Arduino, when I know what goes where, and all.

Go Up