Jaxartes

two bugs in ZPUino_VGA_Adapter/Demo or the libraries it uses

7 posts in this topic

While experimenting with the example "ZPUino_VGA_Adapter/Demo" in DesignLab 1.0.7 I've run into a couple of problems.  I've attached a copy of the sketch, with my modifications to variously make the problems better or worse.  I was running on Papilio Pro, with Arcade MegaWing, with 800x600 graphics selected.

 

Code: video_sketch_2.ino.txt

 

1. The microsecond time values that are transmitted on the serial port, are sometimes very wrong.  The wrong values are ones like 4254601156 -- a little under 2^32.  The cause: TIMERTSC wraps around every 40 seconds or so, so so does the result of micros() based on it.  Now, subtracting one "unsigned long" from another, when the wraparound occurs, wouldn't be a problem.  But dividing by 96 or whatever clocksPerMicrosecond is, and then subtracting, results in this problem.  I see that some fix was put in for millis() but none for micros().  Workaround:  A microsecond-granularity "stopwatch", functions stw*().  But they wouldn't be portable to non-ZPUino platforms, and they assume everyone wants microseconds.

 

2. With the workaround for #1, a new bug popped out: There's a crash happening in testFilledRects() and testFilledRoundRects().  It either hangs the sketch or restarts it.  This problem turns out to have nothing to do with #1, it's just one of those "heisenbugs" which disappear and reappear when you change the code or try to debug them.  The cause: The loops in those two tests will sometimes pass out-of-range (namely negative) values to gfx.fillRect() and gfx.fillRoundRect(); and when those functions try to draw to off-screen addresses they probably overwrite some important memory location.  It's a matter of opinion whether the bug is in the sketch, for passing illegal values to those functions; or in those functions, for accepting illegal values.  Workaround/fix: Changing the loops to avoid out-of-range values.

 

Problem #2 only appeared with those two functions, that I could see; it might apply to others but be harder to reproduce.

 

Share this post


Link to post
Share on other sites

Thank you for the heads up, I'll ping Alvie to see if we can get these addressed.

 

Thanks!

Jack.

Share this post


Link to post
Share on other sites

Hi Jaxartes,

 

Thanks for the reports.

 

Regarding 1), yes, it's probably not well implemented. Let me fix that during the next days.

 

Regarding 2), I have mixed feelings:

 

For one, it would be useful to validate all measures to ensure they stay on screen.

For other, these checks are expensive and will degrade performance significantly.

 

Let me see if I can put those "conditional" in compile time, so one can test their sketches with or without checks.

 

Alvie

Share this post


Link to post
Share on other sites

Alvie - I see what you mean regarding issue #2 and performance.  As far as I'm concerned, fixing the "ZPUino_VGA_Adapter/Demo" example program (to avoid passing the invalid coordinates in the first place) is good.

 

Alternatives to compile time conditionals that occur to me, I'll just throw them out there:

  • an additional set of functions, wrappers around the current ones, that add the checks
  • a new class, wrapper around the current one, that adds the checks (or a subclass?  I'm not sure how that would work out in this case)

Share this post


Link to post
Share on other sites

Ok, done.  I've submitted issues #24 and #25 in ZPUino's GitHub site.

 

I have a couple of related questions:

 

A. Out of curiosity:  You mention "We can use conditionals easily on ZPUino, unlike Arduino".  What makes the difference/is the difficulty?  I thought the big performance problem with conditionals was in pipelined architectures, and I wouldn't have expected the AVR8 architecture to have a deep pipeline.

 

B. Speaking of performance, do you think a "blitter" (2D graphics accelerator) would be of any use in ZPUino?  I'm thinking of creating one as my next project.  The design I've got in mind would do memory-to-memory copies via DMA, with enough sophistication to draw straight lines and rectangles (but not other polygons or curved lines, without a lot of help from the CPU; also it wouldn't do antialiasing).

Share this post


Link to post
Share on other sites

Thanks for submitting the issues.

 

A: I was talking about conditionals in C++ code using #ifdef blocks. In ZPUino you can put a "config.h" file in the sketchfolder with the defines, and that gets included by "Arduino.h" if present. This is something quite difficult to do with regular arduino code. Since most code uses "Arduino.h" your defines will be applied to all of your code.

 

B:Definitely an interesting idea. Should work ok with 16-bit per pixel. If you combine that with some sort of write-combine cache it should give interesting results. Perhaps even more interesting would be texture mapping, which is not difficult from HW perspective (just use fixed-point calculations).

 

Anti-aliasing might be interesting for vectors (like lines) but it's probably too complex (or better, will use quite some resources on FPGA).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now