h4yn0nnym0u5e's latest activity

I’m not convinced FlexIOSPI actually honours the requested mode, so if you need anything other than MODE0 you’re possibly out of luck. I asked @KurtE (the library author) about it, and the response was

What sample rate do you have your Saleae set to? It’s noticeable that the bit banged SPI timebase is way slower than the LPSPI one.

That’s a very impressive amount of I/O already! I make it 85 “pins” if everything is done individually, plus however you’ve done the MIDI. I’d be curious to know how you’ve achieved that, if you have a diagram you can easily post. Just by...

Teensyduino 1.60 and its bundled Audio library should be as stable as it comes. It does not support the use of PSRAM as delay memory, either on a Teensy 4.1 as EXTMEM or on the audio adaptor. It does support the fairly ancient 23LC1024 on the...

In my experience, if you start getting hung up on a single issue it's often well worth the effort to back out of your main project and make a small example to understand and sort that one small area. If after that it still doesn't work in your...

That’s odd, I’ll have to check it doesn’t depend on some library modification that only I have. Shouldn’t, but you never know… AudioEffectDelay uses blocks you allocated using AudioMemory(). There is a somewhat undocumented limit of 896 blocks...

But even if your idea doesn’t work, your goal is achievable, as discussed in my post #4. Just use EncoderTool and one of its various hardware options. Despite the comment in post #7, the code does not require a PCB or surface mount components...

EXTMEM allocates from PSRAM soldered underneath the Teensy 4.1; if that runs out it silently allocates from DMAMEM (which may be what you mean by "the secondary onboard RAM area"). This is irrelevant to a Teensy 4.0, therefore, as noted in my...

I might be wrong, but one advantage I see of using Serial between the Teensys is that you just do a Serial.print.... and it's all buffered and your code can go and get on with other things.

Probably worth doing some searching and experimenting before committing to that route. I haven't tried it myself, but seem to recall people having significant trouble getting SPI comms working between two Teensys. I think they ended up using...

I've been messing around with FlexIOSPI to reasonably good effect, though it does have its quirks. I think it may fail to implement anything other than SPI Mode 0, but having raised an issue with the author I got only the response "No idea...

My improvements to the AudioEffectDelayExternal object, the PR for which oh so nearly got merged 3 years ago, allow use of PSRAM as delay memory, both on the audio adaptor and as EXTMEM (irrelevant for Teensy 4.0, of course), in addition to some...

Yes - looking at the library code, it has no accommodation for different processor speeds. Which Uno? There seem to be several variants.

Sure, there's something there. On a JPG image. I opened the KiCad and the PCB layout does indeed have components with A and K labels on the pins. But nothing on the schematic (apart from tiny symbols within the encoder outlines, implying they're...

You probably want to take a look at EncoderTool, which provides various ways of creating larger encoder arrays using fewer pins. I haven’t used it much, but the author is on here as @luni, though hasn’t posted for about a year. If you’re tempted...

Here's a test sketch I've used in the past. It's doing slightly weird stuff for me at the moment (lots of background noise) but that could be hardware issues. It compiles and runs OK. What version of Teensyduino are you using? #include...

Wow, that’s quite an investment in a reasonably niche component. Though I guess the hindsight suggests that they’re selling OK, and the problem now is reliable supply for restocking. So grateful for folks like you who put the effort into getting...

Specifically the work that I've done is based around being able to allocate a channel as pre-emptible (assigned from the upper 16 channels) or non-pre-emptible (lower 16 channels). Without both of the hardcoded groups it can't work. We did add...

Not I2C, I2S…

I believe that you can't have the DMA pre-emption / priority without expanding to 32 channels. However, as far as I know @jmarsh has already done all the required work there, so the only risk is if he's messed up in some fashion. I don't believe...

I hear you - it absolutely isn't consistent. But the old API would have to be left in place anyway, and it's "simply" another overload of the attachInterrupt() method, I think. Unless I've missed something The option to use lambdas would be...

comment removal in: https://github.com/PaulStoffregen/ST7735_t3/pull/40 and https://github.com/PaulStoffregen/ST7735_t3/pull/41

Easy enough to comment out until officially fixed. Looks like that’s a product which uses ST7796

Yes, I think he ordered about 100? Not a large order by semiconductor manufacturers’ standards… And he’s in the USA, and Rolf’s in Deutschland.

Yes, it’s still in Paul’s master branch - see here.

