Search results

That's great to hear, and I'm glad the code is working out for you. Thanks for your contribution. At some point I need to go back and shore up these libs and officially release them. When I do i'll add your code to the array of supported libs and credit you. I may make small changes for naming...

What's curious to me is the 80% usage and if there's a way to get that higher. 320x240@16bpp over 1 bit SPI should net you up to about 31FPS before saturating the bus so you're close to maximum speed already if not there already. But where's that other 20% of usage getting lost? You got me...

I have a couple of RA8875s because we involved them with an initial prototype of a device we were building for work, so I didn't pay for them fortunately. Can't say I'm a fan of the slow speed of the chip, even with the "graphics acceleration" which is almost useless if you need something that...

FWIW I did recently file this issue (Almost a bug report?) TFT_eSPI appears to be no longer maintained. It might be worthwhile to update docs and samples to LovyanGFX or something #8539 with LVGL recently, suggesting they update their docs to move from TFT_eSPI to LovyanGFX My distaste for it...

oh interesting. yeah i could make one, but i can't test it. instead, I'll leave an open offer to help should one of you decide to implement this driver using the code I provided, but i'll need your help to actually test it. I'm loath to order another screen, just because I've ordered so many...

@Rezo That code could probably be adapted. The initialization codes and setting the address window and such will largely be the same over i8080 and SPI. It should be relatively easy to adapt it to a SPI version using the driver core I provided in the OP.

I'm familiar with Lovyan. I do not like its configuration setup. I think it's both ugly, and requires too much typing. I do not like what I have seen of the code. I do not like that it integrates support for a (limited) select touch panels. what if i want to use one it doesn't support? I do not...

I do not have an ST7796, and have not used one. Assuming it works similarly to the ST7789 it should be possible to write a driver for it pretty easily using my baseline library.

The issue with 24-bit (even 18-bit with 6 extra NOP bits) is the DMA facilities for this chip expect AFAIK, 8, 16, or 32 bit transfers. It also likes to do byte swapping which I haven't figured out how to disable. That creates some issues trying to communicate with that display. An aside, but I...

I looked into this a bit. It seems the Arduino H7 video library includes an LVGL config for LVGL 8.x and 9.x On windows you'll find it here. In linux, i forget where they put it, but you should find it off your home dir somewhere <system...

You know what? I haven't, and then work and life beckoned and I completely forgot about it. If you're going to use Arduino, it handles LVGL badly. You need to put an lv_conf.h in your Arduino/Libraries folder next to the LVGL folder if i recall correctly. And yeah, that's global to all projects...

Folks I found a bug with the DMA that I didn't catch before. It's corrupting once you stop updating the display. As long as you continue to update it works fine. I'm running it down, but I'm waiting on some hardware i need first that should get here any day.

Awesome. I just ordered some of these screens. I've been making paired down drivers that do partial screen updates using DMA suitable for graphics libs like LVGL that produce bitmaps but don't have their own hardware interface with the library. That's all my drivers do is send bitmaps to the...

I added some LVGL 9.2 boilerplate code to the READMEs for each of the drivers (not the base class)

https://github.com/codewitch-honey-crisis/teensy_lcd_dma Here's the benchmark I've been using. It's using htcw_uix instead of LVGL but the concept is the same

I added this driver for the ILI9341 https://github.com/codewitch-honey-crisis/ili9341_t4 also changed the interface a bit so now there's flush() and flush_async() - async uses DMA and takes an optional argument to flush the cache which you'll want to do if your transfer buffers are malloc'd. no...

Solved: I found a quirky bug in my UI code that occasionally made the target draw bitmap larger than the available buffer space. Walking off the end was causing errors in a different part of my code, which confused me and inspired this post. Sorry for the churn. FPS: 150 Transfer completed of...

On to the next struggle. I made some LVGL compliant drivers (partial screen updates using DMA) and a base class to make it easy to implement more. It works for the Teensy 4.x presently. Trouble is I can't get it to work for the ILI9341 which is odd, because aside from the initialization sequence...

Solved: Unfortunately I'm not sure what I did. I went back and retooled my code to remove, and then reinsert this functionality and it worked. *shrug* Sorry for the churn folks. I had been wrestling with this all morning. Previous issue: Previous issue before that: bool...

Edit: Never mind. I solved it. My transfer buffers were too large I'm trying to do DMA to an LCD using 8-bit instead of 16-bit transfers for a couple of reasons. Firstly, the color depth for IoT screens can usually be set to 18-bit "packed" into a 24-bit pixel. That's 3 bytes per pixel, not 2...

In case anyone finds this thread later here's what I've found specifically in my tests. Paul basically said as much, but I'll just hit the highlights: You can use DTCM memory (via declaring a static array) and everything works great without calling any sort of cache flushing method. You can...

Thanks for your help!

I'm on a Teensy 4.1 (MXRT1062) I've been inspecting the code for *_t3 graphics libraries like SSD1351_t3, and ST7789_t3. I noticed there is a complicated anti-caching scheme happening wherein multiple buffers are being juggled and memcpy'd, according to (i think?) Paul's comments this copying...

