Search results

Hi all, I am wondering the limits of this board — could it run 128x196? Or more? I realise refresh rate starts to go down… James

Presume then that then MegaCAN variable should be volatile?

Hmmm — I was using FIFO. If the mailbox has more than one frame in it —*how can I ensure that they are all dealt with in one go? or is that not possible? I'm using MegaCAN which has quite a hefty parsing 450 line switch statement with 63 cases...

Thanks, @tonton81 and @msadie If I'm using interrupts... and can.events() in loop() —*will it process all the frames in one go? or does it rely on the loop to iterate through them? I'd like to add an update flag to the interrupt — so that the display only bothers to update when there is new data.

Got a fresh bare SN65HVD230 working. 10k from RS to ground, 100R across CANH and CANL. That was all. Seems that the breakout board I originally bought was duff. Tempted to try out the TN330/332 as that seems newer and... probably better? Also saves me a 10k resistor by the looks of it. I have...

Thanks! Somehow missed this.

@RayanR — could you draw up your final schematic? Would be super useful.

Does anyone have a working recipe for interfacing a Teensy 4.0 with a Megasquirt? I'm having issues with a SN65HVD230 and my MS3. I'm not getting anything back.

Thanks @luni — I guess in real terms the library doesn’t really need the power of 4.0

@luni — just wondering if the library will work with the new Teensy 4.0

My main reasoning here is that the 1V2 internal reference is less noisy than the 3V3 — if that's not the case then I'm not so worried.

Hmmmm... But I can't use 3V3 for the pots and 1V2 for the other inputs. And more so, cannot use 3V3 for the inputs and 1V2 with the DAC.

No way*—*APA102s are wayyyyyyyy faster thann WS2812.

All, When using the ADC and DAC — I presume the internal reference is pretty much always preferable over the 3V3? Along with various inputs and DAC outputs, I have pots on my board that are currently powered by 3.3V —*the issue being that I cannot switch to 1.2 reference without powering them...

Hi Paul, Sorry, I should have done this in the first place. I've checked the inputs and outputs manually — and they're working fine. #include <Audio.h> #include <Wire.h> #include <SPI.h> #include <SD.h> #include <SerialFlash.h> // GUItool: begin automatically generated code...

Hi all, Does the ADCS object work with 3.6? I don't seem to be able to get it to work. James

Updated the part to correct this a while back — just found this reply. Hopefullly it's right this time but I haven't used the extended version on a board yet. James

WAV playback — but synth stuff would be useful too. I don't mind slightly lo-fi. James

Thanks @MickMad That all sounds about right. Simplicity is reasonably important to me — so being able to do it with a quad opamp would be good.

Thanks Frank!

Hi all, Does anyone have any advice/suggestions on suitable filters for the on-board DAC? Butterworth/bessel/sallen-key etc I'm drawing up a board to help me play with the Teensy and a filter on the audio sounds like a good idea. James

Hi Frank — is there a schematic for the audio out filter?

Doh —*in messing around getting those images to show up I deleted the zip file —*sorted now

Totally — and it makes total sense when it's on a breadboard — but this is for an Eagle device. Assuming the USB host will do midi at some point I already have an idea for something I want to make whereby breaking out those to a USB connector will be needed.

I've updated the Eagle devices I made in this post: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=114719&viewfull=1#post114719 Enjoy!

I don't see why you wouldn't break that out to socket? Or are the pins not the standard 0.1"?

Ok — that's cool — make sure you include the disclaimer! I'll PM you when I've made the simplified version.

Hi all, Here are a couple of Eagle devices for 3.5/3.6. Let me know if anyone has any thoughts on improvements etc I've listed the different pins but only the primary ones —*for instance only the first channel of SPI and I2C etc — I figure this means you can put it in to Eagle and connect...

Thanks! I've set it up like this: adc->setReference(ADC_REF_3V3, ADC_0); adc->setReference(ADC_REF_3V3, ADC_1); adc->setResolution(16, ADC_0); adc->setResolution(16, ADC_1); adc->setSamplingSpeed(ADC_VERY_HIGH_SPEED); adc->setConversionSpeed(ADC_VERY_HIGH_SPEED); And I had set...

So I'm being silly here... If I do this... ADC::Sync_result result = adc->analogSyncRead(A2, A3); in = result.result_adc0; analogWrite(A14, in); The values are right — but they seem to wrap around. Is it because it returns a uint32? I'm not getting it.

Hi all, So I have a self-built Teensy "3.1" and am having some issues with analog in. I know that this has worked fine before when I've been using a standard premade Teensy. So I am not sure what is going on. I am using a opamp to scale an input of -5 to 5v to 0 to 3v — which is going to the...

Hi Paul, Doesn't seem to make a difference. Did you note the adjustments I made to the Audio library above? James

Great! It was just the CS in the wrong place —*was using 10. All sorted — thanks Manitou!

Hi Paul, I did install the latest SD library and uncomment that line —*it certainly improved what I was trying to do before. I'll double check when I get home. James

Reading another thread I presume that this chip works with the library. I get this when running the hardware test: Raw SerialFlash Hardware Test Read Chip Identification: JEDEC ID: 0 0 0 Part Nummber: (unknown chip) Memory Size: 1048576 bytes Block Size: 65536 bytes Reading...

Makes sense. The odd thing is it will often work for a bit and then crash. And sometimes only on one object. So I wonder if there is a way to prod it back to life.

I've been playing with my code a bit more and found that setting a low buffer seems to make the Teensy audio library crash when you hit it with a lot of .play() really quickly. Usually leaving only one of the AudioPlaySdRaw instances working — sometimes taking them both out. (I have two running...

Changing AUDIO_BLOCK_SAMPLES to 16 in the core AudioStream.h file gives me a latency of around 1.5ms Changing to 32, 64 etc does as expected and increases it proportionally. Is there any way of defining AUDIO_BLOCK_SAMPLES in my main file rather than going and editing the core file? *EDIT*...

If fat is slowed down by addressing etc - how about copying it from FAT and in to the last few Mb of the SD card using the direct SD read library?

Frank - so am I not gaining anything by not opening every time? Mxxx - I just commented out the .close() Linuxgeek - the sample is very short and finishes before it gets triggered again

As seen here:

So as expected, it now gives me a minimum of 6ms latency — maximum of 8.5ms or so. The latency progressively gets smaller until it gets to 6ms at which point it jumps back to 8.5ms. Presume this is in time with the audio update. bool AudioPlaySdRaw::play() { if (!rawfile) {...

We already have a playing state - so that is covered. Don't think there is a need to make a differentiation between stopped and paused. I reckon it's best not to make any assumptions of what is happening. So play() just plays from wherever you are at*— to make the file go back to the start then...

True, best not to break the current model. Maybe then add an open(filename) and a play() — alter play(filename) to use the open(filename) if there isn't a file already loaded.

Cheers. I didn't have time to look at this yesterday. The more I think about it the more sense it makes to follow SD card conventions and have open() close() Then play() and pause() don't do anything with the file side of things.

I'll start by expanding play(char filename) to also just play() — and add a load(char filename) that doesn't play.

Just doing and "rawfile = SD.open("file.raw") takes 3ms. So for sure that is adding to the delay.

So my quest is to try and reduce the latency of the PlayRAW function whilst playing via A14/DAC. It takes 3ms to open a file from the SD card — and my use for this is to play samples repeatedly. Looking at the code it's not doing anything clever to avoid opening the same file on a second call...

Yes, apologies to Pensive for the thread derail —*that's my fault. I've made a new thread here: https://forum.pjrc.com/threads/28974-Audio-Library-Play-Latency?p=76155#post76155

Thanks all. I timed the SD.open function and it takes 3ms for the RAW drum sample I am testing this with. Reading those threads — it can take as long as 2.9ms to run the audio update? — which may account for the variation I was seeing. Is there a way to force an audio update straight after a...