Tempo/speed control of MCU

[bunker]

Hi all. I'm starting to read up on PIC programming and I've got a question I've been struggling to find an answer to. Am I barking up the wrong tree or is there a simple ish way to control the speed of a sequence programmed into a PIC? I've read that the clock rate can be altered so the instructions of a loop (BSF, BCF etc) can be carried out more 'slowly'. Is this true? In which case would you use a variable frequency squarewave oscillator fed into the OSC IN of the PIC? Or do you need to use a look up table with a range of tempo/BPM values written into it that will execute the loop at a predetermined speed? Basically I want to build a simple sequencer based around a PIC. Nothing too fancy but with a few basic controls including tempo. A clock input from another sequencer would be stunning but thats another issue.

As I'm learning I want to start small and use it as a test bed to try stuff out on, learning as I go so I don't want to start with someone else's code as I'm not really learning if that makes sense?

Sorry for my ignorance, I've never had any programming experience so all this is completely new to me. I've bought and read a couple of PIC books aimed at the beginner (flashing LED's etc.) but I must admit its a bit of a learning curve!! I'm trying to get to grips with Assembly Language and I'm getting the hang of it I think so I'm reticent to start trying to learn C, a language I know a lot of you guys use.

I get that 'so near but so far' feeling regarding PIC chips; i can see how I could programme them for all sorts of uses but I keep hitting stumbling blocks. When I try and find answers I feel like I'm being blinded with science and feel even further away!

Thanks in advance!!

[gdavis]

Look into setting up a timer to trigger an interrupt that increments the sequencer step. Use an analog input to read a potentiometer and covert that value into the timer period based on what you want your speed range to be.

Timer based interrupts are flexible, accurate and free the processor up to do other things. For these reasons they are very common for tasks that need to happen at specific intervals so this will be a good learning experience for you.

[bunker]

Hey thanks for that. I've briefly read about interrupts, but just the basics (ie washing machine door opens etc) . I'll have a read up and see if it starts to make sense! Thanks again!

[bunker]

I've a very brief look around and I think I understand what's required!

You set a counter running which counts up on each clock cycle. When the counter over flows it causes an interrupt which in turn advances a timer. I'm assuming you somehow tell the PIC how many times to count up and its this figure which effectively controls the speed of the sequencer?

for the sake of illustration and without using the correct maths I'm assuming it would be something like

start counter
count to 255 (one increment of the timer)
10 increments of the timer later (lets say for the sake of argument that takes 10ms)
generate interrupt (advance one step of sequence)

start counter
count to 255
20 increments = 20ms
generate interrupt (advance one step of sequence but at half the tempo of the previous example)

So would you write a look up table with each of these 'count totals' corresponding to a voltage applied to the a/d input?

eg.

3 volt = 100 counts = 1Hz = 60 bpm
2 volt = 50 counts = 0.5Hz = 120 bpm
etc.

I know the maths is ignoring the clock frequency the PIC is running at and the prescaler etc, I just want to make sure I'm looking at the right thing!

Thanks again!!

[gdavis]

The exact implementation may vary a depending on the features a particular processor offers.

You shouldn't need a look-up table, the math should be straight forward. Save your memory.

With a 16 (possibly even 8 ) bit counter and scaler options it should be plenty slow enough to not need to count overflows, but depending on the processor you might want to go that way.

I'm not really familiar with the PIC family but it sounds like the basic timer just does a simple count up with overflow. You can adjust the time it takes by pre-loading the counter. So for example if it takes 1 sec for an 8 bit counter to count up from zero, pre-load it with 128 and it will take 0.5 sec. This would be a more typical approach than counting overflows as it will generate fewer interrupts (let the counter do the counting, don't count the counter). The downside is it sounds like you have to pre-load the start value again every time it overflows but I wouldn't worry about that for the speeds a sequencer would be going.

More advanced PIC timers will have a match register which you can load with the desired count value. Then the counter will start from zero and overflow when it reaches the match register value instead of counting all the way up. This match register only needs to be set when you want to change the tempo, not every overflow, so it's a slightly better option than the basic one above. But again, at sequencer speeds either should suffice.

[bunker]

Thanks so much for that! I need to get investigating a little further but its starting to make sense to me now. As I said previously I'm completely new to programming so it takes a little while to sink in and make sense! The final option of loading the counter sounds like the best option, I'll head over to the Microchip site and see if I can find a target device.

Just out of interest what MCU family do you have experience with? What, for you, are the pro's and con's of the different families? I opted to go with PIC as there seems to be quite a lot of info out there for novices such as books, articles etc. I'll be writing in assembly language as this seems to be the default for PIC's and at 35 instructions I'm guessing it'll be easier to learn than C.

Thanks again for your help.

[gdavis]

Well, I'm actually an electrical engineer, so a lot of my knowledge is more theoretical than first hand I learned assembly on processors like the 8086, 68000 and an old DEC pdp-11. At work we used to use ARM based processors but have recently created our own processor.

