## Is it possible to setup ATmega with 921600 UART Baudrate!

40 posts / 0 new
Author
Message

I have a nextion LCD communicating to my ATmega32a over UART, My circuit is externally driving the ATmega32 with a 16Mhz crystal oscillator. The screen has a maximum baud rate of 921600. According to the ATmega32a datasheet baud rate examples for (16Mhz), I can see only a jump from 0.5 to 1Mhz. My understanding is that the UART is derived by the external fOSC and the prescaler settings of the UBBR.

Is it possible mathematically to drive the ATmega UART Prepheral with 921600? By mathematically here I mean setting the UBBR along with the U2X with a value that would accomplish my desired baud rate of 921600?

Note: I intended not to use a soft-uart due to the memory and processing limitations in my application.

This topic has a solution.

At the tiniest fraction of scale, physics is more interesting!

Last Edited: Thu. Nov 26, 2020 - 01:50 AM
This reply has been marked as the solution.

At 16 Megahertz the % of error is over 8.5%.  Thats not going to work.

Now 14.7456 gives you 0% error at 921600

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Thanks, Jim, it's good to know that 8.5% is the error limit.

With the LCD baud rate options of 250000, 256000, 512000, and 921600. I'll stick with the 250000 as it's my best option, for now, I guess.

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:
Thanks, Jim, it's good to know that 8.5% is the error limit.

No, 2% is the error limit for serial communications with a USART.  THat 8.5% is never gonna fly.

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Aser Elshawi wrote:
ith the LCD baud rate options of 250000, 256000, 512000, and 921600. I'll stick with the 250000 as it's my best option, for now, I guess.

What LCD are you using?  Never heard of those oddball rates

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

It's Nextion 3.5" LCD Resistive touch screen (NX4832T035) which I bought from Amazon (US)

In this page it say's the Valid values are: 2400, 4800, 9600, 19200, 31250, 38400, 57600, and 115200, 230400, 250000, 256000, 512000, and 921600

I tried to set up the LCD for 500K, but it didn't accept the instruction since it's not one of the available options on the LCD

I agree, honestly, those are weird rates! especially the numbers coming after 230400. I wish if they had SPI, but unfortunately, UART is the only option to interface with this LCD

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:
2400, 4800, 9600, 19200, 31250, 38400, 57600, and 115200, 230400

These are common baud rates.

These:

Aser Elshawi wrote:
250000, 256000, 512000, and 921600

Not so much.

Just go to teh USART section of the AVR datasheet and pick a baudrate that has less than 2% from the common rates.  Those Nextion screens are dog butt SLOW so a high speed serial connection is not gonna do you any favors.  19200 should be all you need.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

FOR YOUR EXACT DISPLAY  PART NUMBER THE DATASHEET SAYS:

Also 16 MHz is not really a great xtal freq for uarts, there are other that give a wide range of bauds, with better (perfect) timing.

The freq you get is just a division, so you can evaluate dividing by X vs (X+1) to eval the freq step size; there is nothing in between...When the divisor shrinks down to 4.. 3... 2... 1...the steps get big quick.

Never try dividing by zero, the AVR will glow

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

250K works well for me on both the LCD and the ATmega. I totally agree. The screen is very slow. My intention is not to speed up the drawing as much as to speed up clearing the Tx buffer rather than slowing down my write throughput. I'm using standard C printf in my code and I'm just initializing my UART with HWuart_Init(250000), and including stdio.h to print on UART

I'm attaching the source code I developed a long time ago for the UART just for reference.

Currently, my code doesn't handle the overflow properly. Probably I should work on it later to better handle this part.

Thanks!

## Attachment(s):

At the tiniest fraction of scale, physics is more interesting!

Last Edited: Wed. Nov 25, 2020 - 03:14 AM

LooL

Never try dividing by zero, the AVR will glow

It's very strange because you're right! I double-checked and the datasheet says the max baud is 115200, however 250000 works perfectly for me, or at least for now! (The screen accepts the baud setting and responds properly to the commands). I guess I was lucky not to pay attention to this part in the datasheet and try the 250000. Although after knowing I hope it doesn't trouble me later!

Unfortunately, I'm stuck with my 16 Mhz for now, because the screen is not the only thing I'm interfacing with, and I need the max speed out of the ATmega I'm using.

