Start a new topic

Extend drawing primitives

In addition to the current drawing primitives I'd like to see 


  • filled circles
  • (filled) ellipses
  • circle/ellipse sectors/segments (start and stop angle plus optional inner radius)
  • circle/ellipse by enclosing rectangle
  • spline



9 people like this idea

Also allow for HEX color codes 0xaaRRGGBB (aRGB 888 - aa only fully opaque [aa != 0] or transparent [aa == 0]) to be sent via serial.


2 people like this

Also a poly line (e.g. "pline x,y[,color][,x,y[,color],[...]]") would be good to speed up serial communication and building of joint objects.


Subsequent transmissions of "x,y[,color]" combos should just draw a line from last position to these coords till you receive 0xFF 0xFF 0xFF


Also a "plot x,y,color" wouldn't be bad (instead of "line x,y,x,y,color")




2 people like this

I am now reviewing all of the Feature Requests, this will take some time, patience please.

filled circle - implemented with cirs command

conversion from Hex?  not sure

But if Transparency 1555 is adopted there is more to deal with in conversions

llipses start/stop, spline, pline, plot - carried forward

"But if Transparency 1555 is adopted there is more to deal with in conversions"

How so?

Accepting 0xAARRGGBB (8888) doesn't mean the display can't internally convert to 1555. The native structure of the STM32 family is 32bit for integers 16bit values usually still get 32bit aligned (unless packed and hence throttling the µC).

And anyway, adept programmers are usually much quicker in chotting down the binary representation and translate into hex (four bit per hex digit) than having to calculate the decimal representation or even type it into calc.

On the other hand allowing for `0bARRRRRGGGGGBBBBB` for pure binary would be nice too ;-)

I'd also welcome binary operators like &, |, <<, >>, &=, |=, <<=, >>= (if they haven't already been added recently ;-) )

okay, so when numbers went to include negative values, there will be conversion conflicts.

Not saying the MCU can't do its job - it is just going to break a lot of existing user code.

white is no longer 65535, but 32767 -- only blue is not effected. -- lots of code to break

Color depth drops from 65536 to 32768

But 1555 is being advocated for, I am personally recommending it.

Binary operators ARE JUST NOW added to the list.


STM32 is 32 bit family with 32 bit registers and limited to thumb 16 bit, each 32 bit costs cycles.

I'd love to pick your brain sometime.


Scruff.r  =)  Can you do me a favour?

You have great ideas, but I have to get through this long neglected list.

If you have more ideas add them to a thread that doesn't have the "I am now reviewing" line

Or open a new Feature Request Post - it will be at the end of my list as it is the newest.

Otherwise I might miss them thinking I have completed that thread.  It is my "I did that one" marker




Login or Signup to post a comment