Which chip do i use?

[mackrackit]

Maybe you should try and learn regular interrupts before going for the big guns Darrel gave us.

You said that you do not understand interrupts. Search the forum for Olympic Timer or real time clock. Paul B has a good example too. Once you work through these you should have a good understanding of the behind the PBP and using an interrupt pin is not much different.
The above mentioned threads:
http://www.picbasic.co.uk/forum/show...=olympic+timer

http://www.picbasic.co.uk/forum/showthread.php?t=2129

[The Master]

Ok. Ill have a read through them. I thought the thing Darrel made was to make interrupts easier.

Can someone give me a bit of info on the pins used please. I can read those threads tomoz but i need to get the PCB designed ASAP. Do i need the zero-crossing diodes going to RB0/INT and the serial input go to just another normal I/O pin?

Is there a chip suited to this circuit? I see what Jumper was saying about having a 40 pin chip but space is tight and i wont need to expand on this project. If i have missed anything then ill find it when im designing the PCB.

If the worst happens and i cant learn interrupts fast enough then i can still use the circuit without PWM but the hardware has to be right. I can reprogram the chip but i cant remake the PCB

[The Master]

Heh. Ive decided to use a PIC16F877A, I already have a few of them laying around so i can run some tests without buying new parts. I would like to use a chip which has the right amount of ports for the job but i dont know how to find one properly. Ive used these chips before though (just not with PWM). Does anyone have any comments about it? Is it a good/bad choice? Anything i have to be carefull of when using it?

I had a thread the other day because i couldnt use one of these chips but i found the breadboard i was using and i had connected the resonator to the wrong pins! haha. Tested today and it is running a test pattern fine

[tenaja]

Ok. Ill have a read through them. I thought the thing Darrel made was to make interrupts easier.

Actually, what he made was to make interrupts more "real-time." It doesn't make PBP interrupts themselves easier, it makes "hardware" interrupts easier.

An interrupt is a hardware bit in the PIC (there are typically quite a few) that is set when a certain condition occurs. (Here are a few examples: when an a/d conversion is done; when a timer overflows; when a certain i/o pin changes state, when serial data arrives.) When one of these bits gets set, the code stops executing at its current position, and temporarily goes to the assigned interrupt code.

Now here's the part that describes why Darrel's code is helpful:

A "software" interrupt is BASIC-speak for checking the interrupt flags after each basic command. If a flag is set, then the code essentially gosubs to the interrupt code. This is the standard way to do interrupts within PBP. It's not a true interrups, but this is a "safe" way to do it, because none of the temporary hidden system variables are overwritten during an interrupt. (These system variables are used within the compiler commands, and are invisible to you unless you look at the compiled code.) This is an easy way to do it if you don't need 100% perfect timing.

A "hardware" interrupt is also BASIC-speak for a "real" interrupt. Instead of checking the flags, it relies on the hardware to do the interrupt if you have the Global or Peripheral Interrupts Enabled. That is, if you set the flags properly, then within a clock cycle or two, the code jumps to the interrupt handler. This is nice because the timing is instant, accurate, and precise. However, if you are in the middle of a BASIC command (or math operator), and you also use that command within your interrupt, then when it returns to where it was previously, the values could be corrupt. This is why Darrell put together his code routines... so it can save the hidden system variables, go through the interrupt, restore the system variables and return without losing any information in the process.

I'm sure this will help you understand a lot more. Basically, if you need precision--such as audio pwm--then you want to use the hardware interrupts. If you are doing something where the timing is much more casual--such as charging a battery--then you might as well use the s/w interrupts; they are easier to implement.

[The Master]

Hmm. Im making lights dim. I would say the timing is pretty important on that and the hardware interrupt looks like it would work best.

What i want is serin2 to wait to serial data forever (or until it gets some data).

If RB0/INT goes low then i want to run a sub.

Does what you said mean that the data coming in from serin2 could be currupted?

Im not really sure what to do now. Ive been reading through those 2 links but they arnt making much sense to me and i cant relate them to what im doing

[tenaja]

Hmm. Im making lights dim. I would say the timing is pretty important on that and the hardware interrupt looks like it would work best.

What i want is serin2 to wait to serial data forever (or until it gets some data).

If RB0/INT goes low then i want to run a sub.

Does what you said mean that the data coming in from serin2 could be currupted?

Im not really sure what to do now. Ive been reading through those 2 links but they arnt making much sense to me and i cant relate them to what im doing

You can't use serin2 and hardware interrupts at the same time. The serin2 command is a software loop watching for the pin to toggle. If you interrupt out of that, then you lose bits or bytes. If you must watch RB0, then you also must use the hardware usart with a hserin command.

If you are using RB0 as an interrupt, then you could use a loop to watch for the uart buffer to be full. Using the usart gives you the advantage of a 1.9 byte buffer. I say 1.9 because you get one full byte, plus however long it takes to receive another byte and move it there before its overwritten.

You really should get a development board and play with the serial inputs and the interrupts to see how it works. If you don't do that, then you'll be depending on the board to write your code.

[The Master]

I dont want anyone to write all my code for me but a few examples would be nice.

So, I cant use serin2 like i normally would. The rest of that bit is a bit confusing. Are you saying that i should have a main loop that keeps an eye on serial data coming in and when it reaches a certain length then deal with it however i would if it had just come from serin2? Then in the background i should have RB0 interrupt the code and run the PWM sequence?

Im sorry im not getting it. There must be a few ppl sat at home shouting at their PCs "I cant believe he still doesnt understand!!!" lol. I have a feeling that eventually something will click and suddenly it will all seem really simple

[mackrackit]

"regular" interrupts will see the event happen be it an internal timer or change on a pin. Then it waits until the program is finished doing what ever then goes to the interrupt routine. This is the timing issue spoke of. That is where the clock programs come in for an explanation, there is only so much time between interrupt events.

If the program is in the middle of a serial command and an interrupt flag is set, the interrupt will not run until the serial routine is finished.

Here is a recent thread where an interrupt is being worked out.
http://www.picbasic.co.uk/forum/showthread.php?t=7490