Start a new topic

Numbers our text?

To get a clock on a nextion screen you can use text or numbers. You can of course put the separators in the background if necessary. The question is because I would like to choose the least overload opportunity. Or does this make no difference at all?


Is there actually a general rule for this kind of choices and why?



Who knows this?


Thank you in advance for your response!

Greetings,

Ben.



Is there anyone who knows that?


Thank you!


Regards,

Ben.

> Is there actually a general rule for this kind of choices and why?

Premature optimization is the root of all evil.


Implement it as easy as possible, don't start to make things complicated.

-If you discover at a later stage that the display is too slow optimize there, eventually move load to the MCU

-If you discover at a later stage that the MCU is too slow optimize there, eventually move load to the display.

-If you discover at a later stage that the serial connection is too slow optimize there, use fewer commands.

I might argue, good planning saves errors in design and costs less.

 - patch work band-aids post design can complicate design errors.

 - less design costs to implement thought first, then to debug code

 - less embarrassment to clientele when it functions correct first time.

 - patchwork deployment ... more infrastructure needed to redeploy


Conversions cost a few cycles, interpreted conversion more cycles


When the Nextion side MCU has nothing else to do

  conversion from number to text will not make much difference


When the Nextion side MCU is tasked with other things

   forgoing conversion from number to text may shave a some cycles


RTC is numeric - it  is a number - there is no conversion needed.


Rendering to screen is always from component .x and .y 

   to component .x+.w-1 and .y+.h-1

Obvious attributes to disable are ones that require extra render steps

 - .isbr  may contain line break - rtc value most likely not

 - .spax, .spay  hor/ver spacing - better is to use space designed in font

 - .xcen/,ycen  - these if not left and up need more calculations

 - .style/.sta - any other than flat/solid color require additional steps

 - .w/.h - any oversized pixel region needed to render costs cycles


When seconds is known 2 digit, number .lenth = 2

   .w - font width * 2 and .h equal to the font height


Smaller pixel regions render quicker than larger

  - using a 80x160 font will most likely cause flickering

  - if you can get away with 8x16 it will render faster than 12x24

    -   8x16     128 pixels per character

    - 12x24     288 pixels per character

    - 16x32     512 pixels per character

    - 48x96   4608 pixels per character

 

It is all about pixel counts.

With a note on loads:  MCU vs Nextion


Loads should not arbitrarily be transferred based on space, speed,

   or any other factor.  MCU controls, Nextion input and status.


The concept of Human Machine Interfacing is for Nextion to

  - provide users with appropriate choices for selection

  - provide a means to capture user choice

  - preprocess user request for transport to MCU

  - be able to effectively receive and display status and alerts

The task of the MCU is to control the project

  - be able to receive the incoming user request

  - decide if the user input is valid at this moment in time

  - decide if it is safe to execute the request at this time

  - to only execute valid and safe requests

  - to provide user with decision, status and progress of request

  - to alert the user to any unsafe conditions that may exist


The transfer of load should never include MCU side control logic

The MCU should always remain in control.


What would happen if control logic is inside Nextion and

   an incident occurs where serial communications is lost?

   - a disaster should never be a possible outcome.

The MCU should always remain in control

   - only if all logic is Nextion side such that it is a standalone

     should control logic ever be considered to be in Nextion.


Then there is the maintenance/replacement cycles

  - when a component fails (MCU or Display) 

    - only the failed component should need to be replaced

When both need replacement - this was a design error from beginning.

Such would only drive costs upward for a lack of thought from onset.


I would have to state, foreward thought is perhaps the most valuable.


You made a lot of things clearer to me. Thanks for that!

Larger parts of a program have already been made but for the future this is very useful.

But ,of course, also for the things that have to happen in my current program.

So I still have the problem of a clock and temperature measurement that cause overload in my void loop.

I hope this might help! So thanks again for your kind explanation.


Greetings,

