Fall time seems like a good time to focus on cleaning out clutter, doesn’t it? 😄 Well, while doing that I found a box of used AA batteries from Halloween string lights. I really didn’t want to get rid of them because they might have enough life left for a mouse, a keyboard, or the many remotes around the house.
Since my basement is cluttered (polite term for it), naturally I can’t put my fingers on where I placed my old DVM to measure the battery voltage. In the box where I thought I placed the old DVM, I found a PSoC 63 CY8CPROTO-063-BLE proto board.
Hmm…I guess I could always make a new DVM. Sounds like something an engineer might do. It’s a purpose driven life, right? 😉
This low-cost prototype board features the Infineon AIROC CYBLE-416045-02 certified EZ-BLE Creator module based on CY8C6347BZI-BLD53 MCU silicon. I see in the module datasheet, a 12-bit 1 Msps SAR ADC is available that I can use to measure the AA battery voltage. I know what to do with the 12-bit voltage DAC later.
It’s easy to start and finish my new DVM design using ModusToolbox 3.0. It has many configuration tools and plenty of code examples. I will be able to measure my AA batteries quicker than I can find my old DVM in my basement! Actually…much quicker.
After downloading, installing, and launching ModusToolbox 3.0, I start a “New Application” within the Quick Panel to launch the Project Creator tool and pick the CY8CPROTO-063-BLE Board Support Package (BSP.)
The CY8CPROTO-063-BLE documentation in the Quick Panel will help me understand the hardware configuration for the board.
I have a long list of example applications to choose from. The “ADC_basic” application description states, “this example demonstrates use of the ADC (Analog to Digital Converter) HAL driver to perform voltage measurements.” Yep, this is what I need to measure AA batteries. Having an example code will get me to the finish line faster. I will change the default application name to ‘myDVM’ and create my firmware.
Like on my misplaced DVM, I will need a method to display the measured battery voltage. By default, the example code configures one ADC channel in single ended mode and prints the conversion result through the debug UART for viewing on a terminal program using cy_retarget_io_init API found in main.c, line 205.
ADCs need a voltage reference (Vref) and I see on line 145, main.c, the ADC Vref is configured to VDDA through the CYHAL_ADC_REF_VDDA define in the cyhal_adc_config_t structure.
What is VDDA set to?
The Quick Panel BSP documentation tells me VDDA on the proto board is set to 3.3V.
This can be verified on the CY8CPROTO-063-BLE schematic found on Infineon’s website.
Measuring a 1.5V AA battery within a 0 to 3.3V range does not provide the accuracy an **bleep**-retentive engineer, like me, desires. But, since Vref is wired to VDDA, I can’t make a hardware change. Hmmm…
Combing through the HAL documentation at the Quick Panel link, I see that I have an option to divide the ADC VDDA Vref by two. 3.3V/2 = 1.65V provides a tight range perfect for a 1.5V battery.
At line 145 in main.c, I’ll change “CYHAL_ADC_REF_VDDA” to “CYHAL_ADC_REF_VDDA_DIV_2”.
I need to solder a couple of lengths of wire on the prototype board to function as probes:
After connecting the prototype board to the PC and going through USB enumeration, I found the COM port. I use CoolTerm for my terminal program and configure the COM port for:
All set to build and program the proto board using the ‘myDVM Program (KitProg3_MiniProg4)’ launch option found under the Quick Panel ‘Launches’ heading.
Once done, you will see the terminal update with the message on line 217, main.c (see below.)
Time to test
While connecting my AA battery to myDVM probes, I remember Woody’s quote from Toy Story when the toys were placing the batteries back into RC’s remote-control unit, “PLUS IS POSITIVE! MINUS IS NEGATIVE!” Sorry, I love that movie…Now, I can see the first AA battery I picked out of the box looks good enough to use again. On to the next battery…
What about the DAC I mentioned earlier? – you will find out in Part 2 of this blog series.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
By technically required cookies we mean cookies without those the technical provision of the online service cannot be ensured. These include e.g. cookies supporting essential services like a smooth reproduction of video or audio footage. So called ‘functional cookies’ are also assigned belonging to this category. Functional cookies store information in order to provide you comfortable use of our online services (e.g. language selection). The legal basis for the processing of personal data by means of cookies of this category is Infineon’s legitimate interest. This includes, among other things, the interest in having a professional external presentation as well as an optimal balancing of the loads on the server due to technical reasons.
By performance and marketing cookies we mean cookies which are technically not required. We use performance and marketing cookies only if you have given us your prior consent. With such cookies, we collect information about how users interact with our website and which pages have been visited. This helps us to understand user activity on our website on an aggregated as well as on a personal level to provide you relevant content and services.