h4yn0nnym0u5e's latest activity

Earlier probably at default 16 MHz - so with that the current library giving MIN=12ms and MAX=56ms, and audio playing again no issue

It’s only being called a second time because there’s no clean way to set up the display with DMA and a specific IRQ priority, given the legacy API. Hence I’ve tried to graft on priority setting after DMA begin(), because we don’t know the channel...

This is great - thanks so much for testing, it’s really useful.

New commit, can do async update of the changed (rectangular) area of the framebuffer, which saves you keeping track yourself. See update mode 9 for an example. Thus far this can’t also be continuous, but who knows what tomorrow will bring?

Having some issues changing the interrupt priority after it's been attached. Your code allows it to be set if the vector is unused or you're attempting to raise it, but doesn't allow you to "change your mind later". Would it be sensible to allow...

That sounds about right. I tried to follow what @KenHahn said about the changes he had to make for the MINI, so it should be rotated correctly, not have the red LED illuminated, and have the inversion set correctly. Indeed, the clip update is...

I'm hoping to make some changes to streamline the user experience with this, but those are unlikely to touch the basic principles of how the clipped async updates are done.

Sure, here you go. Note this is a "snapshot in time", so could potentially go out of date if @jmarsh find bugs or needs to make changes. The .zip includes a link to the exact commit - obviously don't put that in your cores/teensy4, just the code!

Yes, software support will happen. #784 already merged. It will be in 1.60-beta5. I might rename "qspi_memory_base" before updating LittleFS, and minor changes like removing the unused PSRAM_IDs[] array might still happen, but small details...

Now that's a clever idea! Do you plan to make a PR for this? Apart from those of my own making, I haven't had any issues with it, and I can't see that there would be any.

