Toy Synthesizer

Toy Synthesizer: Boards have arrived

So, I had a surprise delivery this morning… 10 PCBs for the new synthesizer.

These are just two-layer affairs… with the idea being that anyone can manufacture these themselves. The top layer if made at home is done just by covering one side of a double-sided PCB with tape. The other can be done by hand with a dalo pen, using photographic methods or using toner transfer.

One thing I did have originally, and lost when I told Kicad to delete all footprints when re-working the design, is the mounting holes in the corners, something I’ll have to re-add.

I’ll have to pick up some 74HC574s (or perhaps ‘573s, since that’s what the hobby shops sell… won’t matter for this project, either will do) and get soldering this weekend.

2017/06/09 by Projects Public Syndication Toy Synthesizer 0

Toy Synthesizer: First working prototype

So… after some cursing at me being dimwitted enough to get the amplifier around the wrong way… and luckily the amplifier is a tough little beast… I managed to get some basic functions going.

It is supposed to be polyphonic, the synthesizer supports it, and it does actually work, but it seems my GPIO arrangement isn’t picking up multiple buttons correctly.

Ahh well, we’ll get there. 🙂 At least it is making noises and flashing lights on cue, so in that sense, a minimum viable product has been achieved.

Ohh, and I was able to bump the sample rate to 16kHz. 32kHz was a bit much for the little MCU though, it couldn’t quite keep up.

Code size at this point is 3.6kB… so still lots of room left. The answer might be to implement an I²C slave mode so I can interrogate it from the host.

2017/05/28 by Projects Public Syndication Toy Synthesizer 0

Toy Synthesizer: Getting OC1B & OC1D to play together

So… a bit of head scratching this afternoon. I had working PWM on the LEDs… which was fantastic.

With the trade-off of LEDs being ⅛ brightness maximum, which is fine since the LED strings that I’ve been given for this project would make Manfred Mann proud…

I was a little stumped with my audio PWM. I could not get a peep out of it, not via the amplifier or anything else. Tracing back, I was getting nothing out of the PWM pin. Real strange. Looked up the data sheets, couldn’t see what I was doing wrong.

My code for initialising Timer1 looked like this:

	/* Timer 1 configuration for PWM */
	OCR1B = 128;			/* Initial PWM value: audio */
	OCR1D = 32;			/* Initial PWM value: light */
	OCR1C = 255;			/* Maximum PWM value */
	TCCR1A = (2 << COM1B0)		/* Clear OC1B on match,
					   nOC1B not used */
		| (1 << PWM1B);		/* Enable PWM channel B */
	TCCR1B = (1 << CS10);		/* No prescaling, max speed */
	TCCR1C = (3 << COM1D0)		/* Set OC1D on match,
					   nOC1D not used */
		| (1 << PWM1D);		/* Enable PWM channel D */
	TCCR1D = (0 << WGM10); /* Fast PWM mode */

It looked fine… even checked the header files to see there wasn’t some cock up in the headers. Never had an issue with avr-libc, but you never know, and of course, no problem there.

In exasperation, I swapped setting up TCCR1A and TCCR1C. Bingo, I had PWM both channels. Why? Turns out there are some bits in TCCR1C that shadow TCCR1A, and I was inadvertently setting those back to 0 when I set up TCCR1C. So my code now:

	/* Timer 1 configuration for PWM */
	OCR1C = 255;			/* Maximum PWM value */
	TC1H = 0;			/* Reset counter high bits */
	TCNT1 = 0;			/* Reset counter low bits */
	OCR1A = 0;			/* Initial PWM value: spare */
	OCR1B = 127;			/* Initial PWM value: audio */
	OCR1D = 127;			/* Initial PWM value: light */
	TCCR1A = (1 << PWM1B);		/*
					 * Clear TCCR1A except for PWM1B,
					 * we'll configure OC1B
					 * via the shadow bits in TCCR1C
					 */
	TCCR1B = (1 << CS10);		/* No prescaling, max speed */
	TCCR1C = (2 << COM1B0S)		/* Clear OC1B on match,
					   nOC1B not used */
		| (3 << COM1D0)		/* Set OC1D on match,
					   nOC1D not used */
		| (1 << PWM1D);		/* Enable PWM channel D */
	TCCR1D = (0 << WGM10);		/* Fast PWM mode */
	TCCR1E = 0;			/* Not used: PWM6 mode */

