Search:

What those two chips have in common is auto context save for interrupts.
i simulated the 1824 and the problem was not experienced, but who would trust a simulator



try this for...

125KHz is [COLOR=#333333]only available with a pbpl compile

from the manual hpwm section



every chip you have posted about on this subject is quite capable of that output.
your posted code...

why would the uart need a TMR1 interrupt ?

code ?

your understanding is flawed and math is incorrect

Duty is Steps x 0.625% // steps = CCPR1L x4 + CCP1CON<5:4>

so:
80x0.625% = 50% <=> steps = 20x4 + 0
56x0.625% = 35% ...

totally missing the point

CCPR1L = $14 not 14 ; its hex 14 or dec 20

maybe more like duty cycle of 2.8us/8us * 100 = 35%




or correctly
' To get a 50% duty cycle output,
CCPR1L to $14 and CCP1CON<5:4> to <0:0>.

from the data sheet, my best guess . i see no attempt to read portb before sleep

You need to travel back in time ten years , last known semi workable setup was with mplabx 2.35

i would not expect to ever receive a malformed bit from a keeloq serial stream , the data may be useless however.
single point sampling should be ok imho

in simple terms adding the two's compliment of a var to a number is equivalent to subtracting the var from a number
providing they are all the same integer var type

In a noisy environment you can over sample a bit to be sure of data validity, i expect the serial data from a keeloq
chip to be quite clean so a single sample point would suffice

sample...

a couple of ways


pulsetrain:
index=67
while index
while !portb.0 :wend ;wait for hi
index=index-1
pauseus 600 ;bit period=3*te ie 3*400=1200uS
code.0[index]= ~...

result of sim
9225

maybe but it has positive indication of failure , it ceases testing on failure and it actually detects failures.
i would not be quibbling over a few words of code space when the entire process of...

i would do it this way




sample_data var byte[32]
fail var bit
sample var byte
a_one var byte
a_zero var byte

so a command is *99 or *9 or *09 [where 9 == a numeric digit]
and a parameter is 9 up to 999999

how do you signal that the command has been input and the parameter begins

i would be...

where did you get that idea, it is very possible with the correct syntax

suggest a read of the manual re

Applying Offsets to Bits within a Variable or Register

ask yourself

what is the biggest command sequence that will be input ?
how does the pic know when the input seq is complete ?

when you know those answers then the answer will be obvious

its best to be correct for future reference , not all i2c devices are so forgiving

as maybe but you are still incorrect , if you use a logic analyzer you will see the transaction ends abnormally



wrong way
i2cwrite ldta, lclk, adr, cnt
correct way
i2cwrite ldta, lclk,...

not in my view
addr var byte
addr= $46
i2cwrite sda,sck,addr,[opecode]
i2cread sda,sck,addr,[dat.highbyte,dat.lowbyte]

9x2x8 lcd "command delays" per text line is probably the worst delay
your snippet lacks that exact detail


the st7920 chip has a spi i/f that's a little faster and uses less pins too

there...

its called two's compliment , no magic involved

https://en.wikipedia.org/wiki/Two%27s_complement

each and every i2c command has incorrect syntax

only if you interpret it incorrectly and ignore the sign bit



show your code