Ben.


Steve (indev2) made a clear point on loop long ago

 - empty loop() running should have count 170,000 to 230,000 per sec.

It went something like this sort of in this fashion



uint32_t count, now, next1, next2, next3, lapse = 0;


void my1000func(void) {

   // insert code needed to run each 1000ms

}


void my5000func(void) {

   // insert code needed to run each 5000ms

}


void my60000func(void) {

   // insert code needed to run each 60000ms

}


void setup(void) {

   Serial.begin(250000);

   while (!Serial) {  }

   now=millis();

   count=0;

   next1=now+1000;  // set next1 for 1000ms from now

   next2=now+5000;  // set next2 for 5000ms from now

   next3=now+60000;  // set next3 for 60000ms from now

}


void loop(void) {

   uint32_t st, et;


  // conditional call occurring only when millis() > next1

  if(millis()>next1) {

    // loop counter output in only one of the conditional branches

    lapse=millis()-next1; // ms from last next1 and millis() right now

    next1 = now+1000;  // set next1 for 1000ms from now

    // call to function needed around every 1000ms

    my1000func();    

    Serial.print(count/lapse);

  }


  // conditional call occurring only when millis() > next2

  if(millis()>next2) {

    next2 = millis()+5000;  // set next2 for 5000ms from now

    // but let's time how long this function code takes

    // call function only around every 5000ms

    st = millis();

    my5000func();

    et = millis();

    Serial.print(et-st);

  }


  // conditional call occurring only when millis() > next3

  if(millis()>next3) {

    next3 = millis()+60000;  // set next3 for 60000ms from now

    // call function only around every 60000ms

    my60000func();

  }


  count++;

}



The above shows how to measure your loop() and functions

  - code typed direct into forum, didn't try compiling it yet

    so, excuse if typo or two - just correct me if any are found


loop() has to have a high enough count to receive from the buffer

- only at end of loop() is buffer is bytes read from RX register and

   - or also within nexLoop() if using the Iteadlib Arduino Nextion Library

        which is usually placed as the first line of loop()

- a hardware buffer is maybe 3 words worth = 3 characters

- loop should reach end before hardware buffer overflows

  - when it does char is removed from RX into Arduino soft buffer 

  - when it doesn't chat is lost - messing everything up

  - this is usually on an interrupt, saving our butts many many times

But code will still need to process soft buffer before it too overflows.


But you also see how to make it so some code only runs at varied

intervals and place that code outside of loop and not run every loop

 - this is calling code conditionally and not unbridled.


If count becomes so low, you will end up with buffer issues

  - you will need to either decrease baudrate or

  - decrease how much work is done per second


Any debug to Serial Monitor (Serial or dbSerial) should be

  - shortest message possible to indentify

  - at the highest reliable baudrate possible to reduce time

     (debug messages are not really final MCU code)

 

And remember to thank indev2 (Steve) for his work towards this.

Will also say that if millis() is too large (0ms or 1ms)

  one can switch millis() out for microSeconds()


Use of delay() command is usually a sign of bad design

  - causing the MCU to halt in place on that code line

    doing absolutely nothing until the time to delay is up

  - this can cause missed interrupts and lead to lost data


Inserting a debug message Serial.print(blah-blah);

  - into various segments of code

  - even on every line if need be 

proves whether or not the MCU reaches that point or not


Time how long something is taking to complete

   - compare actual time to user expectations

   - many code errors are in not waiting or taking too long

ie: are actual examples

   - user wanted to read two thermos and report every second

      - since each thermo required 750ms to take reading

         it is impossible to read both in 1 second and have time to report.

         it requires a modified approach - default will indeed fail

    - halting code with delay(1000) will halt for full second

         but also any inbound touch press will also be halted and lost

         if not on the first time through, a few more loops and ...


These are some basic debugging tools seen to rare in forum code.

This is very interesting! What would this mean for the loop that I have now and described below?

Perhaps I should add that I use separate text fields for time and date because they are adjustable. I'm using a five seconds delay. This allows the seconds counter to make a five-second leap what does not look nice. But a delay of a second, for example, gives overload problems.Furthermore, under the temperature measurement there is a warning light that blinks with a 5 second time. Also not beautiful! The warning is used for too high or too low temperatures. Would it, in your opinion, be possible to adjust this loop in the above-mentioned system and thus bring about improvements?.This is my sketch:


// ----------------------- Loop -----------------------



void loop(void)

{


unsigned long nuMillis = millis();

if (nuMillis - klokMillis >= klokInterval)

{





// Stelt in op de huidige tijd


CurrentTime = rtc.now();




sensors.requestTemperatures(); // Zend het commando om de temperatuurmeting te halen.

float x = sensors.getTempCByIndex(0); //Zet de verkregen waarde in x

dtostrf(x, 5, 2, buffer_sensor);

if (strcmp(buffer_sensor, buffer) != 0) //Overschrijft de temperatuur alleen bij wijziging waarde.

{

//Omrekening waarde naar graden voor de temperatuurschaal

// Temperature (linear)

// temperature = 0, angle = -45 degrees

// temperature = 50, angle = +225 degrees.

// range of temperature is 50

// range of angle is 270 (225 + 45)

//float temperature;

float angle = (x / 50.0 * 270.0) - 45.0;

int degrees = int(angle);

temp.setValue(degrees);

if (angle < 0) //Als de stand lager is dan 0 en dus negatief wordt.

{

angle += 360; //maak een positief aantal graden voor de meter

}

strcpy(buffer, buffer_sensor);

}


if (x < minTemp || x > maxTemp) //indien de temperatuur buiten het toegestane bereik valt

{

if (setPic == HIGH)

{

setPic = LOW;

p0.setPic(2);

}

else

{

setPic = HIGH;

p0.setPic(1);

}

}

digitalWrite(TxPin, setPic);






//Zet de tijd op mijn Nextion scherm.



Serial2.print("t0.txt=\""); //t0 is mijn uren teksttbox

if (CurrentTime.hour() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.hour());

Serial2.print("\"\xFF\xFF\xFF");



Serial2.print("t1.txt=\""); //t1 is mijn minuten tekstbox

if (CurrentTime.minute() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.minute());

Serial2.print("\"\xFF\xFF\xFF");



Serial2.print("t2.txt=\""); //t2 is mijn seconden tekstbox

if (CurrentTime.second() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.second());

Serial2.print("\"\xFF\xFF\xFF");




//Zet de datum op mijn Nextionscherm


Serial2.print("t3.txt=\""); //t32 is mijn dag tekstbox

if (CurrentTime.day() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.day());

Serial2.print("\"\xFF\xFF\xFF");



Serial2.print("t4.txt=\""); //t4 is mijn maand tekstbox

if (CurrentTime.month() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.month());

Serial2.print("\"\xFF\xFF\xFF");



Serial2.print("t5.txt=\""); //t5 is mijn jaar tekstbox

if (CurrentTime.year() < 10)

{

Serial2.print("0");

}

Serial2.print(CurrentTime.year());

Serial2.print("\"\xFF\xFF\xFF");

klokMillis = nuMillis;

}


//Zodra de desbetreffende knop wordt losgelaten

//wordt het corresponderende component (pagina, id en component naam) opgevraagd.


nexLoop(nex_listen_list);


// Update lights


UpdateLights(CurrentTime);


}


Thanks very much for your time!

Greetings,

Ben.



 .

Maybe I may add this to my last post: The temperature measurement does not have to be written to Nextion, so there is already a buffer between but improvement is possible? By the time and date, only the second "per second" has to be written away. One hour only once per hour, right? Or do I think wrong now? Thanks again,

Ben.

