Which chip do i use?

[The Master]

Aha! Ive just read a whole thread of people having digs at each other but in the end i found out that its because i havnt got MPASM turned on. Ive enabled it and got the program to compile. It did give me 2 warnings though.

Warning[211] c:\picbas~1\pwmtes~1.asm 227 : Extraneous arguments on the line.
Warning[211] c:\picbas~1\pwmtes~1.asm 227 : Expected (ENDIF)

I assume that 211 is the error code and 227 is the line. If that is correct then this error is on line 169 of the origional "DT_INTS-14" file. The line says "End If". I think this is because .bas files open with VB and for some reason it added the space in. The origional file doesnt have the space. So, ive copied the origional file back out of the zip, commented out those 3 lines again and now its giving me another error

Error[113] c:\picbasic\pbppic14.lib 1141 : Symbol not previously defined (INT_ENTRY)

Ive tried deleting all the files generated for DT_INTS-14 (like the asm file etc). Ive hit compile again and yet another error.

Error[113] c:\picbas~1\pwmtes~1.asm 115 :Symbol not previously defined (PIR1)

Now im stuck. Does anyone have any suggestions?

[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