using 9600 bps, i have read that 1 bit should take 104 uS and half of that 52 uS. i'm confused why 0x0c was used and 0x18 since when we converted these two to dec they give the value of 12 and 24. What's going on?
The loop takes 4 cycles to execute and is executed 24 times = 96 cycles. Plus 2 cycles for the initialisation, plus 4 for the call .. return. And I assume some overhead in the calling routine will all add up to around 104 cycles.
The loop takes 4 cycles to execute and is executed 24 times = 96 cycles. Plus 2 cycles for the initialisation, plus 4 for the call .. return. And I assume some overhead in the calling routine will all add up to around 104 cycles.
It's 4 cycles because the first 2 instructions take 1 cycle each and the goto takes 2. It is executed 24 times because Delay_Count is previously loaded with 0x18 which is 24 decimal. I know this because I studied the data sheet.
i would not put too much effort into hardwired code, unless you want a reference design or want to save costs.
normally PIC with integrated serial port would be used, or at least, timing will be derived from interrupt/TIMER register.
hardwired code is difficult to maintain. it may work in the end but unless you know exactly what you are doing you make your life more difficult than neccessary.
personally I almost never use hardwired delay, execept to insert a few NOPs.
90% of all PIC programs do not consider* the exact number of cycles (while of course they consider the number of TIMER cycles, and interrupts).
or at least, a majority of advanced user's programs.
*this is made up but also on PC the only language which is using such delays is old MS-DOS based BASIC. now replaced with software timers.
however, you should also feel free to use whatever technique you want, and not to rely legally binding on my advice.
i would not put too much effort into hardwired code, unless you want a reference design or want to save costs.
normally PIC with integrated serial port would be used, or at least, timing will be derived from interrupt/TIMER register.
hardwired code is difficult to maintain. it may work in the end but unless you know exactly what you are doing you make your life more difficult than neccessary.
personally I almost never use hardwired delay, execept to insert a few NOPs.
90% of all PIC programs do not consider* the exact number of cycles (while of course they consider the number of TIMER cycles, and interrupts).
or at least, a majority of advanced user's programs.
*this is made up but also on PC the only language which is using such delays is old MS-DOS based BASIC. now replaced with software timers.
I would disagree entirely, by using software delays, and software UART's it gives you far more choice - you're not restricted to particular pins for a UART, and you can have multiple UARTs if you need them. As for software delays, they are far more versatile and often more accurate than using timers - you can adjust software delays to give timing to one instruction cycle, you can't do that with timers.
Using in-build hardware has it's uses, and for some purposes a hardware UART is absolutely essential - but getting 'hung up' on using the hardware when it offers no advantage (and often is a disadvantage) isn't a good idea.
Evaluate each task individually, and decide which method provides the best solution for that particular task.
yes Nigel Goodwin, but DELAY will lock up the PIC, while TIMER won't.
that's what i wanted to say.
if you must refresh a display (for instance) you can not delay too long, not even one 1/100 second. some approaches do not use 20 MHz or even 4 MHz but just 500 KHz, for instance in order to save power.
As you explain, each case should be considered carefully.
yes Nigel Goodwin, but DELAY will lock up the PIC, while TIMER won't.
that's what i wanted to say.
if you must refresh a display (for instance) you can not delay too long, not even one 1/100 second. some approaches do not use 20 MHz or even 4 MHz but just 500 KHz, for instance in order to save power.
As you explain, each case should be considered carefully.
Yes - but the obvious solution to that is a timer interrupt - simple delays, even using a timer, sit in a loop waiting for it to time out. In that case there's no advantage in using a timer, and plenty of disadvantages.
lets just say rb0 was high. so next instruction "bcf status,c" is skipped. since rb0 is high "btfsc porta,0x00" instruction will cause execution of next line which is setting status bit 0 to 1. and this is the part i don't get. the line "rrf rcv_byte,f"
the way i see it. rcv_byte value is eight zeros (00000000). when rrf line get executed the value of c was appended to rcv_byte, starting from left.