Help to output pulsetrain based on adc readings

[buzzlightyear]

I'm trying to come up with a pulsetrain device, using the 08m2, details in the comments in the code, but if anything is unclear let me know!

symbol Trig =  pinC.3
symbol PulseRate = b0 'Pot connected to pin 1
symbol PulseAmount = b1 'Pot connected to pin 2
symbol Spread = b2 'Pot connected to pin 4

main:
readadc 1, PulseRate 'this is the rate of the pulses
readadc 2, PulseAmount 'this is the number of pulses from 2 to 8
readadc 4, Spread 'this is the addition of delay between each individual pulse
if Trig = 1 then 'on rising edge of input pulse in C.3, C.0 to output pulses according to the pot settings
'if while a pulse sequence is active a new input pulse arrives then restart the pulse sequence,
'if no input pulse then set C.0 to low, loop around main.


goto main

The pulses are only output once the input detects a rising edge, the input pulse is of unknown and changeable duration, and if a new input is detected the output pulse sequence is to restart.
The spaces between the output pulses will be in the milliseconds range (lets say 5-100ms variable, for now) the individual pulse length will be around 5ms, I want to be able to specify (by way of 3 pots) the number of pulses output, the rate of the pulses for example every 10ms, and the spread which will allow the rate to be non linear, for example 1-1--1---1----1-----1 or 1-----1----1---1--1 etc

Not quite sure how to implement all this, so any help is welcomed, thanks

 

[AllyCat]

Hi,

No replies, perhaps because you haven't told us the application and we can't guess all the undefined details. Also, what is your experience, are you "comfortable" with interrupts, PWM, PEEK/POKE of SFRs and using the "unsupported" on-chip hardware such as timers and capture/compare latches, etc.?

Basically, we need to know the tolerances and "jitter" that you can accept for the timing. Jitter will occur with any software- (Program) controlled events, depending on what (else) the program might be doing at the time, even (or particularly) if using interrupts.

So, for example, what time delay is acceptable between your input edge and the first pulse? Does the program need to detect another input edge DURING an output pulse? If so, should the pulse stop immediately or continue to its end; then how long should the gap be, etc.?

Cheers, Alan.

 

[hippy]

It's quite an involved problem to have an answer on a plate for but it can probably be approached iteratively.

I would start with a scheme which provides a variable number of pulses in response to the trigger and get that working and handling restarts on a new trigger. Though I would be tempted to perhaps ignore restarts before the output train has finished to begin with.

Then add a pot which specifies the gap time between pulses.

Then determine how the gap will be varied and how the linearity will change and add the third pot to control that.

 

[buzzlightyear]

Hi Alan - Sorry for not being clearer, basically the 08m2 input pin (C.3) will be connected to an external logic gate, upon receipt of the high on pin 3 the pulse train sequence starts, but if the input detects a high before the sequence has finished then it restarts, so lets say the pulse train is set to 8 pulses, a pulse at the input starts the sequence but only 5 pulses have been output before a new input pulse is received, so a new sequence of 8 will be output. The timing needs to be as accurate as is realistically possible, because eventually this will form part of a larger project to do with rhythmic timing, but the input pulse will be of undefined duration so I'd like the sequence to start (or restart) within a millisecond or better ideally from when the input goes high. I suppose as tight a loop as possible will be required, I think that I will want the pots read inside the timing loop perhaps at the start of the loop, before any pulses are output, I have no idea how the interrupt will fit into it or if there is another way to detect a new pulse?


My experience is absolute beginner, I have made a few successful projects through trial and error, feedback and help from this forum, modifying other code and sometimes a bit of blind luck I am gradually learning more by experimenting but have yet to delve into some of the more advanced stuff like with interrupts, PWM, PEEK/POKE but am very keen to learn how to implement these. I bought the David Lincoln book but unfortunately it does not cover the kinds of things that I am wanting to do - or perhaps it does but my lack of application of some of the concepts is eluding me. I have used ADC, input, output, pin handling, variables for things like counting, setfreq and disconnect, jumping around the program using subroutines and labels and a few of the other simpler things, but I do find that applying some of the concepts to what I wish to achieve is where I struggle sometimes.

Hi Hippy - I see your point and that is sound advice, at present I am stuck on the part of using the pot to determine the number of pulses I'm thinking perhaps a for next loop but maybe that will not be the optimal way once the other pots are added - what do you think?

Thanks for the replies.

 

[AllyCat]

Hi,

As hippy says, your whole project is quite involved so it's proabably best to start simply. Reading the pots is easy and doesn't need to be done too often, only between the output pulses, or even only between the "bursts" of pulses. Assuming the pots are connected between the PICaxe's rails (Vdd-Vss) then basically use a READADC into a byte and divide by a value to give the number of steps you want, e.g. divide by 32 to get 8 steps.

The main factor is whether you use the resident commands (e.g PULSOUT) or do all the timing with software loops. The former will give you "calibrated" times, for the latter you will have test and measure. You can't test a pin (or even detect an interrupt) during a PULSOUT so you would have a problem if the "rising edge" starts and goes away again DURING an output pulse.

Cheers, Alan.

 

[buzzlightyear]

Thanks Alan, I did do as you suggest and got something working ok on the simulator, but when I transferred it to the hardware it was not working properly, possibly due to the breadboard or maybe something I have overlooked, for now I am going to take a break from this one and focus on something else, I have been reading up on some of the things you mentioned in your earlier post (SFR's and latches) although not totally understanding it all yet, but thanks for the pointers.

 

[hippy]

Thanks Alan, I did do as you suggest and got something working ok on the simulator, but when I transferred it to the hardware it was not working properly, possibly due to the breadboard or maybe something I have overlooked, for now I am going to take a break from this one and focus on something else

You are always welcome to post your circuit and code here and members will be take a look. It may be something obvious or simply an oversight.

There often are some issues in taking simulated code to real hardware because the real world can be quite different to the artificial, stepping through code and toggling simulated inputs isn't the same as using higher speeds and physical inputs.