12f675_fuse_about_to_blow!

[LEDave]

Hi everyone.

I haven't posted for a wee while but have been busy reading and building my first two circuits.

The first is a 12F683 driving four LED's in a binary pattern 0-9 as per the thread (I've also added a nice little Night_Rider effect). I must say, although simple in what I've achieved, when those four LED's run up that binary pattern it was a real thrill, amazing.

The second circuit marrying the binary counting PIC to the BCD decoder driver then seven segment display is about half way built ( I'm quietly confident about this one fingers x'd).

Once again, thanks for all your help on here. I really wouldn't have got this far without it.

I'll be back when the second circuit is completed (early part of next week).

Hope you're all keeping well.

David

[LEDave]

Hi Everyone.

Just to let you know I've got a a working circuit!!!!! Yippee.

It's a 12F683 into a SN74LS47N display driver and a 1" seven segment display counting up to nine.The PIC output also switches four transistors with collector LED's for a binary output count as well.

Simple stuff for you boys I'm sure but I'm chuffed to bits right now.

Not sure where to go or what to do next (any ideas welcome).

Thanks for your help as ever.

Dave

[mackrackit]

COOL!!!! You are moving right along.

Here is an idea. Setup a hardware timmer to change the display once per second.

[LEDave]

Here is an idea. Setup a hardware timmer to change the display once per second.

Hi mackrackit

Are we saying for example to use the trimmer pot on the PICkit1 to alter the display speed ADC? (ADCIN).

I'm seriously considering buying the the full program version by the way (I'm just trying to convince myself I'm clever enough to figure out how to use / make the most of it...lol).

Really enjoying it though (headaches aside ;-))

Dave

[mackrackit]

No, not trimmer... or timmer .... I really need to get a dictionary

Timer as in TMRO.

Many times we will at the beginning of a new project to make sure things are setup correctly we will do a simple "blinky" just like we tell the newbees to do. I will a lot of times leave it running as a "heart beat" type of thing. But if you do this using pauses to blink the LED the pauses will maybe get in the way.

So now comes a basic interrupt based on time.
This may or may not be correct for your chip so verify with the data sheet.

    INTCON.5 = 1    'ENABLE TMR0
    OPTION_REG = %10000101  '16BIT 1:64 PRESCALE
    ON INTERRUPT GOTO TLOOP

    MAINLOOP:
    'MAIN CODE GOES HERE
    GOTO MAINLOOP

    DISABLE
    TLOOP:
    INTCON.2=0:TOGGLE PORTD.4
    RESUME: ENABLE

[LEDave]

Hi mackrackit, everyone.

I've been doing a lot of reading trying to figure out what's actually going within your Timer / Interrupt program. So here's my interpretation (he typed as he makes a fool of himself again).....!

 INTCON.5 = 1    'ENABLE TMR0

Setting the Interrupt_Control pin.5 = 1 simply enables the Timer0 interrupt.

OPTION_REG = %10000101  '16BIT 1:64 PRESCALE

First of all you set the Global Interrupt Enable bit.7 =1.
Then bits 0 = 1 & bit 2 = 1 sets the PRESCALE value 1/64 of the system clock.
4MHZ or the instruction clock 1MHZ (not 100% sure on that one) This divided down figure is then sent to the TIMER0 register (incremented count from the prescaler).

When the count goes from FF(HEX) +1 (255 decimal,it over-runs back to zero).

So (wild assumption here) when the count overflows passed 255 the INTERRUPT occurs and the program jumps to the Label TLOOP. The LED blinks, then INTCON.2 pin is the reset to 0 and it does it all again.

So basically to my (small) mind the LED would blink every 1/64th of 1MHZ.

Anywhere warm on this one?

Dave

[mackrackit]

Warm...

Setting the Interrupt_Control pin.5 = 1 simply enables the Timer0 interrupt.

That is not setting a pin, it is setting bit#5 of the register.

When the count goes from FF(HEX) +1 (255 decimal,it over-runs back to zero).

Correct.


Now for the tricky part.
Running with a 4MHz OSC the chip is actually running at 1MHz.. Or cycles at 1 micro second (ticks).
If the prescaler is set for 1:1 then it will overflow every 256 micro seconds.
If the prescaler is set for 1:2 then it will overflow every 512 micro seconds.
If the prescaler is set for 1:256 then it will overflow every 65536 micro seconds.

[LEDave]

Hi there.

As ever can I start with a question:

The TIMER program. My reading of it is that with a prescaler of 1:64 the LED
attached to PORTD.4 would blink (toggle) every 16384 microseconds (pretty quick) And that because this is driven by the internal clock runs independently of any code enclosed within 'MAIN'. For example, you could have an LED set within MAIN to say PORTD.3 which would blink every 2 seconds whilst the LED on PORTD.4 would to all intents and purposes show permanently on (like you said a heartbeat indicator that all's running well).

Am I reading this right?

David

[HenrikOlsson]

Hi Dave,
Yes, the LED would toggle every 16384uS, in other words it would blink at rougly 30.5Hz, youll be hard pressed to see that. If you change the prescaler to 1:256 you'll get 4000000/4/256/256/2 = 7.62Hz.

The problem with PBP's way of handling interrupts is that it can not interrupt the command/statement that it is currently executing. Lets say for example that your main routine looks something like this:

Main:
  GPIO.0=1
  Pause 500
  GPIO.0=0
  Pause 500
Goto Main

This would blink a LED connected to GPIO.0 at 1Hz and you would think that the TMR0 interrupts would blink the other LED at 7.62Hz, unfortunatley that's not the case....
In the above code the interrupts generated by TMR0 would only get served between each statement. In other words, during the 0.5 second pauses the 7.62Hz blink would stop.

Basically, what PBP does, under the hood, is to add check after each statement, like:

Main:
  GPIO.0=1
  IF Interrupt goto TLOOP    'This is not the actual code it adds, it's just to illustrate the principle
  Pause 500
  IF Interrupt goto TLOOP
  GPIO.0=0
  IF Interrupt goto TLOPP
  Pause 500
  IF Interrupt goto TLOOP
  Goto Main
  IF Interrupt goto TLOOP

As you can see, if an interrupt occurs in the middle of a Pause it won't get serviced until the Pause statement has finished so if you're using PBP's ON INTERRUPT you need be aware of this. There are other ways to do it which doesn't suffer from the issue described above (Darrels Instant Interrupt routines obviously).

Hope it helps.
/Henrik.

[LEDave]

Hi Henrik

As you can see, if an interrupt occurs in the middle of a Pause it won't get serviced until the Pause statement has finished so if you're using PBP's ON INTERRUPT you need be aware of this.

Very interesting that because I built a little test circuit based on mackrackit's code using a PIC12F683 (program below) with the INTERRUPT toggling an LED on GPIO.4 The MAIN code turned an LED on and off you've guest it using pause statements!

I was expecting the INTERRUPT LED (GPIO.4) to blink really quickly and the LED on GPIO.0 to blink at 500 mili_secs much slower, in reality they were much the same speed.

The manual refers to this as (latency). Like you say it pays to be aware of it. You wouldn't want an interrupt acting as an emergency stop when combined with a long pause statement.....Ouch!

ANSEL  = %00000000
CMCON0 = %00000111
TRISIO = %11101110
GPIO   = %00000001
INTCON.5 = 1                    'ENABLE TMR0
OPTION_REG = %10000101  '16BIT 1:64 PRESCALE
 
    ON INTERRUPT GOTO TLOOP

    MAINLOOP:
    PAUSE 500    
    low GPIO.0   
    PAUSE 500    
    high GPIO.0  
    GOTO MAINLOOP
     

    DISABLE
    TLOOP:
    INTCON.2=0:TOGGLE GPIO.4
    RESUME: ENABLE

[HenrikOlsson]

Hi,
Now that you're aware of how ON INTERRUPT works there are a few things that can be done to help speed up the response (latency). Instead of having a single 500ms long pause, how about 500 pauses, each 1ms long?

i VAR WORD
Main:
  GPIO.0 = 1
  GOSUB GoToSleep
  GPIO.0=0
  GOSUB GoToSleep
Goto Main

GoToSleep:
  For i = 1 to 500
    PauseUs 1000     'Tweak this if timing is critical.
  Next
RETURN

Now, you should get pretty close to what you expected in the first place. If timing is really critical you'll need to tweak the PauseUs statement as each time thru the loop takes a couple of uS longer due to the inserted checks of the interrupt-flag and the fact that it takes a few cycles to jump around inside the FOR-NEXT loop.

Also, remember what we said about HIGH and LOW? That they write to the TRIS register everytime.....and there's no need for you to use them as you've so elegantly set the TRIS register correctly at the beginning of your program. It's usually "better" and faster to simply write directly to the port register with GPIO.0=1 etc.

/Henrik.

[LEDave]

Henrik thank you.

The program ran a treat. GPIO.0 blinking away at around a half a second period, GPIO.4 essentially 'on' all the time, very clever.

Nice little project you set up there mackrackit, thanks a lot. I've learned a lot from that namely:

1/ Read the program specification more closely! mackrackit wrote:

But if you do this using pauses to blink the LED the pauses will maybe get in the way (they did. I'm pleased they did though, I've learned from that).

2/ How a timed INTERRUPT works and some pitfalls (PAUSE)!

3/ A re-iteration about HIGH / LOW writing to the register everytime they're used. Far better to set the TRISIO register up and write directly to the PORT. I'm starting to appreciate the subtlety of these things, still lots to learn / re-learn though.

Right then, what's next?

Dave

[rmteo]

My suggestion is to learn what a "true" interrupt is and how to use it - as your next step. If it means using DT's routines because PBP does not do it, then by all means do so. It will enable you to do so much more as you advance in your adventures with microcontrollers.

[LEDave]

Thanks for that rmteo.

I'll bear that in mind. Don't forget I'm very new to this, sure I'll have to learn all about interrupts at sometime (maybe now is that time).

I'll be very interested in hearing where mackrackit, Henrik and Joe S think I should go next as they have an understanding on where my knowledge base (or lack of it) lies.

Hey I couldn't turn an LED on a Month ago!

Cheers.

Dave

[mackrackit]

Henrik,
Thanks for finishing that lesson, I got busy.

rmteo,
Good point about ASM interrupts. I am not sure if Dave can do that with the demo version. But when he gets the full version...

Dave,
We are not finished with PBP interrupts yet
As you saw things can move pretty fast with the hardware and if you want to have an event happen at a certain time no matter what an interrupt can help.

Many times it is not recommended to use PAUSEes because as you now know they block other things from happening. There are enough things that do this without adding more, but sometimes we have to use them. Every thing in its place.

Now try something like this...
Do a "MAIN_LOOP" that will TOGGLE a LED with a button press. Every time you press a button the LED changes state.

Then make a BYTE size variable and add the PBP interrupt routine for another LED. The new variable will increment a value of 1 every time the interrupt "triggers".

After a given amount of "trigger", the variable reaches 10 the second LED changes state.

This should happen whether the first LED and button has been activated or not.
By having the variable increment to change the second LED state you can now make it blink at any time frame you want.

[rmteo]

It may be worth pointing out that one does not need to use ASM to use interrupts. I have (and use) 3 different versions/dialects of BASIC for PIC's and they all handle interrupts (including vectored interrupts) without having to delve into ASM. Same situation with C.

[mackrackit]

It may be worth pointing out that one does not need to use ASM to use interrupts. I have (and use) 3 different versions/dialects of BASIC for PIC's and they all handle interrupts (including vectored interrupts) without having to delve into ASM. Same situation with C.

But this is a PBP forum... So the point is???

[LEDave]

Gulp, I'm on it.

I'm probably going to go quiet for a while trying to figure this one out. I'll give it my best shot though.

I suspect you and Henrik could code it in about five minutes!

Then again I'm not you or Henrik..... :-)

Dave

[mackrackit]

I suspect you and Henrik could code it in about five minutes!

Maybe I can now... 15 years ago would be a different story.

You are doing great! Keep at it!

Oh, forgot to mention the assignment is due Friday

[LEDave]

Hi everyone.

I've been busy on the 'assignment'.

I've got the first part going namely:

Do a "MAIN_LOOP" that will TOGGLE a LED with a button press. Every time you press a button the LED changes state.

I built a test circuit which I made a small mistake on, then having zero programming confidence quickly convinced myself I'd made a code error, turned out I'd soldered a link into the wrong place (hours wasted), grrrr.

So on my PIC12F683 GPIO.5 has a push button attached which changes an the state of an LED on GPIO.0 everytime it's pressed, so far so good, now for the tricky part....!

It's taking longer than expected so my homework may not been handed in until Monday.

Still, only 14 Years and 48 weeks to catch up with you mackrackit!

Dave

[mackrackit]

Still, only 14 Years and 48 weeks to catch up with you mackrackit!

And I am trying to catch up with Bruce...

It never ends

[LEDave]

Hi everyone.

Struggling a bit (well quite a bit actually) with the second / third parts of the project.

The brief says:

Then make a BYTE size variable and add the PBP interrupt routine for another LED. The new variable will increment a value of 1 every time the interrupt "triggers".

Ok, so what I'm trying to do here is to use the INTERRUPT flag as my counter (INTCON.2=1) I've set the prescaler at 1:256 = 65536us = 7.6HZ and set 'I' as a VAR BYTE.

My theory goes something like this:

If count (VAR BYTE 'I' incremented by the INTERRUPT flag) = 10 then TOGGLE the LED.

Here's how I'm trying to do it and where I'm falling down.

IF INTCON.2=1 ' INTERRUPT flag overflows
THEN I = I + 1  ' add 1 to the value of I.
INTCON.2=0    ' Reset the overflow flag.
IF I<=10 GOTO MAIN ' If count doesn't  = 10 loop again.
IF I =10 GOTO TOG ' If count = 10 then TOGGLE the LED.

I'm thinking at 10 'counts' at 7.6HZ should be approximately blink the LED once a second-ish.

All a bit fragmented I know but I hope what on saying is on the right tracks.

Any thoughts, pointers?

Dave

[mackrackit]

The basic interrupt routine you have worked with

    DISABLE
    TLOOP:
    'DO SOMETHING
    INTCON.2=0
    RESUME
    ENABLE

SOMETHING...
I = I + 1
IF ??? THEN
???
RESET COUNTER
ENDIF

Tick Tock...

[LEDave]

DISABLE 
TLOOP:
IF INTCON.2=1 THEN I = I + 1 :INTCON.2=0 IF I<=100 GOTO MAIN IF I =100 GOTO TOG
 tog:TOGGLE GPIO.2
 RESUME: ENABLE

That's what I was trying to fit in.

Blimmey, it's nearly Friday already

Am I close-ish.

Dave

[mackrackit]

Close-ish...

IF INTCON.2=1
is not needed in the interrupt routine, that is what send the code there in the first place.

The rest might work.
Does it??

[LEDave]

Mmmm.

I was trying to use then reset IF INTCON.2=1 to increment count on 'I' the VAR.

IF INTCON.2=1 THEN I = I + 1 :INTCON.2=0

I'll sleep on it (I hope it doesn't keep me awake thinking).

