newbie Q - edge detection?

Hello

I'm looking through the PB Pro manual, trying to work out how to detect a rising edge on a port input (for a PIC such as a 16F628, for example).

I want to detect edges rather than levels - rising and falling - on inputs and generate output pulses which occur as a result. The inputs will be (0V-->+5V) or (+5V-->0V) transitions, derived from TTL or CMOS input pulses or clocks etc.

By the way, I realise that there'll be some propagation delay through the PIC due to machine cycles etc. but that's not a problem - a few us in a few tens of ms is a small per cent delay. I should also note that I realise that I can differentiate the input with hardware in order to provide a narrow pulse and measure it with PULSEIN etc - I want to see if it can all be done in firmware though.

Can anyone suggest how to build a routine in PBPro? I can't see from the commands in front of me how to go about it (I am assured it is possible in ASM but that's a bit ambitious for me at the moment).

Cheers for any pointers - I'm having fun at the moment downloading example .BAS files and compiling them to the hex and ASM results, in an atttempt to relate the assembler listing to the basic source.

RMC, England

look in the datasheet about Interrupts on change... on some PORTB i/o

Interrupts are the best way, but if you can't use those you can do it as follows:






TopOfLoop:

If Old.Y ^ PortX.Y > 0 THEN
Old.Y = PortX.Y
IF PortX.Y = 1 THEN GOTO DoSomething
ENDIF
GOTO TopOfLoop


DoSomething:



The program loops and tests the port bit against a saved value using
the bitwise exclusive OR. If the saved value is different, then "Old"
is set equal to the port bit. Only when the Port bit has switched from
"0" to "1" will it jump out of the loop.

If you need to detect say only one or two pins on falling (or rising edge), then you may want to use timers in counter mode. Should work for you.

Then have a check like

Code:

---

IF TMR0=1 THEN 'TMR0 is either on falling or rising edge as you need.
TMR0=0
GOSUB GET_PIZZA
ENDIF

---

Read this

http://www.precision.net.in/picbasic/PIC_INT.PDF

.

I know you're new to PICBasic but you may want to take a look here:

http://ww1.microchip.com/downloads/e...Doc/41214a.pdf

Read through this document and see if anything in there is close to what you were looking for. If so the Capture/Compare/PWM module in the pic is what you will want to use.

Many thanks for the varied and detailed replies. I've downloaded the PDFs as recommended and I am trying to make sense of the info therein. I do appreciate the replies and I was hoping to be able to embrace some of the information, but ...

I have a question relating to the learning curve - could someone have a look through the following prose and let me know if I should pack it in or persevere please?

Now is the time for me to admit that I have spent at least 3-4 hours most evenings for the last fortnight trying to compile something that I can understand. So far, all I have managed is to modify an example program to get a couple of buttons to latch a couple of LEDs and a third button to switch them off. I estimate a total of about 30 hours of my effort to get to this stage.

I had a choice of PicBasic or C or ASM and I chose what I hoped would be the easiest. I think I made the right choice but I am also beginning to think that even Basic is beyond me.

I have tried drawing a flowchart of what I need - it helped slightly but the fundamental problem is one of understanding the Basic commands. Here are my observations regarding my own dismal progress:

1) Things like (for example) the BUTTON command don't seem to behave the way I expect them to behave.

2)How on earth anyone ever follows more than one for..next loop, especially nested ones, is beyond me.

3) More than one variable? How do you ever keep track of it in your mind, or even by using loads of diagrams and paperwork?

4) Conditionals such as If..then..else doesn't seem to work - I can see the "if" and "then" parts but the "else" seems to be missing in most examples, or at least the "flow" of the program appears incongruous.

There are a dozen applications for PICs that even I can see should be simple to arrive at (relating to MIDI and aspects of analogue electronic music in particular - trigger generators, clock dividers, interfaces and so on) but the time is approaching for me to throw in the towel.

I had thought that I should see some useful prgoress in two weeks ! Perhaps I should invest in some books - can anyone recommend an ideal title for someone who has ZERO programming skill?

I will take number 1.

Quote:

---

Originally Posted by RMCRAVEN

1) Things like (for example) the BUTTON command don't seem to behave the way I expect them to behave.

---

I never used Button command so far because it is complicated for me too.
Use IF...THEN instead. Much simplier, easier...

But of course this does not remove Button command from the Earth! It will always be there for someone.

I'll try 2 & 3...

Code:

---

For CounterA = 1 To 20  ; "CounterA" keeps track of the loop count for the first FOR/NEXT loop

    For CounterB = 1 To 10  ; "CounterB" keeps track of the loop count for the second FOR/NEXT loop
        Pause 1
    Next CounterB
   
    Pause 1
Next CounterA

---

What happens is...

The first loop begins (call it the "A" loop), and "CounterA" is automatically set to '1' at its start.

The next line of code starts up a second loop (the "B" loop), setting "CounterB" to '1' at the start of that loop.

Since the first "Next" command is the "Next CounterB" line of code, the "B" loop will now continue for 10 iterations until it is finished.

We now hit the "Next CounterA" line - we go back to the beginning of "A" loop, the "CounterA" variable is incremented by 1, and then we restart the "B" loop again, finishing it before again going back to the "A" loop.

The "B" loop runs start to finish each time through the "A" loop. The "B" loop will be run a total of 20 times, for a total of 200 cycles (10 cycles per "B" loop, times 20 "A" loops).

