ADC value display on Kentec lcd using Tm4c123g launchpad.

Might this work - when reading your ADC the results will vary between 1 and 4 digits. (let's choose 3416 as your (decimal) ADC count/reading)

Now - when attempting to send that numeric data to your display - you must convert that 12 bit value into, "Decimal Ascii." That may be done by adding 0x30 to each individual ADC digit. (i.e. 3416 is sent to the display as: 0x33 - 0x34 - 0x31 - 0x36)

Note that your ADC register likely will contain a "Hex value" - which you must convert to decimal. (usually by "hex2dec" code-function)

Hello Amit,

I am trying a similar thing, but instead of using the ADC I am using a reed switch to measure rpm. I have the rpm value calculated and stored as the variable timer. I would like to display Timer on the screen, but i keep getting the value D. instead of my string "RPM:  " with the value i want displayed after it. this is my code I'm working with now. I have a function setting up the display value, and then trying to display it on a canvas. I would like to display my variable timer which has the rpm value on the screen. 

The yellow squiggle says "tContext **" is incompatible with parameter type of "const tContext"

Then this is for the canvas

The Yellow squiggle says "void(*)(uint32_t, tContext *)" cannot be used to initialize an entity type of "void(*)(tWidget, tContext *)"

Thanks,

Mike 

Hello Amit,

Yes, I think in the code above it i tried typecasting it in the one part i have commented out above. I am not sure what is going wrong i am not getting a value to display or even RPM: i only have an ascii number. Any other suggestions?

Thanks,

Michael Winter 

Michael Winter75 said:

The yellow squiggle says "tContext **" is incompatible with parameter type of "const tContext"

GrStringDraw (&sContext,string,-1,100,50,0);

That statement should be changed to remove the extraneousness ampersand:

GrStringDraw (sContext,string,-1,100,50,0);

Michael Winter75 said:

The Yellow squiggle says "void(*)(uint32_t, tContext *)" cannot be used to initialize an entity type of "void(*)(tWidget, tContext *)"

Thanks Chester, 

I fixed what you said, and I am still not able to display what i want. In my code i have listed above I have two ways of doing it. One is commented out, and the other isn't. Which one should I use? the one that i currently done have commented out how does it know that I'm trying to display "RPM: %f"? and the %f is the timer value? Also do I need any special initializations to write a string to a canvas? besides the canvas configuration i have and the function that I'm trying to pass into it? 

Thank,

Michael Winter 

Hello Amit,

I tried what you have said, and a lot with trying to get the "RPM: %.1f" for displaying the rpm as a float. I am not getting the output i like instead of seeing RPM i see an ascii value. Any suggestions as to how to fix this or a different way to display this value? 

Thanks,

Mike.

Michael Winter75 said:

I tried what you have said, and a lot with trying to get the "RPM: %.1f" for displaying the rpm as a float.

Looking at TivaWare 2.1.4.178 there is no support for floating point in the uvsnprintf() function.

You can use the sprintf() family of functions in the compiler run-time-library to format floating point values, as long as the TI ARM compiler --printf_support option is set to full:

Might we ask, "Why would "float" be required to display RPM?"  (especially as a "single" Reed switch serves as low-tech pick-up.)

You (should) note that Chester has been good enough to report that "float" is NOT supported!    (in your present usage, code situation)

Burdening the program (and helpers) w/this demand may not make great sense...

This (really) is Chester's post. (to answer)

Firm/I have produced/sold hundreds (likely thousands) of RPM tracking/reporting/displaying devices (via motor control) - and rarely (perhaps never) has a decimal point been required.

Again - Chester has been so good as to report that "float" is incompatible w/your present code implementation.    (and proves w/out (real) merit - w/single Reed switch as input source!)

KISS dictates that you employ the simplest method possible to, "Get something to (somewhat) work" - only later should your attempt target "refinement and/or perfection!"

You are noting that vendor's Graphic API "giveth" and (sometimes) "taketh away."

You've been "stuck" in this, "Failed display of RPM" for quite some time - and as this is a VERY common Display requirement - it is hard to understand how this Graphic API has so impeded your highly (predictable) display usage!    You may consider employing (your own) method of "Screen Writes" should Chester prove unable to "crack this bottleneck."   (He's quite good - I'm trying to "ease" his efforts by "killing float"..)

It would appear that if you are able to, "Place OTHER (not Live/Acquired) Text or Numerals - at the correct Screen Locations" you must (somehow) force/manipulate your, "Live Acquired, RPM Data" into agreement w/the data style/type/format which - more generally - succeeded.

Should note that as a past Display Vendor - we developed our own Graphic Code System - which (easily/immediately) enables placement of "live, acquired data" upon the "Widget-Free" (thus "Live Data Welcoming") Screen!

Michael Winter75 said:

I think it could have something to do with the setup of me trying to pass this as a function into a canvas?

- The g_sIntroduction canvas, using the OnIntroPaint function

- The g_sPrimitives canvas, using the OnPrimitivePaint function

Do those examples help?