New update pushed. We now have the ability to update a clipped area of the display asynchronously: create a framebuffer create an intermediate buffer with useIntermediateBuffer(#bytes) - I used 1920 bytes, enough for 2 full screen lines write to...

I did that so any combination of cores and LittleFS will work - people get into so much trouble by having a forgotten tweaked library installed! old+old: obviously OK old cores + new LittleFS: no variable in cores, LittleFS falls back to...

I can never find notes left on a commit :( Good point on the PSRAM_IDs array - it was only for debug. I'd remove it, but Paul's now pulled the changes. I feel there's enough obscure register bashing in the code already without doing weird...

Looks like my changes to cores have been pulled in :) Guess it’s easy to tell that it hasn’t broken use of existing PSRAM, even if you don’t have the new one to try… hopefully LittleFS is pending acceptance of your offer, @KenHahn, or maybe the...

Yes - I stared at that for quite a while trying to pick holes in it, to no avail ... then the penny dropped. void DMAChannel::attachInterrupt(isr_t isr, uint8_t prio) { // since two channels share each interrupt, use whichever priority is...

Making progress, I think. I noticed that interrupts are shared between DMA channels X and X+16 ... and SPI was on channel 0, and Audio on 16. Creating a dummy DMAChannel in the right place pushes Audio to 17, and it all starts working. So...

The memory-to-memory is assembling pixel data from separate framebuffer lines into a continuous stream. Say the clip area is 80x80, the minor loop copies 80 uint16_t and updates the source pointer to the start of the next 80 pixels on the next...

After a long gap I'm coming back to this, and using it in anger! It's definitely made an improvement in my attempts to have audio and asynchronous TFT updates co-existing, but I'm not quite there for some reason. If I can't figure it out I'll...

Don't see why not - since you're loading the entire TCD from a memory image each time, that image can have arbitrary contents including looping back to the start. That does sound like you'll be hogging the DMA hardware permanently, though, which...

Sure, but you cannot set NBYTES greater than 16 (for SPI), so saying "You can safely set NBYTES to whatever value you like" is misleading...

Not quite true, I discovered, though your suggestion of NBYTES=8 will be OK. I think the minor loop is relatively dumb, and fires out NBYTES whenever requested, all in one go. Because the SPI FIFO is only 16 words, setting NBYTES to a greater...

Yup, as implied in I said you’d need to do plenty of datasheet reading :) Given your need for 8-bit transfers, each TCD could have a major count of 25,000, so you’d need 8 sets of settings for a 200,000 bytes fire-and-forget transfer. Very doable.

Two PRs submitted for cores (#784) and LittleFS (#60). Tested with one or two 16MB PSRAM parts, and one plus a QSPI Flash.

The question is a bit ambiguous … but I’m pretty sure it’s about SPI transfers, not memory-to-memory. I just noticed the ‘scope settings … don’t use 1x on your probes, 10x is the correct setting for most purposes.

Most (all?) of the DMAChannel stuff seems only to make use of the major loop, which can only do 32767 transfers (section 6.5.5.32 in the Reference Manual); depending on the transfer size of 8, 16, 32 or 64 bits, you could get up to 262,136 bytes...

I will reach out to SparkFun.

Perhaps, but I fear their buying power would be measured in tens of thousands per annum at best, and ISSI probably wouldn't be interested in spinning up the fab lines for fewer than a million. I'd love to be wrong about that, and they must have...

None of the parts on your list appears to be the IS66WVS16M8FBLL. Most web searches seem quite happy to give you some vaguely-related part if there isn't an exact match, unfortunately.

Nope, it’s a 3.3V part, same footprint as the standard 8MB PSRAM, and a glance through the FlexSPI commands used vs. the datasheets suggested nothing needed changing apart from allowing the new chip ID and detecting its size (shamelessly cribbed...

So it would appear. I’ve diverted back to ST7796 display stuff for a while, but when I return to this I’ll check that LittleFS can be fixed to coexist nicely, and then there’s a nice neat PR package. Sounds like a good challenge!

I've pushed up a commit which gives you a way to switch the hardware over to the Mini Platform using one macro; change #define notMINI_PLATFORM to #define MINI_PLATFORM. If I've missed anything or got it wrong, please drop me a PR and I'll fix it.

You had something similar happen when you were making some connector mods and the CS pin got left disconnected I think. Along a similar line, when I first modified the prototype to go from ILI9341 to use the new ST7796, I forgot to cut an inner...

Hmm. I'm not aware of anything I'm omitting from the torture test startup that I should be including. One would hope that tft.init() would include everything needed, but maybe not. Is your software online somewhere I can look at it to see what...

I've pushed another commit which should fix the mode 4 (whole screen in one DMA) updates, and has the sgtl5000.setAddress(HIGH) commented out; I've jumpered that back to the default address on my hardware, so it shouldn't be a problem for future...

Thanks - I'm quite pleased myself! Unfortunately there's still nowhere one can buy the IS66WVS16M8FBLL - they're still only showing as "sampling" on the ISSI site. Hard to say when distributors might have stock; the datasheet is Rev A January...

Ah, yes, sorry, I’m always doing that. My poor long-suffering test audio adaptor has had its I2C address changed - I really should change it back, or fit a jumper. I haven’t been rigorous about re-testing all the update modes as I go along; when...

I've got hold of a few IS66WVS16M8FBLL chips (3.3V 16MByte), and have managed to get the cores to initialise them correctly. Two of them show up as 32MB, and the standard PSRAM test passes. I don't have a lot of Teensy 4.1s knocking about, so the...

This sounds a bit similar to a sound variously reported as ticking or buzzing, when recording to an SD card on the audio shield. See this post and surrounding discussion for possible remedies, though they don't seem to work for everyone. Reading...

Just been having a brief dig around the web - I don’t have any RA8875 hardware. The driver code doesn’t seem to have any asynchronous update capabilities, which is possibly because there’s no way to fit an 800x480 frame buffer in the Teensy’s...

Your posted code is unreadable! Could you please edit your post to put it in the code tags (circled in red), and check using the preview (green). The toolbar may look a bit different, I‘m on a tablet…

…or delay() … We’d need to see your wiring (schematic and image, ideally), and more / all of your code, posted in </> code tags to preserve the formatting, if the problem persists after fixing that. If your code is too big, please write a small...

More updates... attachInterrupt() renamed to setDMAinterruptPriority() mid-transaction break added in DMA+IRQ asynchronous updates, i.e. those started with updateScreenAsync([true|false], true); updates to torture test Brief testing so far...

I've started using VSCode for more complex editing tasks (though I do try to ensure all my example code works out of the box using the Arduino IDE...). Anyway, if you install that, and open the folder...

Based almost entirely on this post, a typical Teensy 4.1 might be expected to run at about -20ppm. Given that Tascam are pretty reputable, I'd be surprised if their kit is dramatically worse. A one second difference would be 555ppm, well outside...

OK, I've pushed a bunch of changes to the big-screen-t4 branch, which should include continuous updates now working again - use UPDATE_MODE values of 3 or 7 in Audio_TFT_Display_torture_test.ino to test. Apart from those, there are some...

Years ago I looked at slow responses for misbehaving bots. Maybe there is some way to do it, but it's tricky to accomplish without tying up resources on our side while the connection remains open. For an idea of the scale, yesterday's log file...

I started by aiming to break up the long SPI transactions into short chunks, so the display doesn’t hog the bus when it’s shared with other hardware needing regular access (audio being the known candidate and test case). That’s essentially done...

Ah … I’m talking about the Teensy-optimised library. Thread at https://forum.pjrc.com/index.php?threads/st7796-teensyduino-support.76510/

I'm messing about with the ST7796 driver, and it tries to infer the SPI bus in use from the SCK and MOSI pins specified in the constructor. I'd guess it should be fine if you use the "primary" pins (black on the pinout card), not sure about the...

Good point. I added a MIT license. Did you already test the usb interface with more than two channels?