Dave

[mackrackit]

Something...
I = I + 1
if ??? Then
???
I = 0 'reset counter
endif

[HenrikOlsson]

IF INTCON.2=1
is not needed in the interrupt routine, that is what send the code there in the first place.

Correct. But remember that if/when you start adding more interrupt sources you need to determine which one it was that tripped so checking the interrupt flag is probably good practice. But as have been said, it's not strictly needed in this case.

You seem to have a GOTO Main inside the ISR - you can do that but it is probably not a good idea as it will restart from the beginning of the program and not where it got interrupted. This MAY not be a problem in THIS particular program but can cause some interesting results so - try not to do that.

Have a look at this:

DISABLE 
TLOOP:
IF INTCON.2 = 1 THEN    'TMR0 Interrupt?
   I = I + 1            'Increment counter
   IF I = 100 THEN      'Has it reached 100?
      TOGGLE GPIO.2     'If so, toggle LED...
      I = 0             '...and reset counter
   ENDIF
   INTCON.2 = 0            'Reset interrupt flag
ENDIF
RESUME                  'back to work.
ENABLE

/Henrik.

[LEDave]

Well once again I've learned a lot of things, thanks as ever.

In the UK there's a famous comedy sketch where a musician says "I was playing all the right notes
but not necessarily in the right order".