We still need to turn PWM1B on via TCCR1A… but we set the output control mode via TCCR1C to avoid clobbering our settings.

Having fixed that, I now have a second problem, in my dead-bugging of the amp, I got my left and right arse-about, which would explain why my amp is making no noise. That’ll be a tomorrow job methinks, at 22:30 UTC+10:00 it is too dark to work on PCBs. I’ll just keep myself amused looking at the waveform on the oscilloscope.

2017/05/27 by Projects Public Syndication Toy Synthesizer 0

Toy Synthesizer: Peripheral detection and I²C bus enumeration

So these are some completely untested notes on how I might achieve auto-detection of peripherals and I²C devices.

The idea here is that a peripheral can be plugged into any of the 8 ports on the device. It won’t matter, because there’ll be a standard boot-up procedure, consisting of:

  1. Deriving an I²C bus address (possibly by sampling ADC LSB bits to generate a random address) and verifying that there are no clashes by attempting to poll the derived address a few times.
  2. Performing a read of the bus roll-call I²C address to enumerate the IDs of all automatically-addressed I²C devices on the bus. During this step, the GPIOs are monitored: the slave should pulse the GPIO it is connected to as it “calls out” its ID.
  3. Measuring ADC readings at the GPIO pins and observing power-up state (common GPIO pin in high-impedance state)
  4. Pulling the common GPIO pin (MISO) high and seeing which GPIO pins go high.
  5. Pulling the common GPIO pin (MISO) low and seeing which GPIO pins go low.

The peripherals may be connected via a number of ways:

The boot-up procedure is used to determine what is attached, by performing some simple actions and observing the GPIO pin, which thanks to the ‘4066s, also doubles as an ADC.

As for I²C addressing… I do not want to have to program a unique address into each device. The concept here is instead that each device generates its own address, waits for a clear moment on the bus, then tries polling its proposed address to see if it gets an ACK. In the case of a time-out, it waits a random length of time and tries again when the bus is clear, and after a few times, can safely assume it has the address.

This gives rise to a problem though, knowing what the addresses of the neighbours are.

The idea here is to use a roll-call address. This is common to all units implementing the auto-addressing protocol. When a device hears the roll-call address, it tries to send its ID in reply. When another device with a numerically lower ID sends at the same time, the device sees the collision and tries again on the next byte. As each calls out its ID, it pulses the interrupt pin low (if it uses one).

The result from the master’s perspective is it sees a stream of IDs sorted from numerically lowest to highest, terminated by a stream of 0xff bytes. Direct peers are able to then detect who their peers are.

Timing of all of this will be the challenge. We want to ensure everyone has a unique ID by he time the first roll-call is performed so we can move on to detecting the dumb devices (LEDs and buttons). This network feature will be a stretch-goal of the project though, so plenty of time to think about that.

2017/05/27 by Projects Public Syndication Thinktank Toy Synthesizer 0

Toy Synthesizer: PWM Outputs work

So, I’ve done some tweaks to the prototype… namely fixing some wire assignments. I also had to drop my 1kΩ resistor on the input to a 100Ω as the voltage drop of the 1k was too high.

At the moment, I am seeing ~3V at the MCU, which is good enough.

Beneath the afro of wires, is the prototype.

… and this is the PWM LED control in action (animated GIF). So PWMing the output enable of a 74LS374 works, and doing the same on a 74HC574 should too.

So, I’ve done some tweaks to the prototype… namely fixing some wire assignments. I also had to drop my 1kΩ resistor on the input to a 100Ω as the voltage drop of the 1k was too high.

At the moment, I am seeing ~3V at the MCU, which is good enough.

Beneath the afro of wires, is the prototype.

2017/05/07 by Projects Public Syndication Toy Synthesizer 0
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

July 2026
S M T W T F S
 1234
567891011
12131415161718
19202122232425
262728293031  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon