Start a new topic

Variable transfer/update speed

 Hello I am using the display to show six different voltagelevels provided by raspberry over UART.


I send each voltage level as a variable into the HMI then I use a Timer function to update the display as a use a Gauge and Pictures as Numerical display (because Fonts are so uggly).


This setup is not very fast even I have already increased the UART Baudrate.


I suppose the problem is that I transport all the variables in separate messages. Have anyone a good Idea how to speed this up?

I dont found a built in function to crop variables (e.g. use a transport string containing all variables) or to use a kind off array...


Hi Sascha (deutsch, oder :-)),

I do not think the transmission time will be the problem here. Have you considered to do the display updates not by means of a timer, but to trigger it yourself, after having sent the data? That is something Patrick suggested when I had a similar issue. He proposed to define a Hotspot area m0, then put the update logic into the touch trigger. Whenever you need a screen update, you then can send a "click m0,1".
If you got an enhanced Nextion model, you could try to send all variables encoded low-endian in 4 bytes each in a row as raw data into the EEPROM (wepo) and read them out again on the Nextion as numbers. But EEPROM operations are not very fast themselves and the EEPROM can only be written a limited number of times.

 

ja deutsch...

I also thought about the EEPROM but I will destroy it very fast with this...

If you think that the timer is the problem I will try some other screen update methods than the timer. Does anybody now what has priority for the MCU work on the UART queue or the timer setting?

 

Fonts are limited to monobit 1/2 width of height fixed width at the moment.

There is no font anti-aliaising or font smoothing

However a font editor may assist, it will certainly reduce file size

(I may be biased to my ZI Font Editor, but there are others as well)

Check Tools,Tips Tricks and How-TOs thread in Gallery


Timer is tricky, it be overloaded.  50ms can occur in sequential sequence 1400ms out - but this depends on how well you overload it.  Model makes a small difference in figuring out what resources are available to assist in optimizing.   Font .txt and .val needs to adjust per your situation to steal back cycles Turn wordwrap off, adjust alignments to use less branches, change .w and .h to use less pixels. 


Knowning the ranges of all 6 timers maybe can reduce transport, and samples rates a definite need to know

and why don't you set the Gauges value directly?

Assuming, g0 is your gauge, just send out a g0.val=value  (were value is a value between 0 and 360)

On this way, the Gauge refresh itself automatically, no need for any further click or screen refresh or timer action ...

And send out 6 values with 115200 Baud is pretty fast ... your STM is much more speedy than you can send out your data ...

My timer update is complex I think its too much data to send when I do it in raspberry:


if(bt6.val==0)
{
  va8.val=0
  bt7.val=0
}else
{
  va8.val=60
  bt7.val=1
}
va6.val=va0.val+409
va7.val=va6.val+va8.val
p8.pic=va7.val
p9.pic=va1.val+529
p10.pic=va2.val+529
if(bt0.val==0)
{
  p0.pic=va10.val+147
  j0.bco=59164
  j0.pco=25388
}else
{
  p0.pic=va10.val+248
  j0.bco=60629
  j0.pco=53254
}
j0.val=va10.val
if(bt1.val==0)
{
  p3.pic=va11.val+147
  j1.bco=59164
  j1.pco=25388
}else
{
  p3.pic=va11.val+248
  j1.bco=60629
  j1.pco=53254
}
j1.val=va11.val
if(bt2.val==0)
{
  p4.pic=va12.val+147
  j2.bco=59164
  j2.pco=25388
}else
{
  p4.pic=va12.val+248
  j2.bco=60629
  j2.pco=53254
}
j2.val=va12.val
if(bt3.val==0)
{
  p5.pic=va13.val+147
  j3.bco=59164
  j3.pco=25388
}else
{
  p5.pic=va13.val+248
  j3.bco=60629
  j3.pco=53254
}
j3.val=va13.val
if(bt4.val==0)
{
  p6.pic=va14.val+147
  j4.bco=59164
  j4.pco=25388
}else
{
  p6.pic=va14.val+248
  j4.bco=60629
  j4.pco=53254
}
j4.val=va14.val
if(bt5.val==0)
{
  p7.pic=va15.val+147
  j5.bco=59164
  j5.pco=25388
}else
{
  p7.pic=va15.val+248
  j5.bco=60629
  j5.pco=53254
}
j5.val=va15.val

Depending on if a button is pressed the Gauge has different colours and the pictures to load are also different (differnet colours)

 

Nextion is interpreted code, so timing is all about pixel counts and bit timing.  A 50ms timer has already limited to a max of 20 (or more often ~19.5 timer triggers per second).


Is you sample rate actually 20 times per second, are you sending these 6 values over serial ever 50ms, or is the timer needed only to process this routine.


Disclaimer - I am guessing at 50ms timer - you never truly stated that.

Model is ??/  Basic or Enhanced?    Model Size ?



Timer is now at 100ms and I am using enhanced model 5". The Serial update interval is also set to 100ms.

What about using some nested IF statements in the timer to change only display when a value is changed?
I already did this on the raspberry side and can see that if only one or two values are changing the screen refresh is faster.

 

Sascha


Without testing all the actual code and debugging this code (not fan of)

I am only able to give roughly things for you to make considerations of.


I am not a fan of using timers to check for changes and act if changed.

Rather, I would use a hotspot to place code in when changes are made


g0.val=73

g1.val=142 ...

click m0,1  // code to make change is in Hotspot m0 press event


This way when the change is made, you trigger the code needed to

update the screen and reflect the current state.  This is more proactive

rather than constantly polling to check if a change has been made.

Only when your value changes, do you need to execute and most

executions will most likely be in under that 50ms minimum timer.

No need for a timer that can interfere in other code

Login or Signup to post a comment