Can confirm that AT25SF641F (64MBit) fails to enter FAST mode with error 0xE004 - device/blob mismatch

MX25L6433F (64MBit) works correctly.

AT25SF appears to have non standard commands and registers for enabling quad mode and reading status registers.

Furthermore, I'm finding that the AT25 will randomly fail to be detected on startup, and continue to do so until some unknown sequence of events resets it.
When in this failed-to-detect state, my attempts to read flash registers using cmd_flash_spitx/_spirx return 0xFF
I can't make much progress with debugging this as it starts working when I need it not to, and I don't know how to make it fail again.

BT815's Display Enable (DE) output is active positive.

I am trying to use a display with an ILI9806E driver which requires Display Enable to be active low.

How do I change the polarity of DE so that it is compatible with this display driver?

Thanks

I'm thinking about how to couple 4 bt815 that can display 1080p but I do not see how to do. It could be super cool

Square peg, round hole. But if you wanted to engage in techno-masochism, you might consider the following:

Use a single external oscillator to drive all four BT815s
Logically OR together the RGB lines.
Connect MISO for only one BT815 (or add logic so that if only one CS is active, that MISO is connected).
Setup each one to draw 1/4 of the screen(540p). Set the front/rear porch times for each one so that each 1/4 screen is offset in the overall frame(1080p) position.
  v Display1 area
_____________v horizontal rear porch
|/----\      |
|\----/      |
|            |
|____________| < vertical rear porch

        v Display2 area
_____________v horizontal rear porch
|      /----\|
|      \----/|
|            |
|____________| < vertical rear porch

  v Display3 area
_____________v horizontal rear porch
|            |
|            |
|/----\      |
|\----/______| < vertical rear porch

        v Display4 area
_____________v horizontal rear porch
|            |
|            |
|      /----\|
|______\----/| < vertical rear porch

Enable CS for all 4 BT's and enable the pixel clock. All things being good and deterministic, they should all be synced with each other,
but producing output in different quarters of the screen.

Each BT will need its own unique display list with all coordinates offset according to it's position in the output frame.
To maintain synchronisation it will probably be necessary to send the SWAP command to all 4 BT's at once.

HSYNC and VSYNC pulses should be the same on each one, so no need to OR them (just use one set).
Chopping the screen vertically 4 ways may be better than 2x2, because variations in timing will have less impact on a line-by-line basis compared to pixel-by-pixel...
 ...assuming the timing parameter values can be set appropriately (for any of this).

This is a terrible idea and probably won't work.
But if you really wanted to try it, this is the best approach I can think of.
If you make it work, send me pics 

Whoops. Seems I dropped a 2 from the base address when adding the offsets.

Cheers.

I noticed that edge strips don't anti-alias, so need to be outlined anyway.

Using Scissors is the easiest way for simple shapes, but doesn't allow for moving the shape using vertex offsets. For that, stencilling is required.

For shapes with relatively thin diagonals, drawing multiple parallel lines seems to be the easiest way.

I haven't been able to get compressed images to work yet. PNGs load, but return zero length.
I'm now trying to upload compressed raw L4 converted output from the Asset Converter. For some reason it doesn't compress files when 'compressed' is selected. I've written a python script to compress the raw files and output to c array, but so far I've only gotten errors from CMD_INFLATE.

Hi,

I was hoping to be able to draw filled polygons using an FT813 so that I can replace some large icon bitmaps with a small list of vertices, saving me a whole load of flash memory space.

I looked at application note AN334 https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_334-FT801_Polygon_Application.pdf and I saw filled polygons.
On closer inspection, it seems that the polygon is split up into smaller sections so that they have vertical and horizontal edges for the scissor command to trim to.
This makes diagonals impractical however, as they would have to be cut up into squares whose sides match the width of the diagonal section. A long thin diagonal would require many cuts.
Concave polygons also need to be chopped up into straight edged convex pieces, and would need some thinking about..


Firstly, is filled concave polygons something that is likely to be supported in the future? Are the existing range of chips field upgradable, or would this feature require rolling out a new product?


Secondly, what would be the best way of getting around this?

1) I could draw over the unwanted part of the polygon with another polygon set to the background colour, but this wouldn't preserve non uniform backgrounds.

2) Perhaps I could draw to the stencil channel instead, but the stencil is 1bit and wouldn't have nice smooth edges when I fill, so far as I can tell from the docs, haven't tried it yet. I suppose I could then draw the outline with with a LINE_STIP to get the anti-aliased edges.

3) Or I could break up the icons into smaller components and composite them, making use of completely blank rectangular bitmaps that can be generated with the MEMFILL command and using the bitmap transform to rotate them to get the diagonals. Rotating bitmaps is a bit iffy, though. I did try animating a rotating circle and it did not look good. Its size and position kept shifting about.

4) Or I could give up and just use bitmaps, take the hit on space, hope deflate does a good job.

I think option (1) would suit my immediate needs, but I'd like to know if other folk have encountered this limitation, how they've gotten around it, and why that method, so I can make an informed decision before making a commitment.

Cheers,
 AT38

Hi,

 I am attempting to run the touch screen calibration as per the documentation:

(Init screen here)

cmd(DLSTART)
cmd(CLEAR(1,1,1))
cmd(TEXT(80,30,27,OPT_CENTER, "Tap the dot")
cmd(CALIBRATE)
cmd(DISPLAY)
cmd(SWAP)

while(REG_CMD_READ != REG_CMD_WRITE);

This gives me a black screen with a small box of white hash near the top left. (I can post a picture if it would help)
Tapping the screen three times completes the operation, but the transform matrix is wrong because the dots aren't displayed and I've tapped in the wrong places.

The default matrix gives almost the right values, except that it's upside down, so I suppose I could invert param E and it would work,
but I'd like to have the calibration macro working correctly.

I've been having a hell of a time trying to get touch tracking working today, but I don't want to post about that until I've confirmed that the touch matrix is calibrated correctly.

Cheers

 AT38

Figured it out.

I had an SPI transfer struct with a pointer to one of its own fields when writing a single register, which was fine when memory was dynamically allocated.
But I changed it to static allocation, copying the struct's values into a fifo, instead of a pointer.
The copied struct's pointer was still pointing to the original, causing garbage to be written to SPI after the original was removed from the stack.

This only affected initialisation, so display list updates were working. The display had already been initialised by the previous build.
I had thought that sending POWERDOWN and then ACTIVE would re-init, but apparently not. So the display worked fine until the power was cycled.
Once the power was cycled, all the initialisation was lost. The faulty code couldn't re-init the display, and hence the lack of output and odd PCLK speed.


I hope my ineptitude proves useful to others, or at least entertaining. 

Cheers,

AT38