I'm a big believer in using what you're comfortable with. These days we have so many choices with comparable features for just about everything that I think feature comparisons become secondary when deciding on a brand or line of products. Any of the popular lines will have products suitable for just about anything the average (and even many expert) hobbiest wants to do. Things like budget, availability, ease of use, support etc. become more important.

I got an arduino nano (based around atmega328) to play around with at home because it was inexpensive, based on an established line of MCU's, simply connected through USB and used freely downloadable drivers, IDE and SDK. Probably not as neatly packaged as the PIC products but I was used to this sort of thing already so it wasn't too difficult for me to set up.

For the average hobbyist a broad support base is important and PIC definitely has that. I don't have anything against PIC, it's just that at the time I was searching for my first kit I didn't really have any specific plans in mind and PIC seemed like more of a financial plunge.

By the time I started with the synth stuff I'd already messed around with the arduino a bit so just stuck with that since it was at hand. Right now I'm just using it for a basic midi to CV/GATE for my otherwise all analog project, but if I get into adding more MCU features to this project I can see using it up pretty quick, so I might end up upgrading to another AVR or ARM based product simply because it's what I'm familiar with.

I come across PIC projects all the time on the web so I might get into it one of these days, but for now I have more than enough to keep me busy.

[AT]

The advice to use interrupts is good advice. Once you learn them, life is good. It's tedious to set up at times, does require a good reading of the Interrupts area of the datasheet.

If you want to intake a clock from another synth you can (making sure the voltage is 0-5v max) set up a pin for a High/Low edge interrupt, then sync to that.

PICs have several kinds of interrupts and you will be checking which flag exactly is the one involved (unless you know there's only going to be one vector in, for instance).

This I am about to say comes with the caveat that development may or may not be be at a halt, but I use Oshon Software's PICSimulator IDE and PIC18Simulator IDE to do things the assembly folks say can't work. And it has a simulator, so you can learn things without burning chips and scratching your head too much (you will still, but not as much)

http://www.oshonsoft.com

For your kind of work either way, you'll want a chip with a 16 bit timer, more are better (18F series generally has up to 3 x 16 bits in various forms), 16F typically only has one) and if it's overflowing too soon, you can 'prescale' it, and now you are cool (though you might need to adapt your maths elsewhere).

If you don't want to use prescaling, you can count overflows as noted, that's not hard, and works just as well and actually provides you some increased 'resolution'. 8 bit timers will be overflowing way too much, including by the time you exit the interrupt, depending on your overhead there. So, 16 bit timers are the ticket I'd think.

Some theory...forgive any errors please.

Assuming an 18F Series (18F1320 for instance)

A 16 bit timer gives you roughly 65536 'counts' at overflow, so say your chip is running at 20Mhz, then you have 5,000,000 instructions per second (each instruction takes 4 clock cycles, generally)...so that means about 76 overflows a second of the 16 bit timer, assuming no prescaling, which just means the timer pulse is divided. Prescale of 2 would give 38 overflows for instance, prescale of 4 would give about 19 per second...and so on.

If you intake your ADC info using a potentiometer, you can assign your longest time period as some factor of the value 1023, shortest to 1 or 0, with some minimum being in play.

Let's say you wanted to have a minimum time of 96 notes per second...you would be fine with a non-prescaled interrupt.

If the time you wanted for 'maximum' was 1 note every 2 seconds, then you will be counting overflows during the interrupt until the value reaches 152 or so, then fire off your clock pulse or note on/off sequence. (assumes no prescaling)

Psuedocode...

Set up PIC...

init ADC, etc
init timers and interrupts...set timer to 0 or other value.
// Timer overflows once past 65535.

MainLoop:
CheckADCInput // there you will be setting the timer and var timePeriod
If fireInTheHole
Fn FireNoteOff // outputs the note on/off, etc
fireInTheHole = 0
endif

goto MainLoop

ISR: // on interrupt

if due to Timer1 Interrupt flag // Pseudocode
overcount = overcount+1
if overcount >= timePeriod
// Do your Note out/note off, etc
// Set a clock pulse, or a flag var
// for your main loop to do now
overcount = 0 // reset to zero
fireInTheHole = 1// Main loop will act now
endif
Timer1 Interrupt flag = 0 // not how you really do it but...
resume

You will want to account for cycles and such if other operations can throw off your timing enough to be heard. If you need more 'resolution' or overflows, just reset the timer period during the interrupt itself to overflow sooner. (set it to already be at 1/2 done for instance to 'double' the interrupts, period = 32767, etc). You can also handle things during the interrupt itself...if timing is super critical.

Hopefully this provides you the gist of one way to approach this. I'll be doing this myself soon for a gate hold and pulse out generator, then I can help more, but I'm not an assembly person. I admire those who can do it. I just mind my business during interrupts so as not to bog them down too much, and the basic works out alright.

Another way, get an Arduino...there's lots of demo code. I'm used to PICs, and enjoy them, lots of control you have, but I have a Mega 2560 to play with some time.

rc

[bunker]

Hey RC, that is a huge help! I won't profess to understanding it entirely with my first read through but I do get what you are saying. Thanks very muchly!

I have been very tempted by Arduino and others have pointed me in that direction too but I was really trying to find my programming feet, so to speak, with one family of devices and one language. Maybe I made a bad call with PIC/Assembly, I just thought the language would be the easiest for a novice to pick up and run with plus most of the 'beginner' books that I have seen (and the two that I bought) are based on PIC/Assembly. I did buy an introduction to C (or something similar..) but I'm afraid it scared me off a bit! My head was already throbbing when I started reading it and I found it a bit of a struggle.

I' have a good study of the pseudocode that you so kindly provided and the theory behind the operation then cross reference it to the books I have (timers, ISR's etc) and I'm pretty sure the pennies will start to drop into place!

