64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

peepsalot posted:

Yeah i was thinking maybe storing a hardcoded lookup table of a quarter of a sine wave and flipping it around the different ways to get the full wave.

The CORDIC algorithm might be helpful for generating sine waves without a hardware multiplier.

One way I can think of offhand to do instrument sounds would be to record a short (0.1 second-ish) snippet of that instrument playing a sustained note, and then play that snippet back at a faster or slower rate. Digitize the sound, then FFT and un-FFT it to get a symmetric sample that won't blip when it repeats.

A less satisfactory way may be to try to figure out a harmonic profile for the instrument you want to replicate - i.e. a piano might have a fundamental tone with amplitude 1.0, a second harmonic with amplitude 0.5, third harmonic at amplitude 0.1, etc., and so you generate those harmonics and blend them together with appropriate relative weighting. Then you'd change the harmonic weightings to get 'flute' or 'tuba' sounds.

# ¿ Nov 24, 2012 23:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 06:25

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

You'd do the FFT/iFFT in a pre-compute step on a normal computer, then download the result into whatever memory was on your board and play it back faster or slower to pitch shift. The purpose of the FFT stuff is to make sure that if you have a sample length of T seconds all the harmonics in the sound have periods that fit into T seconds in integer multiples so you have a minimal 'skip' when the sample repeats.

The FFT stuff may well be overkill though, and best left to a later polishing stage. Maybe just try getting a 4kb sample to play in a loop at variable speed and worry about making it sound pretty later.

# ¿ Nov 25, 2012 01:09

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Martytoof posted:

If I wanted to have my uC produce a lifelike sound instead of a harsh "BEEP" through a standard piezo speaker, what would be the best/simplest/cheapest way to implement something like that?

I just mean like a lifelike bell "*ding*" sound, not an mp3 or ringtone or anything like that so I think a full on SD card MP3 player circuit would be way overkill.

Suppose you go back to the analog world for a second, where the circuit below produces a Vout signal like the one shown in the plot when the voltage source is a step function at t=0:

That output looks like a bell ringing at about 700Hz and decaying over about one second. You could apply that voltage to your speakers to get a 'natural' bell sound.

To get that signal output without needing any analog circuitry you can write down the analog circuit equations to solve for Vout in the time domain, then use the discrete step approximations of the time derivatives to get a step-update equation that looks like (*handwaves away a page of algebra*):

vp = (2*v0 - vn) + (vn - v0)*(dt/(R*C)) - (v0*dt*dt/L*C));;

where vp is the current value of Vout, v0 is the value Vout had on the last iteration, vn is the value Vout had two iterations ago, and dt is the time between iterations.

That probabally looks like a mess, but the code comes out to be pretty simple:

C# code:

        void Oscillate()
        {
            float vp = 1f;
            float v0 = 0f;
            float vn = 0f;
            float L = 5e-3f;
            float C = 10e-6f;
            float R = 10000f;
            float dt = 1e-5f;
            float t = 0f;
            float tMax = 1.0f;

            while (t < tMax)
            {
                // shift the old values one notch backward in time
                vn = v0;
                v0 = vp;

                // update the new values of vp and t
                vp = (2 * v0 - vn) + (vn - v0) * (dt / (R * C)) - (v0 * dt * dt / (L * C));
                t += dt;

                // TODO: apply new value of vp to speaker output here
            }
        }

dumping the output of that code into Excel verifies that it gives the desired result:

You can mess with the initial value of vp, and the values of R,L,C, and dt to manipulate the sound pitch and decay duration.

# ¿ Dec 16, 2012 22:51

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

More of a hardware question, but has anyone had problems running a uC programmer off a laptop?

My AVRmkII programmer works like a champ when plugged into my desktop, but when I try to run it off my laptop the programmer LEDs blink and I don't get any errors in the IDE but the new code only seems to transfer over to the chip about 20% of the time. The other 80% of the time the chip just resets and runs whatever old code was present like nothing happened.

I'd assume that the physical interface must be optoisolated, so the power supply of the laptop floating slightly relative to the dev board shouldn't be an issue, right? Maybe the laptop USB port can't supply enough power to run the programmer?

# ¿ Sep 22, 2013 23:18

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Delta-Wye posted:

This is what I would guess. Flashing can be a bit of a current hog. I wouldn't have guessed it would have been enough to reset everything, but who knows.

I checked the specs on the programmer and it can draw up to 200mA, so that might well be the issue. The next step would be to try to dig up a powered USB hub and route things through that to see if it works.

One thing I don't get however is that it seems like not having enough power to flash properly should return some kind of error - either the programmer would get corrupted data parroted back on the MISO line or the chip's memory would be corrupted. Neither of these things happen though, the IDE doesn't report any programming errors and when the chip doesn't update its code the old code continues to run just fine. :shrug:

# ¿ Sep 23, 2013 01:44

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Anyone know of a microcontroller that can do a 3MHz A/D conversion at about 8 bit resolution for about 2k points per trace? I have an analog system in mind that would run at about 300kHz and is going to need a uC installed to turn parts on/off, and it occurred to me that it'd be pretty sweet if we could run some of the signals through an analog mux to an A/D port so we could monitor single signals from a remote PC. It'd be like having a lovely oscilloscope right there on the board for debugging/tuning the system.

Unfortunately this is turning out to be a rough thing to Google for (uC + ADC + fast is not a helpful combo). I found one XMEGA chip that could go to 1MHz, but thats about 3x the frequency I'm trying to monitor and dangerously close to the Nyquist limit. Any other good options?

# ¿ Oct 21, 2013 01:45

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

^^^ Well that inspires confidence :v:

Sinestro posted:

Some PSoCs (the highest end 5LP models) have a 2MHz ADC.

Edit: http://www.cypress.com/?mpn=CY8C5667LTI-LP009

Cool, thanks for the suggestion! I haven't played around with PSoC stuff before but it looks like an interesting option.

# ¿ Oct 22, 2013 01:06

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Atmel Studio 6.2 (set up for an ATtiny24) is taking this ISR handler code

code:

int ISR(TIM1_COMPA_vect)
{
    return 0;
}

and returning this warning message: "type of 'TIM1_COMPA_vect' defaults to 'int' [enabled by default]".

It spits up even more warnings if I remove the initial int or the return 0 which I don't think I've ever needed to include in an ISR declaration before. Any idea what is causing this issue?

# ¿ Sep 24, 2014 03:25

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

^^^ That's the version of ISR I've always used and expected to work this time. It looks like the ISR macro isn't defined now though (see below).

Mr. Powers posted:

Do you need to do ISR(int Name)? Normally your function attributes come before return type, but I don't know if that is required. I guess it depends on what the ISR macro expands to.

That seems to work! And it led to another realization which is that the ISR macro doesn't seem to be defined anywhere. The compiler thinks I'm just declaring a new function named ISR which is why it wants me to be specific about argument and return types.

Now I just need to figure out why TIM1_COMPA_vect (and other common things like PORTA or DDRB) are properly defined in the AVR libraries for this chip but ISR is not. I'll dig into that tomorrow.

Thanks for the replies, both of you.

# ¿ Sep 24, 2014 04:39

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 06:25

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

EpicCodeMonkey posted:

Include <avr/interrupt.h> to get rid of the undefined macro warning.

This seems to be the key thing I was missing. Previously I've always used ATMega chips and the Atmel Studio setup for those includes an asf.h file that then includes interrupt.h for you. It seems that the ATTiny setup doesn't have an asf.h analogue so I have to include things manually. Not a big deal once you know about it.

Thanks again for all the helpful comments.

# ¿ Sep 25, 2014 02:40

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread