Better menu labels

Just a thought: What about changing the names of 'Patt' and 'Perf' to 'Steps' and 'Live' ? These are full words, not abbreviations, which I guess is a bit better.

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

File page on its way

I have started working on the file system and file page. I've landed on a design with 8 pattern groups (folders) with 12 patterns in each. In addition, a yet-to-be-decided number of songs and performance setups will be available.

The external memory seems to be working OK, however, I'm not sure I'm addressing chip 1 correctly. I've moved all LCD character data to the external memory and written a separate program to load them. This saves me a lot of RAM in the main program.

Lastly, I've added a slight longer delay to each LCD write, this completely fixed problems I've had with disappearing characters and errors related to the display. I've also connected the mode-dial to the different modes, making it possible to switch between the step sequencer, setup and file pages.

For some reason, no tracks are available when I disconnect and reconnect the power. Not sure if this is related to the internal saving of pattern settings, will have to check this later.

Feature update

I'm closing in on finishing the intended features. Three major things are not yet started: 'File' (pattern saving and loading), 'song' and 'perform'. Setup is almost finished, the same goes for the sequencer features.

Implemented and upcoming features:

Implemented:
- LCD support, inc time, bpm and play mode
- step sequencer
- record mode
- play/pause mode with correct tempo
- tempo adjustment
- clip board (multi track)
- accent
- velocity page
- velocity entry
- settings edit page
- Internal EEprom support (for persisting current setup)
- Flam
- Swap
- Swing
- Mute & Solo

Upcoming
- Song and perform modes
- Flam cut'n'paste
- Tap tempo
- Midi output... (This is almost finished but not tested yet)
- Midi input?

:-D

Performance mode - ideas

The intention with performance mode is to load patterns 'on the fly', allowing unique performances to be created from pre-programmed patterns.

Patterns can be loaded by name or number, but it might be a good idea to pre-assign patterns for easier access?

One could, for instance, assign a pattern to each of the 32 steps in the step sequencer. To queue a pattern for the next 'loop', one presses the according step button while in play mode. The assignments should of course be user controllable, and be saved as a 'performance setup'.

In performance mode, a pattern should be played/looped until a new one is selected, and the next pattern should not start before the previous one is finished. Also, it should be possible to add a 'stop' clause at the end of a pattern, automatically stopping playback once the end of that pattern is reached.

Perhaps it also should be possible to link patterns, e.g. group four patterns into a loop?

In song mode, the same patterns should be selectable (and assignable), but no looping is performed as a song is just a list of patterns to play.

Thought: Should it be possible to record a performance as a song, and edit it afterwards?

Display reconnected

I've just merged the older LCD panel code base with my newer keyboard/LED code, and also connected the LCD display to the new controller card for the first time. To my big surprise it worked immediately! Finally both the LCD screen and the keyboard are up and running at the same time. And it only took me about 3 years ;-)



I also constructed a new cable and added connectors to the LCD end as well, as the soldered-on cable started to show some wear and tear. As the connector on the controller end is a normal ribbon cable connector, but the other end requires a 2,54mm spacing of the cables, I had to add to come up with a special solution. I am very satisfied with the end result, both in terms of how the cable looks and how it will fit the system.

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

First keyboard/sequencer integration

For the first time since I began working on the project, the keyboard and leds now integrate with parts of the sequencer software. I've added the possibility to toggle the step leds, and switch between the 12 internal sequencer tracks. It is extremly fast and works incredibly well. I'm so really satisfied with the result! I should put up a video of this to show how cool it really is :-D

Also, I broke my PICFlash2 In-circuit programmer and had to order a new one from Mikroelektronika. Not sure what happened, but I think I put the power to my circuit on the power out pins instead of the power in ones...

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...

Updated design files

I have compiled a selection of up-to-date design files as well as the software created this far. The two archives can be found here:

hardware
software

Success!

Everything works like a dream now :) I've implemented all commands and tested the keyboard using the second controller as a loopback. It looks so good I can hardly stop working on it :-D

I may have to simplify the transfer protocol a bit though, to get increased throughput. Hopefully I can skip some error checking if I just make sure that no invalid state leads to a deadlock.

The remaining work on the keyboard is now:
- Glue some of the perspex pieces in place so they don't obstruct the keys
- Drill holes for the rotary givers and implement the necessary code
- Cut and solder the paths for the second row of instrument select buttons
- Fix the keys on the keypad that are not working (two signal paths)
- Fix a problem with S528 - it seems one of the switches does not work very well (a key release is send immediately after key press). I suspect this is a hardware error.

And then - onto coding the controlling software! Can't wait!

Inter-mcu communication working

I've finally got the communication working with both mcu's on the controller pcb. I ended up bending away pin 6 on the LCD/midi controller, to prevent it from interfering with the data transfer, and it works very well. finally I can test the transfer protocol :-)

All leds working

I'm back to working on the real keyboard circuits after spending a week debugging the soft_uart code. I've tested the leds and all work as expected, both as red and green. It looks fantastic. I've made some code testing a running light, and the outcome is really encouraging!

1 bit! 1 stupid bit!

Finally! I've discovered what has caused all my pain and suffering the last days. It appears that there's some kind of bug in mikroC, in the Soft uart library. This means that I manually have to send a single 1 after transmitting a byte. Doing this, everything works like a charm! Woohoo! I really love mikroC, but it has a few bugs too many. Still, I always get answers from the developers and it has a lot of built in features I would never ever manage to code myself if I had to write in assembler.

I've tried various speeds. It seems that 38400bps works fine, but at 115200 some bytes are dropped. At 38400bps I'm able to transmit 4800bytes/sec, (a bit lower really, there's some overhead), or about 0.2 milliseconds per byte. It could mean a slight delay from pressing a key to the result is received by the second controller, but I guess I just have to try this out. I could also try to up the speed to, say 57600 and see what happens...

Update: 57600 works fine.
Update: 57600 does not work for receiving data when the receiver runs at 8MHz. I have to try this again when both uC's are on the real board.
Update: To use PORTA, it is necessary to add "ADCON1 = 0x07" to turn off analogue inputs.

Inter-uC communicatoin

I am having some problems getting the soft-uart from MikroC to work properly. I have been trying to send data from PORTA.F4 for a long time without success. Yesterday, after first having some problems because I didn't connect ground on my prototype card to ground on the EasyPIC3 development board, I managed to use soft-usart-write to send data that could be received with the real uart of the other uC. However, When I send 0x36 using the soft uart, it is received as 0x13 on the other. I have no idea why yet, either the clock frequency is wrong or some interrupt delays the sending. Will have to work on that.

Also, I had to switch to PORTA.F0, not sure if I have broken PORTA.F4 or if I just need to disable something.. not a big deal anyway, but took ages to figure out.

Display working

I've rewritten my old sequencer code to accomodate changes to the circuit design. Some of the display pins were shifted around. In the process, I discovered that the circuit was set to use 8px wide fonts while my software uses 6px fonts. To fix this I've modified the cable between the controller and display. I've also added a jumper to version 1.2 of the controller hardware, making it possible to switch between 6 and 8 pixel wide fonts.

I had to add a 1us delay to the data output functions too, to prevent 'lost bytes' when writing to the display.

Files:
Eagle sch and pcb files (hardware)
MikroC software

Crystal learning

After some debugging of the controller PCB I've come to the conclusion that I've done a tiny but crucial error. When both mCU's are connected, the crystal won't oscillate. The reason, it seems, is because pin 9 on mCU 1 and pin 10 on mCU 2 are connected to the same pin on the crystal. On my prototype card I get oscillation when the same pin on both mCU's go to the same pin on the crystal.

I will update the circuit to accomodate the change. Guess I'll have to bring out the knife and cut some paths on the etched cards.. *sigh*