Start a new topic

NexNumber: What's wrong with this piece of code?

 Code is:

 

#include "Nextion.h"

uint32_t number = 0;

NexNumber n0 = NexNumber(0, 1, "n0");

void setup() {
  nexInit();

  n0.setValue(9999);
  n0.getValue(&number);
  dbSerial.println(number);
  
  n0.setValue(99999);
  n0.getValue(&number);
  dbSerial.println(number);
}

void loop() {
}

 

Output in serial monitor is:

recvRetCommandFinished ok
recvRetNumber :9999
9999
recvRetCommandFinished ok
recvRetNumber :4294936223
4294936223

Why does the Nextion display always return '4294936223' instead of '99999'?

I can set the value to ninethousand without problem, but not to nintyninethousand. Why? That should be in the range of a uint32_t, shouldn't it?

The HMI file consits of only a freshly created single page and a single number box. Nothing more. No extra code in user code on postinitialize event, touch event etc.


What's wrong with this?


See also http://support.iteadstudio.com/support/discussions/topics/11000009877 (but whether there is a lenth attribute or not dos not make a difference).



Looks likes an expected response from a non 32-bit MCU.

When the compiler parses it is dealing with MCU specific max integer


This is typically where reading the 400 to 1800 page MCU reference comes in and becoming familiar with how your compiler works (any compiler worth its weight, their site usually has explanations of such)


But perhaps try casting



Which MCU are you using?

Such missing details are the essential clues

9999 is falling within a range of 14 or 15 bits   0..16384 or -16384..16383

99999 is falling within in a 17 or 18 bit range   0..131072 or -131072..131071


So when the number is larger than the register needing to hold it ... it wraps.
Wrapping goes something like 32766, 32767, -32768, -32767 ...


You have declared number as a uint32_t, an unsigned long 32 bit
uint32_t number = 0;


These lines are dealing with your declared 32 bit variable number
    n0.getValue(&number);
    dbSerial.println(number);

But these lines are dealing with non-typed constants
   n0.setValue(9999);
   n0.setValue(99999);

So look at it and tell me how a compiler is to know what type 9999 or 99999 is to be?
- so, as it doesn't know, then it will "pick one" from max integer defined by your board
- the reason max integer is defined for your board is a fallback for what you just did
  (sending an non-typed constant)
- what is defined for the board has to be specific to what your MCU is capable of
- what the MCU is capable of is within those hundreds of reference pages the chip manufacturer wasted their time to write and organize all the little petty details that state exactly how the chip operates.
- so knowing which MCU allows to download the correct reference manuals, cause at hundreds to thousands of pages, it is a waste to download so many and not find what you are looking for.  Or worse, you try to force the wrong instruction meant for one chip onto the wrong chip and damage your MCU.

Now from the compiler side, the task of the compiler is to take what the humans have written in one of hundreds of programming languages and turn that gibberish into logical code that will be destined for the MCU.  In this process, it also tries (keyword tries) to optimize the code removing as many redundant (keyword redundant as estimated by the compiler and not necessarily what the user thinks is) lines of code and code branches to render machine instructions specific for the target MCU.

So to determine what the heck the compiler just did when it rendered something you were just not ready to accept - this is where we investigate the compiler.  Buried deep within its docs are the rules that it follows to determine how the heck it managed to mangle your 99999 into a 4294936223 and all the reasoning and logic behind how it came to that conclusion.  

Knowing these rules and logic allows you to format your coding efforts to achieve your desired results.
Exploiting the effects from these series of commands and avoiding those that will mangle and completely destroy much of your coding efforts like 99999 has done.

But hey, why bother reading the docs?  We be men, no need for docs.

@Paul


Why don't you do some simple debugging to find out exactly where the problem lies.


Plug your Nextion return line into a USB to Serial adaptor or the main return Serial of your mcu and watch what comes back in a serial monitor (in Hex view if its just junk as ascii). You should be doing this stuff as part of your project development. Anyone trying to help you would pretty much have to do that work for you. You know a little bit of effort on your part, until you have exhausted the tools that readily available to you, might prompt a better response from readers on this forum.


As I see it now, you give up far too easily because you can't be bothered to do even the basic stuff.


Just my $0.02


Regarding

https://github.com/itead/ITEADLIB_Arduino_Nextion/issues/36

- referencing your own posting does not support an argument of known issue


Regarding

See https://github.com/itead/ITEADLIB_Arduino_Nextion/issues/32.

Also not necessarily a 'known issue"

What it states is that user doesn't know their programming language


Changing the lib code to fit your error?  Well good luck with that.

The bandaid you make today will end up breaking tomorrow.


User coding is not the responsibility of the manufacturer.  That is user domain.

Where to find the work around is Arduino Reference - big section

image

So I will admit it where and when I am wrong.  But I am only partially wrong.


Seems that users may have an issue when their selected MCU is AT Mega2560

Seems that users may have an issue when their selected compiler is Arduino

Seems that users may have an issue when their selected library is IteadLib Arduino Nextion Library.


And in this combination, then an issue may indeed exist.

And this is where I may have been partially wrong.


But where I am not wrong

 - Nextion is a serial device with posted text based instruction set

 - As such, the Nextion is used with 1000's of MCUs

 - As such, the connecting MCUs can be programmed in 100's of languages

 - As such, each language can have several compilers for selected language

 - As such, each compiler/language combo presents many libraries

 - Users choice of MCU, language, compiler and library - was the users choice.


 - Version 0.9.0 of the IteadLib is actually listed as Latest(unstable) - huh.

    https://github.com/itead/ITEADLIB_Arduino_Nextion

    - as such a user choosing unstable over a stable version ... user's risk. no?


But it certainly not my job to know or investigate every combination - impossible

 - user programming and choices of their selections still remains the users domain.

 - it was also not mentioned in the topic that you were using the unstable version

    (a key piece of missing information discovered by investigating)

Login or Signup to post a comment