While a FOR/NEXT loop is running, you want to make sure your code does not alter the "Counter" variable that is used to store the loop count (unless you are intentionaly changing it!).
Before a FOR/NEXT loop starts, or once the loop is finished, the variable can be used freely for other purposes in your code.


On #3... Give the variables names that mean something to you - instead of x, y, z, etc, use RedLED, GreenLED (pin variables), EventCount, PumpStatus, etc. Try not to use abbreviations, as you'll forget what they mean after a short time (I always do anyways).


Clear as mud? :-)

Arch

Well, those responses were both quick and illuminating! Unfortunately, a couple of hours of experimenting and my loops won't work (the compiler tells me I need an "else" and then tells me that the else isn't associated with a for..next!).

I've spent too long on trying to learn today - time to try again tomorrow. Thanks for everybody's assistance though; I'll press on with it during the week and see if anything begins to sink in.

Cheers

RMC, England

Sometimes the best way to understand how to structure code is to look at some examples and work your way through it, and then modify it. To give you some idea on how FOR / NEXT loops work:

For (variable) = (start value) to (stop value)
Do something
Next (variable)

so:

led var PORTB.0
i var byte

For i = 1 to 10
high LED
pause 1000
low led
pause 1000
NEXT i

Would turn on an LED on PORTB.0 for 1 second, then turn it off for a second ten times (ie untl i = 10)

If you want to count up in jumps, or count down you use the STEP command

For (variable) = (start value) to (stop value) step (value)

So
For i = 20 to 1 step -1
would effectively count down from 20 to 1 in single digits (ie 19,18,17.... etc)

For i = 1 to 100 step 2
would count give values for i in even values upto 100 (2,4,6,8... etc)

Hope this helps

Many thanks for the efforts you have all put into explaining things for me. Some of it has helped and I feel that I have grasped a tiny bit of programming mentality.

I have now spent the last 5 or so days working through some of the PBP examples. I've also been working through an online ASM course so as to try to grasp some of the background to the PIC16F62X datasheet, which I have also been trying to absorb parts of.

To be blunt, it isn't sinking in. I fear that it's likely to be beyond me (again - just like 6502 was 20 years ago when I did my college work, , and just like C was 5 years ago when I went on a 1 week beginner's course).

The frustrating thing is this: I think I have identified that what I want to do is almost trivial!

Please have a look at my plan if you have a few moments:

1) detect a rising edge on an input clock signal, frequencies f <= 100Hz - use portB.0 interrupt

2) Use that as a trigger to generate f/2, f/3, f/4... f/8 from remaining port B output pins
and/or
3)provide portA.0 "f/n" output where n is derived from a 4 bit switch on port A1..4 - some kind of binary or decade counter type approach I suppose.

4) Every time that rising edge occurs on PortB.0, transmit 0xF8 serial out of the USART (MIDI clock @ 21.25 kbps)

5) Detect two other pins' (e.g. A.5 and A.6 ) rising edges and transmit other words (0xFA or 0xF0) out of the USART. This could be done by ANDing with B.0 I suppose.

I'm hoping to use a PIC16F628 seeing as it has the hardware USART I think I need. I have someone else's assembler code which is used for the other part of the project,namely to read a MIDI data stream and provide TTL pulses when certain MIDI events occur (start/stop/continue and clock)

Am I right in my assertion that all of this is easily within the capability of a 20MHz MCU?

Cheers

RMC

I can sympathize with some of the learning curve. I took BASIC in school 20+ years ago on an OS/2 machine. That machine that weighed 50 pounds probably didn't pack half the power of even the most basic PIC today which I still find amazing. It was the most basic of BASIC you could say and back then I had a hard time even grasping that - and loops were totally alien as I didn't "get" those at all.

In short, like you RMC, this programming thing didn't make any sense. But I kept at it and then one day it fell into place and I was able to get through that part of the class easily.

PBP was a whole new ball game again, but by then I had learned a bit more of the basic language even though it was still 20 years ago that I had touched it, so the learning curve was not as bad. PBP still packed in all sorts of new commands that I had never heard of before and still take some time to grasp.

I'm by no means an expert and I still classify myself as a newbie, but I want to assure you that if you work at it you can learn and the "basics" will fall into place and seem very easy. Just by reading this board I've been learning more and more and so can you, just don't give up and don't be afraid to ask questions!

Bart

@bartman and all

thanks for your encouragement. I think I am trying to run before I can walk so if I aim my sights a little lower, perhaps my frustration will diminisha dn I'll start absorbing the information!

I'm going to continue with PBP and also continue with my initial exploration into assembler. I'm hoping the two will to some extent compliment one another.

I'll keep reading!

Thanks for the encouragment

RMC, England

Personally I taught myself picbasic so I could avoid learning assembly. While assembly can get you out of trouble from time to time, I don't know that having an understanding of it would help.

I would concentrate your efforts for now mastering picbasic. The key when your learning is break a program down to smaller parts and get the small parts working. So if you have an LCD get a "hello world" before continuing.

However be ready for those smaller parts to "break" when you start merging them. You'll do fine! Read posts and ask specific questions, you will get there.

If your code is not working, post here for us to have a look.

Also if you are going to use Interrupts, then in your case, you should use PortB, bits from 4 to 7, because these have an interrupt on change feature.

Ioannis