- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am guessing this is something simple I am overlooking, but I am unable to get the ADC to correctly read input voltage values. See the attached project. For example, my multimeter (and a back up) are reading:
ADC 0: 2.368V
ADC 2: 2.283V
The processor is computing:
ADC 0: 2.255V
ADC 2: 2.180V
Both values are about 5% different - could be a red herring.
Any ideas?
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you are using Vdda as reference: are you sure it is _exactly_ 4.68V as you have specified?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At first you should query for an _IsEndOfConversion() before you read the values from ADC.
Additionally you may calibrate the ADC by measuring and setting offset and gain.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
_IsEndOfConversion() is not needed - the SARSEQ does double buffering of results (see thr PSoC4 TRM, part 19.3.4.3).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could increase the sample average to a higher value. But using VDD has issues. You could use an extra channel and read the VDD and then use it in your equations instead of the fixed value of 4.68. I would use the internal voltage reference of the ADC and use a voltage divider to make sure you don't over range you readings for each channel.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you want to measure Vdd, and have Vdd as reference at the same time, use the ADC to measure a reference voltage instead. Unfortunately that doesn't work in the PSoC4 since the internal reference is not accessible 😞
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your reference is Vdda, which is typically a low accuracy LDO or regulator
output. Use your multimeter to measure Vdda, then scale by the inaccuracy
(gain error) you find the SAR readings. If you need more accuracy use the internal refer-
ence and R dividers (precision) on inputs to get the CM range you want for
the input.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you all for your input. Since this is not a high precision application, I am going to use the multimeter scaling method. It seems to be working reasonably well.
Anyone have a good work around for sprintf()? I am running out of memory with it, and am trying to write float data to an SD card with two decimal points precision.
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you running out of heap memeory or out of flash memory? The first one can be increased in the design-wide resources. For the latter one you need to find something else to spare...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At top of this page put "PSoC4 sprintf" into the Keyword Search field. Take care that you use Creator 3.1.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have looked around, and there is not much for floats. I guess I could break it down into integers and print each of those and recombine with a '.'.
One more quesiton - I have sprintf() working...at least compiling, but it does not produce a string. The code is:
sprintf(curSolStr,"%0.2f \r\n",currentSolar);
The '/r/n' are showing up in the char array curSolStr, but not the value 'currentSolar' which is '0.246'. Any thoughts?
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately the non-nano library is way too large. I enabled the -u _printf_float option, and it still overflows. Deleting the SD card allowed it to process, but I sort of need that for this application...
Unless anyone has any other floating point operations, I will have to wait for the new M processor for sprintf() and use tiny print splitting the integer and fraction and recombining them.
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
printf requires to increase the heap size. With Creatior 3.1 the default is just 128 bytes which is way too low. Set it to something 0x400 (in the design-wide resources)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to increase heap size to no avail. See attached. It seems like the functions that are running me out of memory are the SD card functions.
I have come up with a clunkier version that works using tinyprintf, but if I could get sprintf to work, I would. Like I said, the PSOC Mwill be great for this.
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you set the project build from "Debug" to "Release" having a much stronger optimization level? Debugging is barely possible with that setting, but if that works I can help you further...
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It worked! However, now I have the other version working fine using much less memory and debuggable, so I will probably use that for my data logger for now.
Thanks for all the help, once again, I walked away slightly more knowledgeable.
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a (bit time-consuming) way to get all you want: By right-clicking on a generated C-file you may select "Build Settings" from which you can now select for this file the "Release" compile. This will reduce flash usage for all the files you do not need to debug.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tom, would you mind posting your "final" working project. I have a
son that wants to put a data logger on his Motot Guzzi bike to optimize
tuning, and it would be handy if I do not have to re-invent the wheel.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
See the project attached below. It is full of quesitonable code, I am sure, but it works great, and I just got my results off of the SD card and are working with them in an Excel spreadsheet right now. The project currently measures some data for a solar powered lighting project I am working on, but it will be nice to have a custom data logger on hand for future projects.
Thank you,
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The internal reference can be brought out for other uses on the ADC. You just need to select internal reference 1.024V bypassed and I would add a op amp buffer to prevent loading of the reference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But even then its available only on the external pin, not for internal routing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you abandon Vdda as Vref then of course you will need external
R dividers to handle the higher Vxin you want to measure. But
you would gain a net higher accuracy by using the internal Vref and
precision thin film Rdivider.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intdernal reference -
Its 2 %, maybe use an accurate external Vref to power Vdd and eliminate R dividers on
input pins. 2% is ~ 6 bits, food for thought. Or use ext ref directly on SAR.
Regards, Dana.