well I've never used a pic before, I've used picaxes, so I don't have any hardware/programmer circuits/programs/etc. so I really need to know what to buy to do what I need, part numbers are useful as I always hate getting the wrong stuff as I then have to reorder/pay more delivery I think rotary encoders would be good, if you can give me a link to a good one, and how to use it with a suitable pic (again, pick me one ) that'd be great and also some help on how to PWM outputs..
16F88. Pic a rotery econder thats suiteable for your mounting + tactile responses, almost any should work, post here and we can advise.
erm I can't seem to find one that looks right. I'm not too sure what I'm looking for on rotary encoders as I've never used ones... there seem to be really expensive and really cheap and a few quid each ones. binary, hex, decimal, ones with lots of pins, ones with only a few?!?!? perhaps 3 pots and a switch would work easier (only 4 pins)?
You could even just use one pot and a button to change between the colours levels if you don't want to use a rotary encoder. That makes things even simpler as the A/D converter is a peripheral.
hmm, I'd like to be able to change the colours though, so like I can just change the pots (by twisting them) to get like lots of different colours...
What I mean is that you could twist the knob to change the brightness for the reds, press the button and then set the brightness for the greens, and again for blues, then the same for the 2nd set of LED's.
yeah but then you can just change different values for the colours at the same time (ie, just mixing as you go, you need to set a red, set a blue, then go back through just to change the red).. something good would be: set the three values for led set 1, then press a button, that 'saves' it into the pic and keeps outputting those colours for led set 1, but then you can set led set 2, and press the button to save and then it will not set anything, then pressing again will set no 1, but changing the pots while a certain set is selected will change the values as you go, like a 'live' mix... understand?
hmm after thinking about it overnight, just digital control would probably be okay. if I can do something like what special k did, then I could try to make a VB app with 6 sliders that'll change the values over serial.
Okay, trying to get back to the original problem... May I suggest you start a new thread 'computer'? Maybe a kind mod could to a bit of splicing to seperate the two? Once again, it looks like TheAnimus is closest to what I want. What you were suggesting sounds something like what I'm envisaging I'm reading through your code trying to get a handle on what it does - I think I'm starting to make sense of it now. Couple of questions - what d'you mean by 'light' logging? ...and why are only 8 useable? I'm not quite sure I understand that bit? I've done some assembly before (for some motorola chip - 68hc12 I think) and I've done a lot of C, but I'm struggling to follow the flow of the example you gave. Could you give a more pseudo-code-ish version so I can get a bit more of an idea of how what you suggested operates? I've got a feeling that working out which colour / effect to do next may take too long with this method. Either that, or it'll produce some peculiar / jaunty looking lights which stutter. Your earlier suggestion in Post 14 of using interrupts sounds more suitable. Having re-read it a few times, it makes sense now (it didn't before ). Ah, but I don't just want PWM, because I also need to alter the duty cycle dynamically, for each channel - R, G, B. I get the impresson that what I'm trying to get out of this is being slightly miss-interpreted.. ? Let me try and make how I imagine it to work a little clearer... There are basically 2 things I want the LEDs / Luxeons to do... 1) Strobing effects - flashing on and off. Turn the light on / off at different speeds. This could be as simple as just flashing at a constant speed. I'd like to be able to program more sophisticated steps though, making the length of the dark / light sections vary (that make sense?). 2) Colour - the ability to reproduce a massive range of colours. if I could control each led through 256 levels of brightness, then by setting each LED to different brightness, the resulting combination of R, G and B should mix to produce ~16M colours! Now what I'd like is to be able to switch colours - not just by changing suddenly from one to another, but also to smoothly fade. This diagram might explain it a little clearer : The strips are some different effects I'd like to produce with the horizontal axis being time.
well the code i've listed there would give you, 9*9*9 = 729colours. (8 + off=9). getting 16 differn't PWM values from an internal oscilator is very difficult to do and have something left for micro time while avoiding flicker. to get more values, you will probably need to use a 20mhz oscilator. This makes it easyer to get the low light levels on the LED without flicker. The idea there can be extended to the 16bit tmr0 register too, but there are other ways of making pwm in code.
hmmm... well, after thinking about it for a minute, 9 would be fine - 729 colours is LOADS - I doubt you'd see much difference in this application. There's just one thing I don't quite follow with your idea. You mentioned I'd have time to execute a small amount of other code, but I can't see how you'd go about timing it so that the PWM remains smooth? Is that what the interrupt does for you? [Edit]Thinking about it, I can see how the lower light levels would be more difficult to reproduce - lower light levels require lower duty cycles which means there is a bigger gap between pulses. Makes sense [/Edit]
I can't see how you'd get a smooth fade between colours with only 9 levels. Even with 64 levels the steps are visible towards the lower brightness levels.
The interupt does just that, interupts your program execution, and does that code. I should of explained the LOG bit, i brought it up on a thread a while back, when i was trying not to use a micro for throbing an LED. Basically we see light levels logrythmically (just like we hear things log). This means, for there to be a small gradual step, we have to half the level. So getting the LED to be just dim is often hard. Even a 1 in 65536 dutey cycle its suprisingly bright. I would have a play myself see whats best for you. The code i used before i: MOVLW 0xC0 MOVWF TMR0 That had the effect of making the TMR0 interupt happen every 63 cycles. This means the code's limitation is that it will only allow you go 1 in 256 dutey cycle. (its actually 1*64 in 256*64 cycle). Its these 64 cycles that u have avaible this code isn't very efficent, but you should be able get some stuff done in that.
Okay, that makes sense now. I had a feeling that's what you meant by logs - I've worked with some digital acoustics before and stuff like niquiest (sp?) frequencies when you're sampling spring to mind. I guess the best way forward now is to do as you suggested and try some stuff out - see what works and fiddle with it 'till it does. Thankyou all for the help and advice - it's been extremely gratefully received! If you have any further thoughts, let me know - I'd be very happy to hear anything you have
Yup, sounds about right to me. Had a quick google, but couldn't find anything to confirm. Is that for a fixed image etc. though?
what we're effectivly doing is making a fixed image, much the same way as a CRT VDU does. I'm fairly sure its 76hz. But you will probably find aiming for 80hz won't be a problem.
Whoa... No way for his application (if that's what you are suggesting...)! 76Hz will give him a visible flicker if he plans on moving the source of the light (which he will be if he plans on waving the sticks around, which is what he said he would be doing in his first post). Google persistence of vision and propeller clocks. -special [k]