Printable View
Hi. I need a PIC chip that can output software PWM to 24 pins, on/off to 3 pins and have serial in/out. It needs to have at least 2 bytes of EEPROM. It needs to use an external oscillator.
Can anyone tell me which chip would best suit me or even better how do i figure it out myself? Is there a list somewhere that will allow me to select the features i want and run a search?
Hi,
Most PIC:s can do what you have asked for as long as they have enough PORTs availible.
Do you plan to make a small, big or huge program ?
Are you going to make one or one millions units (is price per unit a big factor)?
What will the future look like (USB or anything more special)?
A first choice would be 16F887 since it is cheap, has a reasonable big program space, internal EE-prom, UART and is pincompatible with other pics such as 18F4620 (for later emergency upgrades using the same footprint).
The 18F series will give you more speed (40 MHz compared to 20) and much more program memory compared to 16F887.
You didn't say if the PWM is running contantly or not. Maybe the need for speed is more important than price per unit.
Just to make sure:
I am talking about the 16F887 (eight eight seven), not the 877 or 877A which are the older chips doing more or less the same thing.
/me
I was looking at a PIC16F874. It seemed to be alright but i wasnt sure about it.
Ive changed the 24 outputs to 16 outputs now to save money on triacs and waterproof sockets (i cant believe how much these cost!).
the PWM could be running constantly. Its to control bulbs (with fading) and it will be possible to fade some bulbs out and hold them at a certain brightness for a while.
Something i forgot to mention is interrupts. I know i need at least 1 interrupt pin. From reading a few datasheets it seems that most chips have 1 pin EG "RB0/INT" but some say you can use RB4-7 as interrupts too. Whats the difference between RB0 and RB4-7?
Im not sure how big the program will be. Im hoping pretty small. It will simply accept commands from serial then either use that data to set brightness levels for the bulbs or return a value from the EEPROM (the boxes address).
I take it and "I/O" pin is any input or output pin (excluding OSC in/out unless the OSC pins work as like RA4 aswell)
So i think i now need 23 I/O pins
(16) Software PWM outputs
(1) Serial in
(1) Serial out
(3) Multicolor LED
(1) Button
(1) Zero-crossing interrupt
23 + (2 OSC) + MCLR + VCC + VSS = 28 pins
Ive just had a quick search and found PIC16F882. Would that work?
if you interface AC, PWM will be useless anyways, you'll need to use a Interrupt to detect the zero crossing and play with your output delays within your ISR.
Your main program may assign delay to your output.
Probably also doable to do everything in a tight loop.. but i tend to say it could be a killer situation.
Whats ISR mean?
I have an idea of how i can write this code in a few simple lines but i dont know how to use interrupts at all. I assume i have 2 interrupts. If one of them goes low then that is the zero-crossing and the code will goto the PWM area. If the second interrupt pin (serial) changes then do i run serin toget the data or wouldnt that work?
2 main things i need to know at the moment.
Which chip do i need?
How do i detect interrupts?
BTW. Im buying all my parts from http://www.rapidonline.com so it would be nice if i could get the chip from there. I dont think that last one i found is available from them.
Edit: Do the PIC codes mean anything? Like 16F = 20 pin, 18F = 40 pin etc. Or do they just increment with each new chip?
ISR: Interrupt Service Routine : It's the code area used when an interrupt happen.
Begin with ON INTERRUPT and/or Darrel's Instant interrupts.
Ive just googled it and based on this satement "Once you try this, you may never use ON INTERRUPT again." I think i should just use Darrel's Instant Interrupts. Ill have a read and see what i can come up with. Thanx
Hi,
I hope you have downloaded the pdf datasheet for the 16F882. There you can see that this PIC belongs to a family of PICs starting with the 882 and ending with the 887. There is a table showing the memory size and partnumber/number of pins for these pics.
INT0 is the only external interupt source for the 882-887 family and the rest of PORTB has interupt on change support. This means that you can set up the INT0 pin to generate an interupt when this pin goes either high or low (set in SW).
The rest of PORTB has interupt on change mening it will generate an interupt if any of these pins (that has this function activated) changes state. And then you have to figure out which pin did what and why...
There is a big table for this too under CPU special features.... interupts :-)
The microchip webpage has the price for the 882 at USD 1.20 and the 887 USD 1.84. This can be the best spent 64 cents in your entire life :-). Or you can choose a 884 (still basically the same chip for USD 1.64) since this is a 40-pin package and then keeping the options for plugging in a 18F when you run out of speed and program memory)
Probably you have forgotten a few pins in your idea that you will "remember" later and making a design using a 28-pin device and planning to use more or less all pins is hmmmmm not that smart :-) (unless you really know what you are doing like Melanie and her friends).
Maybe a LCD... some more buttons..... smoke detection..... automatic fire extinguishing.... you get the idea.... things tend to grow with time and some projects newer really finish.
But if I were you I would:
Download the datasheet for the 16F882 (same datasheet as for 883 884 886 887)
Check if they are supported by PBP (if not memorize which are for later use)
Not choose a 28 pin PIC since it will kill the future plans and leave no room for misstakes
Choose a 40-pin PIC (884 or 887 if we only look at this family) unless price and pcb size is really important)
The 884 is 20 cents cheaper then the 887 but you only get half as much program memory.
Of course these prices might be different from what you pay in the stores but it will at least give us a chance to compare apples and bananas.
In the end it all comes down to what can be found in your local hardware store or what can be salvaged from previous projects.
A start is always a good start!
/me
Hmm. Ill start off with interrupts. IVe been reading this incredibly long thread and i think im starting to understand how it works but i do have a question about it. In one of the posts he says "And, all of this is happening behind the scenes of your normal PBP program." Does that mean for me that i can have serin wait for data (with no timeout) *AND* still have the PWM stuff running at the same time? (Meaning i only need 1 interrupt pin)
I understand how the other interrupt pins work now. Bit annoying but maybe i dont need them anyway.
I do always look at the datasheets for chips but i dont completely understand them.
If i have forgotten any pins then its bad anyway. I can do breadboard testing but once i make this thing it has to work first time. Space is an issue. Im trying to cram so much into such a small box.
How do i tell if it supports PBP?
Right. Ive just connected a PIC up and checked that its working. Now im trying out the hello world example. Ive pasted the code in from that page exactly but i get 3 errors when i try to compile
ERROR: Variable wsave3 position request 416 beyond RAM_END 79.
ERROR: Variable wsave2 position request 288 beyond RAM_END 79.
ERROR: Variable wsave1 position request 160 beyond RAM_END 79.
I dont understand what they mean or how to fix them. Im testing on a PIC16F84A. I have set the chip correctly in PBP this time :P and ive downloaded the 14 bit version of the interrupt code (for 12F-16F)
Ive just loaded the bas file up and theres some comments saying i can comment out the lines that are causing a problem. Ive done that and now theres another error.
Error PBPIC14.LIB 1141 : [255] undefined symbol 'int_entry'
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?
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
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
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 :D
Actually, what he made was to make interrupts more "real-time." It doesn't make PBP interrupts themselves easier, it makes "hardware" interrupts easier.Quote:
Originally Posted by The Master
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.
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.Quote:
Originally Posted by The Master
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.
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
"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
When dealing with interrupts and critical stuff... you don't want to use anything else than a REAL USART. Select a PIC with a EUSART/USART, use it and forget SERIN/SERIN2/DEBUG.
I knew my ears were burning for some reason today. :)
Don't want much, Do you? :eek:Quote:
Originally Posted by The Master
Let's see, you want 24 software PWM's, plus + ...
Maybe we can just make it a moot point by determining your PWM resolution requirement.
1. What frequency PWM do you need?
2. What resolution? 4, 8, 10 bit ?
The reason I ask can be found here ...
http://darreltaylor.com/DT_INTS-14/SPWM.html
In particular, read how many Interrupts/Instructions per second it takes to accomplish software PWM.
I would guess that the reason you had problems with Instant Interrupts previously Today, is because you were using a 16F84A.
Kind of like running windows on an original IBM PC. (you might get it working, but it'll suck)
Switch to at least the 16F877, but I'll bet you're going to need an 18F.
.
Oh, and if that makes it sound impossible to you?
Here's something else to ponder.
It's just that, Nobody's written it yet. :(
http://www.picbasic.co.uk/forum/showthread.php?p=45597
.
Darrel. I changed the design yesterday. I only need 16 PWM pins now. Someone made some circuits for me years ago that do exactly what im trying to do now and they work perfect. They only used smaller chips i think PIC16F84's. The person who made them lost the origional code in a format and i hardly ever see him online now. I guess he wasnt using your code though. Ive swapped to a PIC16F877A now. I hope that will do better.
Im not sure about the frequency/resolution. I want a brightness control that is 0-100%. Here in the UK we have 50Hz which means 100 zero-crossings per second so i think for 100 brightness levels i should split each half cycle into 100. That should mean for a brightness level of 50% i wait 5ms before turning the output on. Im not sure how this would work though because 1% would be 100ns but isnt that faster than the chip can handle?
Im sure im going about this bit the wrong way too.
I checked the datasheet for PIC16F877A and it says it has USART So that should be ok.
mackrackit. Its all becoming clear now. Im about to read through that thread now but i think i understand how it should work.
Random thought. I can upload the .HEX file from one of the chips i have already doing this kind of thing with 8 PWM outputs. I dont know if anyone can do anything with it. Maby decompile to assembly?
Just read through that thread and the PDF in it. I only understood some of it through. Im using triacs so i cant use bi-phase angle modulation. Phase angle modulation is what i was thinking of. Turn an output on at a set point durin the half cycle and let the triac turn itself off at the next zero-crossing. I dont think the drawbacks of that method will affect me because im not using LEDs. I got completely lost at BAM.
The idea i had would work like this
Obviously i wouldnt type out hundreds of if statements, i would use a loop instead but thats what i was thinking of. It looks a little slow though :(Code:interruptpoint: 'This is where it goes on interrupt from the zero-crossing pin RB0
if brightness(0)=100 then
high porta.0
endif
if brightness(1)=100 then
high porta.1
endif
.........
pause (100th of a cycle)
if brightness(0)=99 then
high porta.0
endif
......
'by now it should be right at the end of the half cycle
'set the pins to low so the triacs dont all come back on in the next half cycle
low porta.0
low porta.1
resume
I know ive got to learn serial now without using serin2.
Which interrupt method do i need? (or which one should i start learning?)
Should I also guess that the serial is comming in at 250kbaud?
There are 512 frames, at ~40hz.
A.K.A. ... DMX
.
I was going to use 9600n. Thats what everything else uses including the origional boxes my mate made
EDIT: The plan wasnt to use these as DMX lights but how hard would that be? IVe got a DMX controller and i think its faster than anything ive done using the serial port (My DMX box is USB>DMX)
Hehe. Ive had a quick google of DMX in PBP and it sent me to this thread. BTW, the person who made my origional boxes is electronicsuk (Matt).
After reading that thread im not sure about DMX. I looked at assembler once then quickly made a break for the exit
Very!Quote:
Originally Posted by The Master
Got paid to do it once.
Came up with 1 18F as the front end receiving the DMX.
And any number of slaves (8 per PIC).
Up to 512 channels total. (lots of slaves, kinky)
Unfortunately, it was for LED's (high powered one's, but still LED's)
It'll be harder for A/C dimmers.
.
DMX is out then! I dont want this to be any harder than it already is.
Ive just been reading some of Matt's threads. I can see a few references to the boxes he made for me. Just to add, those boxes are still working perfect after something like 3 or 4 years. Nice job!
Anyways. I cant seem to find much in those threads about the bits im stuck on. There is 1 thing that can be learned from them tho. Dont rivet triacs to anything! I had to replace one once without getting to the solder side of the PCB.
This thread or more specificly the last post is quite interesting. Can someone tell me if the following is correct.
There is a receive flag. Possibly whatever PBP uses as a boolean value. When serial data arrives at the chip this flag is set to true.
RCREG returns the first byte from the serial buffer and removes it from the buffer. If this causes the buffer to be empty (that was the last byte) then the RX flag is set to false.
I take it this uses the hardware UART thing to add data to a buffer (with no code)
Ive just found another thread with sample code of using UART and interrupts. It looks simple enough so im gonna test it out when i get back home (stupid work, ruining my day :P)
Ive had a go at writing some code. This is just for the serial part. The idea is that if the chip gets chr(255) then it sets the next 16 bytes to the brightness levels (Later to be used to control the triacs).
I do have a few questions about it though. Can this only be used on a pin labeled RX? For this chip the pin labeled RX is RC7.Code:datapos var byte
newbyte var byte
brightness var byte [15]
trisc=%11111111
spbrg=129
rcsta=%10010000
datapos=16
loop:
if pir1.5=1 then
newbyte=rcreg
if newbyte=255 then
datapos=0
else
if datapos!=16 then
brightness(datapos)=newbyte
datapos=datapos+1
endif
endif
endif
goto loop
An example i have says "RCSTA = %10010000 ' Enable serial port and continuous receive". What are we setting here? Are we telling it which pin is being used or is it just a standard value that means "on"?
Is my code any good or should i scrap it and start again? :P
Ive just tried out Darrel's code again now im on this new chip and it compiled first time without me having to edit anything :D I used it to monitor the falling edge and i connected 2 diodes up. I did a quick test...
And the bulb lights up at half brightness :D WOO! Im just having a read through "Multiple Software PWM". Then ill have to figure out how to add serial to it but it looks like i can use his code for that tooCode:ToggleLED1:
pause 5
high PORTd.7
pause 1
low PORTd.7
Ive written some test code using DT's example
It works perfectly except the bulb fades out half way then pauses slightly then fades out completely. It also fades as its coming back in. Does anyone know why that is and how to fix it?Code:INCLUDE "DT_INTS-14.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP.bas" ; Include if using PBP interrupts
resolution var byte
x var byte
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler INT_INT, _ToggleLED1, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
@ INT_ENABLE INT_INT ; enable external (INT) interrupts
Main:
for resolution=0 to 100
pause 1
next
for resolution=100 to 0 step -1
pause 1
next
GOTO Main
'---[INT - interrupt handler]---------------------------------------------------
ToggleLED1:
for x=100 to 1 step -1
if resolution=x then
high portd.7
endif
pauseus 150
next
low portd.7
@ INT_RETURN
I think ive been looking at this the wrong way round. Ive had the multimeter on one of the boxes Matt made (8 triacs are riveted to the side so i cant see under the PCB). From what i can see the interrupt pin isnt connected at all. I think he has a main loop which just waits for a certain pin to go low (for the zero-crossing) then executes the bit to control how bright everything is. As for the serial input i think that is where the interrupt comes in. Either that or there is no interrupt at all and he checks that in the main loop too. Now its starting to sound simple :D
For now im gonna use the same chips Matt used and see if i can make his circuit work on a breadboard. Then i can copy the hex code to the new chips. That gives me 8 outputs so ill need 2 chips per circuit but they are cheaper than 1 big one.
1 thing i find weird about his circuit is that MCLR doesnt appear to be connected to anything :S
Hi,
Reverse engineering is not my favorite game so do not expect any more help from me again.
Need any more help? Ask Matt!
/me
I would ask Matt but hes never online anymore. Hes always busy.
From what ive learned in this thread and looking at the top of his PCB i think i can see how and why he has connected certain things up. Im gonna get hold of a 16MHz resonator and borrow one of the chips from the boxes. If i can get one of the origional chips to work then i could simply copy the code but i have an idea of how he programmed it too so i can also experiment with that.
Whats wrong with reverse engineering anyway? I tend to learn best by seeing a finished product then looking at all the bits in it to see how it works. It also leads to me question why it has been done in such a way. Like why does Matt appear to have used a method that nobody has mentioned here?
You would have to ask him. There are many ways to do the same thing. Is one better than the other, who knows. This thread was not started about why some one did a project a certain way. It was about which chip would work. Then it went on to interrupts.Quote:
Like why does Matt appear to have used a method that nobody has mentioned here?
As far as reverse engineering.
Using it to lean is one thing but to duplicate a product is on the verge of stealing.
If the product is open source that is something else.
Want to build a device that works like one made by someone else, fine. Use your own ideas and you will get help on how to make them work. Want it to be exactly like the one made by another, buy one from them.
I dont want it to be exactly the same. Thats why im putting so much effort into learning this. Im doing loads of tests on Matts box now and theres a few things i still dont get but im getting there. Just about to try some code out (stuff i invented myself). But im gonna put it on one of the boxes Matt made. I know the box works perfect so i can test my code better. Once i get my code working then it will help me understand the circuit better.
I dont want to "copy" Matts design. I want to figure out how he did it then do it in my own way
OK
Some chips have an internal MCLR , I like these for ICSP.
Let us know how you code works out and where you need help from there.