12f675_fuse_about_to_blow!

**mackrackit** · - 9th November 2010, 00:26

The short answer about the pre-amble is it sets up the receiver hardware with data that is not noise so when the remainder of the data comes in, in our case the SYNCH, the SYNCH byte is easily detected from noise.... The receiver hardware acts on it but not the receiver code.
SYNCH is for software
PRE-AMBLE is for hardware
Something like that.

The long answer.
http://davehouston.net/RFTipsTricks.htm

**LEDave** · - 9th November 2010, 00:54

Hi mackrackit, thanks for the reply.

I'll settle for the short answer right now (I'm off to bed in a mo) and read the long answer tomorrow.

Dave

**LEDave** · - 13th November 2010, 22:02

Bruce's program is very well documented, it would be good to know I'm reading how to put the PIC to sleep and wake on interrupt. Am I on the right lines here?

Code:

INTCON = %00001000  ' Enable port change wakeup from sleep

Setting INTCON REG bit 3 to 1 enables the GPIO port change interrupt, the interupt flag is set on INTCON REG bit 0. (I'm thinking bit.0 is now logic 1 until cleared.)

Code:

IOC = %00011000     ' Wakeup on change enabled for GPIO.3,4

Setting the IOC pins 3 / 4 (button presses) to logic 1 (goes low when button pressed).

Code:

Main:    
    ' Read port to clear missmatch, if with no buttons pressed, then
    ' clear int-on-change flag & snooze until wake up on change. This
    ' conserves battery power on the demo board with 3V coin cell.
    IF (GPIO.3=1) AND (GPIO.4=1) THEN ' pins will be 0 only when buttons are pressed
     E_OUT=0         ' Disable transmitter
     INTCON.0 = 0    ' No buttons down, so clear int on change flag
     @ SLEEP         ' and start snoozin..zzzzzzzzzzz
     @ NOP           ' Do nothing for 1st instruction on wake-up
    ENDIF
    E_OUT=1          ' Enable transmitter (+ lights RFEN LED on demo board)
    PAUSEUS 25       ' Allow RF stage to stabilize

So if no button is pressed:
1/ GPIO.3 / 4 stay high
2/ E_OUT=0 the transmitter (SYMBOL E_OUT = GPIO.5 ' RF transmitter enable output) stays off.
3/ INTCON.0 = 1 changes to INTCON.0 = 0 (software reset)
4/ @ SLEEP (The PIC goes to sleep, no time value set).
5/ @ NOP (I'll take as per NOP above, I couldn't find anything on this in the manual).

If buttons on GPIO.3/4 are pressed then the program continues....... As I will tomorrow.

How does this look?

Dave

**mackrackit** · - 14th November 2010, 04:54

3/ INTCON.0 = 1 changes to INTCON.0 = 0 (software reset)

INTCON.0 will only "=1" when one of the IOC pins change state. The code makes sure the "trigger" is set before sleeping. I think you got that though.

5/ @ NOP (I'll take as per NOP above, I couldn't find anything on this in the manual).

No Operation... I am here but I ain't doing nothing.
Look to the data sheet under Instruction Set Summary. The ASM instructions are found there.

Looks like you have been studying

**LEDave** · - 14th November 2010, 16:11

Cheers mackrackit, I was pretty close then-ish.

I think I've got the whole sequence now:

INTCON REG bit 3 set to 1 enables the INTCON REG flag bit 0. Bit 0 changes 'flags' when a button is pressed which is controlled by ( IOC = %00011000 - the buttons in effect)

It was this line from the program that threw me:

Code:

INTCON.0 = 0    ' No buttons down, so clear int on change flag

I originally thought that if no buttons were down then INTCON.0 = 0 so there was no flag to clear but on reading Bruce's:

' No buttons down, so clear int on change flag

made me think it must be set to '1'.

Thanks for the explanation.

Dave

**mackrackit** · - 14th November 2010, 16:22

Sometimes it is hard to say. From the data sheet.

bit 0 GPIF: Port Change Interrupt Flag bit
1 = When at least one of the GP5:GP0 pins changed state (must be cleared in software)
0 = None of the GP5:GP0 pins have changed state

If one of the two buttons were down and the other up when the bit was cleared,( made zero), then releasing one OR pushing the other will cause the flag to be set, (bit 0 = 1) , just looking for a change, any change.

**LEDave** · - 14th November 2010, 17:11

Thanks for that mackrackit, I think I'm there now

Just as an aside here, when I first started PIC programming in February I think it was, I never thought I'd ever figure out how any of the registers worked. I think I'm slowly getting there now though.

So the last bit of program from the Main: section was:

Code:

ENDIF
    E_OUT=1          ' Enable transmitter (+ lights RFEN LED on demo board)
    PAUSEUS 25       ' Allow RF stage to stabilize

Which is GPIO.5 RF transmitter enable output (SYMBOL E_OUT = GPIO.5).

So the next part is the Encoding. I've got an idea on how this works (but not the full picture), I'll post up later.

Dave

**LEDave** · - 14th November 2010, 21:45

I've just spent two hours working on a post which I'm not going to post for the minute.

However Question:

How does:

Code:

DAT_OUT.0[1]

work? Or were do I look for the solution, is it in the manual? (I'd rather try and find the answer) if I can't I'll ask

The whole piece of code is:

Code:

DAT_OUT.0[1]=~GPIO.3

I think the

Code:

~GPIO.3

part simply sends to GPIO.3

From the manual:

If you don't want MicroCode Studio to interpret a control sequence, but rather send it as normal characters, then just use the tilda symbol (~) in front of the $ or # symbol. For example, letter ~#9712345 would be sent as letter #9712345.

Have I got that bit right?

Dave

**mackrackit** · - 14th November 2010, 22:04

(I'd rather try and find the answer) if I can't I'll ask

COOL!!!

"~" Look at the table under Math Operators 4.17 in the PBP manual.

And these may help.
http://www.picbasic.co.uk/forum/showthread.php?t=544
http://www.picbasic.co.uk/forum/show...1955#post91955
http://www.picbasic.co.uk/forum/show...&p=189#post189

You may want to set up a little test program and send values to a LCD or something to play with this.

**LEDave** · - 14th November 2010, 23:06

You may want to set up a little test program and send values to a LCD or something to play with this.

I will, the LCD's been looking a little lonely lately. I'll let you know how I get on.

Cheers mackrackit, you're a star.

**LEDave** · - 14th November 2010, 23:52

Code:

~ Bitwise NOT

So it's a Bitwise NOT then (well I've never heard of that one before, I'll get straight on it)

And not:

If you don't want MicroCode Studio to interpret a control sequence, but rather send it as normal characters, then just use the tilda symbol (~) in front of the $ or # symbol. For example, letter ~#9712345 would be sent as letter #9712345.

Like I thought it was. I can be almost dangerous with my assumptions sometimes

Dave

**HenrikOlsson** · - 15th November 2010, 06:21

Hi Dave,
I'm jumping in here.... The docs you've quoted is the docs for MicroCodeStudio, specifically its built in terminal emulator where the ~ means what you've quoted.

But in the PBP language ~ means bitwise NOT, negate or invert - whatever you like.

Code:

GPIO.0 = ~GPIO.1       'Set GPIO.0 to the inverted state of GPIO.1

/Henrik.

**LEDave** · - 15th November 2010, 20:31

Hi Henrik,

Yes, NOT GATE or inverted output, here's a Wiki link for any other newbies:

http://en.wikipedia.org/wiki/Inverter_(logic_gate)

Like I said in my post above, it's easy to jump to the wrong conclusions(that's why I appreciate your and mackrackit's help so much)

Speaking of help, I blew the dust of the old LCD and ran a modified program from mackrackits link:

Code:

MyVAR VAR BYTE
Mybyte var byte
Mybit VAR bit

LET MyByte = 7

For MyVar = 0 to 7
MyBit = MyByte.0(MyVar)
LCDOut $FE,1,"Bit ",#MyVar,"=",#MyBit
Pause 2000
Next MyVar

When I ran it, Bits 0-1-2 were 1's the rest 0's following the pattern for Bin 7

. So onto Bruce's code below:

Code:

' Only DAT_OUT bits 1 and 2 are used. We add a few 1's in bit
    ' positions 0,3,5,7 to balance out the data packet being sent.
    DAT_OUT = %10101001
    ' Get data on button inputs & invert 0's to 1's
    DAT_OUT.0[1]=~GPIO.3
    DAT_OUT.0[2]=~GPIO.4
    INTCON.0 = 0  ' Clear int on change flag
      
    ' Build checksum of 2 data bytes
    CHK_SUM = (DAT_OUT * 2)

Well the checksum would be two BYTES of:

Code:

DAT_OUT = %10101001

With bits 1 & 2 being 0's (not inverted).....I think.

Code:

DAT_OUT = %10101001  DAT_OUT.0[1]=~GPIO.3 DAT_OUT.0[2]=~GPIO.4

Would mean (I think again) bit 1 & 2 would invert to a 1 in the DAT_OUT_BYTE. Or saying that maybe it's only bits 1 & 2 that are inverted and sent. Mm, not sure but I'll go with the first option.

Tin hat on, duck, am I close? (if not, just say so and I'll carry on thinking / reading).

Dave

**mackrackit** · - 16th November 2010, 02:54

Tin hat on

I wear one made of aluminum foil...

Code:

IF (GPIO.3=1) AND (GPIO.4=1) THEN

Because of this both bits in question are "1" when not pressed. So they will invert to "0".
If the thing was not sleeping that is.

But wait...

Code:

DAT_OUT = %10101001

They are "0"...

What if one of the buttons are pressed?

In the end, all eight bits of DAT_OUT are sent.

Yes, I am being a cryptic smart _ _ _.

**LEDave** · - 16th November 2010, 15:42

I wear one made of aluminum foil...

Spoken like a true engineer, even uses a ground plane as a hat

Yes, I am being a cryptic smart _ _ _

Well I know what I'll be doing tonight.... uncryptifying!

Dave

**LEDave** · - 17th November 2010, 17:11

It's looking like I'm going to need someone to hold my hand and gently walk me through this one as I'm confusing myself: Here's my latest piece of reasoning / thinking.....

Right then:

This is the data BYTE to be sent.

Code:

 DAT_OUT = %10101001

Bruce says:

Only DAT_OUT bits 1 and 2 are used.

So at the moment they're 0 - 0.

So I'm going to leap in here and say that from the code below DAT_OUT.0[1] (bit one of the BYTE) will be equal to the inverted state of GPIO.3 (the program only gets to this piece of code after a button press though).

Code:

DAT_OUT.0[1]=~GPIO.3

And DAT_OUT.0[2] (bit two of the BYTE) will be equal to the inverted state of GPIO.4

Code:

DAT_OUT.0[2]=~GPIO.4

So taking SW1 as the button being pressed: GPIO.3 which was '1' when not pressed goes to '0' when pressed then gets inverted ~ to a '1' which becomes bit one of the BYTE.

How does that sound? North of the North pole? South of the South South pole? Or under the ice at either pole?

Dave

**mackrackit** · - 17th November 2010, 21:04

I'm going to need someone to hold my hand

So taking SW1 as the button being pressed: GPIO.3 which was '1' when not pressed goes to '0' when pressed then gets inverted ~ to a '1' which becomes bit one of the BYTE.

Yup, you got it!

**LEDave** · - 17th November 2010, 21:26

I'm going to need someone to hold my hand

Well metaphorically speaking, I was beginning to panic figuring the code out.

So am I right in thinking that the DAT_OUT byte:

Code:

 DAT_OUT = %10101001

Becomes:

Code:

 DAT_OUT = %10101011

When SW1 is pressed.

And

Code:

 DAT_OUT = %10101101

When SW2 is pressed.

The checksum:

Code:

' Build checksum of 2 data bytes
    CHK_SUM = (DAT_OUT * 2)

Will that always be the calculated value of BYTE:

Code:

DAT_OUT.0[2]=~GPIO.4

Because this is the last BYTE to be read / run in the program sequence.

Dave

**mackrackit** · - 17th November 2010, 21:58

So am I right in thinking that the DAT_OUT byte:

Yes, you have all of that correct.

CHECKSUM..

Because this is the last BYTE to be read / run in the program sequence.

We are dealing with BITs here.

Code:

    DAT_OUT.0[1]=~GPIO.3  'BIT #1 of DAT_OUT
    DAT_OUT.0[2]=~GPIO.4  'BIT #2 of DAT_OUT

Back to what you have above that either BIT#1 or BIT#2 will be changed when a switch is pressed, DAT_OUT will be either
%10101011
or
%10101101
So...
CHK_SUM = (DAT_OUT * 2)
Will be
CHK_SUM = (%10101011 * 2)
or
CHK_SUM = (%10101101 * 2)

**LEDave** · - 17th November 2010, 22:31

We are dealing with BITs here.

The penny has finally dropped

So the checksum is made up of:

Code:

DAT_OUT = %10101001 Plus the BIT that has changed *2

Cheers mackrackit, I need a lie down, I expect you do too:

I don't know how you put up with me sometimes.

Dave

**mackrackit** · - 17th November 2010, 22:56

I don't know how you put up with me sometimes.

I remember asking that same question to a couple of folks. And I imagine you will also hear that same question.

**LEDave** · - 17th November 2010, 23:17

I remember asking that same question to a couple of folks. And I imagine you will also hear that same question.

You know I really wish I was clever enough to help folk out, one day perhaps, one day.

Well here's some good news. That's the TX program covered and believe it or not I've got a pretty good idea of how it all works

Thing is, have you seen the RX program

So where to next mackrackit? Should I start modifying the TX - RX programs to send a 'TEST' BYTE out and receive it to simulate the Bird_Daily_Count_Total?

Or start working through the RX program?

Dave

**mackrackit** · - 17th November 2010, 23:32

Or start working through the RX program?

Might be a good idea to run through it. ASM is not my strong point, but Bruce has plenty of comments there.

Just to be sure we are looking at the same code, here is what I have.

Code:

'****************************************************************
'*  Name    : rfPIC_RX.BAS                                      *
'*  Author  : B. Reynolds                                       *
'*  Notice  : Copyright (c) 2007 Reynolds Electronics           *
'*          : All Rights Reserved                               *
'*  Date    : 10/09/2007                                        *
'*  Version : 1.0 (Momentary decoder version)                   *
'*  Notes   : 2-Bit decoder for Microchip RF dev system         *
'*          : with rfRXD0420 module installed in PICkit 1 board *
'****************************************************************
@ DEVICE PIC16F676,MCLR_OFF,INTRC_OSC_NOCLKOUT,WDT_OFF,BOD_OFF
@ DEVICE PWRT_ON,PROTECT_OFF

    DEFINE OSC 4
    DEFINE NO_CLRWDT 1      ' Watchdog timer is disabled, so we don't need to reset it
    DEFINE OSCCAL_1K 1      ' load factory calibration value
    DEFINE INTHAND RESET_VT ' Interrupt on Timer1 overflow to reset outputs in 65.5mS
                            ' if no serial data received in this time period
    SYMBOL  D_IN = PORTC.1  ' data input pin
    SYMBOL  TMR1IF = PIR1.0 ' Timer1 overflow interrupt flag (reset in int handler)
    SYMBOL  TMR1IE = PIE1.0 ' Timer1 interrupt enable bit

    'Variables for saving state in interrupt handler
    wsave   VAR BYTE $5F system    ' Saves W
    ssave   VAR BYTE bank0 system  ' Saves STATUS
    psave   VAR BYTE bank0 system  ' Saves PCLATH
    fsave   VAR BYTE bank0 system  ' Saves FSR

    ' Working variables
    MATCH     VAR BYTE bank0 system ' Match variable
    DAT_OUTB  VAR BYTE  ' Holds decoded data for output
    DAT_IN1   VAR BYTE  ' 1st Data byte
    DAT_IN2   VAR BYTE  ' 2nd Data byte for verify
    CHK_SUM   VAR BYTE  ' Holds checksum received
    CheckSum  VAR BYTE  ' Computed checksum of all bytes received
    LOOPS     VAR BYTE  ' Loop var

    ' Constants
    Synch    CON "~"    ' 01111110 synch byte
    N2400    CON 16780  ' 2400 bps inverted
    N4800    CON 188    ' 4800 bps inverted

     ' hardware init
    PORTA = 0
    TRISA = %00111001   ' RA1 and RA2 are LED outputs
    PORTC = 0           ' Clear outputs on power-up
    TRISC = %00111110   ' RC1 = RF input
    IOC = 0             ' Interrupt on change disabled
    VRCON = 0           ' Comparator Vref disabled
    CMCON = 7           ' Disable comparators
    ANSEL = 0           ' disable A/D
    OPTION_REG = 128    ' Pull-ups off

    ' Setup Timer1 for resets after ~65.5mS
    T1CON = %00000000   ' Internal clock, 1:1 prescale, Timer1 off for now
    TMR1L = 0
    TMR1H = 0           ' Timer1 low & high bytes cleared
    TMR1IF = 0          ' Clear Timer1 overflow flag before enabling interrupt
    TMR1IE = 1          ' Enable Timer1 overflow interrupt
    INTCON = %11000000  ' Global & peripheral ints enabled
    MATCH = 0           ' Clear match count
    GOTO    MAIN        ' Jump over int handler

ASM  ; Timer1 overflow interrupt resets outputs when no valid key press
     ; is detected within ~65mS
RESET_VT
    movwf  wsave         ; Save W
    swapf  STATUS, W     ; Swap STATUS to W (swap avoids changing STATUS)
    clrf   STATUS        ; Clear STATUS
    movwf  ssave         ; Save swapped STATUS
    movf   PCLATH, W     ; Move PCLATH to W
    movwf  psave         ; Save PCLATH
    movf   FSR, W        ; Move FSR to W
    movwf  fsave         ; Save FSR

    ; Do interrupt stuff here
    bcf    T1CON,TMR1ON  ; Stop Timer1
    clrf   TMR1L         ; Clear low byte
    clrf   TMR1H         ; Clear high byte
    bcf    PIR1,TMR1IF   ; Clear Timer1 interrupt flag bit
    clrf   PORTA         ; Clear outputs on button release
    clrf   MATCH         ; Clear match variable

    ; Restore FSR, PCLATH, STATUS and W registers
    movf    fsave, W     ; retrieve FSR value
    movwf   FSR          ; Restore it to FSR
    movf    psave, W     ; Retrieve PCLATH value
    movwf   PCLATH       ; Restore it to PCLATH
    swapf   ssave, W     ; Get swapped STATUS value (swap to avoid changing STATUS)
    movwf   STATUS       ; Restore it to STATUS
    swapf   wsave, F     ; Swap the stored W value
    swapf   wsave, W     ; Restore it to W (swap to avoid changing STATUS)
    bsf     T1CON,TMR1ON ; Re-enable Timer1 before exiting interrupt handler
    retfie               ; Return from the interrupt
ENDASM

MAIN:
    ' Fire up Timer1 before entry to serial input routine
    T1CON.0 = 1

    ' at 4MHz Timer1 overflows in 65536 * 1uS (~65.5mS) if no Synch byte
    ' and serial data arrive on time. SERIN2 timeout & label options
    ' are useless with a noisy RF receiver output - as noise continually
    ' resets the timeout period causing it to hang forever.

    ' Wait for Synch byte, then get new inbound data & checksum
    SERIN2 D_IN,N2400,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM]

    T1CON.0 = 0    ' Stop Timer1 once we've received data
    TMR1L = 0      ' Clear low byte
    TMR1H = 0      ' Clear high byte

    ' / **** Begin data validation **** /

    ' Calculate checksum by adding 2 data bytes together
    CheckSum = DAT_IN1 + DAT_IN2

    ' Test new checksum against one received in CHK_SUM
    IF CheckSum != CHK_SUM THEN MAIN ' Failed checksum, return

    ' Test data bytes for match
    IF (DAT_IN1) != (DAT_IN2) THEN MAIN ' Failed data comparison, return

    MATCH = MATCH + 1        ' We have a match so increment match count
    IF MATCH = 2 THEN DECODE ' Everything matched twice, we're good
    GOTO Main                ' Else do it all over

    ' Everything looking good - so place new data on outputs
DECODE:
    ' Place decoded values on port pins..
    PORTA = DAT_IN1 & %00000110
    DAT_IN1 = !DAT_IN2  ' Destroy the match
    MATCH = 0
    GOTO MAIN

    END

**LEDave** · - 17th November 2010, 23:58

That's the one.

An awful lot of new stuff there. Now I'm thinking should I really jump in and start to learn a little Assembly as well?

That's where I was in February trying to light my first LED.... The rest is history as they say. I remember reading the Microchip stuff saying there was only 35 instruction words to learn (I'm sure I read that somewhere) and thinking to myself "How difficult can that be"......lol.

Well you're getting to know me now mackrackit, slow, not very bright but determined!

I'm game if you are.

Dave

**mackrackit** · - 18th November 2010, 00:17

I think for now being able to read the ASM code enough to understand what is going on will be enough. Then learn how to write some of it later.

Have you done anything with interrupts yet? That is what the ASM is doing in this code.

**LEDave** · - 18th November 2010, 00:33

Have you done anything with interrupts yet? That is what the ASM is doing in this code.

We have touched on it, we did a timing loop interrupt program (it might have been before I bought the full PBP program) so quite a while back .

So where to start then?

**mackrackit** · - 18th November 2010, 00:49

So where to start then?

At the top...

The PBP manual has a section in the back about interrupts in ASM, Read it along with the code.
Basically, when an interrupt is called things have to be saved so the program can pickup where it left off while dealing with the interruption. Have you ever received a phone call and when the call was over forgot what you were doing when the call came in? We do not want the PIC to have that problem.

**LEDave** · - 18th November 2010, 23:40

Have you ever received a phone call and when the call was over forgot what you were doing when the call came in? We do not want the PIC to have that problem.

I've had conversations lately where I've gone off track for a moment and completely forgot the main thread of what I was saying, I think the Interrupt handler in my brain need dubugin

The PBP manual has a section in the back about interrupts in ASM, Read it along with the code.

Page 200 in the manual, I'm reading it and trying to work through the code. Bruce's code is exactly the same well very similar, with the Interrupt block in the middle added.

Thanks for the pointer mackrackit.

Dave

**LEDave** · - 20th November 2010, 23:34

Here's my take on what's going on. From the top:

Code:

T1CON = %00000000

Pre-scale Bits 4 & 5 set at zero for 65536 count - TMR1ON bit zero set to zero (not on).

Code:

TMR1IE = 1

But: TMR1IE = PIE1.0 so PIE1.0 = 1

Code:

INTCON = %11000000

bits 6 & 7 Peripheral & global interrupt bits set.

MAIN:
' Fire up Timer1 before entry to serial input routine
T1CON.0 = 1

So Timer1 bit.0 = 1 Timer1 turned on and count starts........

If the count reaches 65536ms then the Interrupt flag TMR1IF PIR.0 goes to 1 then the program jumps to:

Code:

DEFINE INTHAND RESET_VT

I think this a kind of GOTO ASM in 65.5ms (Timer1) if no data comes in. If data had come in the program would have continued.

Not very well explained I'm afraid, how did I do..........?.....Gulp.

Dave

**mackrackit** · - 21st November 2010, 10:08

Sounds pretty good to me.

A point though..
RESET_VT
inside the ASM part of the code is an ASM label.
DEFINE INTHAND RESET_VT
Tells where to go when the interrupt occurs.

**LEDave** · - 21st November 2010, 14:17

Hi mackrackit.

My mistake, I should have said:

If the count reaches 65536ms then the Interrupt flag TMR1IF PIR.0 goes to 1 then the program jumps to:

Code:

RESET_VT

Not the DEFINE.

So when the program jumps after PIR.0 = 1 to RESET_VT it then runs the Register saving code, then the INTERRUPT routine, then restores all the previously saved values back to exactly the same condition as pre - RESET_VT. Can we come back to that part the ASM stuff later but for now assume there was some DATA received and the next block of PBP code.

Dave

**mackrackit** · - 21st November 2010, 14:35

Can we come back to that part the ASM stuff later but for now assume there was some DATA received and the next block of PBP code.

Yup, sounds like you have the interrupt idea worked out.
On to MAIN...

**LEDave** · - 21st November 2010, 15:51

MAIN:
' Fire up Timer1 before entry to serial input routine
T1CON.0 = 1

So the Timer1 is running and we've got 65.5ms to receive the data.

I guess a question here would be how fast does a PIC receive DATA? At the moment we're only receiving the SYNCH - DAT_IN1 - DAT_IN2 & CHK_SUM BYTES. If for example when the project is running and we send accumalative Bird Box Visit_Data (day1 + day2 etc.....n) then after a Month we'd have 30 Bytes or Words even, would that time_out? Because as the program stands:

Code:

T1CON.0 = 0

After the Data has arrived.

Anyway moving on.

So the Data has arrived:

Code:

SERIN2 D_IN,N2400,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM]

Then:

Code:

 T1CON.0 = 0    TMR1L = 0  TMR1H = 0

So Timer1 is stopped - TMR1H&L BYTES cleared.

Before I carry on with **Begin Data Validaition**

What does the ! in: IF CheckSum ! mean please mackrackit.

Dave

**mackrackit** · - 21st November 2010, 18:22

Manual section
4.18. Comparison Operators
Not equal !=

I guess a question here would be how fast does a PIC receive DATA?

I think once the PIC starts receiving with SERIN2 it will not stop till finished. I will have to check to be.

**LEDave** · - 21st November 2010, 23:08

Manual section
4.18. Comparison Operators
Not equal !=

Cheers mackrackit, thanks for the pointer.

Dave

**LEDave** · - 22nd November 2010, 17:56

Calculate checksum by adding 2 data bytes together

Code:

CheckSum = DAT_IN1 + DAT_IN2

So the CheckSum = (%10101011 * 2 BYTES) if SW1 ( GPIO.3) was pressed.

or (%10101101 * 2 BYTES) if SW2 (GPIO.4) was pressed.

Plus we should have the already have a calculated CHK_SUM that was sent.

So:

Code:

CHK_SUM   VAR BYTE  ' Holds checksum received

And:

Code:

CheckSum  VAR BYTE  ' Computed checksum of all bytes received

Therefore:

Code:

IF CheckSum != CHK_SUM THEN MAIN ' Failed checksum, return

If Checksum (!) is not = CHK_SUM then go back to MAIN the checksum has failed.

The same with:

IF (DAT_IN1) != (DAT_IN2) THEN MAIN ' Failed data comparison, return

The DAT_IN BYTES must also be equal, if not then back to MAIN:

If however everything matches then continue to MATCH..........

How does this look?

Dave

**LEDave** · - 22nd November 2010, 22:14

Another question:

Code:

wsave   VAR	BYTE $5F system	   ' Saves W

Bruce's code talks of Bank0 system. Am I correct in saying that BYTE $5F system is setting bit.5 of the STATUS REG to 0 which is selecting Bank0 ($5f = %1011111).

So to change from Bank0 to Bank1 would be %1111111

Also:

Code:

movwf  wsave	 ; Save W

So these commands mean Move the contents of the W REG to the address of wsave.

Mm, not really sure about this............(more reading to do).

Dave

Dave

**mackrackit** · - 22nd November 2010, 23:31

The DAT_IN BYTES must also be equal, if not then back to MAIN:

If however everything matches then continue to MATCH..........

How does this look?

I think you got that part down.

Bruce's code talks of Bank0 system. Am I correct in saying that BYTE $5F system is setting bit.5 of the STATUS REG to 0 which is selecting Bank0 ($5f = %1011111).

So to change from Bank0 to Bank1 would be %1111111

Like I said, ASM is not my strong point. Not sure I have a strong point...
Below tells how to change banks, I think.

Code:

If the PICmicro has more than 2K of code space, an interrupt stub is automatically added that saves the W, STATUS and PCLATH registers into the variables wsave, ssave and psave, before going to your interrupt handler. Storage for these variables must be allocated in the BASIC program:

	wsave  var	        byte $20 system
	wsave1 var	byte $a0 system		' If device has RAM in bank1
	wsave2 var	byte $120 system	' If device has RAM in bank2
	wsave3 var	byte $1a0 system	' If device has RAM in bank3
	ssave    var	byte bank0 system
	psave    var	byte bank0 system

Code:

movwf  wsave	 ; Save W

So these commands mean Move the contents of the W REG to the address of wsave.

Yes.
Also notice that all of the data is restored in the opposite sequence it was saved.

If I am giving wrong ASM info , somebody please jump in and correct me!

**LEDave** · - 22nd November 2010, 23:55

Hi mackrackit,

Not sure I have a strong point...

Hey, you put up with me, so patience is one of them

And don't forget it was trying to turn an LED on using ASM that after a near breakdown put me onto PBP

I'll go onto MATCH & DECODE tomorrow, slowly getting there (slowly).

Dave

**LEDave** · - 23rd November 2010, 14:37

It still doesn't take much to stump me I'm afraid........

Code:

 MATCH = MATCH + 1        ' We have a match so increment match count
    IF MATCH = 2 THEN DECODE ' Everything matched twice, we're good
    GOTO Main                ' Else do it all over

When the Timer was set up for a 65ms reset we had:

Code:

MATCH = 0           ' Clear match count

Then the SYNCH_BYTE & DATA etc arrived and everything was good giving:

Code:

MATCH = MATCH + 1        ' We have a match so increment match count

So to my mind that makes MATCH = 0 +1 ie 1.

But then we have:

Code:

 IF MATCH = 2 THEN DECODE ' Everything matched twice, we're good

So either the data arrives twice within the 65ms time period to move onto DECODE or my understanding of MATCH = MATCH + 1 is wrong.

Help!

Dave

Thread: 12f675_fuse_about_to_blow!

Thread Tools

Search Thread

Display

Members who have read this thread : 1

Bookmarks

Bookmarks

Posting Permissions