I was a little (ok a lot) like that in this last exercise. I had written down I = 0 to reset the counter, I knew
I had to do that which is something and I'd figured I = I + 1 to add to / increment the counter, so not all bad.

Henrik highlighted within the program:

 INTCON.2 = 1 THEN   'TMR0 Interrupt?

I guess that's because as mackrackit pointed out to me that for the program to be there the INTERRUPT
must have already occured?

ANSEL   = %00000000      'Disable analog select so ports work as digital i/o
 CMCON0 = %00000111      'Disable analog comparators
 TRISIO = %11111110      'TRISIO.0 set as OUTPUT
 GPIO   = %00000000      'All bits set LOW
 INTCON.5 = 1            'ENABLE TMR0
 OPTION_REG = %10000101  '16BIT 1:64 PRESCALE
 

 ON INTERRUPT GOTO TLOOP  'ON INTERRUPT GOTO the INTERRUPT handler LABEL 'TLOOP'
                              
 i var byte               'Set I as a VARIABLE BYTE

Main: 
 
Not_pressed:
PAUSE 25                            'Leave 25mili_sec for a button press to occur.
if GPIO.5 = 1 THEN GOTO Not_pressed 'Keep waiting for +0v button press on GPIO.5
IF GPIO.5 = 0  THEN goto LED        'Button has been pressed move to LABEL LED:
LED:
TOGGLE GPIO.0                       'Change state of GPIO.0 pin
GOTO Not_pressed                    'Start again
 
 DISABLE                            'Disable INTERRUPT in handler
 TLOOP:
 IF INTCON.2 = 1 THEN   'TMR0 Interrupt?
   I = I + 1            'Increment counter
   IF I = 100 THEN      'Has it reached 100?
      TOGGLE GPIO.2     'If so, toggle LED...
      I = 0             '...and reset counter
   ENDIF
   INTCON.2 = 0         'Reset interrupt flag