Thanks!

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:
My intention is not to speed up the drawing as much as to speed up clearing the Tx buffer rather than slowing down my write throughput. I'm using standard C printf in my code and I'm just initializing my UART with HWuart_Init(250000), and including stdio.h to print on UART

I think your code is in need of an update if you need to run the usart that fast for a nextion screen.  I have used them in the past with a dinky Mega328 running at 4.192 Mhz and 19.2k and never had issues sending /receiving information.  Just my opinion, it's your design.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

It's very strange because you're right! I double-checked and the datasheet says the max baud is 115200, however 250000 works perfectly for me

It is hard to say for sure...the manual (used for all displays) shows the wider range.    Maybe they  added more speeds to the lineup over time & simply never updated all of the datasheets...that does happen a lot, sadly.  I did note that one of the other displays does indicate the higher speeds---so who knows!!

Products sometimes show a "more limited" feature set compared to \$\$\$ models when, in fact, some limited features are readily available on both (just to make the \$\$\$ model look better).   The all-new Chevy Wumpus, includes engine diagnostics !!!

I think your code is in need of an update if you need to run the usart that fast for a nextion screen

Maybe the code is just too impatient...it shouldn't have to write that much stuff to the display (unless you are making a video game).  For example, instead of sending the value of a temperature over & over 30 times a second (or trying to!), send it once, only when the value has changed.  The program should recover & handle the possibility that the display is too busty  ....skipt it, or come back & try again on the next loop round.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Nov 25, 2020 - 05:09 AM

Remember when people spent a lot of effort optimizing their screen re-display algorithms because the "display" might be at the other end of a dialup link running at 1200bps or lower, and even the "local" terminals were limited to 9600?

I feel old...

```/********************************************************\
*                                                        *
*       Ultra-hot screen management package              *
*                                                        *
\********************************************************/

/***********************************************************-*****

/-------------\
/               \
/                 \
/                   \
|   XXXX     XXXX   |
|   XXXX     XXXX   |
|   XXX       XXX   |
\         X         /
--\     XXX     /--
| |    XXX    | |
| |           | |
| I I I I I I I |
|  I I I I I I  |
\             /
--         --
\-------/
XXX                    XXX
XXXXX                  XXXXX
XXXXXXXXX         XXXXXXXXXX
XXXXX   XXXXX
XXXXXXX
XXXXX   XXXXX
XXXXXXXXX         XXXXXXXXXX
XXXXX                  XXXXX
XXX                    XXX

**************
*  BEWARE!!  *
**************

All ye who enter here:
Most of the code in this module
is twisted beyond belief!

If you think you understand it,
You Don't,
So Look Again.

****************************************************************/
```

Aser Elshawi wrote:
My intention is not to speed up the drawing as much as to speed up clearing the Tx buffer rather than slowing down my write throughput

Eh?

So why not just use interrupt-driven Tx - then you're not waiting around for the buffer to empty ?

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

I have never used a Nextion but understand that it accepts high-level graphics and text commands via the UART.

The Nextion has its own MCU which speaks to the hardware TFT controller chip.

I assume that most operations will operate nicely.   e.g. clearing the whole screen or drawing a circle.

But if you want to plot one pixel at a time it will be SLOW.

1.  draw main screen with appropriate library methods

2.  update a minimal area when required

3.  keep track of any varying data so that you only update the screen when necessary

As mentioned in #13.   In the old days you would communicate with a mainframe computer via a 9600 baud RS232 Terminal.

Yes,   a full screen editor was usable at 9600 baud.    This was due to libcurses.a that minimised the RS232 traffic when updating the Terminal screen.

Your Terminal might be connected via phone line with a 300 baud modem.    In which case full screen editor was not practical.

I can remember 1200/75 baud modems that were "almost usable" with MicroEmacs or other full screen editor.

David.

david.prentice wrote:
I have never used a Nextion but understand that it accepts high-level graphics and text commands via the UART.

Yes and no.

There is a microSD card slot on them where you load the Graphics files and such with an external writer.  You CAN load the files through the usart, but thats usually done with a USB to ttl converter. And it's done at a VERY low baud rate by default so it takes forever.

IF the OP is just doing some general ascii text back and forth from the AVR to the Nextion screen 9600 is more than plenty fast enough.

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

If you only need to TX at that speed it can be done over the SPI by folding the data over more than one byte. (and forget about the clk)

Probably not worth it for this, since there is no time to make other things unless they also is a "build in" part of the TX routine.

what kind of writes do you you need this high speed for ?

I totally understand that

doing some general ascii text back and forth  from the AVR to the Nextion screen 9600 is more than plenty fast enough.

But what I'm trying to do here, is to use the drawing capabilities to plot co-ordinates based on a live data stream.

Something very much similar to what is in david.prentice answer, in my drawings, I'm considering all the points he mentioned which are perfect guidelines in my opinion. Although in my case, I need to use the highest possible baud rate.

@250K baud, data rate would be 25000 B/s, assuming 1 stop bit no parity. In a 10 ms cyclic or runnable, I'm only able to send 250 characters through commands, including the wasted 3 bytes delimiter at the end of each command. @921600 baud, I'll for sure be able to at least triple this rate, which will be very beneficial in my case, but unfortunately, it's not possible.

For sure I'm using interrupt-based UART, and when I refer to buffer, I mean software buffer, not the UART hardware buffer register.

I have noticed the screen (NX4832T035) can handle up to 921600 upload/communication speed, but yes this is based on my own experience, which may differ due to hardware variations or something that I'm not aware of.

You may select the desired upload baud rate from the top right drop-list menu:

Thanks, everyone!

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:

But what I'm trying to do here, is to use the drawing capabilities to plot co-ordinates based on a live data stream.

Be more specific.    What do you actually want to see?

Plotting a single pixel at X, Y is fairly trivial.    You can plot 480 points in a short time.   i.e. a continuous line.

If you want the graph to scroll to the left as you plot each pixel it would mean re-plotting the whole graph as each new value arrives.

Of course,  a regular TFT can use its hardware scroll ability to take that work off your hands.

There are occasions when you need to take the "engineering view".   i.e. is it practical to implement with the available software and hardware?

If not,   think of another screen format approach.

David.

In a 10 ms cyclic

Do you need to completely update the entire screen every 10ms?  How about  10 times a sec (100ms)?

I would think they would have commands so you could just set the endpoints of a line, to save from having to send all of the points in between.  Of course , that wo'nt help in drawing a very "jagged" line.

But what I'm trying to do here, is to use the drawing capabilities to plot co-ordinates based on a live data stream

Do you have an example of what you hope to display?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Thanks, everyone for your replies. The only reason I didn't explain what I want to do on the screen in detail is I'm trying to stay on the forum's topic as much as I can.

let's assume that I receive the coordinates of two points (X0,y0) and (X1,y1) constantly refreshing, and I would like to draw something like the following on the screen for example. Assuming y0 is different from y1 and the same for X0 and X1. X is the horizontal axis, y is the vertical axis.

Screen GUI designing commands: https://nextion.tech/instruction...

I don't think this can be easily achieved by sending two or three short commands.

I need to accomplish this on a cheap, available, and touch screen, which can be easily interfaced with a small microcontroller such as the ATmega family. That's why I went with the Nextion screen.

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:
I need to accomplish this on a cheap, available, and touch screen, which can be easily interfaced with a small microcontroller such as the ATmega family. That's why I went with the Nextion screen.

You might want to look at some of the TFT touchscreens Adafruit has.  These are great little kits, far cheaper than NExtion too.  ANd have SPI interfaces which are way easier and faster to use than USARTS

YMMV.

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

I don't think this can be easily achieved by sending two or three short commands.

Well, that defeats the whole point of this type of display, doesn't it?...you are supposed to use the built-in drawing commands to do the drawing (or pull up a predefined image).

.....so if you don't create content that uses the commands, just use a generic LCD display & a non-serial graphics package instead.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

If you want to blit entire frames I recommend ILI9341 based displays but if it's driven using a serial link like SPI you'll want something that can run the SPI very quickly (I drive mine from a 600MHz Teensy that can run the SPI at 30MHz).

avrcandies wrote:
that defeats the whole point of this type of display, doesn't it?...

It does seem so.

Aser Elshawi - have you contacted Nextion to discuss whether this product is actually suitable for you requirement?

They should be able to advise whether it's possible and, if it is, the best way to achieve it using the available facilities:

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Your example in #21 is very difficult to draw with regular Graphics libraries.

It seems to have a Blue trapezoidal area with a colour gradation.

If X0 alters by dX0 it involves drawing a new triangular slither in white and several new triangular slithers in graded Blue and some in White.

Just draw your original graphic on paper.

Add the new x,y points.   Observe how many triangular slithers are required to update the display.

Triangles are especially difficult to calculate and draw.   All the same,   if your Nextion library has high level commands for filled triangles it is probably less UART traffic than you drawing individual pixels.

I strongly advise you to look at graphics that are attractive, intuitive and easier to draw.

Hey-ho.   I have still not looked at Nextion commands.    I just assume that you can make impressive images by using the facilities.    I understand that you can store 32GB of images on an SD Card.

There is a lot to be said for a Graphics Engine on the Display.   You can draw very fast to a TFT with a Cortex-M4 and parallel bus.  Some M4, M7 have specific hardware for this.

But you can also produce some attractive results with everything running on a Teensy4.x

David.

#21 make me a tad confused.

Does this mean that you only get 4 coordinates and from that you have to (re)draw the hole picture ?

if that is true how many bytes over the UART is a picture, and what else do you need to while updating the picture ?

and how often do you get new coordinates?

Bottom line--Plan to draw your images using the graphics commands available, not the other way around.  If there is no circle command, then don't plan on displaying any circles...etc, etc

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Seems almost everyone agrees on changing the hardware for better meeting the requirements. At this point, I totally agree. When I started the project I saw the screen commands and I thought using them would be feasible, but now it is very much limited with the command-write speed and not the commands and memory capabilities.

david.prentice wrote:
You can draw very fast to a TFT with a Cortex-M4 and parallel bus.

I couldn't agree more, this sounds like a good combination for what I need.

awneil wrote:
have you contacted Nextion to discuss whether this product is actually suitable for your requirement?

Yes, and for some reason, I got better information here than from what I got from their website! which is kinda weird, I know!

jgmdesign wrote:
You might want to look at some of the TFT touchscreens Adafruit has.  These are great little kits, far cheaper than NExtion too.

I'll will definitely check that out!

avrcandies wrote:
Well, that defeats the whole point of this type of display, doesn't it?

I'm actually using the screen commands extensively to do the example I just posted. for example, I'm drawing a line with the "line X0,Y0,X1,Y1,color" command in a for loop, while changing the color for the gradation effect.

After calculating the line equation from (X0,Y0) and (X1,Y1). I can basically draw the line on the screen repeatedly in a for loop, while changing the line intersection point with the X-axis for example.

```// x_start_point is the x value on every line when y=0
for(i=x_start_point_begin;i<x_start_point_end;i++){
//calculate x0 and x1 from the line equation and color value
//based on gradation speed and level
printf("line %d,0,%d,480,%d\xFF\xFF\xFF",X0,X1,color);
}```

This is just a partial example from what I was thinking to do.

Thanks again everyone! your comments do really encourage and help, and to be honest I'm new to the community, however I'm impressed by the amount of experience you guys all have.

At the tiniest fraction of scale, physics is more interesting!

Sounds cool  but a bit expensive

At the tiniest fraction of scale, physics is more interesting!

It's not as simple as displaying a picture. I don't know how many bytes it would take to draw such a simple-looking figure but looks like a lot because the screen takes the commands as text over serial. And yes it's somehow a strange way of sending the commands, but it's the only way.

At the tiniest fraction of scale, physics is more interesting!

Aser Elshawi wrote:

Sounds cool  but a bit expensive

We must be talking about different things?

I see your display typically at:

NX4832T035 display - \$30

The kind of display I was talking about is:

ILI9341 display - \$12

Or is yours not like the one in the first link?

Aser Elshawi wrote:

I'm actually using the screen commands extensively to do the example I just posted. for example, I'm drawing a line with the "line X0,Y0,X1,Y1,color" command in a for loop, while changing the color for the gradation effect.

That is incredibly inefficient way to do it.   ---- with any hardware or any software.

avrcandies wrote:

Bottom line--Plan to draw your images using the graphics commands available, not the other way around.  If there is no circle command, then don't plan on displaying any circles...etc, etc

+100

As I said in previous replies.   I do not have Nextion.  Nor studied the available Nextion commands.

If you want colour gradations.   Calculate X start and X end point,  start colour, end colour for a particular Y row.    Draw horizontal lines.    Angled lines are very expensive.

You have chosen something that is fairly difficult to do.    And it does not even look very impressive.

I strongly advise you to go back to your drawing board.    A nice cup of tea always helps.

Yes,  I know how to achieve your image on a regular dumb display with regular graphics library.

You can only work with the Nextion commands.

If you design your project well,  the Nextion could make impressive images.    With little low-level programming effort from you.

Most work will be done with a GUI on the PC.   i.e. using artistic and design skills rather than C, C++ programming skills.

David.

That is incredibly inefficient way to do it.   ---- with any hardware or any software.

NO it's seems to be the best way when you look from the communication point of view. (yes the display have more to do but that is not OP's problem yet)

I had a very quick view of the lib, and it does seem that you can send a text program (look like basic) to the display, if that is true then that could be a way to do it.

You can draw a filled rectangle efficiently on 99.9% TFT controllers.   A line is just a thin filled rectangle.   Pixels are sent in a block.

Drawing a series of angled lines requires plotting individual pixels.

Given an image,  it is the same number of pixels whether they are drawn in vertical strips, horizontal strips, diagonal strips.

The OP can try it for himself.   i.e. draw a filled triangle by horizontal strips or angled lines.

The same number of high level commands.   The Nextion firmware just has a harder job for angled lines and the underlying TFT controller requires many more instructions.

This applies to drawing the initial big trapezoid.

The main advice has always been: only update the minimal area.

Obviously this will tend to be thin triangular slivers.   Probably nothing more than a few angled lines.

You can only use the Nextion methods that are available to you.

I suggest that you post on the Arduino.cc Displays Forum

There are Nextion experts who can help.

David.

Last Edited: Fri. Nov 27, 2020 - 02:30 PM

My impression is that the  Nextion  displays are intended for human-machine control GUIs - not really for real-time graphical data displays ?

Perhaps something like this might be better suited:

https://www.lascarelectronics.com/panelpilot

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

They just need to update the display lib...for example they could have a polyfill command where you provide a list of  boundary coordinates, for your pentagon, or random shape.

Since they don't have one, you are stuck.  Even if they had a triangle command you would be in decent shape.  You need to draw using 5, 10, maybe 50 or 100 commands...the idea is quickness.

i did see this posted on the net....you can investigate yourself

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Nov 27, 2020 - 04:33 PM

The problem is that OP want to change colour so a normal fill can't be used.

I'm not talking about the screen only, but rather the whole system in general (micro-circuit components - software).

At the tiniest fraction of scale, physics is more interesting!

david.prentice wrote:
I suggest that you post on the Arduino.cc Displays Forum

I feel at this point I've selected the wrong display for the job, but I'll try for sure. It's always impressive how others may come up with unexpected workarounds.

The screen commands only allow drawings of vertical and horizontal shapes or pictures. The only available diagonal thing is to draw a line with two points as input. That's why I had no option other than to draw a line repeatedly. The screen resolution is 320 x 480. which is not too much for a loop, except for sure when every line is transmitted over UART as a series of characters that represent a single line command, that's why my initial concern was about the UART throughput, and that's why I started this thread.

avrcandies wrote:
I did see this posted on the net....you can investigate yourself

I did try this option. Having the script run on the screen itself through the embedded available timer. Two problems, first, the scripting language is very much limited in a sense I felt it is useless. Second, the timer is really inaccurate and caused me a lot of nonsense trouble.

awneil wrote:
My impression is that the Nextion displays are intended for human-machine control GUIs - not really for real-time graphical data displays?

Unfortunately, I came to that conclusion the hard way  I'll try one of those screens on my next project for sure. Thanks!

sparrow2 wrote:
The problem is that OP wants to change colour so a normal fill can't be used.

Yes, and I can't draw angled shapes on this screen due to the available commands options.

Thanks!

At the tiniest fraction of scale, physics is more interesting!