Once again let me thank both of you for taking the time to help me out

[AT]

Glad to help. You have not made a bad call to use PICs or assembly. PICs are well supported, lots of history, lots of potential still. Depends on your personal taste, there's no right or wrong way.

Learning assembly is not a wasted effort by any means, you have more low level control of everything, and what you learn can convert over to other chips, you just learn a different syntax for the calls mostly, and the registers.

The benefit of the BASIC environs I mentioned is that you can mix and match, include assembly inline...so, no wasted effort. On the other hand, if you can do assembly, then you can use Microchip's compiler, and it is free.

For what you can do with assembly, and PICs, including things which are up your alley goal wise, check out Tom's site, it's the max!

http://www.electricdruid.net

Another good BASIC environment if you like that kind of approach is Proton IDE (Crownhiill in UK publishes that) but it is more costly.

You needn't even use interrupts for your first efforts. Just count main loop cycles and upon reaching your preset threshold, fire off your note, etc. Unless you are doing a lot of ADC in the middle, timing shouldn't be thrown off all that much. But you can limit the effects of that as well.

For example, I set my own chips to only sample the ADC every 40,000 loops around...this provides roughly 125 checks per second at 20MHz, which is fine for setting a 'switch' that way, a range. Unless you are turning the knob really fast, you won't miss anything. But that's how I work it. You can also set an interrupt to fire from the ADC...another way...if it changes.

The plus side of working with interrupts is that what you do there is King, and even if you are in the middle of other code, it skips to the interrupt and there you go, then goes back. (such is why you need to save and reload some system vars on occasion).

Lots to learn, but not impossible, just baby step it. Get your programmer and chip set up first, and remember if using an 18F series at 40MHZ with an external clock, there's a 4x multiplier in the chip, so 10MHZ crystal or resonator does the trick...just need to set the PLL setting and voila, you are at 40MHz. Blink an LED at 1 per second to confirm your clock rate got set right. If it's not as you think, there's a setting off (assuming good 'wait 1 sec' code in place : )

I like PICs for low cost, lots of existing code as well. Arduino does seem to be taking over the IDE and prefab board lands these days though. But I've always liked the underdogs.

If you need a good PIC programmer, I got a PICKit 2 clone from www.piccircuit.com via ebay and it's worked wonderfully, only $30 or so, and came with ZIF socket, a huge aid.

I'm a wordy writer person, so apologies for any over-speechification. Good luck in your explorations. Your goals are achievable. These little chips are the max.

If you haven't seen it check out the Hammond B3 thread on this top list...that is amazing to me. Can't imagine how he programmed all that. So now I have to get a Propeller.

rc

[bunker]

Hey rc, no need to apologise for your speechification! The more the better! The bizarre thing is that I was inspired to start learning about PIC chips after visiting tom's site! I really like his adsr and lfo circuits and that go me thinking about programming. As I mentioned earlier I'm trying to avoid using chunks of other people's code as I don't feel I'm learning by doing that.

I've got a cheap programmer I bought from maplin (a uk electronics store) and I've done the flashing led thing with it! I use a mac so I had to press an old dell laptop into service as it was the only thing I could find with a serial port!!

Thanks again for your assistance and good luck with your project! I'm in work this weekend but I'm hoping to get a bit done with the programmer and your pointers. Ill keep everyone informed of how I get on.

Bunk.

[blue hell]

[bunker]

Hi Jan. Yeah I read about people having issues with different programmers/USB to serial adaptors and I thought it would be just my luck to get a setup that didn't work! At it happened it was a handy move getting hold of the Dell as it allowed me to play about with a couple of applications my Mac wouldn't run. (At the time I only had a PPC Mac, I've since invested in an Intel model). I've actually got an adaptor/lead that I never used in the end.

Thanks for your input! (Excuse the pun )