Drawing pieslice (segement) on and LCD

It's not trivial, but it's not something that should be impossible for someone who passed their math classes in college, either.

If you're in the circle, AND the angle of the line from the pixel to the center is inside the area to be filled in, fill in the pixel. Otherwise, don't.

Alternately, fill in the circle by filling in lines that extend radially from the center outward, and spaced close enough to get full coverage. Fill in with a for-loop that goes from the minimum angle to be filled up to the maximum.

You don't mention how much processor time you have to spend on this -- it'll be easy to do with sines and cosines, more complicated if that takes too much time.

--
Tim Wescott 
Wescott Design Services 

I would think the trig method would be a bit more than is needed. Rather than draw many, many lines with a lot of overlap I would think the way to draw a pie chart is to plot the start radius, the end radius, connect with the arc and then use an area fill algorithm. A table lookup can be done to get the endpoint of the radii which only uses trig to generate the table. I haven't looked for an arc generating algorithm but I expect sine/cosine is not needed for that.

--

Rick

What are you looking for: an algorithm to plot a pie slice? or, an algorithm to *fill* a plotted pie slice?

Do you need an algorithm that works given *any* initial conditions (initial orientation of the slice, initial "non-zero" percentage complete, etc.)?

Does it have to be able to advance in arbitrary increments (always monotonic?)?

Does it need to be reoriented after each update (vs. just "building" on what was complete as of the "previous iteration")?

Computer graphics algorithms are notoriously clever -- typically by

*not* trying to be "general" (e.g., why redraw the 12% portion of the circle from scratch if you are now at 13%?).

I was trying for something conceptually simple, given that the OP couldn't figure it out for himself.

Yes, there's lots of ways to do it that don't involve trig, but do involve more lines of code, more figurin' and actual honest-to-gosh THINKING.

--
Tim Wescott 
Wescott Design Services 

for a

Hi everyone,

Thank you for your replies.

I am using an AT32UC3B0512 microcontroller.

I need the algorithm to advance monotonically ie start with a vertical line from the centre of the circle to the outside edge, then to be able to grow in steps of 1° until the circle is complete.

Andrew

--------------------------------------- Posted through

On Mon, 25 Aug 2014 17:46:11 -0500, ajellis wrote: [ ... ]

It might work to use the midpoint algorithm to calculate the next undrawn circumferential point. You could guesstimate how much progress that would represent, and when you've progressed that much, use Bresenham's line algorithm to draw a line from the vertex of the pie to that circumferential point. Rinse and repeat.

Mel.

Why 1 degree? Why not 1%? How large is the circle (a very large diameter requires more finesse than a smaller one)? How quickly (in calendar time) is the whole process going to happen (i.e., if the whole thing takes 3 seconds, then why other with 1 degree increments that the user will never see in the time it takes for the next update to come along)

Ask yourself what you know about circles that can make your job easier! And, how your knowledge of what you have ALREADY DRAWN can be exploited to draw what needs to be ADDED ;-)

Better to draw from the circumference inward. When you hit a pixel having the color you are drawing, you know you are done -- even if you haven't reached the center! (hand-waving)

What is the diameter of the circle in pixels? How many different angles do you want to be able to show? That cpu has 512KB of flash, which is a lot. Maybe you can just precompute the coordinates of the circle and store them in a flash table, and similarly the endpoints of the circular segments for each angle you want to draw in one quadrant (say 16 of them) and do some range reduction and reflection for the other quadrants. So that would let you show the "pie" growing in 64 steps.

If you want to compute on the fly you can use Bresenham's circle algorithm, or more generally, possibly CORDIC. Or just use some trig library if you don't care about speed and space.

Those are questions that occurred to me too. One degree sounds like far too high resolution for a progress indicator. I would be thinking about perhaps 12 steps in total - anything more detailed would be better shown in figures (percentage complete, time remaining, etc., if you are talking about a time of at least several minutes).

And with 12 steps, the easiest method is to generate the images on your PC and store them on the micro - just copy them with a bit blit.

"other" s.b. "bother" :<

If concerned over the display being "static" for long periods, then add some other (mindless) "activity indicator" so a user knows that the device is "still working on the problem" -- even though it hasn't updated the "progress indicator".

(i.e., 1 degree *or* 1% wouldn't, by itself, be sufficient if it was a 5 hour process!)

Or, play games with reflections, etc.

Without intending to offend the OP, it sounds like a "young" engineer specifying a "1023.276 ohm" resistor...

[Or, a homework problem]

All electronics needs a blinking LED so that you know it is working!

Absolutely. For long periods, a time counter is usually the best choice

- counting down if you know how long the task will take, or counting up if you don't know.

Yes - that makes it more fun too.

Inexperienced engineer was my impression too. It sounds like someone who has a fixed idea of a solution (or been given a fixed idea of a solution), when they should take a step back and try and figure out the /real/ question.

Unless, of course, it just proves that the *indicator* is working! :< (I recall a solaris "activity indicator" that was a separate process that just sat and twiddled an indicator... without any feedback from the process that it was *presumably* monitoring! Kill the *real* process and the indicator still sits there merrily indicating "activity")

Considering how large the circle (pie) is LIKELY to be (in an embedded system... LESS likely to be using a HUGE display!), will there be any

*real* difference (at the pixel level) in the resulting image at X degrees and X+1 degrees?? Shirt-sleeve says you'd need ~100 pixel diameter to *begin* to see any difference (??) -- and, that difference would be so insignificant that a user would probably never notice it!

Exactly. How do you display 1% if you only have 1 degree "resolution"? Or 2%? 3%? 4%? 6%? etc.

[the above intended for the OP to consider]

Have you checked that your LCD has square pixels ?

With some rectangular (but non-square) pixels, your circle will look like an ellipse :-)

Still alternately, fill the circle by drawing succesively larger radii, so there's less overlap

Is the extra read and test cost more than overlapped pixel drawing? Probably depends on new arc size.

w..

You're moving towards a region where, sooner or later (increments less than 90 degrees) you will encounter a portion that has been previously drawn. Once you've hit that point, you can turn around and implement a flood fill algorithm -- which ALSO requires read-and-test in each iteration.

Of course, the smaller the increment, the more readily you will encounter such a point (perhaps condition *how* you run THIS INVOCATION of the algorithm based on the size of the increment... or, unroll the loop a bit and spread the test over several "draw" iterations).

I'm sure someone has already tackled a similar problem...

Hi Everyone,

Thank you for your replies, and I would like to apologise for the delay in responding; I have several irons in the fire at the moment.

It hadn't occurred to me to precompute coordinates and store them in a table. That is the solution I'm working on at the moment.

Andrew

--------------------------------------- Posted through