Finished programming (!?)

This is a great day. The sun is shining, it's about 29 degrees outside (This is Norway and it's not even June yet, so that is pretty good). And the drum machine code is now ready for extensive testing. I guess there are still some small bugs in there, but now all major and minor functionality is finished and the machine is playing cool rythms :-D

Next up will be to get some silk screen equipment and start work on the box. Also I've had to come to terms with a few shortcomings with the current controller design. The LEDs flicker a bit while the sequencer plays, and the encoders are a bit unstable. To overcome this I will have to build a completely new controller again (v5), with a separate led controlling circuit, and with dedicated encoder chips. However, everything works ok, so this wont happen for a while.

I had to re-make the ribbon cables between the controller and the keyboard as well. Half of the numeric keyboard didn't work due to some stupid wiring mishap. Now the only key that doesn't work is the left-key. I'm not sure why yet, have to get my multimeter out and start measuring :-D

I guess this wraps things up for summer, have fun untill the cold winds of fall makes it possible to be inside coding again :-D

Timers on the PIC mcu's

Here is how to work with timers:

1) The timer/counter counts once per microcontroller instruction
2) When the counter reaches it's max value, it overflows (starts at 0) and triggers an interrupt, which we can react to in our program.
3) One microcontroller instruction is 4 clock cycles long, which means that a clock frequency of 8MHz gives 2000000 counter ticks per second.
4) an 8 bit counter can tick 256 times before triggering an interrupt, a 16 bit counter ticks 65536 times. The maximum interval for a 16 bit counter is thus 65536 * (1s/2000000) = 0.032768 seconds.
5) To increase the interval, a prescaler can be added. A prescaler divides the instruction frequency. prescalers on the P18F458 comes in exponential values from 1 to 256.
6) A prescaler of 256 gives an instruction frequency of 2000000/256 = 7812.5
7) The maximum interval for such a timer is thus 65536 * (1s/7812.5) = 8.388608
8) To set the timer to overflow at a given time, we have to set the start value for the timer to a precalculated number. Ex: We want an interrupt interval of 10ms. For this, we can select a prescaler value of 4, which gives us 500 000 timer ticks per second. Without setting the timer start value, the timer will overflow after 13.1072 ms. As we know that one tick equals 1/500000s, we need to divide 0.031072 s by 1s/500000 to get the number of unnecessary ticks = 15536 (well, this was of course quite obvious, but for the sake of the example). We thus need to start the timer at 15536 to make it tick 50000 before overflowing and generating an interrupt.

Easy, right? :-D

Dial idea

I thought of a new cool feature last night - what if, instead of switching instantaneously between two settings, the leds would 'fade'/count down or up to the desired level (within 0,5 seconds or so)?

For example, say that 2 diodes are lit. then a change to 10 diodes is requested. Instead of instantly lighting the 8 diodes, they would lite up like 3, 4, 5, 6 ,7, 8, 9 and then 10, creating a moving indicator. Each diode could even fade in to make a more pleasant effect.

Encoder/leds circuit v1

I've started work on the led dial. So far I've left it to the users to decide if they want to use i2c or any other way of inter-ic communication, all data transmission pins are available as pin outs.

I've also added a mikroelektronika-compatible programming interface to enable programming of the chip after soldering.

The chosen mcu, pic18F2431, contains both a quadrature decoder and an internal ocillator, making the number of external components very low.

I have not yet tried the programming circuit like this, so it may have to be changed.

The schema:



The PCB. Dimensions 29 x 29 mm:



I still have some work to do on the footprint of the encoder, and of course have to find a way to solder this since the mcu, resistors and capacitor are SMDs

Digital LED brightness control

While working on the encoder-with-led-ring concept I figured it might be cool if I could control the brightness of each LED individually. For example, the led ring brightness could increase while turning a specific encoder, or the leds be brighter the further 'up' the ring they are.

I already intend to time multiplex the diodes to get away with a single resistor between 16 leds, so I thought, why not try using pulse width modulation (is that the correct term?) to control the LED brightness in software?

I just did a proof of concept, and although the picture below doesn't do the result justice, you can clearly see that it works :-D

the code for the test is dirt simple. Each led down the row is turned on twice as long as the previous one, exponentially increasing the time (but not the brightness):

Pseudo code of the program is as follows:

while(true){
PORTD = 1;
delay_us(10);
PORTD = 2;
delay_us(20);
PORTD = 4;
delay_us(40);
PORTD = 8;
delay_us(80);
PORTD = 16;
delay_us(160);
PORTD = 32;
delay_us(320);
PORTD = 64;
delay_us(640);
PORTD = 128;
delay_us(1280);
}

Encoder experiences

The encoders on the drum machine keyboard are working now. The missing leads discovered earlier were not the only obstacles I had to overcome. After fixing the circuit, the encoders still didn't work properly. For some reason, I had not thought about what would happen when the encoders stood still and did not have a connection to +5v. This, of course, would lead to floating inputs on the direction-detection flip flops, and no clear readings from the circuit.

I then added 10k pull down resistors to all the inputs, this fixed most of the problems and made it possible to detect encoder clicks.

However, if the encoder is turned slowly, one click of the dial leads to multiple detected clicks, as the circuit keeps outputting clicks, as the flip flops are not reset.

To fix this, I've added a state check in software. Clicks will only lead to events if a 0 has been read in between two reads of 1. This fixes most issues, but quick turns of the dial will in fact give fewer clicks than slowwe turns. Also, I've experienced a few 'backward' clicks in between the forward clicks, not sure what causes this.

But, all in all, things are looking very bright. The mode selection leds light up and respond to the encoder. Now I'll just have to get the rest of the keyboard up and running againg. And fix the head phone amplifier and get a license file for my compiler...