Search results

Very neat stuff! I wonder to what degree the representational aspects are preserved by the many stages of translation occurring here? You start with the emotion (anxiety) and you look at the neural spike recordings, and then you extract some features of that data and use those to drive the...

Honestly, I'm not entirely clear on why it's 50MHz instead of 48MHz; I was just going by the code in http://cache.freescale.com/files/32bit/doc/ref_manual/K20P64M50SF0RM.pdf in chapter 36, the Programmable Interrupt Controller, which assumes the PIT clock is 50MHz. It's entirely possible that...

Oops! Something weird is going on there--even if I make it #ifndef _avr_emulation_h_, I still get the error "cannot convert 'PORTDemulation' to 'volatile uint8_t*' in assignment" on that line, which is bizarre, because PORTD is defined as being of type PORTDemulation in a file whose first lines...

Oh yeah, stupid error--clock delay doesn't need to be nearly so long! I don't know why 100us didn't sound ridiculous to me. The 220us, however, is verbatim from the data sheet: (There's a diagram that goes along with it--the datasheet is at...

Hmm. On closer inspection, I'm *really* confused about how the updated code you posted is working. It appears to send the command code using your modified functions, but then sends the bar graph data using "sendLED," which in turn calls "send16bitData"--which is the old version, not your...

Ah! XOR isn't missing--XOR is an operator that the AVR emulation doesn't handle. Sorry for the confusion. I'm not sure how to rewrite the port-manipulation code to work on both platforms at the moment. Direction registers (DDRB, etc) also appear to be omitted, which may affect other code.

It looks to me like you've inverted the outputs of the LATCH function--in these lines: //PORT_Data &=~ BIT_Data; // set digitalWrite(DATA_Pin, HIGH); The original version you've commented out doesn't actually set the bit--it clears it. Since it does a bitwise AND with the negation...

Oops, you updated while I was writing my reply! Congrats on getting it working!

I'll take a stab at it. I'm not sure what's going on in the line where they've replaced "PORT_Data &=~ BIT_Data;" with "PORT_DATAx &=~ BIT_Data;". I'm not familiar with the keyword "PORT_DATAx", and it's not defined in the program, and a web search for it only turns up this post...so, er, I've...

Thanks for the tips! In fact both the mic and preamp are now working fine--I just hadn't connected things correctly. Once I corrected it to match the design in the preamp's datasheet, it worked fine. They also include specs for adding optional (switched) phantom power, which would make the...

@JBeale: Duly noted. The crummy power supply is just for proof-of-concept testing and experimentation--it offered the dual virtues of "having +/-5v and +/-12V" and "being in the same room." :) I'll use much better parts for the actual device. And the ADC--well, the Teensy's ADC is...

Also: I'm an idiot--the INA 217 data sheet shows the wiring for the mic, both with phantom power (non-electret condenser mics) and without (dynamic mics). Not sure why I forgot about that, because I knew about it previously--I even ordered some bits particularly for the circuit. Ah well...

Found this blog post: http://hifiduino.wordpress.com/2012/09/12/teensy-3-0-with-i2s-interface/ which links to an Application Note: http://cache.freescale.com/files/32bit/doc/app_note/AN4369.pdf Both of those are talking about using DMA and I2S, but they point to another way of doing an audio...

Cool! Thanks for incorporating the interrupt prototypes! If it helps at all, I've got some temporary code working for interrupt priority levels. It only works for 0-15, though; using 0-255 just resulted in the processor ignoring the lower-order bits. Not sure if there's a setting for that I...

Of course--I'm more than happy to share my code. It's nice to hear from someone else who's interested in the same sorts of applications. Output isolation is definitely a good suggestion. I'm just using crummy headphones for proof-of-concept testing right now, so I'm not worried about it yet...

As promised, finally, "playback.cpp": #include "playback.h" volatile int current_sample; int16_t buffer1[MAX_SAMPLES]; int16_t buffer2[MAX_SAMPLES]; volatile boolean using_buffer1; volatile int buffer1_status; // status of buffer1 volatile int buffer2_status; // status of buffer2...

Sure, yeah. I know the chip is deprecated, but since this is a one-off project, the DIP format seemed extremely appealing to me. I'm not very good at soldering, and the surface-mount components are really tricky for me--the audio DACs tend to be ridiculously tiny. I know I2S is standard and...

Thanks, that was exactly what I needed! Here's my line for NVIC_SET_PRIORITY, since that's not currently implemented in mk20dx128.h: #define NVIC_SET_PRIORITY(n, p) (*((volatile uint8_t *)0xE000E400 + n) = p << 4) I'm not completely certain that's right, for three reasons. First, I'm not...

Ah! Thanks, I never would have figured that out. I'm going to try that out now! Thanks, -Nick

Looking at the WaveHC library from the AdaFruit Audio Shield, it looks like they got things working pretty well by using double-buffering (one to fill while the other plays, with tiny buffers--only 512 bytes) and enabling interrupts during the reads to allow playback to continue. And supposedly...

Hi all. So, I'm trying to build an audio recording and playback device using Teensy 3.0. I'm pretty new at this stuff--I've been coding for years, but the hardware stuff still kind of feels like voodoo to me, so please bear with me if I make bizarre choices or silly mistakes. Arduino doesn't...

Sorry all! I guess I wasn't getting notifications about updates to this thread. Glad you were able to suss it out without me! I'm completely a noob at this stuff...I just cobbled it together through looking at the Teensy 3 source files and the K20 family manual. That's why the NVIC line had...

So, this is not entirely my code--I ported over the Arduino sketch from this article: http://blog.makezine.com/2008/05/29/makeit-protodac-shield-fo/ But it runs on Teensy 3.0 now, so that's something. It requires two changes to the C source, though. First, in mk20dx128.c, change "unused_isr"...

Okay, yeah, for the time being I need to modify mk20dx128.c to include the address of my interrupt handler (the 47th table entry is PIT timer 1, currently "unused_isr"). Presumably a later version will make it easier. I just jumped the gun.

Oh...I just noticed this aspect of the one of the kickstarter update pages, which talks about exactly this: Taking a look at both aspects (attachInterrupt and mk20dx128.c). I'll post what I find, in case anyone else is curious. -Nick

Accidentally posted this first in "Bug Reports," which clearly isn't right. Couldn't see how to move the post, so this is just a copy. Sorry for the double-post! I'm porting over an Arduino sketch that relied on the chip for timer-based interrupts. It looks to me from the documentation as...

Sorry, probably should have been in "General Guidance." Not sure how to move it--just copying the post over there. Sorry all!

I'm porting over an Arduino sketch that relied on the chip for timer-based interrupts. It looks to me from the documentation as though the proper timer to use for this on Teensy 3.0 is the periodic interrupt timer, PIT. So I did some setup: // Constants for bitvalues within the TCTRL1...