Maybe I may add this to my last post: The temperature measurement does not have to be written to Nextion, so there is already a buffer between but improvement is possible? By the time and date, only the second "per second" has to be written away. One hour only once per hour, right? Or do I think wrong now?
Meer


Meer

---------------AfrikaansAlbaneesAmhaarsArabischArmeensAzerbeidzjaansBaskischBengaalsBirmaansBosnischBulgaarsCatalaansCebuanoChinees (traditioneel)Chinees (vereenvoudigd)CorsicaansDeensDuitsEngelsEsperantoEstischFinsFransFriesGalicischGeorgischGrieksGujaratiHaïtiaans CreoolsHausaHawaïaansHebreeuwsHindiHmongHongaarsIersIgboIJslandsIndonesischItaliaansJapansJavaansJiddischKannadaKazachsKhmerKirgizischKoerdischKoreaansKroatischLaotiaansLatijnLetsLitouwsLuxemburgsMacedonischMalagassischMalayalamMaleisMalteesMaoriMarathiMongoolsNederlandsNepaleesNoorsNyanjaOekraïensOezbeeksPasjtoePerzischPoolsPortugeesPunjabiRoemeensRussischSamoaansSchots-GaelischServischShonaSindhiSingaleesSloveensSlowaaksSoendaneesSomalischSpaansSwahiliTadzjieksTagalogTamilTeluguThaiTsjechischTurksUrduVietnameesWelshWit-RussischXhosaYorubaZoeloeZuid-SothoZweedsEngels

 

Vertaling gekopieerd

nog 4 vertalingen

Minder weergeven

Openen in Google Translate

Nederlands-Engels woordenboek - Vertalen.nu
www.vertalen.nu/woordenboek/nederlands-engels/
Gratis vertaalwoordenboek Nederlands - Engels. ... Vertaal woorden van Nederlands naar Engels met één druk op de knop ...

Zinnen vertalen naar het Engels, Spaans, Turks, Duits, Portugees ...
www.vertalen.nu/zinnen/
Vertaal zinnen van en naar het engels, spaans, duits, frans, italiaans en meer. ... Tools & widgets. Populair; Zinnen vertalen · Nederlands - Engels · Vervoegen ...

Nederlands-Engels woordenboek - vertaling - bab.la
nl.bab.la/woordenboek/nederlands-engels/
Je kunt naast het woordenboek Nederlands-Engels eveneens zoeken in andere online woordenboeken door deze in het dropdown menu te selecteren.

Engels-Nederlands woordenboek - vertaling - bab.la
nl.bab.la/woordenboek/engels-nederlands/
Je kunt natuurlijk ook een woord in het Nederlands invoeren om naar de Engelse vertaling te zoeken, want in het woordenboek Engels-Nederlands wordt ...

engels - Vertaling Nederlands-Engels - Mijnwoordenboek
www.mijnwoordenboek.nl/vertaal/NL/EN/engels
NL: Deze moeten in het Engels zijn opgesteld EN: These should be in English; NL: Ook wordt er Engels en Spaans gesproken EN: English and Spanish are ...

Google Translate
https://translate.google.com/?hl=nl
De gratis service van Google kan woorden, zinnen en webpagina's onmiddellijk vertalen tussen het Engels en meer dan 100 andere talen.

Online Nederlands Engels vertaler
www.etranslator.ro/nl/nederlands-engels-online-vertaler.php
Nederlands Engels vertaler - de meest geavanceerde online vertaler tussen het ... Online Nederlands Engels vertaler - vertaalt teksten, documenten, zinnen, ...

Linguee | Nederlands-Engels woordenboek (en andere talen)
www.linguee.nl/
Engels woordenboek en zoek wereldwijd door een miljard vertalingen. Talen: Engels en Nederlands.

Nederlands–Engels woordenboek - Majstro
www.majstro.com/woordenboeken/Nederlands-Engels
Uitgebreid online woordenboek Nederlands/Engels met handige functies om vertaling van het Nederlands naar het Engels en omgekeerd te vergemakkelijken.

