• State Resolved
  • Locked Locked
  • Replies 42 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 4867 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294KCPDT: Floating point unit rounding decimal point to nearest 1's place.

Genatco
Guru 55913 points
Part Number: TM4C1294KCPDT

Build project has floating point support  FPv4SPD16 enabled. Integer math adding two decimal numbers divided 100 divided by 3.5 will not produce digits below 1, instead the answer is being round off to nearest 1's value. So setting an exact match count into a timer reflective of a temperature measurement producing digits below ones place are being neglected. That makes for a choppy timer operation where (accurate) temperatures are being measured by ADC producing digits below ones place, also used to control the speed of a fan motor for example.

Example: Int32value=(373 + 373 /100/3.5) or Int32value = 2.1314285714285714285714285714286 yet CCS debug variable show 2 as the answer but not a rounded decimal integer such as 2.13  

Have I missed something of how FPU unit is supposed to allow adding decimal positions below ones place and not simply round them off to nearest 1's place?

  • 0
    Guru 117855 points

    BP101 said:
    decimal integer such as 2.13 

    Might your "idea" of the meaning of,  "integer"  require review?        Your  unique, "creation" of  "decimal integer,  2.13 in value"...  what to say?

    I'm on a "heavy-diet" - yet that  "jumbo shrimp" - appears a "definite-possibility!"   ...     (3 (more) oxymoron illustrations arrive - yet none match the horror - of poster's, "decimal integer, 2.13 in value.")

  • 0
    TI__Guru*** 135355 points
    Hello BP101,

    Is the concern here with the TM4C FPU, or with the CCS FPv4SPD16 support?

    If you believe the issue is with TM4C FPU, can you provide code snippets for the relevant FPU portions as well as the variable declarations and the code where the arithmetic fails?
  • 0 in reply to cb1_mobile
    Guru 55913 points

    Rather why the floating point math upon integers 1 place is not revealed until divided by 50 or 100. That goes the same for printed strings where the 1's place in an signed integer is counting 0-9 then added to the 10's place as it rolls back to 0. Signed integers are especially important for temperature sensors that may range from -40*C to 150*C. Oddly we only see digital temperature floating decimal point displayed after pre-processing the list box integers value, dividing it by 10. That is how it seems as if the FP unit of MCU is working since integer can display as a range 99.9 to 100.0 or as string value 999 - 1000 without the decimal point, e.g. 375 rolling is actually 37.5,6,7,8,9 ->38.0. or 380.

    Maybe it has more to do with FP units claim of single precision what ever that means. Perhaps even CCS debugs variable display has an inability to properly show decimal values. After seeing compiled lines of object code missing in the disassembler view (linked to source output) debug would not move to source code line stating no sources was found. Funny thing is message was right there was no subroutine in the disassembled function, but it did exist.

  • 0 in reply to Genatco
    TI__Guru*** 135355 points
    Hi BP101,

    I clearly missed something in your first post. I see the misunderstanding now.

    Integer
    noun
    1. a whole number; a number that is not a fraction.

    Wouldn't that explain it all?

    Use float as the variable type to get decimal values.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points

    I think the FPU is working as the decimal point is added after division of the integer and moves left inside display list box but is not being displayed in CCS debug variable view as being stated in the binary IEEE info below. Same goes for debug GPTM match count register view, displayed as decimal value there are only whole numbers shown.

    3.1.5 Floating-Point Unit (FPU)

    This section describes the Floating-Point Unit (FPU) and the registers it uses. The FPU provides:

    ■ 32-bit instructions for single-precision (C float) data-processing operations

    ■ Combined multiply and accumulate instructions for increased precision (Fused MAC)

    ■ Hardware support for conversion, addition, subtraction, multiplication with optional accumulate,

    division, and square-root

    ■ Hardware support for denormals and all IEEE rounding modes

    ■ 32 dedicated 32-bit single-precision registers, also addressable as 16 double-word registers

    ■ Decoupled three stage pipeline

    The Cortex-M4F FPU fully supports single-precision add, subtract, multiply, divide, multiply and accumulate, and square root operations. It also provides conversions between fixed-point and floating-point data formats, and floating-point constant instructions. The FPU provides floating-point computation functionality that is compliant with the ANSI/IEEE Std 754-2008, IEEE Standard for Binary Floating-Point Arithmetic, referred to as the IEEE 754 standard. The FPU's single-precision extension registers can also be accessed as 16 doubleword registers for load, store, and move operations.

  • 0 in reply to Ralph Jacobi
    Guru 55913 points
    Yet float type is not part of (stdint.h) where all integer (type/s) ranges are listed but did try float yesterday, will it try again now that the function is actually working with the sensors.
  • 0 in reply to Genatco
    TI__Guru*** 135355 points
    Hello BP101,

    Correct, float is not in stdint.h.

    stdint --> standard (std) integer (int) --> no decimal-capable variables such as float to be found there, only whole number capable variables.
  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    debug GPTM match count register view, displayed as decimal value there are only whole numbers shown.

    Do you expect to view "Non-Integer" numbers w/in GPTM?      Has your "understanding" of  INTEGER  increased?      (i.e.  your earlier "decimal integer" ... does NOT compute.)

  • 0 in reply to cb1_mobile
    Guru 55913 points
    Oddly the float type integer placed into GPTM Match register would only load by single stepping but it did load value 2.15. Sadly the IOT conversion of same decimal number into a short was mangled in the string output as a very long number.
  • 0 in reply to Genatco
    Guru 55913 points
    Most times debug GPTM value reading of Match register displayed as 65536. Perhaps there may be limitations as to what can be done with floating point numbers. Yet CCS debug variable view of (float) data type did then indicate a decimal point.
  • 0 in reply to cb1_mobile
    Guru 55913 points
    FYI: Decimal point conversion was for GPTM CCP0 edge event interrupts for PWM duty cycle updates, an attempt to refine the match step relative to a temperature reading below the 1's place value. Now the duty cycle changes seems to follow the temperatures 10's place value, not even the 1's.
  • 0
    Prodigy 250 points

    I nominate this discussion for consideration for the best post of the year.

  • 0 in reply to Ralph Jacobi
    Guru 55913 points

    Ralph Jacobi said:
    Use float as the variable type to get decimal values.

    You mean like this; float 4 bytes 3.4E +/-38(7digits)? That didn't work so well but it seems the FP unit is having some effect on the divisionary math formula.

    Yet the integer value (int32_t) changes f printed in the string output incremented temperature change counts via 1's position thus making it appear as a decimal value with floating point precision especially as it rolled from 999 to 1000 without a decimal point.

    However the match count being loaded into the GPTM was not reacting but only to the 10's position during CCP0 positive edge interrupt events for match count updates of the timers PWM duty cycle changes. CCP0 interrupt handler so very basic uses (>=) to compare each value of all temperature sensors relative to PWM duty cycle changes. Fun to hear results of the two (if) tests battle for the smallest match value as the temperature of each sensor start to cross match in the 1's place holder position. That is the only time the GPTM match value becomes aware of digits below 10's position, never on the integers rise, only on the fall.

    The idea here is we don't allow any sensor to take priority of fan speed (PWM match count), simply adding sensor read values together could end in disaster. Individual sensor handling become key in the way the single GPTM match count is being loaded.

     	       /* Calculate the low and high side MOSFET temperature values.
 	        * The match count GPTM0A determines the PWM duty cycle produced.
 	        ***********************************************************************/
	        int32PWMDutyUpdateLow =  ((int32MOSTempValueLow / 50) / 3);
	        int32PWMDutyUpdateHigh = ((int32MOSTempValueHigh / 50) / 3);

            /* Check if Low MOSFET temperature sensor is above high side.
             * ADC sample data (-40*C - 150*C) proportionately controls fan speed.
             * Divide N12=100% duty cycle (4800/2-12) where N(6)=50% fan speed.
             **********************************************************************/
	        if(int32PWMDutyUpdateLow >= int32PWMDutyUpdateHigh)
	        {
                /* Update Timer-0A match value with the new PWM duty cycle
                 * based on edges received from PWM interrupt. */
                HWREG(TIMER0_BASE + TIMER_O_TAMATCHR) = (int32FanDutyCycle / int32PWMDutyUpdateLow);
	        }
            /* Check if the high MOSFET temperature sensor is above low side,
             * ADC sample data (-40*C - 150*C) proportionately controls fan speed.
             * Divide N12=100% duty cycle (4800/2-12) where N(6)=50% fan speed.
             **********************************************************************/
	        else if (int32PWMDutyUpdateHigh >= int32PWMDutyUpdateLow)
	        {
                /* Update Timer-0A match value with the new PWM duty cycle
                 * based on edges received from PWM interrupt. */
                 HWREG(TIMER0_BASE + TIMER_O_TAMATCHR) = (int32FanDutyCycle / int32PWMDutyUpdateHigh);
	        }

  • 0 in reply to millwood
    Guru 117855 points

    millwood said:
    I nominate this discussion for consideration for the  best post of the year.

    Does such "nomination" flow from your (very) careful handling/processing of the (newly created) "decimal-integer?"

    Such seems (cannot help myself) a  "definite-possibility."     (that's now  5 "om" (4 deliberate) - single thread ... clear  "HOF" candidate...)

  • 0 in reply to cb1_mobile
    Guru 55913 points
    Perhaps a bit harsh since binary integers represent real numbers in the real world as digits with decimal point (place holders) being add by the MCU FP unit, regardless of (float) syntax naming the binary integer. If that was not true then dividing an integer by 10 would not produce a decimal point before the integers 1's position decimal point place holder, yet it does.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points

    Ralph Jacobi said:
    Is the concern here with the TM4C FPU, or with the CCS FPv4SPD16 support?

    Perhaps FPv4SPD16 project (default) albeit other types of FP support are listed in the drop down selection box. I don't know enough about FP standards upon all MCU math calculations whether (float) type is added or not to know which standard may help refine simple integer match counts.

    Yet I can report symptoms resulting in the operation of FP unit upon division of binary values inserted into GPTM peripheral match count register to more knowledgeable persons. 

  • 0 in reply to Genatco
    Guru 117855 points

    It appears that you launched this thread in the hope of achieving,  "Finer Control" (i.e. likely improving granularity) of your "Individual Timer's PWM (mode) output."      And - to achieve such - you attempted to employ the M4's floating point capability.     (And introduced new/expanded (yet unrecognized) definition of,  "Integer.")

    Is it possible that your objective of,  "finer PWM Control" -  may indeed be achieved - w/out requiring:

    • any use of floating point
    • tortured redefinition of the word "integer"    (it is "no sin" to have not known  - might the (apparent) attempt to mask that fact - disturb?)

    Let's review basic Timer operation & capability:

    The chart above reveals that when placed w/in PWM Mode - your "Individual timer" supplies 16-bit count capacity - plus an additional 8-bit - prescale capacity.      Should that WIDE capacity NOT provide,  "All the fine control/granularity" - one could require?   

    Is it not (more than) likely - that your "math efforts" - for instance any required (intermediate/final) result "scaling" - proved limited (or mistaken) - and thus there existed,  "No REAL requirement to deploy Floating Point?"     I'd place a "tall chip-stack" on a Vegas table - to place that bet.

    Had you revealed the key elements of your code - which describe how you perform temperature measurement - and (properly drive your fan(s)) - those here would have - almost surely - been able to suggest "NON Floating Point Methods" - to (even) better achieve your goals.

    And note too - your Control Code (as shown, w/in 24 Mar, 08:55 post ,above) merely compares, "Hi-Side FET temp vs. Lo-Side FET temp" - apparently with NO CONSIDERATION to (any) OVER-TEMPERATURE Recognition!     Such cannot be right - can it?

  • 0 in reply to Genatco
    Genius 3850 points

    " If that was not true then dividing an integer by 10 would not produce a decimal point before the integers 1's position decimal point place holder, yet it does."

    if you had used quadruple negatives, you could have gotten more people to understand you better.

    I think an integer that can hold fractions is a new data type yet to be invented. 

  • 0 in reply to cb1_mobile
    Guru 55913 points

    Might it be the GPTM counter is processing in decade base 10 mode and incapable to match the timer load value to that of the FP units division that created the binary decimal 1's position.

    The FP units math result (answer) in not an integer by definition after the FP coprocessor divides the original integer value. The integer after FP unit divide conversion morphs as a decimal representation of the original integer having binary weights in the 1's position. The FP unit obviously don't need to see a type (float) syntax order to process integer division, being the math coprocessor of the CPU it provides math equations results for the CPU to use.

    Seeming the GPTM is a decade counter can not load a (match count) with single point binary precision or load any binary match value other than a whole number, especially after FP integer conversion. The GPTM ignores the FP units single precision divide values and reacts only to integers 10's position during match load updates.

    Scaling is only necessary to extend GPTM counts from 12 bits up to 24 bits when very high numbers must be processed in excess of a 12 bit binary value (0xFFF). Scaling would infer higher frequency in excess of 25kHz, e.g. GPTM with 120Mhz SYSCLK time base and (0xFFF) load value would produce a frequency of 29.304khz.

    Point is the GPTM seemingly is not cable to match any FP integers in the 1's position relative to match count updates loaded on the next cycle, It won't load them!

  • 0 in reply to Danny F
    Guru 55913 points
    Perhaps you are unaware that sarcasm has no place on the internet?

    First of all the FP unit division is producing an integer with floating point 1's position regardless of a decimal point being visibly present. The FP unit is creating a fraction by act of division so it is no longer an integer by the definition being toss around.

    Again the display text box pre-processor division produces a decimal point to left of 1's position but the digits inside the value remain the same, no difference with or without a decimal point. That substantiates the 1's position in the value is the result of a floating point math operation upon the integer.

    That said a fraction can exists within a (FP unit processed) integer (type int32_t) and is not imaginary but only to the programmer unaware the FP unit has quantified his math formula into a binary single point number value.
  • 0 in reply to Genatco
    Guru 117855 points
    It REMAINS ... CERTAIN - that the 24-bit, PWM Capacity (under Timer Mode) should be "MORE THAN CAPABLE" to enable EXACTING CONTROL - and avoid the "challenge" and extra MCU Resources - induced via Floating Point.

    You are "silent" w.r.t. your code revealing the REQUIRED, "Test for Over-Heating" - your code (simply) tests for "Hi-Side vs Lo-Side" Temperature - which is GROSSLY INSUFFICIENT!
  • 0 in reply to Genatco
    TI__Guru*** 135355 points

    Hello BP101,

    BP101 said:
    Perhaps a bit harsh since binary integers represent real numbers in the real world as digits with decimal point (place holders) being add by the MCU FP unit, regardless of (float) syntax naming the binary integer. If that was not true then dividing an integer by 10 would not produce a decimal point before the integers 1's position decimal point place holder, yet it does.

    But such representation is thrown away the moment the variable is converted to a type that doesn't support decimal points, plus would you really want to figure out how to decode the binary encoding for the decimal values just to avoid needing to use float variable? Your MCU has more than enough space...
    BP101 said:

    The FP unit obviously don't need to see a type (float) syntax order to process integer division, being the math coprocessor of the CPU it provides math equations results for the CPU to use.

    Well, technically no, but it'd be a waste to use the FPU if the result will be stored in an INT. No difference to just typing x = y/z at that point and call it a day. The results will be equal due to truncation of the decimal points.

    BP101 said:

    Might it be the GPTM counter is processing in decade base 10 mode and incapable to match the timer load value to that of the FP units division that created the binary decimal 1's position.

    Seeming the GPTM is a decade counter can not load a (match count) with single point binary precision or load any binary match value other than a whole number, especially after FP integer conversion. The GPTM ignores the FP units single precision divide values and reacts only to integers 10's position during match load updates.

    Scaling is only necessary to extend GPTM counts from 12 bits up to 24 bits when very high numbers must be processed in excess of a 12 bit binary value (0xFFF). Scaling would infer higher frequency in excess of 25kHz, e.g. GPTM with 120Mhz SYSCLK time base and (0xFFF) load value would produce a frequency of 29.304khz.

    Point is the GPTM seemingly is not cable to match any FP integers in the 1's position relative to match count updates loaded on the next cycle, It won't load them!

    I think the issue here may be the translation of a floating point number to something usable for the GPTM.

    • Step 1: Use FPU functions w/ 'float' defined variables to calculate your answer to desired precision.
    • Step 2: Convert Float number to some form Integer using type casting, which will truncate the decimal places away without assessing it at all. If you wish for the result to be rounded up when applicable, then you need to manually do that before type casting.
    • Step 3: Load integer value into Timer Module.

    If the steps aren't followed in that order, you are likely losing data somewhere along the line.

    If you are still trying to use this non-existent 'Floating Point Integer' of yours, then you are probably missing at least one of the above steps, thus causing your issues.

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Ralph Jacobi said:
    If you are still trying to use this non-existent 'Floating Point Integer' of  yours

    So good to see Vendor Agents now ADDING to the rejection of poster's "Self-Created/Wildly Improper" term!

    Follows a "true copy of thread's "opening post"  ...  "rounded decimal integer such as 2.13." 

    Might this be banned - as well?    (as it (may) confuse those  "very beginners" - landing here.)

    The understanding of the definition of "INTEGER" remains unclear - at least to "one" - here!     This in spite of the fact that you identified poster's improper usage - earlier!

    It is good that you have "re-confirmed" several "outsiders" - earlier noting - the grave "misuse" of a "very standard term!"

    And as clearly stated - simple INTEGER Arithmetic - would easily solve poster's requirement - (as presented - there IS a 24-bit Timer Register capacity) - when in PWM Mode!     The whole "failed venture" into Floating Point - proved  ill-considered & UNNECESSARY!

  • 0 in reply to Ralph Jacobi
    Guru 55913 points

    Ralph Jacobi said:
    If you are still trying to use this non-existent 'Floating Point Integer' of yours, then you are probably missing at least one of the above steps, thus causing your issues

    Perhaps it is not true floating point decimal value after FPU simply divides the value yet it then has a definite floating (place holder) that represents where the decimal point would be if it indeed had one.  That seems more an issue with CCS compiler not knowing the difference when the FPU takes over with integers of type cast float. Besides the GPTM not having single point precision can not act upon the decimal values 1's position being loaded in the match counts of the type cast floating point showing in CCS debug or not. Debug variable view will show decimal point in a type cast float but the GPTM can not process it. 

    Like I said the GPTM is behaving like a decade counter for MATCH count loads of decimal values, changes in the 1's position do not produce any matched down counts or duty cycle changes, errata?  The FPU concatenated divided binary or decimal value shown in CCS debug variable view has a floating decimal place holder added to the left of the 1's position, even when there is no decimal point showing. The counter take the new load (decimal) value and counts down incrementally yet very fast. Very difficult to verify matches produce PWM duty changes but we can here the duty change in very distinct steps of fans speed relative follow matching temperature changes but only in the 10's position, acting like a base 10 decade counter.

    Again we can see the results of floating point integers in the output produced via Printf() and CCS debug variable view indicates the same. So to say floating point binary integers don't exist is simply wrong just because you can't see a decimal point. Perhaps the FPU math coprocessor is more complex than some like to give credit.

  • 0 in reply to cb1_mobile
    Guru 55913 points
    I don't think you are grasping that the integer being input to the FPU is no longer by definition (Only an integer) after the FPU modifies the binary data. The FPU output binary data has floating point precision after any divide operation occurs, there by definition is no longer classified being a simple integer. The value is a binary representation of a decimal integer, technically any number from 0-9 is both an integer and a decimal number.

    If you don't like that tell it to several of DOE paid algebra teachers or they shouldn't teach in math classes a decimal number is also an integer. Just because Borland decided to place a range on the word integer going beyond (0-9) it does not own the first meaning and is not improper to call a decimal number an integer.
  • 0 in reply to Genatco
    Guru 55913 points

    And as clearly stated - simple INTEGER Arithmetic - would easily solve poster's requirement - (as presented - there IS a 24-bit Timer Register capacity) - when in PWM Mode! The whole "failed venture" into Floating Point - proved ill-considered & UNNECESSARY!

    Better check 24bit math twice as 25Khz PWM frequency can not be represented by 24 bit load count values with 120Mhz SYCLK time base. You must have ignored the math posted above? We only need to use 24 bits register for very large counts in very high frequency generation. Do you think I too have that wrong and 25Khz can be represented by such high counts?

    The point is we can only get a very limited number of duty cycle changes relative to the sensors divided variable analog range and maintain 25Khz frequency at all fan speeds. The temperature sensors ADC data has to both produce digital readouts without a long string of numbers, post same digital readout into the IOT cloud and control fan speed steps relative to sensor constraints protecting MOSFET devices. That's a lot of factoring yet it works fairly well 12 10 fan speeds but it should be 100 if the GPTM could honor the 1's position of the decimal value representing the binary integer loaded as a new matching down count. It might simply be the interrupts occurring on positive CC0 edge events of 25Khz PWM frequency updates of duty cycle are not fast enough to capture the 1's position and both edges events triggered interrupts might produce 24 20 speeds.

  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    they shouldn't teach in math classes a decimal number is also an integer.

    Those who cannot, (or will not) "Admit their mistake" are unlikely to benefit from the (proper & informed) input from others.

    It was expected that after the early advisement that your (creation) of  "Decimal Integer" was improper - you'd "Recheck your facts."

    Your attempt to, "Redefine INTEGER" - by introducing the "smokescreen" of the MCU - in no way MASKS your failed understanding of the word!     Pity!

    Three here - to include the vendor agent (twice) - have taken the time/effort to, "Correct your Misunderstanding."

  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    Better check 24bit math twice as 25Khz PWM frequency can not be represented by 24 bit load count values with 120Mhz SYCLK

    And - have you made ANY CASE - at all - for the requirement of a 25KHz PWM?      You are controlling Fan Speed - not a "Space-X" launch.    @ 120MHz you can "FILL" 24 bits SEVEN TIMES w/in ONE SECOND.   (the period is 140mS)    And - it is NOT that one has to use the entire 24 bits - yet it IS THERE (unlike the existence of "Decimal-Integer") and may be exploited - as/if needed...

    Is it not true that ANY math check should (FIRST) include the "Definition of INTEGER?"

  • 0 in reply to Genatco
    TI__Guru*** 135355 points
    Hello BP101,

    If you think there is an issue with the GPTM module, then please open a thread for that topic specifically as it is far different than the FP vs integer debate ongoing here.
  • 0 in reply to Ralph Jacobi
    Guru 55913 points

    Actually believe they are one and the same topic since it seems the GPTM can not properly match counts from the decimal values 1's position being calculated by the FPU. That value is derived from ADC samples that were divided and filtered too by the FPU. That was the entire point of the Post not that the FPU is not specifically working, rather the results for the FPU don't seem work in the GPTM and later finding in this post "No matter how the FPU processes the decimal point positions or adds place holders." 

    I have tried to iterate several times the GPTM is only matching load counts for 10's & 100's decimal position but not the 1's no mater how the FPU is queried for division. That GPTM behavior seems more like decade counter (base 10) to me having spent many hours with chaining several together and de-multiplexing the counts.

    Don't have any more time to debate this FPU issue and the GPTM works with 10 speed steps being ok for now.

  • 0 in reply to cb1_mobile
    Guru 55913 points
    You must have missed 25Khz several times and posts back or have not ever had to control digital fan speed via PWM. Again scaling the GPTM to 24 bits unequivocally will not work to produce 25kHz from CCP0 PWM and requires 40us period to generate 25Khz wave shape at all times. The fan speed is controlled by interrupted updates to the match count load value to control the PWM duty cycle around 25Khz.

    Fail to see how 140ms can keep the frequency constant perhaps you can show us this math or give up on the scale idea. Believe when I say the GPTM ain't matching duty cycle to the 1's digit position no matter the FPU value produce as a match count load.

    Would it not seem odd GPTM only loads match counts (above posted code) that fall on a temperatures 10's position (*C), e.g. 310,320,330,340 etc. but not 311,312,313,314 nor 321- 329, 331-339, 341-349 yet 350 is valid so is 360,370,380,1000 these are not 24 bit integers or decimal values. Those value above (decimal point) added are actually 31.1, 31.2, 31.3 etc. and by dividing integer representing a decimal value in a text box, e.g. value (311/10) gives us 31.1*C as the digital readout. In the real world that is a decimal value produced by an binary integer passing through the FPU, seemingly adding precision to the 1's/10's/100/'s place holder depending on the integer input to the FPU.
  • 0 in reply to Genatco
    Genius 3850 points

    "Better check 24bit math twice as 25Khz PWM frequency can not be represented by 24 bit load count values with 120Mhz SYCLK time base"

    Unless you live in a different universe, a 25khz pwm requires no more than 13 bits to represent on a 120Mhz system.

  • 0 in reply to Danny F
    Guru 55913 points

    Exactly you got it (0x3E8) 4800 decimal "we don't say 4800 number or integer" and 0x3E8 is well below all 24 bit load value, most any count up to including 10 bits is all inclusive. So 24 bit scaling is not required once you do the frequency math and (fractional speed) load values are nothing more than whole number integers counting up or down incrementally representing decimal temperature values. Yet most PWM fan speed controllers do no allow taco to fall below 1500 RPM or simply can not adjust speed that low depending on the manufacturer, some are 2500. As temperature rises fan typically blows harder faster requires the GPM match load value be increased but relative to PWM duty cycle concatenated directly from the value ADC sampled from multiple temperature sensors. The hottest highest value sensor data must always have priority over any lower value reads.

    Anyone FYI; integers do include decimal numbers 0-9 and one web page uses word decimal referring to part of a fraction. Yet word decimal is often used to relate whole numbers too, as via the "Dewy Decimal System" now who's on first not the definition of an computer industry integer (range) that word range gets omitted more often than not. Past integer range think had something to do with ALU math ability.  

    https://www.mathplanet.com/education/algebra-1/exploring-real-numbers/integers-and-rational-numbers

    https://www.mathsisfun.com/whole-numbers.html  

  • 0
    Guru 117855 points

    BP101 said:
    Example: Int32value=(373 + 373 /100/3.5) or  Int32value = 2.1314285714285714285714285714286  yet CCS debug variable show 2 as the answer but not a rounded decimal integer such as 2.13

    Quote above harks back to poster's   very first post here - and TWICE (clearly, above) - makes the claim that an  "INTEGER"  is to include an  "IRRATIONAL" Number.    (as denoted by the decimal point - EMPHASIZED IN BOTH OF Poster's PRESENTATIONS.)       An irrational number is one which cannot be written as a "Whole" - as a "Ratio" - or as a "Fraction."    (thus descends to decimal point.)

    Decimal defines the base TEN - Numeral System - there are also,  "Binary,  Octal & Hexadecimal" Numeral System Representations.    

    Again - "INTEGERS" consist of WHOLE NUMBERS (Rational Numbers) - NO Decimal Point Representation (signalling "irrationality") is to appear.     (barn door "swings shut" on cb1/dead horse)

    It IS hoped that you resolve this - and keep your power stage properly cooled.      We have deployed (both) Peltier & Forced Liquid Cooling - w/in our Autonomous Vehicle network -  both well able to substantially absorb & then transfer (deadly) heat away -  from the delicate/vulnerable  FET Power Stage...    No PWM cooling control even begins to approach anywhere near 25KHz!  (NO case has been made - at all - for your 25KHz (and only 25KHz) requirement...)

  • 0 in reply to Genatco
    Genius 3850 points

    "Anyone FYI..."

    taking a decent middleschool math class will help clearing things up considerably.

  • 0 in reply to Danny F
    Guru 55913 points

    Could some be trying to morph posted issue into something other than what the post was concerned with.

    1. The FPU was not adding a decimal point into the solution after the division of the (int32_t) integer value which violates mathematical conventions taught in any middle school math class. The entire process of dividing the numerator by the denominator adds a decimal point into the solution as mathematical division has been defined and taught by teachers for centuries.

    2. Likewise an integer can be a decimal within a fraction and again the FPU was concatenating a solution rounding it to the nearest 1's position. Question posted asked why that was occurring.

    3. Vendor then mentions we must include type (float) to define (int32_t) value for CCS to show solutions in debug variable view with a decimal point. The FPU (float) solution was still rounded to the nearest -1's place!

    Sorry but I fail to see what all the fuss is other than perhaps some people refuse to accept that an integer can be a decimal value without a decimal point as FPU rounds decimal solutions to the nearest 1's place without type (float) being added to int32_t defined variable. Using sarcasm or innuendo in effort to belittle a poster is abhorrent behavior!

  • 0 in reply to Genatco
    Guru 117855 points

    Try as you might - NO INTEGER can be represented as "2.13" or  "2.13142 (ad infinitum)" - as you've presented - more than once!

    No evidence of alleged "sarcasm" appears, either...    Presented here is a  clear,  "Statement of fact."

  • 0 in reply to Genatco
    Genius 3850 points

    It is certainly wrong to belittle anyone, however justified it may be.

    However, for people who don't understand the difference between integers and real numbers, it is factually true that going to a good middle school can do wonders. After all, that's the very point of education.

    People may find truth offensive but it needs to be said, however "offensive" it may be to some of us.

  • 0 in reply to Danny F
    Guru 55913 points

    Danny F said:
    People may find truth offensive but it needs to be said, however "offensive" it may be to some of us.

    This forum is not the place for anyone to make personal or demeaning points when it could be otherwise taken as sarcasm which you have definitely made a point to reveal in several of your posts, especially your last one.

    Yet neither CB1 or yourself can answer why the GPTM can not load (ALL) concatenated (int32_t) values derived from the FPU. That alone leaves little question in my mind an intent of demeaning sarcasm exists.

  • 0 in reply to cb1_mobile
    Guru 55913 points

    cb1_mobile said:
    Try as you might - NO INTEGER can be represented as "2.13" or  "2.13142 (ad infinitum)" - as you've presented - more than once!

    Seemingly may be wrong in that idea as the (float in32_t) type does produce floating decimal points in CCS debug variable view and the (int32_t) variable define after a divide, e.g (N/10) does produce floating decimal point in the GUI display data. The last part N/10 is working quite well with (int32_t) defined variables as pre-processed (N/10) value loaded into a text box of a widget.

    You are correct that the IEEE FPU binary precision (float) type may have limitations of precision as it seems to round off the value to the nearest -1's or 10'ths position. That seems to define "single point precision" only possible, e.g 2.0-9 are all that can be factored other than floating the decimal point to the right as the value grows beyond the 1's digit place holder.

  • 0 in reply to Genatco
    Genius 3850 points
    "This forum is not the place for anyone to make personal or demeaning points when it could be otherwise taken as sarcasm which you have definitely made a point to reveal in several of your posts, especially your last one."

    I find it highly offensive that you don't allow me to say that a good middle school education can help people understand the difference between integers and real numbers.

    With that, I shall conclude my attempt at helping you, as it has become a waste of my time.
  • 0 in reply to Danny F
    Guru 55913 points
    That's what you were doing helping me by making a snide comment in the process, not once but twice.

    Your point had nothing to do with the FPU handling of integers and more specifically the comment of middle schools hardly passing as innuendo at this point. Infers BP101 didn't learn difference when there is no specific difference other than computer integers have a fixed range. Did I not make it clear digits 0-9 are algebraic integers and who is even talking about real numbers other than Danny. I honestly don't recall numbers in Algebra referred to as being anything other than integers and computers uses integers to represents digits in the real world user interface GUI, does that make integers change into real numbers?

    The links were for reference not to you but to everyone needing a refresher on decimals and integers, me for one. One link makes claim decimals are parts of fractions yet fractions are represented by the FPU via floating point integers. That FPU IEEE post far above tries to relate that too.