@jmarsh, since the DMA ISR has to go through a dispatcher anyway because of the shared vectors, do you think it would be sensible to add an optional “context” parameter to the attached user ISR? Having just a single void* would make so much...

https://github.com/PaulStoffregen/ST7735_t3. Or use my overhauled version at https://github.com/h4yn0nnym0u5e/ST7735_t3/tree/dev/big-screen-t4-muxedCS.

Using PSRAM as frame buffer isn’t as slow as you might fear. And we do now have the option of 16MB parts, though I don’t know how easy they are to get hold of. Having said that, it probably does make sense to have another Teensy just to run the...

That sounds about right to me, though @jmarsh will have the definitive opinion. I believe he’s done all the necessary work on the DMAChannel side, just a PR needed. On the audio side, the stuff I’ve been doing has got way out of hand! I’ll try...

Which were suggested in post #24: Your response (after a digression into isolation transformers - fine for audio, no use for 800kHz digital) being Well, yes. You need a new can, the old ones are smoking your Teensys. Several flavours of worm...

Note that I added (but failed to document in the ReadMe…) a setSPISpeed() method, so you can call tft.setSPISpeed(80’000’000) from your sketch, rather than messing about editing the library source.

That’s good. I’ll try to remember to come back to this and explore which combinations of pins and library modifications do and don’t work, and see if further fixes are possible.

Well … apart from the suggestion of opto isolators, made over a week ago in post #18, and expanded on with specific part numbers a few posts later. For what it’s worth, that’s absolutely the way I’d go.

That’s great news. I’d hoped that might work, but hadn’t had time to try. Once again kudos to @alex6679 🤩

Because, if you’ve gone back to the Teensyduino 1.60 version of the library, the async updates are broken, as I found out last May. It just occurred to me … can you try some different pin choices with my fixed library? It might be worth avoiding...

That’ll be the one. A discussion about the reason for this sketch needing access to the storage() method can be found here. You disabled access in this commit, but maybe it’s worth re-enabling?

Reporting in here on some progress I've made on fixing FIFO lengths, and knock-on "improvements". I started in on this, and found I was doing a lot of copy/paste, which really bugged me. So since it seems likely we'll need to do some pretty...

Well, it's working here, so there shouldn't be a problem with audio. I did have to add a couple of lines to enable my audio adaptor, but I'm guessing you're using something which doesn't need that. On a slightly different note, your example's...

OK, found it. You don't have a frame buffer, so actually all the screen updates are synchronous. But, I hear you say, I called tft.useFrameBuffer(true);! Indeed you did, but you failed to tell it that you'd already allocated the frame buffer, so...

OK, I'm looking at this now. It looks as if there's something weird that's triggering async updates on every write to the frame buffer, not just when we ask for them. The longer TFT_CLK is probably because you're updating the whole area of...

Not that I’m aware of. Obviously I can’t run the code you posted because it’s incomplete, but I wouldn’t expect that flickering. I’d expect screen updates to be quite slow because you’ve called updateScreenAsync(false,false) rather than...

Audio shield uses 19, 20, 21 and 23 … so yes, there is a conflict. Documentation here.

Yes. You're the best. The `mcp0.begin_I2C(0x21, &Wire1);` line was missing from the `setup()` function. Thanks a lot :)

Fairly sure you need to call some sort of begin() on your mcp0 object before you do anything else with it…

I think it's fine here, it's still DMA related since that's how the FIFOs get filled (and DMA being preoccupied is why the watermark should be higher).

Ah, that’s interesting. I’ll grab all the reference manuals and take a look. @jmarsh, is there a better thread to take this to, or should one of us start a new one? Otherwise your excellent work on DMA risks getting sidetracked…

Sure, I got that. But your post #35 suggests there’s a difference between the K66 and RT1062 watermarks, and I’m just not seeing that. It seems to have been done wrong for both…

I kept meaning to look at this ... and now I have ... and I'm not sure I'm seeing what you're seeing. both seem to use a FIFO watermark level of 1 Teensy 3.x have an 8-word FIFO, 4.x have 32 both the reference manuals seem to say that the FRF...

I think you're more likely to get some help if you can make it a bit clearer what you're doing now, and what you think could be improved on. By far the best way to do that is to post a brief but complete sketch that can be compiled using the...

Sorry. Its my bug. I used my old example. Your example works fine. I'll try it in my project :) Display ST7796S FrameBuffer and Audio Test