I have almost no soldering skills, but I married well, so he can solder - it was a condition of our marriage (kidding). I also have a Hakko. That said, even with my resources, I've found myself gravitating towards kits with integrated screens and peripherals. That leads me to a lot of ESP32s...

There are variants if the ILI9341 that are basically compatible but require a slightly different initialization sequence. TFT_eSPI handles these, so I would look there in Bodmer's defines - the init and rotation headers for the ILI9341 variants and you should find the sauce.

I noticed the existing drivers require an entire framebuffer to be used to support DMA. I retooled and stripped these drivers so that they can do partial updates to the display, the way libraries like LVGL and htcw_uix expect. They don't do anything but initialize, rotate, and send bitmaps to...

Sorry to hear it, Michael. Thanks for the info, I missed Paul's comment on that. I'll be sure to check that out.

Thanks.

The ESP32 successfully hosts FreeRTOS alongside Arduino which allows for a scheduler and use of its multiple cores. Arduino itself does not have multithreaded functionality, and synchronization needs to be added to the HAL to support multiple cores, but with an RTOS it is doable, if we can go...

I know it's not a board, but TBH, selling Teensies with PSRAM already attached, simple as it is, would be a huge win for those of us with shaky hands

Thanks for the advice. Arduino IDE 2.x flickers painfully on both my machines, rendering it nearly unusable. STM32CubeMX had a similar issue, - it had to do with them not testing on high end video cards -but I was able to work around it. No such luck with Arduino IDE.

hey, i did have two versions of gccarmoneeabi - one with -teensy as a suffix. I deleted both, in addition to the other folders. I removed the build_unflags/build_flags settings from PIO, reverting them to the default configuration, and rebuilt. I got the same errors, so i went one further and...

I know where the windows folders are. I'll give that a shot, but I'm not confident based on the fact that I was seeing the latest package versions during the build. Either way, I appreciate it.

Yeah, it's a mystery. Thanks for your help folks

framework-arduinoteensy @ 1.159.0 (1.59) - tool-teensy @ 1.159.0 (1.59) - toolchain-gccarmnoneeabi-teensy @ 1.110301.0 (11.3.1)

same errors after using that command.

Hey thanks. I was originally doing -std=gnu++11 in my build_unflags, but that wasn't working. You tipped me off to a fix. When I switched it to 14 from 11 it worked build_unflags = -std=gnu++14 build_flags = -std=gnu++17 -DHTCW_GFX_NO_SWAP I am on the latest PlatformIO package for teensy...

[env:teensy41] platform = teensy board = teensy41 framework = arduino build_flags = -DHTCW_GFX_NO_SWAP lib_deps = codewitch-honey-crisis/htcw_uix Verbose mode can be enabled via `-v, --verbose` option CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy41.html PLATFORM: Teensy...

I'm trying to build for a Teensy 4.1. This used to work. Now I get all kinds of crazy errors. (Both for PIOArduino and PlatformIO) I love your devkit, i do not love the Arduino IDE, so if your kit forces me to use Arduino IDE, I am done with your kit. I am hoping there is a solution to this.

Yeah I've already tried the first two of the three below (from the link) and they didn't work. # These can be overridden in platform.local.txt compiler.c.extra_flags= compiler.cpp.extra_flags= compiler.S.extra_flags=

Thanks! I thought those flags were universal to all the hardware. I guess not. =)

The IDE is 2.3.4. I don't know the CLI version offhand. The problem occurs with both. And I rebooted. So it reloaded. No dice.

I'm not 100% sure this is a Teensy issue, but this technique works with my ESP32s Used platform Version Path teensy:avr 1.59.0 C:\Users\<redacted>\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0 Command executed successfully. Compilation completed successfully. Upload...

Thanks. Off to the TRM!

I do generate it in the correct order - big endian like the display. It's the SPI hardware that's doing the byte swapping. I want it not to. Adding. I don't care about the efficiency of the routine above. 95% of my data is transmitted via DMA.

I'm porting some code to make it friendlier to graphics libraries like mine and LVGL. I'm confused about byte order. See the if() in the code below. I know how to change the byte order of the else block, but not the if true block using the registers. I was hoping for some help there - the same...

Thank you so much! I'll definitely have a look at your code. Casting away const won't work because it would involve detrimentally modifying an existing cross platform graphics library I wrote (https://honeythecodewitch.com/gfx) :( Also I've run into scary issues doing that due to certain...

Sorry, to clarify what I'd like to see is this: readRect(int16_t x, int16_t y, int16_t w, int16_t h, uint16_t *pcolors) const; The way to make const would be like I said, to move all that internal state and SPI code to statics inside template classes, and then instance those *templates* with CS...

I've run into a problem with the optimized ILI9341 driver implementations by Paul S. and Kurt E. The issue is this: Reading from the display can't be done with a const class reference because the methods like readRect() are not marked const, which creates some encapsulation issues. It's also a...

Fair enough. :) I've been studying the datasheets side by side. I'm about as good at that as I am at reading sheet music, which is to say I'm terrible at it, but eventually get it if I squint. I'm much better with code. ha. I guess I'll be the first to try it. It's at least the same processor...