Search results

Maybe i didn't publish a specific teensy article? I thought i did. hmm. oh well, it's been years and my memory is dodgy on a good day. in any case, the code is largely the same, so that article covers what runs on both of them, except for the last mile hardware interfacing.

Sure. But usually you have to make that choice during the design cycle, by which i mean you typically can't just pick and choose. You're either backbuffering or not, so generally you don't have the luxury of deciding for each individual draw scenario. In my "real world ish" tests - dogfooding...

There probably was at one point, on codeproject, where i produced an article about it. However, codeproject went dark (again) recently. I suppose I could rebuild the project. I have at least most of the components around here somewhere still. Edit: Here's the gitbub repo...

The best thing as always is to profile. The one thing to remember when you work your figures though is (a) to use DMA you MUST build a bitmap, even it's all one color. (b) to use DMA *effectively* you really should keep two backbuffers such that you can draw to one *while* the other is being...

I'm not sure how many pins the Teensy can control with DMA but NXP chips are generally pretty capable, so my guess is that it is possible, but non-trivial. The ESP32s have support for DMA with i8080 parallel but i've not seen anything for the teensy. then again, i haven't looked that hard.

That's essentially my point about the "data density" of transactions. Drawing bitmaps allows you to always fill your entire transaction window with data. You're dramatically cutting down on the total number of SPI transactions that you need, and that means less overhead, which means faster...

You seemed to understand, but just in case: I mean writing to bitmaps, writing those to the display. Critically, using DMA to do so, so you get the 20%-30% throughput increase as well, and combining that with a dirty rectangle algorithm so you're only writing bits of the display that have...

Adding, the first rendition of my graphics library for embedded - htcw_gfx 1.x - used direct writes, including a bunch of tricks to speed those up. It wasn't fast enough. In 2.x I got rid of all that for performance reasons, and now I use my htcw_uix lib to do demand draws using my graphics lib...

It's an extreme case but it's also a contrived case. In real world applications, you'll find things like LVGL that use backbuffering can paint faster than similar code using TFT_eSPI because of the way applications typically operate in terms of where and when they need to paint. That's *why*...

I just came here to say if you're looking for maximum performance, direct SPI writes are not the way to go. What you want to do is backbuffer to a bitmap, and then use DMA to transfer bitmaps to the display. The reason is simple. It's math. The density of data per transaction is far greater...

Last I heard the 1170 was too large for what they wanted. I don't know about the other chip. Shame too. I really like the 1170 I have.

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.