12f675_fuse_about_to_blow!

Printable View

Show 40 post(s) from this thread on one page

- 9th November 2010, 00:26
mackrackit

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
- 9th November 2010, 00:54
LEDave

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
- 13th November 2010, 22:02
LEDave

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
- 14th November 2010, 04:54
mackrackit

Quote:

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.

Quote:

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 :)
- 14th November 2010, 16:11
LEDave

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:

Quote:

' No buttons down, so clear int on change flag

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

Thanks for the explanation.

Dave
- 14th November 2010, 16:22
mackrackit

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

Quote:

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.
- 14th November 2010, 17:11
LEDave

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.:D

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
- 14th November 2010, 21:45
LEDave

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:

Quote:

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
- 14th November 2010, 22:04
mackrackit

Quote:

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

:D 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.
- 14th November 2010, 23:06
LEDave

Quote:

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.
- 14th November 2010, 23:52
LEDave

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:

Quote:

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:eek:

Dave
- 15th November 2010, 06:21
HenrikOlsson

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.
- 15th November 2010, 20:31
LEDave

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
- 16th November 2010, 02:54
mackrackit

Quote:

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 _ _ _. :)
- 16th November 2010, 15:42
LEDave

Quote:

I wear one made of aluminum foil...

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

Quote:

Yes, I am being a cryptic smart _ _ _:D

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

Dave
- 17th November 2010, 17:11
LEDave

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:

Quote:

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
- 17th November 2010, 21:04
mackrackit

Quote:

I'm going to need someone to hold my hand

:eek:

Quote:

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!
- 17th November 2010, 21:26
LEDave

Quote:

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
- 17th November 2010, 21:58
mackrackit

Quote:

So am I right in thinking that the DAT_OUT byte:

Yes, you have all of that correct.

CHECKSUM..

Quote:

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)
- 17th November 2010, 22:31
LEDave

Quote:

We are dealing with BITs here.

:o

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: :eek:

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

Dave
- 17th November 2010, 22:56
mackrackit

Quote:

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.
- 17th November 2010, 23:17
LEDave

Quote:

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:cool:

Thing is, have you seen the RX program:eek:

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
- 17th November 2010, 23:32
mackrackit

Quote:

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
- 17th November 2010, 23:58
LEDave

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
- 18th November 2010, 00:17
mackrackit

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.
- 18th November 2010, 00:33
LEDave

Quote:

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?
- 18th November 2010, 00:49
mackrackit

Quote:

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.
- 18th November 2010, 23:40
LEDave

Quote:

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:eek:

Quote:

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
- 20th November 2010, 23:34
LEDave

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.

Quote:

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
- 21st November 2010, 10:08
mackrackit

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.
- 21st November 2010, 14:17
LEDave

Hi mackrackit.

My mistake, I should have said:

Quote:

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
- 21st November 2010, 14:35
mackrackit

Quote:

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...
- 21st November 2010, 15:51
LEDave

Quote:

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
- 21st November 2010, 18:22
mackrackit

Manual section
4.18. Comparison Operators
Not equal !=

Quote:

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.
- 21st November 2010, 23:08
LEDave

Quote:

Manual section
4.18. Comparison Operators
Not equal !=

Cheers mackrackit, thanks for the pointer.

Dave
- 22nd November 2010, 17:56
LEDave

Quote:

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:

Quote:

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
- 22nd November 2010, 22:14
LEDave

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
- 22nd November 2010, 23:31
mackrackit

Quote:

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.

Quote:

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

Quote:

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!
- 22nd November 2010, 23:55
LEDave

Hi mackrackit,

Quote:

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:D

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

Dave
- 23rd November 2010, 14:37
LEDave

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

Show 40 post(s) from this thread on one page