Reverso Context | Vertaling in context van Nederlands naar Engels
context.reverso.net/vertaling/nederlands-engels/
Verkrijg vertalingen in context naar het Engels van woorden, uitdrukkingen en zegswijzen in het Nederlands; een gratis woordenboek Nederlands-Engels met ...


Study the snippet I posted above, and the insights provided

  take the time needed to absorb the knowledge I posted


Your MCU will go through each line of your code only one line at a time

- Examine each line in snippet, time them, ponder what the MCU is doing

- then examine your code, time them, ponder what the MCU is doing

Start to apply the techniques above to your code after understanding it


Sensor.requestTemperatures(); takes a fair amount of time.

How much time?  Above was how to measure just how much time.

Such line is unconditional and run every loop.


How long does that current loop() take to run?

The loop counter posted above shows how to find out.


I highly doubt that you are attempting to get temperature measurements of

around 200,000 samples per second, therefore such unbridled lines of code

will bog loop() down.  loop() is your main function

 - so when you bog loop() - you have bogged everything down.

 - there is no need to spend for a quick MCU if code makes such bog down.

If it is an ambient air temperature measurement

  - does ambient temperature change so rapidly? (1/200,000s or 5µs)

If it is a temperature for while cooking a steak

  - if there even was such a spike in temperature between 5µs to 25µs

     - can an alert be made such that the cook rescues the steak?

     - will the steak turn to charcoal within 25µs?

     - can the cook even react so quickly in 25µs?

Your loop counter needs to be fast enough to allow for incoming bytes


For sensors such as your temperature,

 - research better techniques for reading the values from them

 - such has been posted before on this forum, where ahhh.

Many sensor libraries are always written as if sensor is the only

   thing the MCU is doing .. it is a starting point to show it works.

But when bringing many sensors and things together

   one has to consider how much time to give each sensor, and when

but you have to research for your specific sensor

   what works with a Dallas on OneWire may not work with all.

See how others overcome such challenges


So when you ponder these, then yes it can be improved

 - examine the techniques and points presented above to ponder how

There was a lot of info dumped at one time.

My current project is vastly different from yours

 - different in MCU, in platform. programming language and compiler

 - different goals in what is being attempted to achieve.

I also have much reading to do for mine.

I just looked a the code, and I see that you call serial.print up to 24 times in the loop. This might be a big contributor to your overload problems.

I'd rather prepare the string internally and then call serial.print only once. And if you can put "hh:mm:ss MM:YYYY" in e.g. t0.txt and remove t1, t2, t3, t4 and t5 this would help too (less data to transmit as).


If you keep the loop in your style or change it as suggested doesn't matter. The suggested form is, however, much more friendly to test and develop in my opinion.

Thank you for your comments! As regards the temperature: I thought that this line, " if (strcmp(buffer_sensor, buffer) != 0) //Overrides temperature only with change value.

{

strcpy(buffer, buffer_sensor);

}

, took care of that.

This should ensure that the temperature is only written when modified. Is this right?

This is the temperature in my aquarium, so it's not necessary that the temperature is often measured. Once per minute, for example, would suffice.

The timing is divided into different text fields. These are adjustable. To get this beautiful on two different pages I chose this. Page 0, the dashboard page shows the clock, page 3 setting the time and date.

If it turns out that this is a bottleneck then I will of course have to change this. You have long discovered that English is not my own language, so I sometimes need some time to understand exactly what you mean. In particular, what Patrick earlier wrote has my interest but is not entirely clear to me. So have patience alright?

Thanks!

Ben.



Regarding strcmp: I think it can be replaced by a simple compare (compare two numbers is faster than comparing strings) and save the overhead of strcmp and dtostrf. The temperature is returned as float, isn't it?

Login or Signup to post a comment