BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - darkjezter

Pages: [1] 2 3
1
Discussion - EVE / Re: Modifying RAM_DL on the fly
« on: October 08, 2021, 07:12:22 PM »
RAM_DL is essentially double buffered, so when you build up a list in RAM_DL, you're not updating the display at all until you call SWAP.

So basically, there are 2 independent sets of display list memory.  One which is accessible via RAM_DL, while the other is being used to scan out pixels.  When the swap is processed, those two lists trade places.

In theory, if you populate both copies with your template display list, and manipulate the vertex locations before calling swap then you should be able to achieve what you're going for.

However, this a detail in how the BT815 happens to be implemented, however it is not an explicit part of the specification.  What this suggests is that the BT817 may or may not work the same way, and further that even if it does, you cannot rely upon future iterations of the EVE series to behave this same way.  While you can probably get it to work in RAM_DL as you're trying (if you observe the two separate pages of RAM_DL) there is an option that is within spec, and therefore, is more likely to be 'future proof'

Instead of keeping your 'template' display list in RAM_DL, you can either generate it or copy it in RAM_G, and then use existing commands to have the coprocessor copy RAM_G to RAM_DL.  The benefit here, aside from it being fast and within spec, is you wind up with 1 master copy of your display list, instead of 2 copies, each a frame behind the latest displayed.

2
Discussion - EVE / Re: Flash busy detection
« on: June 18, 2021, 06:50:31 PM »
Just to add, in cases where coprocessor commands return a result, that result is actually placed in the command FIFO at the location labeled 'result' in your example.

So, in order for your C function to retrieve the result returned by the coprocessor, you need to:
  • track where in the command FIFO the result is placed when you send the command
  • wait for the coprocessor to finish executing that command
  • perform a read operation on the location determined above
  • return the result of that read operation through your C function argument pointer

Perhaps you already know this, and/or the library is taking care of this for you, but you'll want to keep it in mind if you're looking at scope traces of the SPI traffic.

3
Discussion - EVE / Re: Widget limit
« on: April 08, 2021, 03:49:59 PM »
Generally, 'partial' anything on the eve requires masking or alpha tricks.  Stencil buffers are one easier way to approach this, and work similarly to how openGL uses them.  However, stencil buffers tend to produce visible aliasing artifacts.

What the built-in widgets use instead are alpha-blending tricks to accomplish much the same thing.  If you're curious to learn how the built in widgets work, you can generate a display list using the coprocessor command, and then read back the display list memory which will contain the resulting display list commands.  It's a bit of work, but I learned a great deal about how to avoid aliasing artifacts when doing the 3d buttons for example.

Looking at the youtube video you linked, the thin circle can be composed of a point with the circle color and radius, a smaller background-colored circle, and then something to overlay at the bottom to give you the gap.

The thicker circle bar that grows along that line though, as it has the rounded ends is likely made up of a line-strip tracing the outline of the circle.  Not how I would have done it personally, but alpha-masking wouldn't have given the rounded ends as easily.

4
The touch transform parameters are a 6-parameter transformation matrix, somewhat similar to the bitmap transform matrices.

The main difference is all 6 parameters appear to be Q15.16 (according to the bit positions shown in the programmers guide under Touch Screen Engine Registers), making them signed numbers with 16 fractional bits.

At it's most basic, parameters A,B,D,E provide an affine transformation of the raw touch values into pixel coordinates, allowing for arbitrary rotation, flip and skew.  Parameters C and F offset the coordinates along X and Y.  Thus the identity matrix with no offset is given by the parameters 0x10000,0,0,0,0x10000,0 for A through F, or 1.0, 0 , 0, 0, 1.0, 0 in their decimal equivalent.

This makes it a relatively standard 6-parameter transformation matrix.

Hope this helps.

5
Discussion - EVE / Re: REG_TOUCH_RZ giving output 32627 without touching
« on: November 25, 2020, 10:14:09 PM »
According to the datasheet, and my use of the 816 with resistive panels... 32767 is what REG_TOUCH_RZ is supposed to read when there is no touch.

It falls toward zero in response to increasing touch pressure.

6
Discussion - EVE / Re: BT817/818 release date?
« on: October 29, 2020, 03:50:29 PM »
I'm liking the looks of CMD_NEWLIST and friends.

Will this would allow coprocessor driven list fragments to be built in RAM_G, even while RAM_DL is busy waiting for a display list swap?

7
Discussion - EVE / Re: SOUND problem
« on: September 22, 2020, 04:03:57 PM »
The code looks fine to me.

I'm not convinced though that Line_in is intended to be used as an output from the board.  Mainly since the connector has "speaker out" and "line in" according to the datasheet.  Are you able to get anything through the speaker outputs?

8
Discussion - EVE / Eve3 built-in fontset
« on: September 08, 2020, 10:53:05 PM »
Greetings all,

I've been looking to see if there are any details available on the font sets which are built into the Eve3 series of chips, but haven't found anything specific.

I'm interested in knowing what the different fonts are, and what licenses apply to their use.  It would also be helpful to know for each of the built in fonts, what the sizes are.  (Regarding size: is there a corresponding point size assuming a given dpi, or some other similar metric)

This information will be helpful to us both for updating our user-manual to reflect the new graphic layouts, and for the purposes of duplicating the appearance of our UI on other platforms.

Many thanks!

9
Discussion - EVE / Re: Tag value of an area with content
« on: June 18, 2020, 10:01:03 PM »
"Why the first tag values are 0 ?"

I got this one.  Reported tag values only update once per video frame (due to the scanout mentioned above)  So touch will almost always be reported first, but expect the corresponding tag update to lag until the next video frame interval.