ENDIF
RESUME:ENABLE           'ENABLE INTERRUPT in handler start prog again

10/10 for you guys.

Dave (not clever just persistent).

[mackrackit]

You are doing great Dave, I wish more that came here wanted to learn and not just looking for a copy/pastes solution.

I agree with Henrik about this

 INTCON.2 = 1 THEN   'TMR0 Interrupt?

Good to learn what to do if you have multiple interrupts. If you only have one interrupt and you are trying to save code space, as with the demo version, or an instruction cycle or two then you can leave it out.

Another thing to think about when using interrupts is to try and keep the instructions in the handler as few as possible. You would not want to miss an interrupt while taking care of one. Might have to get creative at times but that is the fun. Every project is a puzzle.

Hey, you did not ask "whats next"...

Do you have a serial port or a USB to serial converter on your computer?

[LEDave]

Hey, you did not ask "whats next"...

I nearly did, then I thought have we finished TMR0, I'll leave that one_liner one more post I thought, then you beat me to it

Do you have a serial port or a USB to serial converter on your computer?

On this M/C a DELL, I have only USB's. On my old pc I have two USB ports and a serial port on the back going spare.

Quick question:

When I built that last circuit (VDD/10k resistor/GPIO.5/button/gnd) it worked. When the button ON gpio.5 was pressed the GPIO.0 LED lit (most of the time 90%+). On some occations however the LED didn't latch on or off. I'm thinking switch de-bouncing was the problem. Is there a way of making the switch work 100% of the time? Maybe BUTTON.

