Jaxartes Posted January 4, 2016 Report Share Posted January 4, 2016 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. Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 4, 2016 Report Share Posted January 4, 2016 Thank you for the heads up, I'll ping Alvie to see if we can get these addressed. Thanks!Jack. Quote Link to comment Share on other sites More sharing options...
alvieboy Posted January 4, 2016 Report Share Posted January 4, 2016 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 Quote Link to comment Share on other sites More sharing options...
Jaxartes Posted January 5, 2016 Author Report Share Posted January 5, 2016 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 checksa 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) Quote Link to comment Share on other sites More sharing options...
alvieboy Posted January 8, 2016 Report Share Posted January 8, 2016 We can use conditionals easily on ZPUino, unlike Arduino. So it's an option indeed. Still regarding 1) and so that I don't forget about it, can you add an issue here ? https://github.com/alvieboy/ZPUino/issuesYou can also add 2), I'll see best way to implement it without compromising performance too much. Quote Link to comment Share on other sites More sharing options...
Jaxartes Posted January 9, 2016 Author Report Share Posted January 9, 2016 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). Quote Link to comment Share on other sites More sharing options...
alvieboy Posted January 10, 2016 Report Share Posted January 10, 2016 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). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.