In my use of this, I've implemented a sticky tag system.  Touch events are tracked separately from tags, and reported tag values of zero are more or less ignored.  Once a non-zero tag comes in, I latch it internally, remembering its value until touch is released.  New tag values besides the one selected are ignored (only activate one control per touch event), and I also make use of this mechanism to keep a button activated until touch is released, or the finger drags outside of the control (based on position, not tag) plus a margin.  All done without additional drawing commands to the display, and also allowing overlapping release areas between adjacent controls.

Most of this was made necessary by the fact that we're using a resistive touchscreen, and that we need the screens to be usable with work gloves on.

10
Discussion - EVE / Re: Using CALL and RETURN
« on: June 18, 2020, 09:46:43 PM »
"Currently there isn't there isn't a such a register available"

This is good to know, I got the information for that register from the chip datasheet.  Document No.: BRT_000220 Version 1.0

11
Discussion - EVE / Re: Tag value of an area with content
« on: June 17, 2020, 06:26:18 PM »
No matter where you touch the display, I'm pretty sure you should get a tag value of some kind.  When you clear the display, if you've set the bit to clear the tag, the the entire display will return the tag value determined by CLEAR_TAG which is zero by default.  As you draw, tag values are replaced in the region drawn by the current value of TAG (1 to 255 according to the doc, though Rudolph's example also uses zero).  Thus, if you draw your scroll region last, then any touches in it should report that tag value.  The only exception to this will be when using TAG_MASK, which you don't appear to be.

If you've tried Rudolph's suggestion and as a result are seeing tags of zero for your scrollable region, then it sounds like TAG(0) is supported in spite of the documentation, and you've either failed to set tag again before drawing your scrollable area, or drawn something over top of the scrollable area with TAG still set to zero.


12
Discussion - EVE / Re: Using CALL and RETURN
« on: June 17, 2020, 06:11:45 PM »
I took the time to look at the example, which includes the routines after the DISPLAY command.  Though, I see that including DISPLAY, there are 10 commands preceeding the routine start.  The calls use 10 as the offset, which is fine.  But wouldn't that make the documentation incorrect, as the offset is in 32-bit words and not bytes?  According to the doc, the valid range for call is 0-8191, but shouldn't that range actually be 0-2047 for an 8KB display list?

Edit:
"Just a quick note on frame rate, the display list complexity does not affect this"
Is this true even given REG_ADAPTIVE_FRAMERATE which by default is set?

13
Discussion - EVE / Re: Using CALL and RETURN
« on: June 17, 2020, 03:39:20 PM »
How to reference the subroutine?  I haven't played with this yet, but I'll try to address your question.

The doc for the 815 (which I'm using) shows this:
 - dest
The offset of the destination address from RAM_DL which the display command is to be
switched to. BT815/6 has the stack to store the return address. To come back to the next
command of source address, the RETURN command can help.
The valid range is from 0 to 8191.

So, when you make the call you need to include the offset from RAM_DL to the beginning of the routine in the command.  As for what that offset will be, that depends on where you place it when building the display list.  My only observation here, is you might need to be careful placing the routine at the end of your list.  From my own testing, it seems as though RAM_DL is a window into one of two independant display lists, and the swap might just be alternating the roles of those lists.  One which is being constructed, and the other which is actively being displayed.

If that's true, then your routine should be fine anywhere in RAM_DL, maybe even if it appears after the DISPLAY command.  If it isn't, then you might need your routine to appear before DISPLAY.  In that case, you may be better off placing the routines near the beginning of RAM_DL, and skipping over them using the JUMP command.  Then you can easily know ahead of time where the routine was placed.  If using the coprocessor to build the display list, you can use REG_CMD_DL to determine where the next location in RAM_DL is that will be written to.

The only other note I'd add, is you will need to place these routines in RAM_DL for each time you build a new display list.  A common method used with these screens is to have a fixed portion of the screen content (say background and state setup) at the beginning of the list, followed by dynamic content which may change from frame to frame.  The routines would naturally fit into that fixed portion, you just need to be sure to JUMP past them until you intend to call them.

I'm not sure if this helps, but I am interested myself in exploring the subroutines in the display list (eventually).  Just keep in mind, that the available DL memory is just one aspect of the limits of what you can get this chip to do.  Every scanline drawn to the display has to execute the entire display list, and how long that takes will be a function of both the clock speed and the complexity of the display list.  At best, complex lists will slow down the frame rate while at worst you may wind up with hard to diagnose graphic glitches.

Keep us posted!  :D

14
My mistake, upon reviewing my code it turns out that it's CMD_MEMCPY which does not wrap at the FIFO boundary.

Though, I'm still at a loss as to the benefit of doing so with the exception of suppressing updates to REG_CMD_WRITE.

15
The RAM_CMD circular buffer will automatically wrap around IF you fill it by writing to REG_CMDB_WRITE.

If instead you write directly to the FIFO by writing to RAM_CMD plus offset, then no, it will not wrap around.  I'm actually using this technique to fill the command FIFO with self-modifying code to ensure that the code is sent before it begins self-modification.

Once you've written the data to the FIFO, the EVE will not begin execution until you update REG_CMD_WRITE to indicate how much of the FIFO has been filled.  Thus, in the example you've given, either once the FIFO has been filled, or at safe-points along the way, you'll still need to pull CS high and initiate a write to REG_CMD_WRITE before the EVE will consume anything you've written in this way.

By far, the easiest way to write the FIFO is to use REG_CMDB_WRITE instead, which will automatically wrap around AND update REG_CMD_WRITE as you go.  I can't think of any reason not to do it this way unless you are writing self-modifying code to the FIFO.

Hope this helps.

Pages: [1] 2 3