Dave

[HenrikOlsson]

Hi Dave,
Yes the switch probably bounced so it did toggle on then off again before you could see it. Or, you happend to press (and release) the button during the 25ms pause which in case means the program misses the button-press.... Or you pressed it and held it longer than 25ms (quite likely) so that when the program "came around" the button was still pressed so it toggled the LED again....

I'd try lowering that first pause a bit or remove it completely and instead add a pause after the TOGGLE GPIO.0 statement to remove any debounce. Then I'd make the program check that the button was released again before jumping back to Not_Pressed But remeber what happens with the interrupt latency when you're using things like Pause etc.

The BUTTON command is another posibillity but to be honest I don't know exactly how it works internally so I can't say what impact it will have on your interrupt latency.

Side note: You can assign aliases to the port pins (or any variable, register, bit etc). So you can do something like:

myButton VAR GPIO.5
LED_1 VAR GPIO.0
LED_2 VAR GPIO.2

If myButton = 0 then....
....
....

/Henrik.

[mackrackit]

What Henrik said....
I have not used the button command either.
To do a check on the button, if the button is pressed the code would GOSUB to a routine to check if the button is still pressed, then return with that info one way or the other.

But... While we are one the subject of interrupts and GPIO5 is on the pin it is.
Look at Interrupt On Change.

In the mean time find a serial cable to connect to your PC and your board. We will get back to communications later.

Play with the switch problem for now.

[LEDave]

Hi Henrik,

But remember what happens with the interrupt latency when you're using things like Pause etc.

I do indeed remember. So as a rule of thumb, are pauses to be avoided in a program whenever possible or only when using INTERRUPTS.

Dave

[mackrackit]

Hi Henrik,



I do indeed remember. So as a rule of thumb, are pauses to be avoided in a program whenever possible or only when using INTERRUPTS.

Dave

In my opinion everything has a place. But most times it is best to avoid long pauses. If you need to pause for a long time setup a pause loop with several short pauses to total the time. Get into that habit and when you do need to use an interrupt you will be ready.

[LEDave]

If you need to pause for a long time setup a pause loop with several short pauses to total the time. Get into that habit and when you do need to use an interrupt you will be ready.

I can go with that. I liked Henrik's microsecond pauses solution to the INTERRUPT PAUSE problem, which is what your'e saying / reiterating.

Regarding the cable, this isn't what I'm looking for is it? It's the other that needs to be a 'male' connecter is that right?

http://www.maplin.co.uk/module.aspx?moduleno=29968

[mackrackit]

Yup. That will work. Then you need a DB9 female connector that you can solder wires on to go to your dev-board.

[mackrackit]

Dave,
What chips do you have availabe to use?
Did you get any new types?

[LEDave]

I've got 4x12F683 1x12F675 & 2X16F684

The 684 I was / am going to use half of PORTA & PORTC to drive a seven segment display. The first program was just to spell my name DAUE. I got to A then ran out of free code.

I really must buy the PRO_version. Mecanique is the place to buy it from in the UK right?

Dave

[mackrackit]

Buy it from Lester. He is the one that gave us this forum.
http://www.picbasic.co.uk/